Re: [Haskell-cafe] Type family oddity
Claus Reinke wrote: Btw, is there a list of common TF pitfalls somewhere? Some example items so far seem to be: 1 'C a = TF a', where 'a' isn't determinable 2 'TF a' is not fully polymorphic 3 'TF a' is not a decomposable type constructor, it stands only for itself, or for its result (in that way it is more like a defined function application) For 1/2, it is helpful to flatten type family applications: - 'C a = TF a' becomes: '(C a,TF a~tfa) = tfa' - 'TF a' becomes: 'TF a~tfa = tfa' For 3, it is helpful to imagine the arity of type families being marked by braces, to distinguish type family parameters from any constructor parameters, in case the type family reduces to a type constructor: - Given 'type family TF2 a :: * - *','TF2 a b' becomes: '{TF2 a} ~ tfa = tfa b' It should rather be a type-level programming FAQ: Re 1: Ambiguous signatures are a general problem. However, they are syntactically harder to recognise with TFs. Re 2: Applies to GADTs as well. Re 3: I have always been wondering whether we want special syntax for the application of synonym families. That would make it syntactically easier to recognise ambiguous signatures and indicarte syntactically were decomposition is admisible. BTW, part of the problem is that H98 is not entirely consistent with its use of upper and lower case identifiers. Strictly speaking, already vanilla type synonyms should have been lower case as they are a simple form of functions on types (you cannot use decomposition on them!) Then, synonym families could be lower-case, too. Manuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type family oddity
* Claus Reinke: -- erase_range :: (Sequence s) = RangeTrait s - IO (RangeTrait s) This can't work, as you can see after desugaring: -- erase_range :: (Sequence s,RangeTrait s~rs) = rs - IO rs There is nowhere to get 's' from, unless you start applying type families backwards, from results to parameters. Thanks. Indeed, this is a bug in my reading of the specification (and the original even had that Sequence argument). I was led astray by the fact that the type checker accepted the class declaration, even though there's no really good way to provide a concrete implementation. Another example I encountered is this: class Foo f where foo :: f - g -- oops, typo It was very difficult for me to spot this one, too. 8-/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Random question
I just wanted to say thanks to everyone that helped me on this. I'm still reading/cogitating the stuff you gave me, but I did manage to write a Fisher-Yates shuffle using random numbers. I had a lightbulb moment while reading about sequence (so I suppose that might count as my 7th Monad tutorial :). The - takes values out of monads[1]. So simple! -- let c = [11..18] --shuff (length c) c shuff :: Int - [a] - IO [a] shuff 0 xs = return xs shuff (len + 1) xs = (rand 1 (len + 1)) = \r - shuff len $ requeue r xs where requeue = \z xs - (init $ take z xs) ++ (drop z xs) ++ [last $ take z xs] rand :: Int - Int - IO Int rand low high = getStdRandom (randomR (low,high)) Since it's recursive I suspect there may be a way to do this with a fold, but I'll probably work that out at a later lightbulb moment (after more questions:) Thanks again. Iain [1] In a lot of IO tutorials it just seems to be the 'do' syntax for assigning a value to a symbol, but of course, :t getLine getLine :: IO String On 24 Sep 2008, at 10:03 pm, Iain Barnett wrote: Hi, I have a function, that produces a random number between two given numbers rand :: Int - Int - IO Int rand low high = getStdRandom (randomR (low,high)) (Naively) I'd like to write something like take (rand 1 10 ) [1..10] and see [1,2,3,4] ... or anything but nasty type-error messages. I'm reading about 6 tutorials on monads simultaneously but still can't crack this simple task, and won't pain you with all the permutations of code I've already tried. It's a lot, and it ain't pretty. Would anyone be able to break away from C/C++ vs Haskell to help? Just a point in the right direction or a good doc to read, anything that helps will be much appreciated. Regards Iain ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type family oddity
Florian Weimer: I can't figure out why the following code doesn't compile with the October 2n GHC 6.10 beta (-XTypeFamilies -XFlexibleContexts) when the type declaration is not commented out. It's a bug that the code is accepted *without* the signature, as the signature is ambiguous: http://hackage.haskell.org/trac/ghc/ticket/1897 This is not because the code fails to be type-safe, but because (a) you can't use the function erase_range anyway and (b) that it is accepted without a signature, but not with the signature leads to confusion, as you experienced. BTW, the method 'erase' in your code has the same problem. Manuel module T where type family RangeTrait c class InputRange r where remaining :: r - Bool advance :: r - r class (InputRange (RangeTrait s)) = Sequence s where erase :: RangeTrait s - IO (RangeTrait s) -- erase_range :: (Sequence s) = RangeTrait s - IO (RangeTrait s) erase_range r = if remaining r then do r' - erase r erase_range r' else return r GHCi says the type is precisely as specified in the comment. However, when I activate the type declaration, GHC complains: T.hs:16:22: Couldn't match expected type `RangeTrait s' against inferred type `RangeTrait s2' In the first argument of `erase', namely `r' In a stmt of a 'do' expression: r' - erase r In the expression: do r' - erase r erase_range r' T.hs:17:22: Couldn't match expected type `RangeTrait s1' against inferred type `RangeTrait s2' In the first argument of `erase_range', namely `r'' In the expression: erase_range r' In the expression: do r' - erase r erase_range r' Any suggestions? Is this a bug in GHC? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-cafe-cafe? Was: Re: Health effects
Christopher Lane Hinson wrote: What /is/ it with haskell-cafe lately? Do we need a haskell-blah mailing list? I would subscribe to that. Hell, I would post to it probably more than I post to haskell-cafe. But I'd also divert it to a separate mailbox for when I have too much free time. Maybe call it haskell-cafe-cafe? not-haskell? I must admit, I have a bunch of abstract math questions I'd like answers to, and the people round here seem like the kind of folks who might know the answers. But this has nothing at all to do with Haskell, so Cafe doesn't seem like a good place to ask... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] monadic parser with Happy and Alex
Duncan Coutts ha scritto: [...] Now I'm starting to write the parser with Happy, however for the final product I would like to: 1) Be able to do I/O in the lexer, for stylesheets inclusion (@import rule) 2) be able to keep state in the parser (or lexer?), for character transcoding (@charset rule) This should be possible with Happy (and there are some example), however I don't find examples that make use of a lexer written with Alex. See c2hs or Language.C it uses a monadic lexer. Thanks. I'm also looking at HJS (unfortunately new versions use Parsec instead of Alex + Happy). Duncan Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Monad transformers [Stacking monads]
David Menendez wrote: So it might be possible to rewrite your code along these lines: type M = StateT State [] run :: Foo - M () runOr :: Foo - Foo - M () runOr x y = mplus (run x) (run y) runAnd :: Foo - Foo - M () runAnd x y = run x run y The type StateT State [] alpha is isomorphic to State - [(alpha, State)], which means that each of the computations in mplus gets its own copy of the state. There are a few ways to add exceptions to this, depending on how you want the exceptions to interact with the non-determinism. 2. StateT State (NondetT (Either ErrorType)) alpha I have some longwinded code that works, but I'm still thinking about how to do this more elegantly. It looks like what I really need is something like type M = StateT State (ResultSetT (ErrorT ErrorType Identity)) Is that the correct ordering? If so, I guess that means I have to somehow construct ResultSetT. Is there an easy way to do that, given that I already have ResultSet? For example, if I put ResultSet into Traversable, would that let me do it? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: SourceGraph-0.1 and Graphalyze-0.3
I've now uploaded my SourceGraph program to Hackage [1]. It's rather simple at the moment, but if you pass in the .cabal file as a parameter (e.g. run it as SourceGraph Foo.cabal), it will create in the same directory as the .cabal file a Directory called SourceGraph that contains an html report of some basic graph-theoretic analysis of your code. The output format isn't ideal, but it should serve it's purpose for now (I'll fix it up and actually make it usable once my Thesis has been handed in). What I'd appreciate if people could try it out and tell me if there's any code, etc. that it can't parse. At the moment, it ignores all Data-based functions (e.g. class and instance declarations as well as record functions) and only looks at stand-alone functions (i.e. normal functions). SourceGraph requires version 0.3 of my Graphalyze library (version 0.2 added the reports in, but had some bugs that 0.3 fixes). [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SourceGraph -- Ivan Lazar Miljenovic [EMAIL PROTECTED] IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking monads
On Thu, 2 Oct 2008, Andrew Coppin wrote: Consider the following beautiful code: run :: State - Foo - ResultSet State run_and :: State - Foo - Foo - ResultSet State run_and s0 x y = do s1 - run s0 x s2 - run s1 y return s2 run_or :: State - Foo - Foo - ResultSet State run_or s0 x y = merge (run s0 x) (run s0 y) That works great. Unfortunately, I made some alterations to the functionallity the program has, and now it is actually possible for 'run' to fail. When this happens, a problem should be reported to the user. (By user I mean the person running my compiled application.) After an insane amount of time making my head hurt, I disocvered that the type Either ErrorType (ResultSet State) is actually a monad. (Or rather, a monad within a monad.) Unfortunately, this causes some pretty serious problems: run :: State - Foo - Either ErrorType (ResultSet State) You may also like to use: http://hackage.haskell.org/packages/archive/explicit-exception/0.0.1/doc/html/Control-Monad-Exception-Synchronous.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Random question
On Sun, 5 Oct 2008, Iain Barnett wrote: I just wanted to say thanks to everyone that helped me on this. I'm still reading/cogitating the stuff you gave me, but I did manage to write a Fisher-Yates shuffle using random numbers. I had a lightbulb moment while reading about sequence (so I suppose that might count as my 7th Monad tutorial :). The - takes values out of monads[1]. So simple! -- let c = [11..18]--shuff (length c) c shuff :: Int - [a] - IO [a] shuff 0 xs = return xs shuff (len + 1) xs = (rand 1 (len + 1)) = \r - shuff len $ requeue r xs where requeue = \z xs - (init $ take z xs) ++ (drop z xs) ++ [last $ take z xs] Instead of separate calls to 'take' and 'drop' you may prefer 'splitAt': requeue z xs = let (prefix,pivot:suffix) = splitAt (z-1) xs in prefix ++ suffix ++ [pivot] However, accessing list elements by index is pretty inefficient (linear time with respect to index). Is it possible to re-arrange the algorithm? Maybe using more efficient data structures? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Help me prove macid can scale! (Macid stress tests results for happs-tutorial toy job board disappointing so far.)
From: tphyahoo [EMAIL PROTECTED] Subject: Help me prove macid can scale! (Macid stress tests results for happs-tutorial toy job board disappointing so far.) To: HAppS HAppS is a new, relatively unproven technology. So I am asking myself this question. Will HAppS allow me to scale the toy job board I created for happs-tutorial into a high-volume, high concurrency, large-user count type job board? You know, the kind that might make money? I have done some preliminary testing to answer this question, and so far the results have been disappointing. I am hoping that I am doing something wrong, and that there is a way of using macid effectively for more than just toy applications. If there are solution for the problems I'm experiencing I will definitely be integrating this knowledge into the tutorial, so stay tuned. I am seeking feedback from HAppS experts and educated users on the following questions: * Is building a heavy duty website like monster.com in HAppS a realistic goal -- say, in the next twelve months? * Are there certain types of web apps that are unlikely to work well with the HAppS web architecture? * Are there changes I can make to my toy app's architecture -- be it data structures, buying new hardware, whatever -- that will enable me to get good performance against the stress test described below and in the demo? * Are there other HAppS stress tests in the public domain, and what are the results so far? A complete description of the stress test I did (basically, insert 200 users with 200 jobs apiece) along with a runnable demo, is in the tutorial preview at http://happstutorial.com:5002/tutorial/macid-stress-test. (The actual stress test is disabled in the online demo because I don't want to zap my server.) But the summary is, it's slow, slow to start, and creates a huge events file -- 356M. For around 4 records. That's like, 8 megabytes per job, which is a few lines of text. OK, happs isn't a database -- but still. This is all is checked into darcs and tagged: darcs get --tag='stress test'http://code.haskell.org/happs-tutorial Thanks in advance for helping make happs usable in the real world! thomas. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Shooting your self in the foot with Haskell
John Van Enk wrote: You shoot the gun, but the bullet gets trapped in the IO monad. The community points you at the paper Bang-bang-patterns: expressing lethal weaponry in the Haskell typesystem. Your head explodes. BTW, these could go on the wiki. -- src/ -XIncomprehensibleTypes Equivalent to all of: -fallow-inconvinient-types, -XOmnipotentInstances, -XFunkyFunctors, -XSuperTuringTypes, -XErraticTypeClasses, -XCoAntiRetroHyperArrows ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help me prove macid can scale! (Macid stress tests results for happs-tutorial toy job board disappointing so far.)
I don't want to be contrarian, but I guess I can't help myself. Does MACID have anything to say about failover and replication? Isn't that more important than volume? -- _jsn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Linux binary dist problems
Hi all, I just joined this list, I'm interested in learning Haskell to complement my day job language (Java). I was interested in trying to make a simple website using Haskell in order to have something to practise on, however in my host's shared environment I can't use the Linux binary packages - I get the same errors that a few people were talking about in September - firstly the cannot determine current directory, and then after hacking the configure script the [install] Error 136. It seems that this is probably an old libc, but this is an environment that I have almost no control over so I can't fix that. Are there any building from source options if I don't already have GHC? It looks from the porting guide that I might be able to make 6.6.2 with just a C compiler, can I then use that to build 6.8.3? Thanks for any help. As a few people have commented, it would be great to make all this easier, as it's a pretty big stumbling block to starting with Haskell, and people are likely to get discouraged pretty quickly. Cheers, Colin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linux binary dist problems
Colin Fleming [EMAIL PROTECTED] writes: It looks from the porting guide that I might be able to make 6.6.2 with just a C compiler, can I then use that to build 6.8.3? I have the same problem as you -- a hosting environment with an old libc -- and had the same problem with the binary distribution. I think you can do what you have suggested, but I haven't tried. Instead I have decided to build a static binary on a local computer and then put that binary onto the host; maybe this is a solution for you too. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] MPFR / FFI - Nefarious (Simple?) bug
In order to create an arbitrary precision floating point / drop in replacement for Double, I'm trying to wrap MPFR (http://www.mpfr.org/) using the FFI but despite all my efforts the simplest bit of code doesn't work. It compiles, it runs, but it crashes mockingly after pretending to work for a while. A simple C version of the code happily prints the number 1 to (640 decimal places) a total of 10,000 times. The Haskell version, when asked to do the same, silently corrupts (?) the data after only 289 print outs of 1.... and after 385 print outs, it causes an assertion failure and bombs. I'm at a loss for how to proceed in debugging this since it should work. The code can be perused at http://hpaste.org/10923 (and attached) and downloaded at http://www.updike.org/mpfr-broken.tar.gz I'm using GHC 6.83 on FreeBSD 6 and GHC 6.8.2 on Mac OS X. Note you will need MPFR (tested with 2.3.2) installed with the correct paths (change the Makefile) for libs and header files (along with those from GMP) to successfully compile this. Why does the C version work, but the Haskell version flake out? What else am I missing when approaching the FFI? I tried StablePtrs and had the exact same results. Can someone else verify if this is a Mac/BSD only problem by compiling and running my code? (Does the C executableworks work? Does the Haskell executable noworks not work?) Can anyone on Linux and Windows attempt to compile/run and see if you can get the same results? Jared. P.S. I actually have much more code, having wrapped dozens of functions from the MPFR library and created instances using unsafePerformIO and foreignPtrs and all that useful high level Haskell/pure stuff--- all of which basically works perfectly except that it doesn't work at all since it crashes mysteriously after pretending to work at first. I had to narrow it down to something simple and the Print 1.0... 10,000 times was the best I could do. If I can get that working, I will then move on to something like the factorial of 1000 (printing intermediate values), which also works in C, but not Haskell, and after that, maybe everything will just work and I can use/publish this library! - works.c #include stdio.h #include stdlib.h #include string.h #include gmp.h #include mpfr.h #include mpfr_ffi.c int main() { int i; mpfr_ptr one; mpf_set_default_prec_decimal(640); one = mpf_set_signed_int(1); for (i = 0; i 1; i++) { printf(%d\n, i); mpf_show(one); } } Main.hs --- Doesn't work! module Main where import Foreign.Ptr( Ptr, FunPtr ) import Foreign.C.Types( CInt, CLong, CULong, CDouble ) import Foreign.StablePtr ( StablePtr ) data MPFR = MPFR foreign import ccall mpf_set_default_prec_decimal c_set_default_prec_decimal :: CInt - IO () setPrecisionDecimal :: Integer - IO () setPrecisionDecimal decimal_digits = do c_set_default_prec_decimal (fromInteger decimal_digits) foreign import ccall mpf_show c_show :: Ptr MPFR - IO () foreign import ccall mpf_set_signed_int c_set_signed_int :: CLong - IO (Ptr MPFR) showNums k n = do print n c_show k main = do setPrecisionDecimal 640 one - c_set_signed_int (fromInteger 1) mapM_ (showNums one) [1..1] -- mpfr_ffi.c // a little bit of wrapper code... this may be where the problem is // but since the (working) C code uses this and has no problems, I don't // understand why the Haskell code appears to be corrupting the limbs (the mantissa) #include stdio.h #include stdlib.h #include string.h #include gmp.h #include mpfr.h void mpf_show(mpfr_ptr x) { mpfr_out_str(stdout, 10, 0, x, GMP_RNDN); printf(\n); } #define LOG2_10 3.3219280948873626 #define IEEE_BITS 53 void mpf_set_default_prec_decimal(int dec_digits) { double bits = LOG2_10 * dec_digits; int ibits = (int)bits; double ddec; int dec; //printf(DEC_DIGITS = %d\n, dec_digits); //printf(IBITS = %d\n, ibits); ddec = ibits / LOG2_10; dec = (int)ddec; //printf(DEC= %d\n, dec); while (dec dec_digits) { ibits++; //printf(IBITS = %d\n, ibits); ddec = ibits / LOG2_10; dec = (int)ddec; //printf(DEC= %d\n, dec); } mpfr_set_default_prec(ibits); } mpfr_ptr mpf_new_mpfr() { return (mpfr_ptr)malloc(sizeof(__mpfr_struct)); } mpfr_ptr mpf_set_signed_int(int x) { mpfr_ptr result = mpf_new_mpfr(); if (result == NULL) return NULL; mpfr_init_set_si(result, x, GMP_RNDN); return result; } --- Makefile CC = gcc HC = ghc INCLUDE = -I/home/private/local/include -I/usr/local/include -I/opt/local/include LIBS= -L/opt/local/lib -L/usr/local/lib all:works noworks works: mpfr_ffi.o works.o $(CC) -o works works.o -lgmp -lmpfr $(INCLUDE) $(LIBS) works.o:works.c $(CC) -c works.c $(INCLUDE)
Re: [Haskell-cafe] MPFR / FFI - Nefarious (Simple?) bug
Jared Updike [EMAIL PROTECTED] writes: Can someone else verify if this is a Mac/BSD only problem by compiling and running my code? (Does the C executableworks work? Does the Haskell executable noworks not work?) Can anyone on Linux and Windows attempt to compile/run and see if you can get the same results? I can't help you fix the problem, but can confirm that it behaves as you describe on my Linux system. The program works produces correct output, but noworks gives: == [...] 290 1.0 291 1.00315821571076304370386829039486164636536120569099678825575157477354990710405658927062619547595122867857873765133026050519075772712996650488675128428778696175272153632855303857710094714398932056909218681833163883482512398576534211955878126971368731378321605715030861892325510831739618679352919703855747262870175016933079782350322237289103929997053812694251557912158924211585973481445271933347978517620 292 [...] 384 1.00315821571076304370386829039486164636536120569099678825575157477354990710405658927062619547595122867857873765133026050519075772712996650488675128428778696175272153632855303857710094714398932056909218681833163883482512398576534211955878126971368731378321605715030861892325510831739618679352919703855747262870175016933079782350322237289103929997053812694251557912158924211585973481445271933347978517620 385 1.00315821571076304370386829039486164636536120569099678825575157477354990710405658927062619547595122867857873765133026050519075772712996650488675128428778696175272153632855303857710094714398932056909218681833163883482512398576534211955878126971368731378321605715030861892281684860507747503219323326708248193093246881500522519352192987169395899758472958160241015525770811984166890239749344848735134541218 386 ../get_str.c:149: assertion failed: size_s1 = m Aborted == All the values from 291-384 are the same, but 385 is slightly different. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MPFR / FFI - Nefarious (Simple?) bug
On Sun, Oct 5, 2008 at 5:38 PM, Chris Mears [EMAIL PROTECTED] wrote: Jared Updike [EMAIL PROTECTED] writes: Can someone else verify if this is a Mac/BSD only problem by compiling and running my code? (Does the C executableworks work? Does the Haskell executable noworks not work?) Can anyone on Linux and Windows attempt to compile/run and see if you can get the same results? I can't help you fix the problem, but can confirm that it behaves as you describe on my Linux system. The program works produces correct output, but noworks gives: == [...] 290 1.0 291 1.00315821571076304370386829039486164636536120569099678825575157477354990710405658927062619547595122867857873765133026050519075772712996650488675128428778696175272153632855303857710094714398932056909218681833163883482512398576534211955878126971368731378321605715030861892325510831739618679352919703855747262870175016933079782350322237289103929997053812694251557912158924211585973481445271933347978517620 292 [...] 384 1.00315821571076304370386829039486164636536120569099678825575157477354990710405658927062619547595122867857873765133026050519075772712996650488675128428778696175272153632855303857710094714398932056909218681833163883482512398576534211955878126971368731378321605715030861892325510831739618679352919703855747262870175016933079782350322237289103929997053812694251557912158924211585973481445271933347978517620 385 1.00315821571076304370386829039486164636536120569099678825575157477354990710405658927062619547595122867857873765133026050519075772712996650488675128428778696175272153632855303857710094714398932056909218681833163883482512398576534211955878126971368731378321605715030861892281684860507747503219323326708248193093246881500522519352192987169395899758472958160241015525770811984166890239749344848735134541218 386 ../get_str.c:149: assertion failed: size_s1 = m Aborted == All the values from 291-384 are the same, but 385 is slightly different. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe My results (from Linux i686) are slightly different. I am getting [...] 287 1.0 288 get_str.c:149: assertion failed: size_s1 = m Aborted i.e. I never get the random numbers; they are all zeroes but it aborts after 287 successful repetitions. Changing the default heap size (with +RTS -Hsize) changes how far it runs (running with -H32M let it go past 8000 repetitions), so this might be a garbage-collection issue. Hope that is some help to you. Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MPFR / FFI - Nefarious (Simple?) bug
Thanks for trying out my code. I'm glad it's not particular to my system. I suspected it had to do with the GHC RTS monkeying around with the heap (lower precisions print more iterations and maybe aren't moving through the heap as fast?) but I think when I added a statement to print out the hex address for each Ptr MPFR that those pointers (to 'one') in particular weren't getting moved. Likely the stuff living in the heap, pointed at in the MPFR struct, specifically the pointer to the limbs (the mantissa or actual digits of the number) are getting kludged.. I don't really understand why this is the case when I don't think I'm allocating a lot of the heap or anything, just printing the same number over and over... Is there a space leak somewhere? (I can also verify that mpf_new_mpfr is only getting called once per program run by appending to a file each time it gets called). How do I tell GHC leave this mess and anything in the C heap completely alone? Jared. On 10/5/08, Alexander Dunlap [EMAIL PROTECTED] wrote: On Sun, Oct 5, 2008 at 5:38 PM, Chris Mears [EMAIL PROTECTED] wrote: Jared Updike [EMAIL PROTECTED] writes: Can someone else verify if this is a Mac/BSD only problem by compiling and running my code? (Does the C executableworks work? Does the Haskell executable noworks not work?) Can anyone on Linux and Windows attempt to compile/run and see if you can get the same results? I can't help you fix the problem, but can confirm that it behaves as you describe on my Linux system. The program works produces correct output, but noworks gives: == [...] 290 1.0 291 1.00315821571076304370386829039486164636536120569099678825575157477354990710405658927062619547595122867857873765133026050519075772712996650488675128428778696175272153632855303857710094714398932056909218681833163883482512398576534211955878126971368731378321605715030861892325510831739618679352919703855747262870175016933079782350322237289103929997053812694251557912158924211585973481445271933347978517620 292 [...] 384 1.00315821571076304370386829039486164636536120569099678825575157477354990710405658927062619547595122867857873765133026050519075772712996650488675128428778696175272153632855303857710094714398932056909218681833163883482512398576534211955878126971368731378321605715030861892325510831739618679352919703855747262870175016933079782350322237289103929997053812694251557912158924211585973481445271933347978517620 385 1.00315821571076304370386829039486164636536120569099678825575157477354990710405658927062619547595122867857873765133026050519075772712996650488675128428778696175272153632855303857710094714398932056909218681833163883482512398576534211955878126971368731378321605715030861892281684860507747503219323326708248193093246881500522519352192987169395899758472958160241015525770811984166890239749344848735134541218 386 ../get_str.c:149: assertion failed: size_s1 = m Aborted == All the values from 291-384 are the same, but 385 is slightly different. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe My results (from Linux i686) are slightly different. I am getting [...] 287
Re: [Haskell-cafe] Shooting your self in the foot with Haskell
On 10/1/08, John Van Enk [EMAIL PROTECTED] wrote: There's the well known How to shoot your self in the foot list which I have it printed and taped on my desk at work. http://www-users.cs.york.ac.uk/susan/joke/foot.htm I had a co-worker ask me how you'd shoot your self in the foot with Haskell. You aim the gun at your foot, pull the trigger and remove the clip. When you look at your undamaged foot, the hammer clicks on an empty barrel. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Shooting your self in the foot with Haskell
I'll see about putting them there. :) On Sun, Oct 5, 2008 at 6:22 PM, Simon Richard Clarkstone [EMAIL PROTECTED] wrote: BTW, these could go on the wiki. -- /jve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Shooting your self in the foot with Haskell
http://haskell.org/haskellwiki/Shooting_your_self_in_the_foot This needs to be cleaned up a little (lots of dups, though they are all great). On Sun, Oct 5, 2008 at 11:21 PM, John Van Enk [EMAIL PROTECTED] wrote: I'll see about putting them there. :) On Sun, Oct 5, 2008 at 6:22 PM, Simon Richard Clarkstone [EMAIL PROTECTED] wrote: BTW, these could go on the wiki. -- /jve -- /jve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help me prove macid can scale! (Macid stress tests results for happs-tutorial toy job board disappointing so far.)
On Sun, 2008-10-05 at 15:57 -0700, Jason Dusek wrote: I don't want to be contrarian, but I guess I can't help myself. Does MACID have anything to say about failover and replication? Isn't that more important than volume? HAppS does failover and replication within a cluster. They're working on sharding, but that's a good deal harder. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MPFR / FFI - Nefarious (Simple?) bug
On Sun, Oct 5, 2008 at 6:01 PM, Jared Updike [EMAIL PROTECTED] wrote: Thanks for trying out my code. I'm glad it's not particular to my system. I suspected it had to do with the GHC RTS monkeying around with the heap (lower precisions print more iterations and maybe aren't moving through the heap as fast?) but I think when I added a statement to print out the hex address for each Ptr MPFR that those pointers (to 'one') in particular weren't getting moved. Likely the stuff living in the heap, pointed at in the MPFR struct, specifically the pointer to the limbs (the mantissa or actual digits of the number) are getting kludged.. I don't really understand why this is the case when I don't think I'm allocating a lot of the heap or anything, just printing the same number over and over... Is there a space leak somewhere? (I can also verify that mpf_new_mpfr is only getting called once per program run by appending to a file each time it gets called). How do I tell GHC leave this mess and anything in the C heap completely alone? Usually, you can expect GHC to leave the C heap alone. The exception, unfortunately, is GMP (which is used by MPFR). See the following ticket: http://hackage.haskell.org/trac/ghc/ticket/311 I'm guessing that's the cause of the corruption. The relevant note from that ticket: It's a known problem that you can't use GMP via the FFI from your Haskell code in GHC, or use a C library that internally uses GMP. We should really use a private version of GMP with function names that don't overlap, or better still replace GMP altogether. The comment in that ticket from Benedict Huber details some possible workarounds. Best, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell-cafe-cafe? Was: Re: Health effects
On Sun, 05 Oct 2008 13:54:08 +0100, Andrew Coppin [EMAIL PROTECTED] wrote: Christopher Lane Hinson wrote: What /is/ it with haskell-cafe lately? Do we need a haskell-blah mailing list? I would subscribe to that. Hell, I would post to it probably more than I post to haskell-cafe. But I'd also divert it to a separate mailbox for when I have too much free time. Maybe call it haskell-cafe-cafe? not-haskell? I must admit, I have a bunch of abstract math questions I'd like answers to, and the people round here seem like the kind of folks who might know the answers. But this has nothing at all to do with Haskell, so Cafe doesn't seem like a good place to ask... In that case, how about creating a Haskell-Lounge mailing list, exclusively for topics tangential to Haskell? Either that, or just ensure that most off-topic/tangential topics are prefixed [OT]? -- Benjamin L. Russell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] a really juvenile question .. hehehehe ;^)
Hello, I am reading some extant Haskell code that uses Posix signals I am confused by the motivation of the following ... type Signalhttp://hackage.haskell.org/packages/archive/unix/2.3.0.0/doc/html/System-Posix-Signals.html#t%3ASignal= CInthttp://hackage.haskell.org/packages/archive/base/3.0.1.0/doc/html/Foreign-C-Types.html#t%3ACInt nullSignalhttp://hackage.haskell.org/packages/archive/unix/2.3.0.0/doc/html/System-Posix-Signals.html#v%3AnullSignal:: Signalhttp://hackage.haskell.org/packages/archive/unix/2.3.0.0/doc/html/System-Posix-Signals.html#t%3ASignal internalAborthttp://hackage.haskell.org/packages/archive/unix/2.3.0.0/doc/html/System-Posix-Signals.html#v%3AinternalAbort:: Signalhttp://hackage.haskell.org/packages/archive/unix/2.3.0.0/doc/html/System-Posix-Signals.html#t%3ASignal sigABRThttp://hackage.haskell.org/packages/archive/unix/2.3.0.0/doc/html/System-Posix-Signals.html#v%3AsigABRT:: CInthttp://hackage.haskell.org/packages/archive/base/3.0.1.0/doc/html/Foreign-C-Types.html#t%3ACInt realTimeAlarmhttp://hackage.haskell.org/packages/archive/unix/2.3.0.0/doc/html/System-Posix-Signals.html#v%3ArealTimeAlarm:: Signalhttp://hackage.haskell.org/packages/archive/unix/2.3.0.0/doc/html/System-Posix-Signals.html#t%3ASignal sigALRMhttp://hackage.haskell.org/packages/archive/unix/2.3.0.0/doc/html/System-Posix-Signals.html#v%3AsigALRM:: CInthttp://hackage.haskell.org/packages/archive/base/3.0.1.0/doc/html/Foreign-C-Types.html#t%3ACInt busErrorhttp://hackage.haskell.org/packages/archive/unix/2.3.0.0/doc/html/System-Posix-Signals.html#v%3AbusError:: Signalhttp://hackage.haskell.org/packages/archive/unix/2.3.0.0/doc/html/System-Posix-Signals.html#t%3ASignal sigBUShttp://hackage.haskell.org/packages/archive/unix/2.3.0.0/doc/html/System-Posix-Signals.html#v%3AsigBUS:: CInthttp://hackage.haskell.org/packages/archive/base/3.0.1.0/doc/html/Foreign-C-Types.html#t%3ACInt OK .. type is really just a synomym and doesn't invoke type checking like data type declarations do .. so why don't we have all the CInts substituted by Signal? I.e. what did I miss? Thanks, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a really juvenile question .. hehehehe ;^)
vigalchin: Hello, I am reading some extant Haskell code that uses Posix signals I am confused by the motivation of the following ... type [1]Signal = [2]CInt [3]nullSignal :: [4]Signal [5]internalAbort :: [6]Signal [7]sigABRT :: [8]CInt [9]realTimeAlarm :: [10]Signal [11]sigALRM :: [12]CInt [13]busError :: [14]Signal [15]sigBUS :: [16]CInt OK .. type is really just a synomym and doesn't invoke type checking like data type declarations do .. so why don't we have all the CInts substituted by Signal? I.e. what did I miss? Looks like it should all be Signal, and probably should be using a newtype, to prevent funky tricks. The Posix layer is a bit crufty. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a really juvenile question .. hehehehe ;^)
Thanks Don. Maybe both for me and others in order to take the fight to the Klingons and other Baddies, please explain the typefulness protection that newtype affords over the Klingon type ... In the code that I contributed to the library, I like to think that I used newtype appropriately but not perhaps with full understanding. Thanks, Vasili On Mon, Oct 6, 2008 at 12:37 AM, Don Stewart [EMAIL PROTECTED] wrote: vigalchin: Hello, I am reading some extant Haskell code that uses Posix signals I am confused by the motivation of the following ... type [1]Signal = [2]CInt [3]nullSignal :: [4]Signal [5]internalAbort :: [6]Signal [7]sigABRT :: [8]CInt [9]realTimeAlarm :: [10]Signal [11]sigALRM :: [12]CInt [13]busError :: [14]Signal [15]sigBUS :: [16]CInt OK .. type is really just a synomym and doesn't invoke type checking like data type declarations do .. so why don't we have all the CInts substituted by Signal? I.e. what did I miss? Looks like it should all be Signal, and probably should be using a newtype, to prevent funky tricks. The Posix layer is a bit crufty. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a really juvenile question .. hehehehe ;^)
Used wisely, newtype prevents accidentally constructing illegal values of Signal type, by treating them as CInts. You can restrict the valid values of the Signal type to be just those signals you define, not arbitrary bit patterns that fit in a CInt. vigalchin: Thanks Don. Maybe both for me and others in order to take the fight to the Klingons and other Baddies, please explain the typefulness protection that newtype affords over the Klingon type ... In the code that I contributed to the library, I like to think that I used newtype appropriately but not perhaps with full understanding. Thanks, Vasili On Mon, Oct 6, 2008 at 12:37 AM, Don Stewart [EMAIL PROTECTED] wrote: vigalchin: Hello, I am reading some extant Haskell code that uses Posix signals I am confused by the motivation of the following ... type [1]Signal = [2]CInt [3]nullSignal :: [4]Signal [5]internalAbort :: [6]Signal [7]sigABRT :: [8]CInt [9]realTimeAlarm :: [10]Signal [11]sigALRM :: [12]CInt [13]busError :: [14]Signal [15]sigBUS :: [16]CInt OK .. type is really just a synomym and doesn't invoke type checking like data type declarations do .. so why don't we have all the CInts substituted by Signal? I.e. what did I miss? Looks like it should all be Signal, and probably should be using a newtype, to prevent funky tricks. The Posix layer is a bit crufty. -- Don References Visible links 1. mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe