From simonpj at microsoft.com Mon Jan 1 12:45:08 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Jan 1 12:41:35 2007 Subject: Coverage Condition fails In-Reply-To: <4596F570.3060202@iee.org> Message-ID: The coverage condition is described in the paper http://research.microsoft.com/~simonpj/papers/fd-chr Use -fallow-undecidable-instances to make it compile. Simoin | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Adrian Hey | Sent: 30 December 2006 23:26 | To: glasgow-haskell-users@haskell.org | Subject: Coverage Condition fails | | Hello folks, | | Could somebody explain what a coverage condition is and | what this error message means.. | | "Illegal instance declaration for 'GT (GT2 map1 map2) (k1,k2)' | (the Coverage Condition fails for one of the functional dependencies) | In the instance declaration for 'GT (GT2 map1 map2) (k1,k2)'" | | The offending code looks like this.. | | > -- Generalsed Trie map class | > class Ord k => GT map k | map -> k , k -> map where | | > -- Map type for pairs | > newtype (GT2 map1 map2 a) = GT2 (map1 (map2 a)) | | > -- Which is an instance of GT | > instance (GT map1 k1, GT map2 k2) => GT (GT2 map1 map2) (k1,k2) where | | This is with ghc 6.6. The strange thing is this code used to compile | fine with earlier versions (but I don't know if it actually worked | because I never tested it). | | Thanks | -- | Adrian Hey | | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From ahey at iee.org Tue Jan 2 06:10:39 2007 From: ahey at iee.org (Adrian Hey) Date: Tue Jan 2 06:08:58 2007 Subject: Coverage Condition fails In-Reply-To: References: Message-ID: <459A3DAF.8000007@iee.org> Simon Peyton-Jones wrote: > The coverage condition is described in the paper > http://research.microsoft.com/~simonpj/papers/fd-chr > > Use -fallow-undecidable-instances to make it compile. Thanks, it seems to compile now. I've had a quick look at the paper you mentioned and I also see the latest ghc user guide has something to say about this too. But I'm still not really clear about what the problem is :-( (But I haven't really had time to study the paper properly yet either.) > | > -- Generalsed Trie map class > | > class Ord k => GT map k | map -> k , k -> map where > | > | > -- Map type for pairs > | > newtype (GT2 map1 map2 a) = GT2 (map1 (map2 a)) > | > | > -- Which is an instance of GT > | > instance (GT map1 k1, GT map2 k2) => GT (GT2 map1 map2) (k1,k2) where Intuitively, this looks quite unambigous to me and allowing undecidable anything worries me a bit. It makes me think my code is inherently flakey somehow (not sure how right now though :-). Regards -- Adrian Hey From avatar at hot.ee Tue Jan 2 08:02:27 2007 From: avatar at hot.ee (Misha Aizatulin) Date: Tue Jan 2 07:58:57 2007 Subject: Dumping context reduction steps Message-ID: <459A57E3.6040204@hot.ee> hi, is there some command line switch in GHC that would allow me to see context reduction steps during the compilation? Thanks, Misha From simonpj at microsoft.com Tue Jan 2 09:18:59 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jan 2 09:15:30 2007 Subject: Dumping context reduction steps In-Reply-To: <459A57E3.6040204@hot.ee> References: <459A57E3.6040204@hot.ee> Message-ID: -ddump-tc-trace will probably tell you too much, but that's what I use when I'm trying to peer into GHC's innards. I have not documented its output, because I change it every so often; you'll have to look at the source code. A good little project would be to design a sensible output form for context reduction (only -- ddump-tc prints a lot else). Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow- | haskell-users-bounces@haskell.org] On Behalf Of Misha Aizatulin | Sent: 02 January 2007 13:02 | To: glasgow-haskell-users@haskell.org | Subject: Dumping context reduction steps | | hi, | | is there some command line switch in GHC that would allow me to see | context reduction steps during the compilation? | | Thanks, | Misha | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Tue Jan 2 16:01:12 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jan 2 15:57:36 2007 Subject: Unpacking polymorphic fields In-Reply-To: <20061115195510.5929b46e.aljee@hyper.cx> Message-ID: No, there's no easy way (that I can see) to achieve what you want. The problem is that the way to unpack C depends on how you instantiate 'a'. So you need a specialised variant of the actual data constructor C, one for each instantiation of 'a'. (Well, one for each "shape" of instantiation anyway.) GHC doesn't currently generate specialised data constructors. In principle one could do that, but it's not an easy step. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Takano Akio | Sent: 15 November 2006 10:55 | To: glasgow-haskell-users@haskell.org | Subject: Unpacking polymorphic fields | | Hi, | | Suppose I have the following two datatypes. | | data B = B {-# UNPACK #-} !Int | data C a = C {-# UNPACK #-} !Char !a | | If I have a strict function: | | printB :: B -> IO () | printB (B x) = print x | | test :: C B -> IO () | test (C c b) = print c >> printB b | | | I want it to be worker-wrapper-transformed into: | | $wtest :: Char# -> Int# -> State# RealWorld -> (# State# RealWorld, () #) | | but GHC actually generates something like: | | $wtest :: Char# -> B -> State# RealWorld -> (# State# RealWorld, () #) | | The question is: is there any way to ask GHC to produce the former? | If the field is not polymorphic, UNPACK pragma can be used for this, but | it does not work in this case. If there is no such way, would | it be a reasonable "feature request" to add one? | | Regards, | Takano Akio | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From p.tanski at gmail.com Wed Jan 3 00:35:10 2007 From: p.tanski at gmail.com (Peter Tanski) Date: Wed Jan 3 00:31:43 2007 Subject: Replacement for GMP: Update In-Reply-To: <200612291432.34038.naur@post11.tele.dk> References: <200608242039.03298.naur@post11.tele.dk> <9C3460A9-F708-4928-A203-A649D88CDD72@gmail.com> <200612291432.34038.naur@post11.tele.dk> Message-ID: <4942C1CC-99CB-4371-8E1E-4FC742DA1D83@gmail.com> On Dec 29, 2006, at 8:32 AM, Thorkil Naur wrote: > On Friday 01 September 2006 06:43, Peter Tanski wrote: >> ... >> For a brief overview of the speed of the libraries I looked at >> carefully, see http://hackage.haskell.org/trac/ghc/wiki/ >> ReplacingGMPNotes (I added a few charts to show the speed of >> ARPREC, OpenSSL's BN, GMP and LibTomMath. ....) I tested GMP and >> OpenSSL's BN for reference. > > I must confess that it took me a while to understand what you were > doing here > and I am still uncertain: For example, how many multiplications > were actually > performed for bit size 4096? 4096 = size 4 (counting from zero: sizes[5] = {256,512,1024,2048,4096}) 1,000,000 / ( 4 * 3 ) = 83,333 rounds My reason for doing this was simple: as a basic comparison, rather than an absolute measurement, the number of rounds doesn't matter as long as the results are measurable. Besides, more rounds means more time running each test. I did a lot of tweaking, especially with ARPREC, to get each library to (1) a generally available speed and (2) a configuration similar to what it would be when used with GHC. I could have measured the speed in nanoseconds, with one iteration for each calculation using random numbers of a specified size and posting the mean for a number of trials but that would have required me to use OS-X specific profiling software like Shark in order to get reliable measurements--a bit more labour intensive as it would require me to manually perform each test. (I did use random numbers of a specified size.) > In addition, for "Powers", the markings on the > horizontal axis ("256 pow(n,3)", "512 pow(n,4)", "1024 pow > (n5)" (missing a > "," here?), ...) on your graph seem to indicate that you are > changing two > different variables (the bit size and the exponent) at the same time. Yes, the testing is a bit sloppy there (so is the graph; ugly typo). The graph shows a general trend more than anything else. I actually tested the Exponentials (Powers) individually for each size and timing but posting a 3-D graph or making the graph (time = exponent/ size) seemed like overkill or would conflict with the previous measurements. Not a bad idea, though, just for clarity. > I would suggest that you also quoted the original measurements > directly. And perhaps > (especially in case of the "Powers" and "Division") some more > details about > what was actually measured. I did quote the original measurements directly. There wasn't much variance overall and I took what seemed like median results from a number of tests. What matters is the relative time to initialise and perform each computation since in a GHC-implementation each computation would require some minimal initialisation. ARPREC was built for this and in ARPREC-only tests the major factor in speed of initialisation was the time to compute the architecture and precision- specific constants for PI, Log_2 and Log_10 (the Epsilon constant doesn't require much time). Log_2 and Log_10 are necessary for printing Integers because computations in ARPREC are performed as floating-point values and must converted to decimal digits by multiplying by Log_10. (Note that printing Integers also requires a size increase as the mantissa holds the Integer value, requiring further multiplication by the float-exponent.) Details on differences between algorithms used in each library would be fairly complex: as you already know, each library (ARPREC, GMP, LibTomMath, etc.) uses a different algorithm based on the size of the number-array *and* each may have a different implementation of an algorithm--LibTomMath uses a simpler Karatsuba algorithm, for example. > It is distinctly odd that squaring seems to be more expensive than > multiplication for some bit sizes in 3 of the 4 measured cases. This is also an implementation matter: the particular algorithms change with size and squaring may require some extra initialisation for, say, computing the size of the result and the number of operations. All of the libraries provide special squaring functions and I used those. LibTomMath is a good example: it uses its "baseline" squaring algorithm for small sizes and Comba-optimised Toom-Cook or Karatsuba algorithms for larger sizes. (I purposely did not tune LibTomMath or any of the libraries because I wanted a more- or-less average-case comparison, so the Karatsuba algorithm was used for size=512 bytes (128 digits) and Toom-Cook was used for size=2048 bytes (512 digits).) So where you see LibTomMath's time dip in the middle of the 'Squaring' graph it is using the Karatsuba algorithm. ARPREC uses a FFT for everything above size=256 and calculates with fewer actual digits (it stores extra "size" as an exponent, just like ordinary floating point numbers). The trends in the graphs for ARPREC versus GMP generally hold true until GMP's FFT kicks in, at size > 32768. > Also, I > wonder what divisions these libraries are capable of carrying out > so much > faster than comparable multiplications. For the division > measurements, I may > again simply be presuming something about your experiments that > simply isn't > true. As for Division, here is the short answer why ARPREC was so much slower than the rest and why LibTomMath was so fast where a corresponding LibTomMath multiplication was relatively slower. ARPREC computes division as long division for small operands (size=256) and multiplication by the reciprocal (Newton-Raphson iteration followed by Karp's trick to eliminate trailing errors in the mantissa) for larger operations (>=512): that is why ARPREC is so slow at size=256 and grows progressively faster for greater sizes. LibTomMath division relies on subtraction at first to compute the approximate number of iterations--it computes the *entire* number as an approximation rather than GMP's recursive division from the paper, C. Burnikel and J. Ziegler, "Fast Recursive Division" (1998) . For both LibTomMath and ARPREC, if the divisor is greater than the dividend the "division" calculation of an integer (without remainder) is very fast since the result is 0, so for those two I had to check that the random-number divisor was less than the dividend before calculation. >> ... >> I keep talking about ARPREC--why? For three reasons: >> (1) I trust its level of precision--this has been tested, see FFTW's >> benchmark page for accuracy: http://www.fftw.org/accuracy/G4-1.06GHz- >> gcc4/ > > I am not sure I understand here: With respect to Haskell Integers, > I would not > say that there is any concept of a "level of precision": If Integer > computations are not accurate, they are wrong. FFT's must be performed with floating point or fixed point numbers (unless you want to deal with some mad algorithm involving continued fractions): there will always be some approximation so I always consider precision. The same might be said for division with remainder for some algorithms. All this holds especially true when you must round the approximation to what users would expect to be an exact integer. > Again, some additional details about these measurements would be > most welcome. I hope the above explanations help a little. > I looked briefly at ARPREC: It seems that it works with an > explicitly set > maximum bound on the number of digits desired. Although it also > appears that > it is possible to change this bound as computations proceed, such > additional > administration seems difficult to embrace. The size relation for operations corresponds to magnitude, so addition and subtraction operations grow or shrink linearly while multiplication, division and powers (exponents) change logarithmically (roughly, log_2). It would add an extra check on initialisation for every operation (or a string of operations if they were chained together) but it would not be large price. This is actually done internally by all the other libraries, anyway. The simple solution is to put the check into each function in the ARPREC file c_mp.cpp. >> This is the problem I face: GHC unfortunately does not use Integer as >> a mathematical operation but as a primitive type, complete with >> bitwise operations. > > I do not understand what problem you are referring to here. It is both an aesthetic and an implementation problem. If Integer were a mathematical library the primary consideration would be mathematical operations and the user would choose operations to perform a more complex calculation or series of calculations. For GMP or LibTomMath you may know the general size of the operands in your program and use different functions for multiplication, division, squaring, powers, roots or other things like modular arithmetic and number theory. As a pedestrian primitive Integer must support the basic operations (only the basic operations) of a primitive type. All multiplication goes through one function and the user relies on the library to choose the appropriate one. The user would not be able to choose a special multiplication algorithm because he knows the numbers will be, say, larger than 256 bits in size or modularly related. This puts the burden on the compiler to optimise the library for the user, if possible. Meanwhile, as a primitive Integers in Haskell only support a basic set of operations: any extra operations would have to be provided in a special library. (Though I may add extra primitive operations to GHC, this would be nonstandard). As an aesthetic consideration, I mentioned bitwise operations because they are atomic, primitive operations typically associated with machine types (int32_t, uint64_t, etc.). >> Modifying ARPREC will result in a dynamic library (or DLL) that >> outputs simple arrays of doubles--this is how ARPREC currently >> functions; there is no need to wrap a C++ class in an opaque C >> pointer you cannot operate on independently. The huge downside to >> ARPREC and one of the least trivial of my problems is how to >> efficiently convert an array of doubles to precise integers, >> especially for cryptographic purposes. > > Could you explain exactly what this problem is? If it still makes > sense to > spend time on it, of course. This point is somewhat moot since I am no longer using ARPREC :) The first problem is opaque data types from C++/C. If ARPREC stored the resulting number as a Class object with members of different types (ints and doubles), like this: -- apint.hpp class APInt { public: // ... private: int size; double exponent; double* mantissa; }; Then, in a separate .cpp file I would create functions callable from C: -- c_apint.h extern "C" { APInt* newAPInt (int size, ...); void destroyAPInt (APInt* x); int addAPInt (APInt* x, APInt* y, APInt* res); // ... } // end extern "C" The way to work with this in C (and Haskell) would be an opaque pointer: typedef struct APInt* pAPInt; From C, I could never access the members of the struct directly so any special Haskell functions for modifying those members would have to be special functions in the c-interface file, 'c_apint.h'. An additional problem, somewhat related to the opaque-object problem is converting an array of doubles to a (precise) array of uint32_t. Individual conversions between doubles and ints are expensive and you have to be very careful about rounding. Alternatives that avoid rounding are: (1) normalise the arbitrary precision double (and all the doubles in the array) and use a union to access the mantissa of each double in the array directly, and convert each to a uint32_t while carrying the overflow from each mantissa to the next uint32_t; or, (2) convert the array of doubles to a string and convert the string to an array of uint32_t. Both methods are expensive--you would have to multiply the arbitrary precision double by log_10 and normalise it, to say nothing of the conversion. Worse, for Haskell Integers some conversion would be necessary, unless you want to use arithmetic means to perform the bitwise primitive operations. >>> I better be specific here: What I do is integer factorization >>> (splitting integers into their prime factors). And, for example, >>> I have implemented a version of the ECM (Elliptic Curve Method) >>> in Haskell. Having done that (independently and mainly to learn >>> what it was about), I eventually compared it in performance to >>> GMP-ECM which Paul Zimmermann wrote. And I was initially >>> disappointed to find that GMP-ECM was about 7 times faster than >>> my ECM code. Fortunately, various sessions of "hand-waving" >>> brought this factor down to about 1.5. So, whenever GMP-ECM used >>> 2 minutes, my program would use 3 minutes. >> >> One of the reasons I am working on a library written in C++ is that >> Haskell may be too slow for such things. > > I am not sure what you mean here. I would happily accept a price > of, say, 10 > or 20 percent reduced performance, if I got the ease of programming > (mostly) > in Haskell in return. And I am still not convinced that, in a > computation > that involves heavy Integer work, multiplications, divisions, > greatest common > divisor computations with, say, 200-1000 digit numbers, that the > Haskell > reduced performance price could not be kept as low as this. You could be right--at present I am fairly pessimistic about the various overheads imposed by Haskell for such things as arrays but that does not mean I am correct. You may have noticed my mention of the BigFloat library in a somewhat related thread, "bignums, gmp, bytestring ... ?," at http://www.haskell.org/pipermail/glasgow- haskell-users/2006-November/011601.html . BigFloat is an arbitrary precision library Martin Guy originally wrote in Miranda and ported to Haskell: it is a good library but a little slow (see timing results for the Many Digits "Friendly" Competition, where BigFloat competed as Bignum, at http:// www.cs.ru.nl/~milad/manydigits/final_timings_rankings.html ). Of course this is only one library and it is performing some complex calculations. It is interesting to note that BigFloat *is* precise and uses [Int] for the mantissa. There is a note on the BigFloat page about coming close to finding the highest computed power of 2 after more than a month of computation (before someone turned the power off). Of course, you are correct in assuming some of this moot. I am no longer working on a C++ library: it is written in C with some assembler and in my spare time I have been toying with a hybrid Haskell-C system where the Haskell portion of the system works to optimise basic bits of C code. (I mentioned the idea for this in the November 2006 thread linked above.) This should give users the full flexibility of Haskell with the speed of C, though writing it portably is proving to be a real hassle. I have gotten a little side- tracked porting GHC to be Windows-native in my quest to use a better compiler than gcc 3.4 (the best available for MinGW), namely CL, but it is all to the good. I had a lot to learn about Cmm and the Native Code Generator (NCG)--at one time I thought I knew something about Cmm; it was naive. There is a lot of room for NCG optimisations, such as auto-vectorization and floating point exceptions. >> My best question is: are you using pure mathematical formulas for >> this? > > I am not sure what this question means. Please elaborate. It was a question out of curiosity: for your ECM work, are you able to implement the mathematical formulae directly in Haskell? (Yes, I believe "formulae" is the correct plural of "formula.") C programs require many special operations for dealing with the data and a fast Haskell program would probably have to use a few (maybe I am a bad Haskell programmer?). >> If you are using pure mathematical functions, ARPREC is fine (at >> least it is precise). Mathematically, there are alternative >> algorithms for floating point numbers that are not available for >> integers... > > Again, I am not sure what you mean by this. It is certainly > possible to > compute useful inverses of integers without using a floating point > representation. To be sure, the inverse (reciprocal) of an integer > is not an > integer, but it could still be computed in a suitable fixed point > representation. See, for example, Knuth's "Seminumerical > Algorithms" ("The > art of computer programming", vol 2), end of section 4.3.1 and > algorithm R in > section 4.3.3. Fixed point is certainly an option but it is not a "natural" operation over ints and may add more overhead than necessary considering the relative speed advantages of modern floating point processors. (By "not available," I was talking about hardware support though I'll admit my typo-riddled prose may have thrown you off--"Mathematically," may have been an artifact.) All of the fastest integer division algorithms I am aware of do not use fixed point for division by inverse multiplication. > I still believe that the excessive memory usage was caused by GMP > allocating a > lot of storage using the GHC allocator during a single mpz_powm > call, so that > the GHC garbage collector never got the opportunity to actually > free the > allocated storage. The mpz_powm function of gmp-4.2 that I am > looking at > calls mpn_sqr_n inside its main loop and that function itself > allocates > storage in some cases. In other cases, it calls mpn_mul_fft_full > which, > again, allocates storage. O.K. I misunderstood your program: I was under the impression that you wrote the GMP program in C. That is an interesting insight concerning the GHC garbage collector. > so it may very well be that some of the above remarks are not > relevant any > more. In addition, you wrote > (http://www.haskell.org/pipermail/glasgow-haskell-users/2006- > November/011601.html): > >> ... >> Integers are mostly a convenience. >> ... > > ... > > My highest priority is still correctness. The thought that there > might, in > some special case, have crept an error into my basic arithmetic > operators > makes me shudder. In the present case of multiprecision integer > operations, > what worries me is the complications and the many special cases that > implementors deal with. And not least special cases that address some > particular architecture: This opens the possibility that code > working on one > machine stops working on another. The general trend for floating or fixed point libraries that seek precision is low to medium speed; there are many fast libraries out there which are faster but not as precise. One example is the BOOST uBLAS library: it is slower than BLAS but more precise. > It seems that my level of tolerance of such risks is not as high as > most other > people's. Personally, if I were to write a multiprecision library > myself, I > would build in all sorts of possibilities for verifying that > everything > remains in place and results computed were indeed correct. Ideally, these should be handled by the compiler-system rather than run-time checks in code. > For example, I understand that memory errors occur, not often, but > often > enough to be significant for such longwinding computations (days, > months, > years) that I envision. Other people are doing long computations (e.g. > http://www.mersenne.org/) and they exercise some care in the form > of test > programs that are intended to verify that a particular machine is > sufficiently stable. I would probably carry this even further, by > including, > even in "production" runs, various checks (individual arithmetic > operations > verified by checks modulo some number, say). That is an excellent point. No arbitrary (multi) precision library I know of provides a facility for performing such checks. It would be a nice thing to add. > Another thing that bothers me is the unpredictability of the > performance of > these multiprecision packages. When I look at the GMP code, there are > countless special cases that are taken into account. Each of them, > of course, > represents the implementor's desire to provide me, the user, with > the best > service (performance) possible. But it makes measuring performance a > nightmare, because you never know, for sure, whether some special > case has > been taken into account in a particular situation. One reason I kept the comparison of different libraries very basic and general. The best performance comes from special tuning tied to a particular equation, as with FFTW. > This was brought home to me most forcefully some months back: I have > GHC-compiled programs running on a couple of Linux machines (not > the same > Linux distribution), but had used some precompiled GMP package on > both of > these machines. After looking at the GMP code, I realised (as I > should have > much earlier, of course) that I should use a package that was > compiled for > the specific machine I was working on to ensure that all the > various special > performance tricks could come into play. So I did. And performance > improved > on one machine, but degraded on another. I am still not sure what the > explanation of this behaviour really is. But one thing I am certainly > concerned about is whether, in fact, the GMP build process is > actually able > to guess some machine architecture correctly and ensure that its > potential is > used to the fullest extent. This is a very big problem with every fast mathematical library. The GMP build system is primitive (it tends to rely on assembler blocks written for particular types of machines but does not perform further testing). You know how ATLAS uses a specialised build process to automatically optimise code for a particular machine and architecture. It is very delicate and once you have built the library as a developer you cannot expect the same performance if you package the library with a program designed for one operating system and many different (but related) machines: a program for OS X 10.4 built on a ppc7450 (G4) will run differently on a G3 or G5. My own problem involves the different variations for Altivec and SSE on different PPC and Intel/AMD processors, especially if I include any assembler code but also if the library is compiled by a different compiler or compiler version. I should probably make precision the highest priority, portability, second and speed, third. > One thing that seems missing in many packages is the possibility to > experiment > with the tuning parameters more dynamically. For example, GMP > includes a > tuning program that is able to suggest values for certain > parameters. But > these parameters then have to be compiled into the package for > final use. Not > particularly elegant and something which, surely, could be changed, > without > significant overhead. GMP is unfortunately an open-source project, academic or commercial. Some developer would have to spend the time to do the tedious work of weighing the different parameter combinations so the tuning program could determine and input the best performance choices and report back. > The conclusion, for me at least, is this: If you are a naive user > of Integers, > you are much better off with a completely simple, no-special-cases, > solid and > working, multiprecision package. Which might even be fairly portable. > > For heavy users (such as me) with special requirements, it seems > that they can > never get the ultimate performance without having considerable > insight into > the details of the matter anyway. And, hence, they need to do some > complex > work themselves to get the desired performance. A hybrid solution that gave basic Integer functionality but allowed for variations in a special library would be better. Integer may be a Primitive but it should really be a separate Haskell library. Claus Reinke had a good comment about not automatically importing Integer when a user doesn't need it. > For Haskell, this would mean ensuring that the interface between > GHC-compiled > code and some multiprecision package was reasonably comprehensible and > allowed the multiprecision support to be replaced. And here I try > to avoid > the usual dream of "easy replacement", that seems entirely > unrealistic. But > something reasonable that the rest of GHC (and not least: The GHC > developers) > can live with without too much work. And that heavy users, with > sufficient > insight and probably a significant dose of hard work (such as that > you have > put into this) would be able to use for their own purposes. GMP *would* have been easy to replace but, like so much else in GHC, it was hacked in and then hacked in again. No offense to those who have spent more than a decade working on GHC--there is still working code from the early 90's, at least in the Haskell libraries--but I guess it suffers from how fun and easy it is to write in Haskell and the comparative drudgery of cleaning things up. Modularity is key. I really have to stop playing around and post a prototype so people (like you) can have something to work with and criticise :) Cheers, Pete From simonpj at microsoft.com Wed Jan 3 11:09:07 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Jan 3 11:05:35 2007 Subject: [Haskell] Fundep broken in GHC 6.6 In-Reply-To: <2608b8a80611121135s6325c8abw905c17e5c93f9f68@mail.gmail.com> References: <2608b8a80611121135s6325c8abw905c17e5c93f9f68@mail.gmail.com> Message-ID: [redirecting to ghc users] Actually this didn't work in 6.4.2 either! (Though it did in 6.4, for reasons I have not investigated.) Indeed I think your reasoning is correct. GHC tries to be pretty relaxed about reporting ambiguous types, which is what this amounts to really. I have committed a fix to the HEAD that relaxes the condition, and allows this program. It should appear in 6.6.1 also. Thanks for the report Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] | On Behalf Of dpus | Sent: 12 November 2006 19:36 | To: haskell@haskell.org | Subject: [Haskell] Fundep broken in GHC 6.6 | | Hi, | | The following class declaration worked in GHC 6.4. | I recently upgraded to 6.6 (following Debian), and | now it is broken. | | class Error e => Game b mv e | b -> mv e where | newBoard :: MonadState b m => m () | ... | | Since MonadState has the fundep m -> b, the type | of newBoard fully specifies all of the class parameters. | And this worked fine in GHC 6.4. But GHC 6.6 | complains: | | The class method `newBoard' | mentions none of the type variables of the class Game b mv e | When checking the class method: newBoard :: m () | In the class declaration for `Game' | | Any ideas? | | Thanks, | Yitz | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell From cmb21 at kent.ac.uk Wed Jan 3 15:35:09 2007 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Wed Jan 3 15:31:39 2007 Subject: Compiling 6.6 repos on Mac OS X Message-ID: Hi, I have recently tried to compile the 6.6 version of ghc from the darcs repository. I followed the intructions to pull ghc from the repository: darcs get --partial http://darcs.haskell.org/ghc-6.6/ghc cd ghc chmod +x darc-add ./darcs-add -extra pull The build process seems to get past stage 1, but fails at the beginning of stage 2: ../compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-fno-strict-aliasing -H16m -O -optc-O2 -static -I. -#include HCIncludes.h -fvia-C -dcmm-lint -c Linker.c -o Linker.o Linker.c: In function 'loadObj': Linker.c:1383:0: error: 'misalignment' undeclared (first use in this function) Linker.c:1383:0: error: (Each undeclared identifier is reported only once Linker.c:1383:0: error: for each function it appears in.) make[1]: *** [Linker.o] Error 1 make: *** [stage1] Error 1 I am compiling this with ghc-6.6 (the latest version from darcs) and gcc 4.0. Kind regards, Chris. From gale at sefer.org Wed Jan 3 17:26:09 2007 From: gale at sefer.org (Yitzchak Gale) Date: Wed Jan 3 17:22:34 2007 Subject: [Haskell] Fundep broken in GHC 6.6 In-Reply-To: References: <2608b8a80611121135s6325c8abw905c17e5c93f9f68@mail.gmail.com> Message-ID: <2608b8a80701031426y7ad80576i57d6495e0e2e3ade@mail.gmail.com> On 12 November 2006 I wrote (on the haskell list): >> class Error e => Game b mv e | b -> mv e where >> newBoard :: MonadState b m => m () >> ... >> Since MonadState has the fundep m -> b, the type >> of newBoard fully specifies all of the class parameters.... >> But GHC 6.6 complains... Simon Peyton-Jones wrote: > I have committed a fix to the HEAD that relaxes the > condition, and allows this program. > It should appear in 6.6.1 also. Thank you! Am I correct to assume that this fix only applies to the specific case of unspecified class parameters in method declarations? And not any of the other cases where fundeps on class constraints resolve type ambiguity but are ignored by GHC, such as instance declarations? Does the fix actually look at the fundeps in the class constraint on the method, or just relax the requirement that all class parameters be specified in every method? If it is the latter, as I suspect, then is the requirement always relaxed, or only when there is a class constraint on the method? Thanks, Yitz From jim at sdf-eu.org Thu Jan 4 07:26:59 2007 From: jim at sdf-eu.org (jim burton) Date: Thu Jan 4 07:23:22 2007 Subject: IOExts problem Message-ID: <8158283.post@talk.nabble.com> IOExts seems to be unavailable on my system, whereas I'm guessing it should be since the file /usr/lib/ghc-6.4.1/hslibs-imports/lang/IOExts.hi exists...(wrong guess?) Within ghci I get Prelude> :m IOExts Could not find module `IOExts': it is not a module in the current program, or in any known package. Prelude> I am trying to build the latest version of haskore with ghc 6.4.1 and have edited the Makefile to put in references to the location of IOExts.hi: HC_OPTS = -cpp -i/usr/lib/ghc-6.4.1/hslibs-imports/lang/IOExts.hi IOExtensions.o : /usr/lib/ghc-6.4.1/hslibs-imports/lang/IOExts.hi Now make gives the error: jim@unicorn:~/haskore/Src$ make ghc -c IOExtensions.hs -cpp -i/usr/lib/ghc-6.4.1/hslibs-imports/lang/IOExts.hi IOExtensions.hs:20:0: Failed to load interface for `IOExts': Could not find module `IOExts': use -v to see a list of the files searched for make: *** [IOExtensions.o] Error 1 Is IOExts installed as standard with GHC or do I have to tell it the path to the hi file somehow? -- View this message in context: http://www.nabble.com/IOExts-problem-tf2919193.html#a8158283 Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From simonmarhaskell at gmail.com Thu Jan 4 07:34:34 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Jan 4 07:31:05 2007 Subject: importing "in place" and packages In-Reply-To: References: Message-ID: <459CF45A.8080606@microsoft.com> Ashley Yakeley wrote: > Simon Peyton-Jones wrote: > >> Anyway, the solution for you is to install it. > > > I can't install it, the package isn't finished being built at that > point. Or perhaps I could find a way of installing the partial package > to the user database. > > I build part of package javavm. Then I use that to build ShowClasses. > Then I run ShowClasses to generate more source files. Then I use those > to build the rest of javavm. Cabal provides 'setup register --inplace' for exactly this purpose. We don't currently allow the use of completely local package databases - you must use the global or user database - but the package can be used without the files actually being installed. Cheers, Simon From simonmarhaskell at gmail.com Thu Jan 4 07:51:39 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Jan 4 07:48:04 2007 Subject: importing "in place" and packages In-Reply-To: References: Message-ID: <459CF85B.9090207@microsoft.com> Simon Peyton-Jones wrote: > The main program must be in package 'main', which is why compiling ShowClasses with "-package-name javavm" doesn't work. I'll modify the documentation to say this more clearly > > When you say "import JVMBoot", and your javavm package is not installed, GHC thinks you mean "JVMBoot from package main". The only way at the moment you can make GHC realise you mean "JVMBoot from package javavm" is to install it. > > You may say that's a bit silly -- after all, GHC can simply look at the interface file, and that is what you want here. I'll talk to Simon about whether that could be possible, but I'm guessing there's a good reason why not. It would be a bit strange to allow this. The compiler knows nothing about the javavm package at this stage: it isn't installed. So if we came across a module that we were expecting to be part of the main package and it turns out to belong to another, non-existant, package, we'd probably have to invent a package. I just don't have a clear idea for how this would work; my gut feeling is that we shouldn't pursue it, since the right way is to register the package with GHC first (temporarily, to a local database, perhaps). Cheers, Simon > Anyway, the solution for you is to install it. Cabal? There must be a well-understood process but I'm not the one to ask. > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow- > | haskell-users-bounces@haskell.org] On Behalf Of Ashley Yakeley > | Sent: 22 December 2006 10:44 > | To: glasgow-haskell-users@haskell.org > | Subject: importing "in place" and packages > | > | I'm compiling the files for package "javavm" with GHC 6.6 (using > | "-package-name javavm"). As part of the compilation process, I need a > | runnable program that uses the modules I've compiled "in place": > | > | import JVMBoot > | > | But I get this error when compiling my "Main" module (ShowClasses.hs): > | > | ShowClasses.hs:23:1: > | Bad interface file: JVMBoot.hi > | Something is amiss; requested module main:JVMBoot differs > | from > | name found in the interface file javavm:JVMBoot > | > | Really I want to import javavm:JVMBoot, not main:JVMBoot. I tried this, > | but GHC doesn't like it (because it's not Haskell): > | > | import javavm:JVMBoot > | > | I tried compiling ShowClasses.hs with "-package-name javavm". This let > | me compile, but then I get this on link: > | > | /usr/bin/ld: Undefined symbols: > | _ZCMain_main_closure > | ___stginit_ZCMain > | collect2: ld returned 1 exit status > | > | I tried adding a -main-is in the compile step, but this didn't help. > | > | Is there any way to create a main function that calls files imported > | "in > | place" that are in some package? I have the same issue when writing > | tests for my "time" package. > | > | -- > | Ashley Yakeley > | > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonmarhaskell at gmail.com Thu Jan 4 07:58:32 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Jan 4 07:55:05 2007 Subject: LLVM back end In-Reply-To: References: <1164007651.6196.14.camel@localhost.localdomain> <4587E577.8040409@microsoft.com> <1166605815.2671.18.camel@localhost.localdomain> <06811EF1-4FF8-4BE7-BDD2-5017A1AAAF38@gmx.net> Message-ID: <459CF9F8.50407@microsoft.com> Simon Peyton-Jones wrote: > How about > * concurrency (the ability to have zillions of little stacks, > with stack overflow checks and growing the stck on overflow)? > * exception handling (the ability to crawl over the stack > looking for exception catch frames)? > * garbage collection (the ability to find pointers in the stack) I'd imagined that we'd use LLVM as a low-level code generator, doing our own stack management and using the existing GHC runtime support for all of these things. Michael seems to be saying something different though... but it seems to me that anything other than using LLVM as a code generator only is a *lot* of work, and in direct competition with C--, so not an easy sell. Cheers, Simon > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow- > | haskell-users-bounces@haskell.org] On Behalf Of Wolfgang Thaller > | Sent: 20 December 2006 23:55 > | To: ttmrichter@gmail.com > | Cc: GHC Users; Simon Marlow > | Subject: Re: LLVM back end > | > | On 20-Dec-06, at 10:10 AM, Michael T. Richter wrote: > | > | > Well, I'm almost entirely ignorant of LLVM and of Haskell -- > | > especially the internals of both. That makes me ideally suited for > | > this project since I'm not aware that it's impossible. > | > | I'm afraid LLVM currently lacks some features that are required for > | efficient GHC code generation, specifically: > | > | a) Global Register Variables > | b) The ability to put data next to code > | c) (maybe, I'm not sure) Tailcalls > | > | ad a) > | We need to keep some things in global registers for speed reasons > | (depending on the number of available registers); among other things, > | the haskell stack pointer and the heap pointer. Using regular global > | variables instead would be a lot slower. > | > | ad b) > | With (almost) every chunk of code, we want to associate a smal chunk > | of data (the "info table") which contains information used by the > | garbage collector and other parts of the run time system. We want to > | use only one pointer to point to both of those things, and we don't > | want to waste time with any additional indirections, so we make the > | pointer point between the data chunk and the code chunk. > | > | ad c) > | While they are supported in theory, I couldn't get LLVM to generate > | any tailcalls. Maybe I've done something wrong, maybe they're not > | really implemented yet. > | > | So I guess step one would be to start negotiating about those things > | with the LLVM people. > | > | Cheers, > | > | Wolfgang > | > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonmarhaskell at gmail.com Thu Jan 4 08:02:23 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Jan 4 07:58:49 2007 Subject: ghci attempts to link entire package In-Reply-To: <125EACD0CAE4D24ABDB4D148C4593DA9891A91@GBLONXMB02.corp.amvescap.net> References: <125EACD0CAE4D24ABDB4D148C4593DA9891A91@GBLONXMB02.corp.amvescap.net> Message-ID: <459CFADF.9020203@microsoft.com> Bayley, Alistair wrote: > Related to some of the problems Takusen users have had, I have a > question about ghci's linker/loader: why does it appear to try to link > an entire package archive, rather than just the modules that are used? > This is in contrast to the GNU ld program which the compiler uses, which > only tries to link modules which are actually used. > > Is this a feature or a bug? Neither really, just a consequence of the design. GHCi's linker only knows how to link object files, and when it links a package it actually linked a specially generated single .o file constructed by linking together all the object files in the package. There has been talk of adding support to link .a files which would simplify package management, but I guess it might make linking slower. If there's a use case that requires partial linking of a package, then we could consider the lack of partial linking a bug - can you describe why you need it? Cheers, Simon From simonmarhaskell at gmail.com Thu Jan 4 08:05:27 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Jan 4 08:01:52 2007 Subject: Running GHC on the IBM Cell In-Reply-To: <619196350.20061222225108@gmail.com> References: <619196350.20061222225108@gmail.com> Message-ID: <459CFB97.4030806@microsoft.com> Bulat Ziganshin wrote: > Hello Jaap, > > Friday, December 22, 2006, 9:45:39 PM, you wrote: > > >>* Are the .hc files cross-platform? > > > just want to mention that jhc compiler generates pure ansi c code. may be > it's better suit your needs? It's all very well generating pure ANSI C code - GHC can do that too (we call it "unregisterised", and it's how you port GHC to a new platform), but if the original Haskell code you compiled contained any #ifdefs then you still don't have platform-independent intermediate code. Cheers, Simon From simonmarhaskell at gmail.com Thu Jan 4 08:18:06 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Jan 4 08:14:33 2007 Subject: Running GHC on the IBM Cell In-Reply-To: References: Message-ID: <459CFE8E.5040100@microsoft.com> Suter, Jaap wrote: > I'm trying to get GHC to run on the Cell processor. Cool :) > That is, just on the > PPU PowerPC side. The SPUs will continue to run C programs, managed and > driven by a Haskell manager on the PPU. I'm mostly interested in GHC for > its concurrency features (STM in particular). > > Not knowing much about GHC yet, here's what I would expect in the ideal > situation. > > 1. The RTS is largely cross-platform already. I might have to make some > minor tweaks, but for the most part it should compile out of the box. > > 2. I setup GHC to compile my .hs files to .hc files; the C intermediates. > > 3. These are hopefully cross-platform as well, instead of being tied to > my GHC distribution's platform. > > 4. I compile the RTS and .hc files and link them all together. > > 5. Done. > > This raises a few questions... > > * Are the .hc files cross-platform? Or does a GHC compiled for PowerPC > generate different intermediate C code than a GHC compiled for X86? > Ideally the platform specifics are hidden inside the RTS and two > different GHC builds will output identical .hc files. The .hc files are not cross-platform, you need to generate them for your target platform using a working GHC on another machine first. The porting instructions describe how to do this. > * How cross-platform is the RTS? As long as your platform is POSIX compatible, you're probably in reasonable shape. If you're not using gcc, then things might get more difficult, but I believe the RTS has compiled with non-gcc compilers in the past so it shouldn't be too hard. > I downloaded the source tarball and dropped it on top of my XP > installation of GHC. I then generated a simple Hello World haskell .hc > intermediate and tried to compile that and the RTS. Unfortunately I ran > into problems because things like HAVE_WINDOWS_H and HAVE_SIGNALS_H were > defined. > > I started manually editing the code to tweak the configuration but ran > into more problems (signal_set_t doesn't exist on my platform, but can't > be conditionally compiled. static arrays of unknown size (StgWordArray) > make my compiler unhappy. Etcetera). > > At this point I figured I would stop and ask for some help first, before > I invest a lot of energy in a dead-end path. There must be a simpler way. > > I read parts of the "porting GHC to your platform" documentation, but I > believe it addresses a different problem. I don't want to recompile GHC > itself. I want to run my existing GHC on my XP machine and output > intermediate .hc files. I then feed these plus a cross-platform RTS to > my Cell compiler to get a workable program. Ok. So what you want to do is similar to what the porting instructions describe, in that you want to generate a cross-compiler on your host system that can generate .hc files for your target, but you want to continue using this cross-compiler to compile target binaries rather than use it to compile a native GHC. It seems plausible, though it's not something we typically do, so it might be a bit of an adventure. For example, you'll have to invoke the C compiler and linker by hand on the target machine, and those command lines can be pretty long and complicated. First thing to do is follow the porting instructions up until the point wher you have a compiled set of libraries and RTS on the target machine. You can omit compiling GHC itself. From that point, you ought to be able to take .hc files for your program to the target machine, compile them against the .h files in your GHC build, and link them against the libraries and RTS. > I suppose I need to regenerate the ghautoconf for my particular platform > (rather than hand-tweaking the existing one). Unfortunately I'm not much > of a Linux or Gnu toolset expert. I see a bunch of config.* and > configure.* file in the root folder. I suppose I should read up on those > a little more. I'll do my homework first. > > In the meanwhile, if anybody has any quick and simple advice to make > this process smoother that would be greatly appreciated. > > Kind regards, > > Jaap Suter - http://www.jaapsuter.com > > Some more random questions... > > * ghautoconf.h and HsBaseConfig.h have similar #defines (like > HAVE_WINDOWS_H). Is there a reason for that? I always need to update > them in two places now. > > * After downloading the source tarball and unzipping over my XP GHC > installation, I got both an 'include' and an 'includes' directory. This > is somewhat confusing. I wouldn't recommend unzipping the source tree over the installed tree, they aren't designed to coexist. Cheers, Simon From Alistair_Bayley at invescoperpetual.co.uk Thu Jan 4 08:22:29 2007 From: Alistair_Bayley at invescoperpetual.co.uk (Bayley, Alistair) Date: Thu Jan 4 08:18:54 2007 Subject: ghci attempts to link entire package In-Reply-To: <459CFADF.9020203@microsoft.com> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9891A9D@GBLONXMB02.corp.amvescap.net> > From: Simon Marlow [mailto:simonmarhaskell@gmail.com] > > > Is this a feature or a bug? > > Neither really, just a consequence of the design. Well, that would make it a feature, then ;-) > There has been talk of adding support to link .a files which > would simplify > package management, but I guess it might make linking slower. > > If there's a use case that requires partial linking of a > package, then we could > consider the lack of partial linking a bug - can you > describe why you need it? With Takusen, all modules, including the DBMS-specific modules, are compiled into a single library. At present we have 3 DBMS's: Sqlite, Oracle, and PostgreSQL. For example, suppose you had just the Oracle DBMS client libraries installed, and you write a program which only uses the Oracle modules from Takusen. When you link, the gnu ld program attempts to resolve the symbols in only the modules that you've used. You don't need to have PostgreSQL or Sqlite installed, and the linker ignores these modules from the package archive. This is quite nice, because we can distribute the entire library as a single package, and it will work even if the user does not have all of the DBMS client libraries installed. In contrast, when ghci (or runhaskell) attempts to link it tries to resolve all of the symbols in the PostgreSQL and Sqlite modules, and fails because you don't have them installed. The result is that a user of Takusen can't easily use the library with ghci/runhaskell "out of the box", unless they have the full set of DBMS client libraries installed. There are a couple of workarounds, but they're both a bit fiddly, so it'd be nicer (from my POV) if the ghci linker behaved like gnu ld. Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From Alistair_Bayley at invescoperpetual.co.uk Thu Jan 4 11:11:23 2007 From: Alistair_Bayley at invescoperpetual.co.uk (Bayley, Alistair) Date: Thu Jan 4 11:07:47 2007 Subject: ghci attempts to link entire package In-Reply-To: <125EACD0CAE4D24ABDB4D148C4593DA9891A9D@GBLONXMB02.corp.amvescap.net> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9891AA0@GBLONXMB02.corp.amvescap.net> > From: Bayley, Alistair > > The result is that a user of Takusen can't easily use the > library with ghci/runhaskell "out of the box", unless they > have the full set of DBMS client libraries installed. I forgot to mention that there's another difference between ghci and gnu ld: if the external library is called libxx.dll, rather than xx.dll (which is the convention on Windows, it seems), then gnu ld is still able to locate & link to it when you say -lxx, but ghci fails to find it. You have to say -llibxx to ghci for it to work. This also makes distributing the Takusen library as a single package awkward, because 1. the cabal installation detects the presence of the library and configures the package with the -lxx option 2. ghc --make passes -lxx to gnu ld, which is nice... 3. ... but ghci tries to use -lxx also, and fails. So PostgreSQL users can't use ghci with the installed package unless they're willing to re-configure/build/install and change the -l option to from -lpq to -llibpq, which breaks normal compilation with ghc, because gnu ld can't find the library when you say -llibpq. (This affects the PostgreSQL client library on Windows, which is called libpq.dll.) Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From aljee at hyper.cx Fri Jan 5 00:13:49 2007 From: aljee at hyper.cx (Takano Akio) Date: Fri Jan 5 00:10:05 2007 Subject: Unpacking polymorphic fields In-Reply-To: References: <20061115195510.5929b46e.aljee@hyper.cx> Message-ID: <20070105141349.bff05e81.aljee@hyper.cx> Thank you, that helped a lot. Takano Akio From simonpj at microsoft.com Fri Jan 5 12:04:56 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jan 5 12:01:15 2007 Subject: [Haskell] Fundep broken in GHC 6.6 In-Reply-To: <2608b8a80701031426y7ad80576i57d6495e0e2e3ade@mail.gmail.com> Message-ID: I just applied this rule http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html#id3170412 In this case the type of newBoard is newBoard :: (Game b mv e, MonadStaet b m) => m () Following the rules in that manual section, this type sig is (now) ok. Does that answer your qn Simon | -----Original Message----- | From: sefer.org@gmail.com [mailto:sefer.org@gmail.com] On Behalf Of Yitzchak Gale | Sent: 03 January 2007 22:26 | To: Simon Peyton-Jones | Cc: GHC users | Subject: Re: [Haskell] Fundep broken in GHC 6.6 | | On 12 November 2006 I wrote (on the haskell list): | >> class Error e => Game b mv e | b -> mv e where | >> newBoard :: MonadState b m => m () | >> ... | >> Since MonadState has the fundep m -> b, the type | >> of newBoard fully specifies all of the class parameters.... | >> But GHC 6.6 complains... | | Simon Peyton-Jones wrote: | > I have committed a fix to the HEAD that relaxes the | > condition, and allows this program. | > It should appear in 6.6.1 also. | | Thank you! | | Am I correct to assume that this fix only applies to the | specific case of unspecified class parameters in | method declarations? And not any of the other cases | where fundeps on class constraints resolve type ambiguity | but are ignored by GHC, such as instance declarations? | | Does the fix actually look at the fundeps in the class | constraint on the method, or just relax the | requirement that all class parameters be specified in | every method? If it is the latter, as I suspect, then is | the requirement always relaxed, or only when there is | a class constraint on the method? | | Thanks, | Yitz From gale at sefer.org Sat Jan 6 13:58:40 2007 From: gale at sefer.org (Yitzchak Gale) Date: Sat Jan 6 13:54:56 2007 Subject: [Haskell] Fundep broken in GHC 6.6 In-Reply-To: References: <2608b8a80701031426y7ad80576i57d6495e0e2e3ade@mail.gmail.com> Message-ID: <2608b8a80701061058r614fcbc6tf59cdf6f60e59684@mail.gmail.com> Simon Peyton-Jones wrote: > I just applied this rule > http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html#id3170412 > > In this case the type of newBoard is > newBoard :: (Game b mv e, MonadStaet b m) => m () > > Following the rules in that manual section, this type sig is (now) ok. Does that answer your qn Yes, I think it does. I guess I'll only really know when I can either get my hands on 6.6.1, or successfully compile GHC from darcs. Thanks! -Yitz From p.tanski at gmail.com Sat Jan 6 14:47:04 2007 From: p.tanski at gmail.com (Peter Tanski) Date: Sat Jan 6 14:43:25 2007 Subject: Current GMP implementation Message-ID: <03A603ED-F456-4540-A89F-83FB18A3BE27@gmail.com> Hello Thorkil, I updated the wiki Replacing GMP/The Current GMP Implementation page with some introductory notes. I hope the pretty graphic cuts down on a lot of wording necessary. There is no discussion of the Cmm implementation as that is contained in Esa's posts to the GHC users list or in the PrimOps pages in the new Commentary. (Maybe I should move the GMP->Cmm->Haskell discussion into The Current GMP Implementation page but I really have to get some honest coding done.) Cheers, Peter From golubovsky at gmail.com Sun Jan 7 08:29:06 2007 From: golubovsky at gmail.com (Dimitry Golubovsky) Date: Sun Jan 7 08:25:26 2007 Subject: Exception when compiling HAppS Message-ID: Hi, I am getting a strange error message when trying to compile HAppS-0.8.4 with ghc-6.4.1always on the same file. ============================================================ bash$ runghc Setup.hs configure --prefix=/previous/public/HAppS The field "hs-source-dir" is deprecated, please use hs-source-dirs. Setup.hs: Warning: No license-file field. Configuring HAppS-0.8.4... configure: Using install prefix: /previous/public/HAppS configure: Using compiler: /previous/public/ghc-6.4.1/bin/ghc configure: Compiler flavor: GHC configure: Compiler version: 6.4.1 configure: Using package tool: /previous/public/ghc-6.4.1/bin/ghc-pkg configure: No haddock found configure: No happy found configure: No alex found configure: Using hsc2hs: /previous/public/ghc-6.4.1/bin/hsc2hs configure: No c2hs found configure: Using cpphs: /previous/public/nhc98/bin/cpphs configure: No greencard found configure: Dependency base-any: using base-1.0 configure: Dependency fps>=0.8: using fps-0.8 configure: Dependency HaXml>=1.13&&<1.14: using HaXml-1.13.2 configure: Dependency mtl-any: using mtl-1.0 configure: Dependency network-any: using network-1.0 configure: Dependency stm-any: using stm-1.0 configure: Dependency template-haskell-any: using template-haskell-1.0 ============================================================ bash$ runghc Setup.hs build The field "hs-source-dir" is deprecated, please use hs-source-dirs. Preprocessing library HAppS-0.8.4... Building HAppS-0.8.4... Chasing modules from: HAppS,HAppS.Agents.MailSender,HAppS.Agents.SessionKeeper,HAppS.Agents.SessionKeeperEx,HAppS.Agents.Users,HAppS.Agents.WithBlockingIO,HAppS.DBMS.Index,HAppS.DBMS.RSMap,HAppS.DBMS.Table,HAppS.MACID,HAppS.MACID.Saver,HAppS.Protocols.Base64,HAppS.Protocols.Cookie,HAppS.Protocols.DNS,HAppS.Protocols.DNS.HiWire,HAppS.Protocols.DNS.RR,HAppS.Protocols.DNS.Type,HAppS.Protocols.HMAC,HAppS.Protocols.HTTP,HAppS.Protocols.HTTP.LowLevel,HAppS.Protocols.SimpleHTTP,HAppS.Protocols.JSON,HAppS.Protocols.MessageWrap,HAppS.Protocols.MinHaXML,HAppS.Protocols.SHA1,HAppS.Protocols.SMTP,HAppS.Protocols.SURI,HAppS.Protocols.W64,HAppS.Protocols.XSLT,HAppS.Protocols.XSLTSMTP,HAppS.Util.Concurrent,HAppS.Util.Cron,HAppS.Util.Common,HAppS.Util.EventHandler,HAppS.Util.StdMain,HAppS.Util.StdMain.Config,HAppS.Util.StdMain.StartState,HAppS.Util.TimeOut,HAppS.MACID.Checkpoint,HAppS.MACID.Monad,HAppS.MACID.Saver.Impl.File,HAppS.MACID.Saver.Impl.Queue,HAppS.MACID.Saver.Types,HAppS.MACID.Serialize,HAppS.MACID.SideEffect,HAppS.MACID.Transaction,HAppS.MACID.Types,HAppS.MACID.Util,HAppS.MACID.Var,HAppS.Protocols.DES,HAppS.Protocols.DNS.Cache,HAppS.Protocols.DNS.ChooseMethod,HAppS.Protocols.DNS.LoWire,HAppS.Protocols.DNS.MutableEnv,HAppS.Protocols.DNS.MXClient,HAppS.Protocols.DNS.Name,HAppS.Protocols.DNS.NSTree,HAppS.Protocols.DNS.Util,HAppS.Protocols.HTTP.Clock,HAppS.Protocols.HTTP.FileServe,HAppS.Protocols.HTTP.Handler,HAppS.Protocols.HTTP.LazyLiner,HAppS.Protocols.HTTP.Listen,HAppS.Protocols.HTTP.ServerPart,HAppS.Protocols.HTTP.Types,HAppS.Protocols.SURI.ParseURI,HAppS.Util.StdMain.StartStateTH,HAppS.Util.ByteStringCompat Skipping HAppS.Util.ByteStringCompat ( src/HAppS/Util/ByteStringCompat.hs, dist/build/HAppS/Util/ByteStringCompat.o ) Skipping HAppS.Protocols.SURI.ParseURI ( src/HAppS/Protocols/SURI/ParseURI.hs, dist/build/HAppS/Protocols/SURI/ParseURI.o ) Compiling HAppS.Protocols.HTTP.LazyLiner ( src/HAppS/Protocols/HTTP/LazyLiner.hs, dist/build/HAppS/Protocols/HTTP/LazyLiner.o ) *** Exception: waitForProcess: interrupted (Interrupted system call) ============================================================ bash$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.4.1 bash$ ghc-pkg -l /previous/public/ghc-6.4.1//lib/ghc-6.4.1/package.conf: rts-1.0, base-1.0, haskell98-1.0, template-haskell-1.0, unix-1.0, parsec-1.0, haskell-src-1.0, network-1.0, QuickCheck-1.0, HUnit-1.1, mtl-1.0, fgl-5.2, X11-1.1, HGL-3.1, stm-1.0, readline-1.0, (lang-1.0), (concurrent-1.0), (posix-1.0), (util-1.0), (data-1.0), (text-1.0), (net-1.0), (hssource-1.0), NewBinary-0.1, Crypto-2.1.0, HTTP-2005.11.23, hxt-5.3, CabalFind-0.2, Cabal-1.1.3, FilePath-0.1.0, UNISTD-0.0, DB-4.2, SYSLOG-0.0, XPROTO-0.0, HSFFIG-1.1, BF-0.0, Fudgets-0.1, (cpphs-1.3), HaXml-1.13.2, fps-0.8 Has anybody encountered this? Thanks. -- Dimitry Golubovsky Anywhere on the Web From catamorphism at gmail.com Sun Jan 7 12:08:44 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Sun Jan 7 12:04:58 2007 Subject: Exception when compiling HAppS In-Reply-To: References: Message-ID: <4683d9370701070908j6944048alc2134c6a4d72ee1f@mail.gmail.com> On 1/7/07, Dimitry Golubovsky wrote: > Hi, > > I am getting a strange error message when trying to compile > HAppS-0.8.4 with ghc-6.4.1always on the same file. > [snip] > *** Exception: waitForProcess: interrupted (Interrupted system call) > This could mean a lot of things. What OS and platform are you using? Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "Would you be my clock if I promise not to hang you / Too close to the window or the picture of the pope? / I won't set you back and I won't push you forward / I just want to look in your face and see hope" -- Dom Leone From golubovsky at gmail.com Sun Jan 7 15:57:52 2007 From: golubovsky at gmail.com (Dimitry Golubovsky) Date: Sun Jan 7 15:54:05 2007 Subject: Exception when compiling HAppS In-Reply-To: <4683d9370701070908j6944048alc2134c6a4d72ee1f@mail.gmail.com> References: <4683d9370701070908j6944048alc2134c6a4d72ee1f@mail.gmail.com> Message-ID: Hi, On 1/7/07, Kirsten Chevalier wrote: > > I am getting a strange error message when trying to compile > > HAppS-0.8.4 with ghc-6.4.1always on the same file. > > > [snip] > > *** Exception: waitForProcess: interrupted (Interrupted system call) > > > > This could mean a lot of things. What OS and platform are you using? > bash$ uname -a Linux dmghome 2.2.16 #9 Mon Sep 16 22:43:25 EDT 2002 i686 unknown -- Dimitry Golubovsky Anywhere on the Web From catamorphism at gmail.com Sun Jan 7 16:01:25 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Sun Jan 7 15:57:38 2007 Subject: Exception when compiling HAppS In-Reply-To: References: <4683d9370701070908j6944048alc2134c6a4d72ee1f@mail.gmail.com> Message-ID: <4683d9370701071301g6cd456dkab6026984edb7abc@mail.gmail.com> On 1/7/07, Dimitry Golubovsky wrote: > On 1/7/07, Kirsten Chevalier wrote: > > > > I am getting a strange error message when trying to compile > > > HAppS-0.8.4 with ghc-6.4.1always on the same file. > > > > > [snip] > > > *** Exception: waitForProcess: interrupted (Interrupted system call) > > > > > > > This could mean a lot of things. What OS and platform are you using? > > > > bash$ uname -a > Linux dmghome 2.2.16 #9 Mon Sep 16 22:43:25 EDT 2002 i686 unknown > By way of figuring out which system call is getting interrupted, can you run your "runghc" command with strace, like so: bash$ strace [whatever you were typing to build happs before] and paste the last couple of lines of strace's output? Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "What is research but a blind date with knowledge?" -- Will Henry From golubovsky at gmail.com Sun Jan 7 22:32:00 2007 From: golubovsky at gmail.com (Dimitry Golubovsky) Date: Sun Jan 7 22:28:13 2007 Subject: Exception when compiling HAppS In-Reply-To: <4683d9370701071301g6cd456dkab6026984edb7abc@mail.gmail.com> References: <4683d9370701070908j6944048alc2134c6a4d72ee1f@mail.gmail.com> <4683d9370701071301g6cd456dkab6026984edb7abc@mail.gmail.com> Message-ID: Hi, On 1/7/07, Kirsten Chevalier wrote: > By way of figuring out which system call is getting interrupted, can > you run your "runghc" command with strace, like so: > bash$ strace [whatever you were typing to build happs before] > and paste the last couple of lines of strace's output? Surprisingly, tonight I was able to get past that file, and compiled the whole package. So the question remains in semi-closed state. I hope that future versions of GHC will be more informative of which child process caused such error. -- Dimitry Golubovsky Anywhere on the Web From quarantedeux42 at yahoo.fr Wed Jan 10 16:24:40 2007 From: quarantedeux42 at yahoo.fr (Fernand Lacas) Date: Wed Jan 10 16:20:43 2007 Subject: HDirect and GHC-6.6 Message-ID: <20070110212440.77872.qmail@web27703.mail.ukl.yahoo.com> Hello, This is my first post on this mailing list and I hope it will not be too off-topic. My point is that I have worked a little on the porting of the last (0.21) version of HDirect (http://www.haskell.org/hdirect/) to ghc 6.6. I succeeded in compiling the ihc.exe (idl compiler) but I'm now stuck on the boot-strapping of the COM library (which is required to have support for Automation). This seems to come from a new feature of the package management system, which includes the package's name in the interface files (.hi). Alas, on the beginning of this new year (happy new year to you all), I lack time to understand the cabal system to solve this. I've written to the people mentioned in the README (and others), which are supposed to support the library, but got no answer. I assume they are no longer supporting it. Thus, I simply wanted to know if someone on this list, more involved with ghc or haskell's community, would be interested to have the sources files so that, may be in the near future, hdirect could be up to date with ghc, and also that other people could benefit from that small contribution without re-inventing the wheel (my changes are not complex, but rather tedious because I had to track all deprecated libraries, correct a GHC-specific bug). I also think that hdirect build process should be translated to Cabal's setup (it currently uses Makefiles, but the build process is not straightforward, so the adaptation requires a knowledge I do not have of Cabal). Sincerely yours, Samuel P.-S. I do not check this mail on a daily basis, so it is possible I won't answer immediately, but within one or two days. Excuse my french, it is my mother tongue. __________________________________________________ Do You Yahoo!? En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicit?s http://mail.yahoo.fr Yahoo! Mail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070110/4945b908/attachment.htm From marco-oweber at gmx.de Thu Jan 11 07:44:35 2007 From: marco-oweber at gmx.de (Marc Weber) Date: Thu Jan 11 06:40:37 2007 Subject: HDirect and GHC-6.6 In-Reply-To: <20070110212440.77872.qmail@web27703.mail.ukl.yahoo.com> References: <20070110212440.77872.qmail@web27703.mail.ukl.yahoo.com> Message-ID: <20070111124435.GA25673@gmx.de> On Wed, Jan 10, 2007 at 09:24:40PM +0000, Fernand Lacas wrote: > Hello, > This is my first post on this mailing list and I hope it will not be > too off-topic. > My point is that I have worked a little on the porting of the last > (0.21) version of HDirect ([1]http://www.haskell.org/hdirect/) to ghc > 6.6. I succeeded in compiling the ihc.exe (idl compiler) but I'm now > stuck on the boot-strapping of the COM library (which is required to > have support for Automation). > This seems to come >from a new feature of the package management > system, which includes the package's name in the interface files > (.hi). > Alas, on the beginning of this new year (happy new year to you all), I > lack time to understand the cabal system to solve this. I've written > to the people mentioned in the README (and others), which are supposed > to support the library, but got no answer. I assume they are no longer > supporting it. > Thus, I simply wanted to know if someone on this list, more involved > with ghc or haskell's community, would be interested to have the > sources files so that, may be in the near future, hdirect could be up > to date with ghc, and also that other people could benefit from that > small contribution without re-inventing the wheel (my changes are not > complex, but rather tedious because I had to track all deprecated > libraries, correct a GHC-specific bug). > I also think that hdirect build process should be translated to > Cabal's setup (it currently uses Makefiles, but the build process is > not straightforward, so the adaptation requires a knowledge I do not > have of Cabal). > Sincerely yours, > Samuel > P.-S. I do not check this mail on a daily basis, so it is possible I > won't answer immediately, but within one or two days. > Excuse my french, it is my mother tongue. Hi Samuel. I know. If you want to use hdirect with com support you need some kind of 2 stage build. I've tried to compile it some time ago and I failed (lack of knowledge and understanding haskell at that time).. So you did succeed? similar to ghc its using a 2 stage build. I will post a link to this message on cabal-devel@haskell.org avoiding cross-posting, too So we have by now 4 packagers having problems with the current cabal system? wxwidgets, gtk2hs, hdirect and ghc itself? Greetings Marc From cperfumo at gmail.com Thu Jan 11 07:32:58 2007 From: cperfumo at gmail.com (Cristian Perfumo) Date: Thu Jan 11 07:29:01 2007 Subject: GHC Runtime System In-Reply-To: References: Message-ID: Hi Friends. I'm trying to modify GHC runtime in order to add some new functions to STM API. Wich documentation (if there's any) do you suggest me to read? I mean... what's the starting point to learn how to link a Haskell function in STM.hs with a C function in STM.c? Regards. Cristian Perfumo From catamorphism at gmail.com Thu Jan 11 07:37:47 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Thu Jan 11 07:33:46 2007 Subject: GHC Runtime System In-Reply-To: References: Message-ID: <4683d9370701110437h4672367ep8dfa44e716463f6b@mail.gmail.com> On 1/11/07, Cristian Perfumo wrote: > Hi Friends. > I'm trying to modify GHC runtime in order to add some new functions > to STM API. Wich documentation (if there's any) do you suggest me to > read? I mean... what's the starting point to learn how to link a > Haskell function in STM.hs with a C function in STM.c? Check out: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts to start with. As you learn more, you can add to the commentary if you notice any places where it's incomplete. And if anything isn't clear, you can always ask about it on this mailing list. Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "'Compassion' doesn't mean 'letting fucktards do whatever they want just because they want it.'" -- lj user="uberwald" From haskell at list.mightyreason.com Thu Jan 11 08:14:05 2007 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Thu Jan 11 08:09:57 2007 Subject: GHC Runtime System In-Reply-To: References: Message-ID: <45A6381D.7090203@list.mightyreason.com> Cristian Perfumo wrote: > Hi Friends. > I'm trying to modify GHC runtime in order to add some new functions > to STM API. Wich documentation (if there's any) do you suggest me to > read? I mean... what's the starting point to learn how to link a > Haskell function in STM.hs with a C function in STM.c? > Regards. > Cristian Perfumo Out of curiosity, what additions or changes do you want to make? From sof at galois.com Thu Jan 11 10:53:59 2007 From: sof at galois.com (Sigbjorn Finne) Date: Thu Jan 11 10:50:32 2007 Subject: HDirect and GHC-6.6 In-Reply-To: <20070110212440.77872.qmail@web27703.mail.ukl.yahoo.com> References: <20070110212440.77872.qmail@web27703.mail.ukl.yahoo.com> Message-ID: <45A65D97.6020205@galois.com> Hi Samuel, you may want to check out the CVS version of HDirect, which does have a version of the compiler which is reasonably up-to-date wrt GHC + Cabalized versions of both the 'comlib' and 'hdirect' libraries. foo$ export CVSROOT=:pserver:anoncvs@cvs.haskell.org:/cvs foo$ cvs login (Logging in to anoncvs@cvs.haskell.org) CVS password: cvs foo$ cvs co fptools/hdirect (Derived from CVS setup instructions at http://cvs.haskell.org/ ) I apologize for not having the time to work on or support that code. hth --sigbjorn On 1/10/2007 13:24, Fernand Lacas wrote: > Hello, > > This is my first post on this mailing list and I hope it will not be > too off-topic. > My point is that I have worked a little on the porting of the last > (0.21) version of HDirect (http://www.haskell.org/hdirect/) to ghc > 6.6. I succeeded in compiling the ihc.exe (idl compiler) but I'm now > stuck on the boot-strapping of the COM library (which is required to > have support for Automation). > This seems to come from a new feature of the package management > system, which includes the package's name in the interface files (.hi). > Alas, on the beginning of this new year (happy new year to you all), I > lack time to understand the cabal system to solve this. I've written > to the people mentioned in the README (and others), which are supposed > to support the library, but got no answer. I assume they are no longer > supporting it. > > Thus, I simply wanted to know if someone on this list, more involved > with ghc or haskell's community, would be interested to have the > sources files so that, may be in the near future, hdirect could be up > to date with ghc, and also that other people could benefit from that > small contribution without re-inventing the wheel (my changes are not > complex, but rather tedious because I had to track all deprecated > libraries, correct a GHC-specific bug). > > I also think that hdirect build process should be translated to > Cabal's setup (it currently uses Makefiles, but the build process is > not straightforward, so the adaptation requires a knowledge I do not > have of Cabal). > > Sincerely yours, > > Samuel > > P.-S. I do not check this mail on a daily basis, so it is possible I > won't answer immediately, but within one or two days. > > Excuse my french, it is my mother tongue. > From rodrigogribeiro at gmail.com Thu Jan 11 11:27:06 2007 From: rodrigogribeiro at gmail.com (Rodrigo Geraldo) Date: Thu Jan 11 11:23:06 2007 Subject: Problems building GHC Message-ID: <21ba18fc0701110827k32ee8407o9a15e7db814f9fe6@mail.gmail.com> Hi! I start to "hack" GHC, and, I 've tried to build it, but the build return this error message : configure: GMP_CHECK_ASM_W32: fatal: do not know how to define a 32-bit word make[1]: *** [boot] Error 1 I've tried to build GHC using mSYS and MinGW under MS windows xp... Does anyone have any idea of how can I solve this problem? Thanks Rodrigo Geraldo Ribeiro PS: Sorry for my english... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070111/15b51013/attachment.htm From quarantedeux42 at yahoo.fr Thu Jan 11 16:25:48 2007 From: quarantedeux42 at yahoo.fr (Fernand Lacas) Date: Thu Jan 11 16:21:48 2007 Subject: HDirect and GHC-6.6 Message-ID: <20070111212548.23344.qmail@web27715.mail.ukl.yahoo.com> Hi, Yes, my point was indeed about the second compilation stage : once you have build the libs (comlib, the ihc tool and hdirect), you have to install them (com and hdirect) as packages in order to rebuild the ihc tool with the support for type libraries. At this point, the makefile-based build process fails, and I did not succeed in building the ihc tool with the support for typelibs without the packages because of my lack of knowledge with Cabal. Note that Sigbjorn Finne also kindly answered my post, so I will have look at the cvs version of hdirect. Sincerely yours, Samuel ----- Message d'origine ---- De : Marc Weber ? : glasgow-haskell-users@haskell.org Envoy? le : Jeudi, 11 Janvier 2007, 13h44mn 35s Objet : Re: HDirect and GHC-6.6 Hi Samuel. I know. If you want to use hdirect with com support you need some kind of 2 stage build. I've tried to compile it some time ago and I failed (lack of knowledge and understanding haskell at that time).. So you did succeed? similar to ghc its using a 2 stage build. I will post a link to this message on cabal-devel@haskell.org avoiding cross-posting, too So we have by now 4 packagers having problems with the current cabal system? wxwidgets, gtk2hs, hdirect and ghc itself? Greetings Marc _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___________________________________________________________________________ Nouveau : t?l?phonez moins cher avec Yahoo! Messenger ! D?couvez les tarifs exceptionnels pour appeler la France et l'international. T?l?chargez sur http://fr.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070111/2b964491/attachment.htm From shelarcy at gmail.com Fri Jan 12 01:49:23 2007 From: shelarcy at gmail.com (shelarcy) Date: Fri Jan 12 01:45:32 2007 Subject: HDirect and GHC-6.6 In-Reply-To: <45A65D97.6020205@galois.com> References: <20070110212440.77872.qmail@web27703.mail.ukl.yahoo.com> <45A65D97.6020205@galois.com> Message-ID: Hi Sigbjorn, Is there any plan to transition from CVS to darcs? HDirect is removed from darcs'ing fptools, and left cvs long ago. Because HDirect is not active. http://www.haskell.org/pipermail/cvs-ghc/2005-October/026817.html But HDirect is updated sometime. (We can see HDirect moves 'comlib' into a hierarchic setting, System.Win32.Com.* two month ago.) And Visual Haskell project changes comlib. http://www.haskell.org/pipermail/haskell/2006-September/018445.html http://www.haskell.org/pipermail/haskell-cafe/2006-September/018037.html Unfortunately these changes are independent. It forks comlib now. So I want to know what is common change both repository and what is useful change both version, easily. I think darcs'ing HDirect and two comlib branch realise it. And that helps to revive Visual Haskell's HDirect that can generate it's comlib source code. Best Regards, On Fri, 12 Jan 2007 00:53:59 +0900, Sigbjorn Finne wrote: > you may want to check out the CVS version of HDirect, which > does have a version of the compiler which is reasonably up-to-date > wrt GHC + Cabalized versions of both the 'comlib' and 'hdirect' > libraries. > > foo$ export CVSROOT=:pserver:anoncvs@cvs.haskell.org:/cvs > foo$ cvs login > (Logging in to anoncvs@cvs.haskell.org) > CVS password: cvs > foo$ cvs co fptools/hdirect > > (Derived from CVS setup instructions at http://cvs.haskell.org/ ) > > I apologize for not having the time to work on or support that code. -- shelarcy http://page.freett.com/shelarcy/ From kr.angelov at gmail.com Fri Jan 12 04:40:40 2007 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Fri Jan 12 04:36:39 2007 Subject: HDirect and GHC-6.6 In-Reply-To: References: <20070110212440.77872.qmail@web27703.mail.ukl.yahoo.com> <45A65D97.6020205@galois.com> Message-ID: Some time ago I even started to design my own comlib. It is quite different from HDirect's comlib but is more closer in spirit to Haskell's FFI lib. It isn't completed yet but if someone is interested in I would upload it in darcs next week. It is living in Foreign.COM namespace. Cheers, Krasimir On 1/12/07, shelarcy wrote: > Hi Sigbjorn, > > Is there any plan to transition from CVS to darcs? > > HDirect is removed from darcs'ing fptools, and left cvs long ago. > Because HDirect is not active. > > http://www.haskell.org/pipermail/cvs-ghc/2005-October/026817.html > > But HDirect is updated sometime. > (We can see HDirect moves 'comlib' into a hierarchic setting, > System.Win32.Com.* two month ago.) > > And Visual Haskell project changes comlib. > http://www.haskell.org/pipermail/haskell/2006-September/018445.html > http://www.haskell.org/pipermail/haskell-cafe/2006-September/018037.html > > Unfortunately these changes are independent. It forks comlib now. > So I want to know what is common change both repository and what > is useful change both version, easily. > > I think darcs'ing HDirect and two comlib branch realise it. And > that helps to revive Visual Haskell's HDirect that can generate > it's comlib source code. > > > Best Regards, > > > On Fri, 12 Jan 2007 00:53:59 +0900, Sigbjorn Finne wrote: > > you may want to check out the CVS version of HDirect, which > > does have a version of the compiler which is reasonably up-to-date > > wrt GHC + Cabalized versions of both the 'comlib' and 'hdirect' > > libraries. > > > > foo$ export CVSROOT=:pserver:anoncvs@cvs.haskell.org:/cvs > > foo$ cvs login > > (Logging in to anoncvs@cvs.haskell.org) > > CVS password: cvs > > foo$ cvs co fptools/hdirect > > > > (Derived from CVS setup instructions at http://cvs.haskell.org/ ) > > > > I apologize for not having the time to work on or support that code. > > -- > shelarcy > http://page.freett.com/shelarcy/ > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From kyrab at mail.ru Fri Jan 12 06:39:13 2007 From: kyrab at mail.ru (kyra) Date: Fri Jan 12 06:35:15 2007 Subject: HDirect and GHC-6.6 In-Reply-To: References: <20070110212440.77872.qmail@web27703.mail.ukl.yahoo.com> <45A65D97.6020205@galois.com> Message-ID: <45A77361.8090400@mail.ru> Krasimir Angelov wrote: > Some time ago I even started to design my own comlib. It is quite > different from HDirect's comlib but is more closer in spirit to > Haskell's FFI lib. It isn't completed yet but if someone is interested > in I would upload it in darcs next week. It is living in Foreign.COM > namespace. I'm very interested in such a library. I've also developed my own com (client) library, but as for now it is too raw to be published. Cheers, Kyra From cmb21 at kent.ac.uk Fri Jan 12 08:34:50 2007 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Fri Jan 12 08:31:02 2007 Subject: ghc 6.6.1? Message-ID: Hi, I was wondering when ghc-6.6.1 will be released? I am asking because a patch has been made to the ghc repo to allow multple calls to the ghc.newSession within the API and HaRe depends on this. Regards, Chris. From p.tanski at gmail.com Fri Jan 12 10:12:22 2007 From: p.tanski at gmail.com (Peter Tanski) Date: Fri Jan 12 10:08:29 2007 Subject: Problems building GHC Message-ID: Hello, Rodrigo Geraldo wrote: > I start to "hack" GHC, and, I 've tried to build it, but the build > return > this error message : > > configure: GMP_CHECK_ASM_W32: fatal: do not know how to define a 32- > bit word > make[1]: *** [boot] Error 1 > > I've tried to build GHC using mSYS and MinGW under MS windows xp... This is an error from the internal GMP library's configure file, $ (top_level)/rts/gmp/configure. If you don't have gmp installed already, the GHC build system tries to build it for you. The build system for gmp is very delicate so I would suggest downloading a separate gmp library and installing that in your /usr/lib directory (for MinGW). The gmp library and header file for MinGW, avaliable from http://cs.nyu.edu/exact/core/gmp/ under 'gmp-static- mingw-4.1.tar.gz'. Once you have the library installed properly, the GHC build system will find it and won't attempt to build gmp. I know it sounds like a workaround--we really ought to ensure the gmp build itself works--but in this case it is the gmp build that fails (swox.org's problem, not ours) and the current gmp system should be replaced soon by another library. (I am working on that but for lack of time I am running a bit late.) Cheers, Peter Tanski From dcmorse at gmail.com Fri Jan 12 12:32:47 2007 From: dcmorse at gmail.com (David Morse) Date: Fri Jan 12 12:28:46 2007 Subject: ghc: out of memory error while compiling huge "let" Message-ID: <11f192740701120932jc4518f0o7e60f618f65a190b@mail.gmail.com> I have a machine-generated source-code file that brings my computer to its knees with ghc-6.6. After an hour or so of rummaging around, ghc dies with: "ghc-6.6: out of memory (requested 1048576 bytes)". The linux machine has 1gb RAM and 2gb swap, and I don't have access to a better one. The file is of the form ------------------------------------------- module foo (a,b) where (a,b) = let ...10,300 bindings... ; in ([a1,a2,a3...a300],[b1,b2,b3...b10000]) -------------------------------------------- Is there some simple syntactic refactoring I can do to make this work? E.g. busting the local bindings out of the "let" and into to the global level? The bindings are intertwined, but I could (with some effort) reorder them so that b5000 would only reference b5001...b10000 and never b1...b4999. From catamorphism at gmail.com Fri Jan 12 12:44:38 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Fri Jan 12 12:40:34 2007 Subject: ghc: out of memory error while compiling huge "let" In-Reply-To: <11f192740701120932jc4518f0o7e60f618f65a190b@mail.gmail.com> References: <11f192740701120932jc4518f0o7e60f618f65a190b@mail.gmail.com> Message-ID: <4683d9370701120944k25773cbfke225a647ed26fe98@mail.gmail.com> On 1/12/07, David Morse wrote: > > Is there some simple syntactic refactoring I can do to make this work? > E.g. busting the local bindings out of the "let" and into to the > global level? > > The bindings are intertwined, but I could (with some effort) reorder > them so that b5000 would only reference b5001...b10000 and never > b1...b4999. Somehow I doubt that the answer is going to be that simple, but for starters, what's your ghc command line? (In particular, are you compiling with -O or not? If ghc is eating that much memory than I'd assume you are, but one should never assume.) Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "by God I *KNOW* what this network is for, and you can't have it."--Russ Allbery From ndmitchell at gmail.com Fri Jan 12 12:47:21 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Jan 12 12:43:27 2007 Subject: ghc: out of memory error while compiling huge "let" In-Reply-To: <11f192740701120932jc4518f0o7e60f618f65a190b@mail.gmail.com> References: <11f192740701120932jc4518f0o7e60f618f65a190b@mail.gmail.com> Message-ID: <404396ef0701120947w16a645b5w15be82c502c72303@mail.gmail.com> Hi David, I found that GHC is O(n^2) in terms of the number of lines in a do block, so by splitting up a huge 1000 line do block in to 10 x 100 line do blocks, I was able to get a massive compile time boost. Perhaps you might have similar luck with let's. If you do, report a bug! Thanks Neil On 1/12/07, David Morse wrote: > I have a machine-generated source-code file that brings my computer to > its knees with ghc-6.6. After an hour or so of rummaging around, ghc > dies with: "ghc-6.6: out of memory (requested 1048576 bytes)". The > linux machine has 1gb RAM and 2gb swap, and I don't have access to a > better one. > > The file is of the form > ------------------------------------------- > module foo (a,b) where > > (a,b) = let ...10,300 bindings... ; in ([a1,a2,a3...a300],[b1,b2,b3...b10000]) > -------------------------------------------- > > Is there some simple syntactic refactoring I can do to make this work? > E.g. busting the local bindings out of the "let" and into to the > global level? > > The bindings are intertwined, but I could (with some effort) reorder > them so that b5000 would only reference b5001...b10000 and never > b1...b4999. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From dcmorse at gmail.com Fri Jan 12 13:03:15 2007 From: dcmorse at gmail.com (David Morse) Date: Fri Jan 12 12:59:10 2007 Subject: ghc: out of memory error while compiling huge "let" In-Reply-To: <4683d9370701120944k25773cbfke225a647ed26fe98@mail.gmail.com> References: <11f192740701120932jc4518f0o7e60f618f65a190b@mail.gmail.com> <4683d9370701120944k25773cbfke225a647ed26fe98@mail.gmail.com> Message-ID: <11f192740701121003m7abd7fafj8770622760959fb8@mail.gmail.com> On 1/12/07, Kirsten Chevalier wrote: > for starters, what's your ghc command line? hmake -package HaXml -package HTTP GraphCache.hs ghc-6.6 -package HaXml -package HTTP -c -o GraphCache.o GraphCache.hs ghc-6.6: out of memory (requested 1048576 bytes) From p.tanski at gmail.com Fri Jan 12 16:44:06 2007 From: p.tanski at gmail.com (Peter Tanski) Date: Fri Jan 12 16:40:23 2007 Subject: rfc: colorized Haskell on GHC-Trac Message-ID: <17A922BC-4EFD-4A6B-BCF0-DAC344B8065A@gmail.com> To anyone who has an interest in reading GHC-Trac: In an idle-procrastination moment I started to experiment with html- colour for Haskell code (using hscolour) on a few Trac pages: http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes (some blocks, note Cyan-colour for literal integrals ("1")) http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes/ TheCurrentGMPImplementation (one-line snippets) http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/CmmType (large blocks) What do you think? Better? Worse? Would you rather see a silver/grey background as for other code? Personally I tend to prefer the Orange for top-level function definitions but don't quite know about orange- colour functions as they are used. Most of this is close to emacs- colour codes. For those who are interested in playing around, the easy way to do this is: demarcate a code block: {{{ #!html 
	topLevelFunction ...
}}} Thanks, Peter Tanski From catamorphism at gmail.com Sun Jan 14 15:21:49 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Sun Jan 14 15:17:38 2007 Subject: [Haskell-cafe] Meaning abbreviations stat file GHC In-Reply-To: <87d4647e0701131411n1793dc7fo2508eaf2af59e1c7@mail.gmail.com> References: <87d4647e0701131411n1793dc7fo2508eaf2af59e1c7@mail.gmail.com> Message-ID: <4683d9370701141221u66e0acc4mc1ec77e228957ca5@mail.gmail.com> [redirecting to ghc-users] On 1/13/07, Ron wrote: > Dear, > > I made a profile[1] of a test program: > Where can I find documentation for the meaning of everything mentioned > below? Or alternatively, can anyone explain them? > > Where can I see the effect of using the -xt option in this profile? > > Ron > > [1] > /Main +RTS -p -s -xt -hc > 1,372,408,024 bytes allocated in the heap > 121,255,600 bytes copied during GC (scavenged) > 6,584,692 bytes copied during GC (not scavenged) > 2,768,896 bytes maximum residency (68 sample(s)) > > 2649 collections in generation 0 ( 1.11s) > 68 collections in generation 1 ( 0.49s) > > 6 Mb total memory in use > > INIT time 0.00s ( 0.00s elapsed) > MUT time 5.97s ( 6.63s elapsed) > GC time 1.60s ( 1.88s elapsed) > RP time 0.00s ( 0.00s elapsed) > PROF time 0.19s ( 0.20s elapsed) > EXIT time 0.00s ( 0.00s elapsed) > Total time 7.76s ( 8.71s elapsed) > > %GC time 20.6% (21.5% elapsed) > > Alloc rate 229,946,873 bytes per MUT second > > Productivity 76.9% of total user, 68.5% of total elapsed > I don't think that the format of this file is documented anywhere (though it should be), but this information is really meant for GHC implementors. Have you looked at the chapter on profiling in the GHC manual yet? http://www.haskell.org/ghc/docs/latest/html/users_guide/profiling.html There's also a very sketchy intro to profiling in the GHC Commentary: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Profiling and you're welcome to improve it. If the above documentation doesn't answer your questions, feel free to reply to this mailing list with more specific questions; it might help to explain exactly what you're trying to find out about your program's behavior. Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "What is research but a blind date with knowledge?" -- Will Henry From iampure at gmail.com Sun Jan 14 18:01:22 2007 From: iampure at gmail.com (Ron) Date: Sun Jan 14 17:57:14 2007 Subject: [Haskell-cafe] Meaning abbreviations stat file GHC In-Reply-To: <4683d9370701141221u66e0acc4mc1ec77e228957ca5@mail.gmail.com> References: <87d4647e0701131411n1793dc7fo2508eaf2af59e1c7@mail.gmail.com> <4683d9370701141221u66e0acc4mc1ec77e228957ca5@mail.gmail.com> Message-ID: <87d4647e0701141501u2c912e7apbf29a9c6d8c07ccb@mail.gmail.com> 2007/1/14, Kirsten Chevalier : > [redirecting to ghc-users] > > On 1/13/07, Ron wrote: > > Dear, > > > > I made a profile[1] of a test program: > > Where can I find documentation for the meaning of everything mentioned > > below? Or alternatively, can anyone explain them? > > > > Where can I see the effect of using the -xt option in this profile? > > > > Ron > > > > [1] > > /Main +RTS -p -s -xt -hc > > 1,372,408,024 bytes allocated in the heap > > 121,255,600 bytes copied during GC (scavenged) > > 6,584,692 bytes copied during GC (not scavenged) > > 2,768,896 bytes maximum residency (68 sample(s)) > > > > 2649 collections in generation 0 ( 1.11s) > > 68 collections in generation 1 ( 0.49s) > > > > 6 Mb total memory in use > > > > INIT time 0.00s ( 0.00s elapsed) > > MUT time 5.97s ( 6.63s elapsed) > > GC time 1.60s ( 1.88s elapsed) > > RP time 0.00s ( 0.00s elapsed) > > PROF time 0.19s ( 0.20s elapsed) > > EXIT time 0.00s ( 0.00s elapsed) > > Total time 7.76s ( 8.71s elapsed) > > > > %GC time 20.6% (21.5% elapsed) > > > > Alloc rate 229,946,873 bytes per MUT second > > > > Productivity 76.9% of total user, 68.5% of total elapsed > > > > I don't think that the format of this file is documented anywhere > (though it should be), but this information is really meant for GHC > implementors. Have you looked at the chapter on profiling in the GHC > manual yet? > http://www.haskell.org/ghc/docs/latest/html/users_guide/profiling.html Yes, I spend quite some time on it and have some experience with the cost centres from another project I worked on. > There's also a very sketchy intro to profiling in the GHC Commentary: > http://hackage.haskell.org/trac/ghc/wiki/Commentary/Profiling > and you're welcome to improve it. The ticky option was documented to be for implementors, IIRC. The stat file seemed to be intended for mere mortals, but maybe I misunderstood. > > If the above documentation doesn't answer your questions, feel free to > reply to this mailing list with more specific questions; it might help > to explain exactly what you're trying to find out about your program's > behavior. Ok, the real question is that I want to measure the exact space and time behaviour of a few implementations of algorithms for _scientific_ purposes(i.e. "experimental algorithmic research"). Measuring time in a lazy language is somewhat hard, since you don't want to count the amount of time it takes to create the initial data structures, nor the time it takes to print the result. With some help a scheme was devised to solve this by something like this: main = do f<-readFile "someFileWithData.dat" g<-buildDataStructure f print g==g --force graph construction result <- computeAnswer g print result == result --force complete result By doing several things multiple times, it should be possible to derive how long computeAnswer actually takes, since that's the number I am interested in. A similar thing can be done for space usage, I think, but since I don't understand everything(and I mean everything) that is in the .stat file, there's little point in starting the endeavour. As, I already mentioned, I wasn't able to see what the -xt option changed in the .stat file, but it's important that I do measure the total amount of memory the expression uses(thus including the stack). The real question thus is: how to measure the time and space of a single expression reliably and correctly (where the argument (or all arguments) to that expression is(are) fully evaluated already)? In case you think that doing the measurements in this way is wrong, feel free to tell how it is usually done. I am also a little unsure about how lazyness in for example the State monad works (the building up of giant unevaluated thunks is something I want to avoid) or what difference it makes when I wrap monads in transformer monads(e.g. MaybeT) on it. In fact, I would like to be able to predict before the program runs what its space behaviour will be, but maybe I am asking for too much. I would like to _reason_ about the space usage, such that even when GHC has optimisation turned off, I still _know_ and not _hope_ it uses only a certain amount of memory, for example. A natural question to ask would be whether there's something wrong with Haskell if a user can't do this. I also wonder where the thunks I mentioned earlier actually end up in memory(i.e. heap or stack), but that's just curiosity for this moment. I read half of the STG-machine paper once, but I can't remember the precise contents, though. Regards, Ron From simonmarhaskell at gmail.com Mon Jan 15 09:31:50 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Jan 15 09:27:48 2007 Subject: IOExts problem In-Reply-To: <8158283.post@talk.nabble.com> References: <8158283.post@talk.nabble.com> Message-ID: <45AB9056.3000902@microsoft.com> jim burton wrote: > IOExts seems to be unavailable on my system, whereas I'm guessing it should > be since the file /usr/lib/ghc-6.4.1/hslibs-imports/lang/IOExts.hi > exists...(wrong guess?) Within ghci I get > > Prelude> :m IOExts > Could not find module `IOExts': > it is not a module in the current program, or in any known package. > Prelude> IOExts is (was) in the 'lang' package, which is hidden by default, so you need to say '-package lang' to get it. Bear in mind that lang has been deprecated for a long time, and is gone completely in GHC 6.6, though. Cheers, Simon From simonmarhaskell at gmail.com Mon Jan 15 09:47:26 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Jan 15 09:43:23 2007 Subject: ghc 6.6.1? In-Reply-To: References: Message-ID: <45AB93FE.6090804@microsoft.com> C.M.Brown wrote: > I was wondering when ghc-6.6.1 will be released? I am asking because a > patch has been made to the ghc repo to allow multple calls to the > ghc.newSession within the API and HaRe depends on this. We haven't fixed a deadline yet, since there are a large number of outstanding bugs milestoned for 6.6.1. I'd expect a release within a couple of months, something like that. Cheers, Simon From simonmarhaskell at gmail.com Mon Jan 15 09:58:19 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Jan 15 09:54:12 2007 Subject: ghc: out of memory error while compiling huge "let" In-Reply-To: <404396ef0701120947w16a645b5w15be82c502c72303@mail.gmail.com> References: <11f192740701120932jc4518f0o7e60f618f65a190b@mail.gmail.com> <404396ef0701120947w16a645b5w15be82c502c72303@mail.gmail.com> Message-ID: <45AB968B.3050501@microsoft.com> Neil Mitchell wrote: > I found that GHC is O(n^2) in terms of the number of lines in a do > block, so by splitting up a huge 1000 line do block in to 10 x 100 > line do blocks, I was able to get a massive compile time boost. > Perhaps you might have similar luck with let's. Didn't we fix the do-block blowup? Certainly do submit a bug report if you find GHC going O(n^2) or worse on any particular construct, usually we can find the culprit and fix it. Cheers, Simon From ganesh.sittampalam at credit-suisse.com Mon Jan 15 11:00:51 2007 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Mon Jan 15 10:56:45 2007 Subject: No intellisense in Visual Haskell Message-ID: <8C984B4799C04D4B8F80F746537145E10D6B0FFA@elon12p32001.csfp.co.uk> Hi, I've installed Visual Haskell and am having some trouble with the Intellisense functionality. It works fine on a small project I start from scratch, but doesn't work at all for a bigger project (no tooltips, "Go to Definition" doesn't work, etc etc). Is there any way to debug this? Cheers, Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From mnislaih at gmail.com Mon Jan 15 11:06:22 2007 From: mnislaih at gmail.com (Pepe Iborra) Date: Mon Jan 15 11:02:13 2007 Subject: No intellisense in Visual Haskell In-Reply-To: <8C984B4799C04D4B8F80F746537145E10D6B0FFA@elon12p32001.csfp.co.uk> References: <8C984B4799C04D4B8F80F746537145E10D6B0FFA@elon12p32001.csfp.co.uk> Message-ID: Ganesh, In my experience as a user, it seems that Intellisense stops working in presence of compilation errors. Have you checked this? Cheers pepe On 15/01/2007, at 17:00, Sittampalam, Ganesh wrote: > Hi, > > I've installed Visual Haskell and am having some trouble with the > Intellisense functionality. It works fine on a small project I > start from scratch, but doesn't work at all for a bigger project > (no tooltips, "Go to Definition" doesn't work, etc etc). Is there > any way to debug this? > > Cheers, > > Ganesh > > ====================================================================== > ======== > Please access the attached hyperlink for an important electronic > communications disclaimer: > > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > ====================================================================== > ======== > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From ganesh.sittampalam at credit-suisse.com Mon Jan 15 11:08:11 2007 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Mon Jan 15 11:04:20 2007 Subject: No intellisense in Visual Haskell Message-ID: <8C984B4799C04D4B8F80F746537145E10D6B0FFB@elon12p32001.csfp.co.uk> Sorry, I forgot to make clear that the project builds fine from inside the IDE. -----Original Message----- From: Pepe Iborra [mailto:mnislaih@gmail.com] Sent: 15 January 2007 16:06 To: Sittampalam, Ganesh Cc: 'GHC users' Subject: Re: No intellisense in Visual Haskell Ganesh, In my experience as a user, it seems that Intellisense stops working in presence of compilation errors. Have you checked this? Cheers pepe On 15/01/2007, at 17:00, Sittampalam, Ganesh wrote: > Hi, > > I've installed Visual Haskell and am having some trouble with the > Intellisense functionality. It works fine on a small project I start > from scratch, but doesn't work at all for a bigger project (no > tooltips, "Go to Definition" doesn't work, etc etc). Is there any way > to debug this? > > Cheers, > > Ganesh > > ====================================================================== > ======== > Please access the attached hyperlink for an important electronic > communications disclaimer: > > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > ====================================================================== > ======== > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From kr.angelov at gmail.com Mon Jan 15 11:47:38 2007 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Mon Jan 15 11:43:29 2007 Subject: No intellisense in Visual Haskell In-Reply-To: <8C984B4799C04D4B8F80F746537145E10D6B0FFB@elon12p32001.csfp.co.uk> References: <8C984B4799C04D4B8F80F746537145E10D6B0FFB@elon12p32001.csfp.co.uk> Message-ID: It could help if you can provide an example that breaks the intellisense of Visual Haskell. It doesn't depend on the project size but perhaps you have found a bug in it. Cheers, Krasimir On 1/15/07, Sittampalam, Ganesh wrote: > Sorry, I forgot to make clear that the project builds fine from inside the IDE. > > -----Original Message----- > From: Pepe Iborra [mailto:mnislaih@gmail.com] > Sent: 15 January 2007 16:06 > To: Sittampalam, Ganesh > Cc: 'GHC users' > Subject: Re: No intellisense in Visual Haskell > > Ganesh, > > In my experience as a user, it seems that Intellisense stops working in presence of compilation errors. Have you checked this? > > Cheers > pepe > > On 15/01/2007, at 17:00, Sittampalam, Ganesh wrote: > > > Hi, > > > > I've installed Visual Haskell and am having some trouble with the > > Intellisense functionality. It works fine on a small project I start > > from scratch, but doesn't work at all for a bigger project (no > > tooltips, "Go to Definition" doesn't work, etc etc). Is there any way > > to debug this? > > > > Cheers, > > > > Ganesh > > > > ====================================================================== > > ======== > > Please access the attached hyperlink for an important electronic > > communications disclaimer: > > > > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > > ====================================================================== > > ======== > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > ============================================================================== > Please access the attached hyperlink for an important electronic communications disclaimer: > > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > ============================================================================== > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From ganesh.sittampalam at credit-suisse.com Mon Jan 15 12:32:24 2007 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Mon Jan 15 12:28:21 2007 Subject: No intellisense in Visual Haskell Message-ID: <8C984B4799C04D4B8F80F746537145E10D6B0FFC@elon12p32001.csfp.co.uk> OK, I found the problem while trying to make a cut-down test case. I had a module called Main, but the file was called FooMain.hs - this was causing all the intellisense for every project in my solution to break. I've worked round it by renaming my module to FooMain and passing -main-is in the GHC options, but I'd be inclined to view this as a bug, as I think this is a fairly standard way of working with modules - what do you think? Cheers, Ganesh -----Original Message----- From: Krasimir Angelov [mailto:kr.angelov@gmail.com] Sent: 15 January 2007 16:48 To: Sittampalam, Ganesh Cc: Pepe Iborra; GHC users Subject: Re: No intellisense in Visual Haskell It could help if you can provide an example that breaks the intellisense of Visual Haskell. It doesn't depend on the project size but perhaps you have found a bug in it. Cheers, Krasimir On 1/15/07, Sittampalam, Ganesh wrote: > Sorry, I forgot to make clear that the project builds fine from inside the IDE. > > -----Original Message----- > From: Pepe Iborra [mailto:mnislaih@gmail.com] > Sent: 15 January 2007 16:06 > To: Sittampalam, Ganesh > Cc: 'GHC users' > Subject: Re: No intellisense in Visual Haskell > > Ganesh, > > In my experience as a user, it seems that Intellisense stops working in presence of compilation errors. Have you checked this? > > Cheers > pepe > > On 15/01/2007, at 17:00, Sittampalam, Ganesh wrote: > > > Hi, > > > > I've installed Visual Haskell and am having some trouble with the > > Intellisense functionality. It works fine on a small project I start > > from scratch, but doesn't work at all for a bigger project (no > > tooltips, "Go to Definition" doesn't work, etc etc). Is there any way > > to debug this? > > > > Cheers, > > > > Ganesh > > > > ====================================================================== > > ======== > > Please access the attached hyperlink for an important electronic > > communications disclaimer: > > > > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > > ====================================================================== > > ======== > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > ============================================================================== > Please access the attached hyperlink for an important electronic communications disclaimer: > > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > ============================================================================== > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From ndmitchell at gmail.com Mon Jan 15 12:55:01 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Jan 15 12:50:52 2007 Subject: ghc: out of memory error while compiling huge "let" In-Reply-To: <45AB968B.3050501@microsoft.com> References: <11f192740701120932jc4518f0o7e60f618f65a190b@mail.gmail.com> <404396ef0701120947w16a645b5w15be82c502c72303@mail.gmail.com> <45AB968B.3050501@microsoft.com> Message-ID: <404396ef0701150955o5fb9f4e0ld1243d20ea6ab793@mail.gmail.com> Hi > Didn't we fix the do-block blowup? You did, I just checked on GHC 6.6. I reported it before the bug tracker was in full swing so never got to see it get closed. Thanks Neil From dkirkman at gmail.com Mon Jan 15 21:03:48 2007 From: dkirkman at gmail.com (David Kirkman) Date: Mon Jan 15 21:00:04 2007 Subject: HEAD ghci crash on ppc OS X Message-ID: <92345750-4835-4407-A619-B4A4BCB6FB09@gmail.com> I just built ghc from HEAD on OS X (ppc), and get the following error when starting ghci: ---start [15:15:15][david@isengard]$ compiler/stage2/ghc-inplace --interactive ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.7, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. ghc-6.7(9972,0xa000ed88) malloc: *** error for object 0x3807ff8: pointer being reallocated was not allocated ghc-6.7(9972,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug malloc: failed on request for 11359964 bytes; message: ocAllocateJumpIslands ---end despite the suggestion, a breakpoint in szone_error catches nothing. But a breakpoint in malloc_printf (both szone_error and malloc_printf in the OS, not ghc) gives the following backtrace for an rts compiled with the -g flag: --start Breakpoint 1, 0x9012bb94 in malloc_printf () (gdb) bt #0 0x9012bb94 in malloc_printf () #1 0x90018388 in szone_realloc () #2 0x90018098 in realloc () #3 0x00e6f5c4 in stgReallocBytes (p=0x901a4df4, n=11359964, msg=0xfd9704 "ocAllocateJumpIslands") at RtsUtils.c:209 #4 0x00e97cbc in ocAllocateJumpIslands (oc=0x2b005d0, count=372, first=14502) at Linker.c:1598 #5 0x00e98954 in loadObj (path=0x2e63268 "/Network/Sid/Users/david/ ghc-crap/ghc/libraries/base/HSbase.o") at Linker.c:3743 #6 0x005b660c in s1wt_info () #7 0x00e8a220 in schedule (initialCapability=0x901a4df4, task=0x2e63268) at Schedule.c:608 #8 0x00c60e18 in main (argc=-1877324300, argv=0x3807ff8) at Main.c:105 (gdb) --end The call to failing call to stgReallocBytes occurs at line 1598 of Linker.c, in the following context: --start Linker.c, lines 1597 --> 1602 oc->image -= misalignment; oc->image = stgReallocBytes( oc->image, misalignment + aligned + sizeof (ppcJumpIsland) * count, "ocAllocateJumpIslands" ); oc->image += misalignment; --end oc->image is allocated at line 1326 of Linker.c (listing below), and then never modified until misalignment is subtracted from it at line 1598. Both the comment in the code fragment below, and the actual code in the fragment above seem to indicate that oc->image should be offset by misalignment. --start Linker.c, lines 1315 --> 1327 # elif defined(darwin_HOST_OS) // In a Mach-O .o file, all sections can and will be misaligned // if the total size of the headers is not a multiple of the // desired alignment. This is fine for .o files that only serve // as input for the static linker, but it's not fine for us, // as SSE (used by gcc for floating point) and Altivec require // 16-byte alignment. // We calculate the correct alignment from the header before // reading the file, and then we misalign oc->image on purpose so // that the actual sections end up aligned again. oc->misalignment = machoGetMisalignment(f); oc->image = stgMallocBytes(oc->fileSize + oc->misalignment, "loadObj(image)"); # else ---end The comment above seems to be begging for a oc->image += oc->misalignment; statement right after the call to stgMallocBytes. But I'm assuming it must normally be done someplace else -- I just can't figure out where. Anyway, I've verified that os->image is still pointing to the value returned from stgMallocBytes when misalignment (non-zero) is subtracted from it just before the call to stgReallocBytes. So in my build at least, the execution path is not hitting whatever part of the code that should be applying the misalignment offset to oc->image. Let me know if there is any more information I can give. -david k. From naur at post11.tele.dk Tue Jan 16 00:57:43 2007 From: naur at post11.tele.dk (Thorkil Naur) Date: Tue Jan 16 00:57:43 2007 Subject: HEAD ghci crash on ppc OS X In-Reply-To: <92345750-4835-4407-A619-B4A4BCB6FB09@gmail.com> References: <92345750-4835-4407-A619-B4A4BCB6FB09@gmail.com> Message-ID: <200701160657.43771.naur@post11.tele.dk> Hello, I get a similar reaction starting ghci built from a ghc-HEAD pulled 2007-Jan-12 on a PPC Mac OS X 10.4. Best regards Thorkil On Tuesday 16 January 2007 03:03, David Kirkman wrote: > > I just built ghc from HEAD on OS X (ppc), and get the following error > when starting ghci: > > ---start > [15:15:15][david@isengard]$ compiler/stage2/ghc-inplace --interactive > ___ ___ _ > / _ \ /\ /\/ __(_) > / /_\// /_/ / / | | GHC Interactive, version 6.7, for Haskell 98. > / /_\\/ __ / /___| | http://www.haskell.org/ghc/ > \____/\/ /_/\____/|_| Type :? for help. > > ghc-6.7(9972,0xa000ed88) malloc: *** error for object 0x3807ff8: > pointer being reallocated was not allocated > ghc-6.7(9972,0xa000ed88) malloc: *** set a breakpoint in szone_error > to debug > malloc: failed on request for 11359964 bytes; message: > ocAllocateJumpIslands > ---end > > despite the suggestion, a breakpoint in szone_error catches nothing. > But a breakpoint in malloc_printf (both szone_error and malloc_printf > in the OS, not ghc) gives the following backtrace for an rts compiled > with the -g flag: > > --start > Breakpoint 1, 0x9012bb94 in malloc_printf () > (gdb) bt > #0 0x9012bb94 in malloc_printf () > #1 0x90018388 in szone_realloc () > #2 0x90018098 in realloc () > #3 0x00e6f5c4 in stgReallocBytes (p=0x901a4df4, n=11359964, > msg=0xfd9704 "ocAllocateJumpIslands") at RtsUtils.c:209 > #4 0x00e97cbc in ocAllocateJumpIslands (oc=0x2b005d0, count=372, > first=14502) at Linker.c:1598 > #5 0x00e98954 in loadObj (path=0x2e63268 "/Network/Sid/Users/david/ > ghc-crap/ghc/libraries/base/HSbase.o") at Linker.c:3743 > #6 0x005b660c in s1wt_info () > #7 0x00e8a220 in schedule (initialCapability=0x901a4df4, > task=0x2e63268) at Schedule.c:608 > #8 0x00c60e18 in main (argc=-1877324300, argv=0x3807ff8) at Main.c:105 > (gdb) > --end > > > The call to failing call to stgReallocBytes occurs at line 1598 of > Linker.c, in the following context: > > --start Linker.c, lines 1597 --> 1602 > oc->image -= misalignment; > oc->image = stgReallocBytes( oc->image, > misalignment + > aligned + sizeof (ppcJumpIsland) * > count, > "ocAllocateJumpIslands" ); > oc->image += misalignment; > --end > > oc->image is allocated at line 1326 of Linker.c (listing below), and > then never modified until misalignment is subtracted from it at line > 1598. Both the comment in the code fragment below, and the actual > code in the fragment above seem to indicate that oc->image should be > offset by misalignment. > > --start Linker.c, lines 1315 --> 1327 > # elif defined(darwin_HOST_OS) > // In a Mach-O .o file, all sections can and will be misaligned > // if the total size of the headers is not a multiple of the > // desired alignment. This is fine for .o files that only serve > // as input for the static linker, but it's not fine for us, > // as SSE (used by gcc for floating point) and Altivec require > // 16-byte alignment. > // We calculate the correct alignment from the header before > // reading the file, and then we misalign oc->image on purpose so > // that the actual sections end up aligned again. > oc->misalignment = machoGetMisalignment(f); > oc->image = stgMallocBytes(oc->fileSize + oc->misalignment, > "loadObj(image)"); > # else > ---end > > The comment above seems to be begging for a > > oc->image += oc->misalignment; > > statement right after the call to stgMallocBytes. But I'm assuming it > must normally be done someplace else -- I just can't figure out where. > Anyway, I've verified that os->image is still pointing to the value > returned from stgMallocBytes when misalignment (non-zero) is > subtracted from it just before the call to stgReallocBytes. So in > my build at least, the execution path is not hitting whatever part > of the code that should be applying the misalignment offset to > oc->image. > > Let me know if there is any more information I can give. > > -david k. > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From bernd.holzmueller at ics-ag.de Tue Jan 16 05:59:23 2007 From: bernd.holzmueller at ics-ag.de (=?ISO-8859-15?Q?Bernd_Holzm=FCller?=) Date: Tue Jan 16 05:55:12 2007 Subject: Matching word boundaries in Text.Regexp Message-ID: <45ACB00B.8040206@ics-ag.de> I would like to match word boundaries in a regular expression but this doesn't seem to work with Text.Regex in GHC 6.4.2. The regular expression looks something like: "\\b(send|receive)\\b" to match either the keyword send or the keyword receive but not the word sending. Neither works \< and \> for matching the beginning and end of a word. Thanks for any help, Bernd From gale at sefer