Re: [Haskell-cafe] Re: inserting values in a binary tree
Den Saturday 10 May 2008 00.55.44 skrev PR Stanley: Actually, you've touched an important point there. It's balancing that I'm having difficulty with. Paul So what kind of balancing rules does it have to obey? AVL? Red-black? Something else? At 23:46 09/05/2008, you wrote: PR Stanley [EMAIL PROTECTED] wrote: Hi data Ord a = Tree a = Nil | Node (Tree a) a (Tree a) How would one go about inserting a value in a binary search tree of the above description? Using a library ;) Inserting isn't the problem, balancing is where things get interesting: have a look at http://en.wikipedia.org/wiki/AVL_tree -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell compiler on NetBSD amd64
On Fri, May 09, 2008 at 10:21:19PM -0700, Donn Cave wrote: So here I am with 64 bit Athlon hardware, running amd64 NetBSD (a.k.a. x86_64), reasonably motivated to compile Haskell. From what I make of the porting instructions, So, we are in the same boat then! my only hope is to install FreeBSD-amd64 on another partition and download the 6.6.1 ghc for that platform, use it to generate .hc files to build 6.6.1 on NetBSD, and then use 6.6.1 to build 6.8 or whatever the current version may be by the time I get there? But what I thought was rather to go with OpenBSD, since I figured that it would be closer to NetBSD (You can e.g. build ghc on OpenBSD using NetBSD-generated .hc files on i386), and generate the .hc files on OpenBSD. I have unfortunately not got any further than getting an openbsd partition though, have not had the time to get into the actual porting. Emil -- Donn Cave [EMAIL PROTECTED] -- Emil Sköldberg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] build version problem?
Ok, I'll ask the obvious question... did you try to re-configure? runhaskell Setup.hs configure 2008/5/9 Galchin, Vasili [EMAIL PROTECTED]: Hello, I changed the version # in a cabal file and now I get ... runhaskell Setup.hs configure Configuring unix-2.4.0.0... [EMAIL PROTECTED]:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs build Setup.hs: unix.cabal has been changed, please re-configure. Now no matter what I change the version #, e.g. 2.3.0.0, things are not happy. ? Thanks, Vasili ___ 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
[Haskell-cafe] Re: inserting values in a binary tree
PR Stanley [EMAIL PROTECTED] wrote: Actually, you've touched an important point there. It's balancing that I'm having difficulty with. Paul http://en.wikipedia.org/wiki/Tree_rotation is the key to all this: It changes the tree structure without changing the tree ordering. rotr (Node (Node a p b) q c) = Node a p $ Node b q c untested, mind you. At 23:46 09/05/2008, you wrote: PR Stanley [EMAIL PROTECTED] wrote: Hi data Ord a = Tree a = Nil | Node (Tree a) a (Tree a) How would one go about inserting a value in a binary search tree of the above description? Using a library ;) Inserting isn't the problem, balancing is where things get interesting: have a look at http://en.wikipedia.org/wiki/AVL_tree -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Old editions of The Monad.Reader lost
Almost all? Is that why some are missing? eg. http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2 omits Impure Thoughts 1 - Thtatic Compilathionth (without a lisp) http://www.haskell.org/tmrwiki/ImpureThoughts_2f1. Philippa did not want her articles published under the new license - that's why they haven't been added. Hope this clears things up, Wouter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] unsafeInterleaveIO and OpenGL
Sounds reasonable. 'unsafeInterleaveIO' defers computation of 'vp' until it is actually needed. At this time the viewport might have changed. That sound reasonable indeed, but the viewport does not change and the values I get are really random. I'll try to make minimal example to demonstrate the problem. Thanks, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] I am new to haskell
On 09/mag/08, at 13:59, Benjamin L. Russell wrote: […] i recommend you to read papers from the http://haskell.org/haskellwiki/Learning_Haskell page, in particular those in Advanced tutorials, Monads, Type classes, Popular libraries sections That is one idea. Also, since The Haskell School of Expression (http://www.haskell.org/soe/ ), by Paul Hudak, is sometimes regarded as easier to read as a second book on Haskell, you could read that, too. I think I’ll get the book. Thank you for the suggestions! […] Ciao -- Giorgio Valoti ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List concat
Lennart Augustsson wrote: There are many implementations of such things. Data.Sequence is one. You can also make an implementation that has O(1) cons, snoc, and append, but that's rather tricky and has a large constant factor. Ah. So not only is it possible, but it's already in a standard library. I had a feeling this might be the case... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List concat
On Fri, May 09, 2008 at 11:04:26PM +0100, Lennart Augustsson wrote: There are many implementations of such things. Data.Sequence is one. You can also make an implementation that has O(1) cons, snoc, and append, but that's rather tricky and has a large constant factor. It's also rather difficult to construct a use case that distinguishes between O(1) and O(log(min(n1,n2))) append. For example, building a sequence with either sort of append takes linear time. The constant factors are everything. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Type unions
I have been trying to write a DSL for Povray (see www.povray.org) in Haskell, using the technique of: http://okmij.org/ftp/papers/tagless-final-APLAS.pdf with some inspiration taken from http://okmij.org/ftp/Haskell/DSLSharing.hs The Povray Scene Description Language is a very declarative language, with few high level constructs (even loops take a bit of work) -- which is why I'm putting it in Haskell. At one point, I needed a varargs function for the DSL, a function f :: b - a - b dressed up to take a variable number of 'a's, known at compile time. This was easy enough: data Nil a = Nil data Cons b a = a ::: b a infixr 1 ::: class VarArgs v where apply_args :: (s - a - s) - s - v a - s instance VarArgs Nil where apply_args _ start _ = start instance VarArgs b = VarArgs (Cons b) where apply_args f start (a ::: b) = apply_args f (f start a) b The solution is quite workable: I can simply write the following, and I believe the summation is expanded out at compile-time: apply_args (+) 0 (2 ::: 3 ::: 8 ::: 1 ::: (-3) ::: Nil) But I found I also needed a function to take a union type -- that is, the function would either take an argument of type T1, or of type T2, known at compile time. I tried a similar technique as I tried with varargs, and unfortunately ended up with this: data LeftOf a b = L a data RightOf a b = R b class Union u where apply_union :: (a - c) - (b - c) - (u a b) - c instance Union LeftOf where apply_union f _ (L a) = f a instance Union RightOf where apply_union _ g (R b) = g b type A = Integer type B = String type C = () type Union_ABC u1 u2 = u1 A (u2 B C) f_A = show . (+ 3) f_B = reverse f_C = const unit f :: (Union u1, Union u2) = Union_ABC u1 u2 - String f = apply_union f_A (apply_union f_B f_C) main = do putStrLn $ f $ (L 6 :: Union_ABC LeftOne LeftOne) putStrLn $ f $ R (L hello, world) putStrLn $ f $ R (R ()) Notice a lot of ugliness in my example: e.g., the definition of f, the type signature of f (I can't move the context into the type-synonym Union_ABC), creating objects of the union type, and the unpleasant surprise that I needed to provide the type of 'L 6'. This solution is very not-scalable: the Povray SDL is a messy language, and for my DSL I would need approximately 20 or 30 such unions, each a union of about 20 types (admittedly with a lot of overlap from union to union). I think the solution is to abandon the lofty ideal of statically determining argument types; instead have a universal type with tags to distinguish types dynamically: data Universal = UA A | UB B | UC C f :: Universal - String f (UA a) = f_A a f (UB b) = f_B b f (UC c) = f_C c main2 = do putStrLn $ f $ UA 6 putStrLn $ f $ UB hello, world putStrLn $ f $ UC () ...but I'm not ready to give up hope yet. Suggestions please? Eric ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Copy on read
I just had a random idea, which I thought I'd share with you all. I've heard about systems that do copy on write. That is, all users share a single copy of some structure, until somebody tries to write on it. At that moment they get a personal copy to modify so they don't upset everybody else. This way, you don't have to go to all the expense of copying a potentially large structure unless it's actually necessary to do so. Then I started thinking about Clean's uniqueness typing. If I'm understanding this correctly, it lets you do things like mutate data in-place without requiring a monad. The restriction is that the compiler has to be satisfied, at compile-time, that you will never try to access the old data you just overwrote. Although I once held more optimistic beliefs, as far as I can tell no current, real-world Haskell implementation ever mutates the fields of algebraic data types in-place. (Ignoring for a moment the issue of overwriting a thunk with it's result.) This strikes me as rather pessimistic. I was thinking... If Haskell had uniqueness typing, maybe the compiler could be made to infer when values are used in a unique way. And maybe if the compiler can detect data being used in a unique way, it could code for in-place updates instead of copying, and thereby gain a performance advantage. I don't know how viable this would be - the thing that immediately jumps out at me is that in practice there might be comparatively few places where you can *guarantee* the transformation is safe, and so it might not get applied very much. And considering all this would likely take a fair bit of work on the compiler, that wouldn't be a great payoff. Still, the idea of the compiler transparently rewriting your pure functional code to efficient mutable updates (when safe) is very appealing for performance reasons. Thoughts, people? [I'd be surprised if I'm the first person ever to have this idea...] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Order of Evaluation
Hello You may find this paper useful http://research.microsoft.com/~simonpj/Papers/spineless-tagless-gmachine.ps.gz It should give you the general feeling of how things are actually executed. It's quite old, some things in GHC have changed, but the overall scheme, I believe, is the same. The competent people will correct me, if I'm wrong. PR Stanley wrote: Hi (take 4 . map (0)) (f s t) where s = 2 : t t = 3 : s f = zipWith (-) What would be the order of evaluation for the above code? How would I illustrate the evaluation step-by-step? I'm guessing that the code necessitates lazy evaluation and as such it starts with take then it applies f which in turn applies s and t and zipWith until the first element satisfies the predicate in map and This is repeated 4 times What does the list think? Many thanks, Paul P.S. I'm not done with induction. I'm just letting it rst for a bit. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type unions
Try making a type class for the functions. That will allow you both varargs and unions. Have a look at Text.Printf. -- Lennart On Sat, May 10, 2008 at 1:28 PM, Eric Stansifer [EMAIL PROTECTED] wrote: I have been trying to write a DSL for Povray (see www.povray.org) in Haskell, using the technique of: http://okmij.org/ftp/papers/tagless-final-APLAS.pdf with some inspiration taken from http://okmij.org/ftp/Haskell/DSLSharing.hs The Povray Scene Description Language is a very declarative language, with few high level constructs (even loops take a bit of work) -- which is why I'm putting it in Haskell. At one point, I needed a varargs function for the DSL, a function f :: b - a - b dressed up to take a variable number of 'a's, known at compile time. This was easy enough: data Nil a = Nil data Cons b a = a ::: b a infixr 1 ::: class VarArgs v where apply_args :: (s - a - s) - s - v a - s instance VarArgs Nil where apply_args _ start _ = start instance VarArgs b = VarArgs (Cons b) where apply_args f start (a ::: b) = apply_args f (f start a) b The solution is quite workable: I can simply write the following, and I believe the summation is expanded out at compile-time: apply_args (+) 0 (2 ::: 3 ::: 8 ::: 1 ::: (-3) ::: Nil) But I found I also needed a function to take a union type -- that is, the function would either take an argument of type T1, or of type T2, known at compile time. I tried a similar technique as I tried with varargs, and unfortunately ended up with this: data LeftOf a b = L a data RightOf a b = R b class Union u where apply_union :: (a - c) - (b - c) - (u a b) - c instance Union LeftOf where apply_union f _ (L a) = f a instance Union RightOf where apply_union _ g (R b) = g b type A = Integer type B = String type C = () type Union_ABC u1 u2 = u1 A (u2 B C) f_A = show . (+ 3) f_B = reverse f_C = const unit f :: (Union u1, Union u2) = Union_ABC u1 u2 - String f = apply_union f_A (apply_union f_B f_C) main = do putStrLn $ f $ (L 6 :: Union_ABC LeftOne LeftOne) putStrLn $ f $ R (L hello, world) putStrLn $ f $ R (R ()) Notice a lot of ugliness in my example: e.g., the definition of f, the type signature of f (I can't move the context into the type-synonym Union_ABC), creating objects of the union type, and the unpleasant surprise that I needed to provide the type of 'L 6'. This solution is very not-scalable: the Povray SDL is a messy language, and for my DSL I would need approximately 20 or 30 such unions, each a union of about 20 types (admittedly with a lot of overlap from union to union). I think the solution is to abandon the lofty ideal of statically determining argument types; instead have a universal type with tags to distinguish types dynamically: data Universal = UA A | UB B | UC C f :: Universal - String f (UA a) = f_A a f (UB b) = f_B b f (UC c) = f_C c main2 = do putStrLn $ f $ UA 6 putStrLn $ f $ UB hello, world putStrLn $ f $ UC () ...but I'm not ready to give up hope yet. Suggestions please? Eric ___ 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] Type unions
Try making a type class for the functions. That will allow you both varargs and unions. Have a look at Text.Printf. Thank you -- looking at Printf was very helpful. My syntax is much happier as a result. I also see now that I am approaching the problem from the wrong direction -- that by writing a whole slew of functions whose behavior depends arbitrarily upon their argument type, I would need to code the desired behavior for each function and each argument type; getting hung up on making the syntax manageable hid this realization from me. The solution is for me to try much harder to extract common behavior across argument types and only code special cases when truly necessary. Eric ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Type unions
Hello Eric, Saturday, May 10, 2008, 8:26:27 PM, you wrote: Thank you -- looking at Printf was very helpful. My syntax is much happier as a result. btw, i also recommend to look into HsLua[1] which uses type classes in very smart and elegant way to automatically convert between Haskell and Lua data types [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hslua -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Copy on read
If Haskell had uniqueness typing, maybe the compiler could be made to infer when values are used in a unique way. And maybe if the compiler can detect data being used in a unique way, it could code for in-place updates instead of copying, and thereby gain a performance advantage. Uniqueness typing does not lead to in-place update. If a value is only used once, then there is no need to update it at all! In fact, I believe ghc does this analysis, and has a minor optimisation that omits the thunk-update. That is, if an unevaluated thunk is forced, but it has a unique usage, the original thunk is not overwritten with an indirection to the reduced value (as it normally would be), but the reduced value is just used directly. I believe that rather than _uniqueness_, you are really trying to describe _linear_ usage, that is, multiple uses, but in a single non- branching sequence. Single-threaded usage of a data structure might permit in-place modification of its parts. The analysis for linear usage is much more difficult than for uniqueness, and David Wakeling's PhD Thesis Linearity and Laziness (circa 1990) did some experiments, but was ultimately pessimistic about the value. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Old editions of The Monad.Reader lost
On 2008.05.10 12:17:45 +0100, Wouter Swierstra [EMAIL PROTECTED] scribbled 0.4K characters: Almost all? Is that why some are missing? eg. http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2 omits Impure Thoughts 1 - Thtatic Compilathionth (without a lisp) http://www.haskell.org/tmrwiki/ImpureThoughts_2f1. Philippa did not want her articles published under the new license - that's why they haven't been added. Hope this clears things up, Wouter I see; that was what I thought, but there was no note explicitly saying so. I'll go add them. -- gwern SRI d DIA Tangimoana ssor IDP Pesec VIP Schengen timers pgp2wndCJw9GG.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell compiler on NetBSD amd64
emil.skoldberg: On Fri, May 09, 2008 at 10:21:19PM -0700, Donn Cave wrote: So here I am with 64 bit Athlon hardware, running amd64 NetBSD (a.k.a. x86_64), reasonably motivated to compile Haskell. From what I make of the porting instructions, So, we are in the same boat then! my only hope is to install FreeBSD-amd64 on another partition and download the 6.6.1 ghc for that platform, use it to generate .hc files to build 6.6.1 on NetBSD, and then use 6.6.1 to build 6.8 or whatever the current version may be by the time I get there? But what I thought was rather to go with OpenBSD, since I figured that it would be closer to NetBSD (You can e.g. build ghc on OpenBSD using NetBSD-generated .hc files on i386), and generate the .hc files on OpenBSD. I have unfortunately not got any further than getting an openbsd partition though, have not had the time to get into the actual porting. I wonder if it is still possible to use the .hc files already generated for the OpenBSD/amd64 port, and use those to do the port to NetBSD/amd64. http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/ghc/ Actually, with headers starting to diverge, it might make more sense to just generate the amd64/netbsd .hc files from i386/netbsd -- where there's already a working ghc. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell compiler on NetBSD amd64
On Sat, May 10, 2008 at 12:13:16PM -0700, Don Stewart wrote: I wonder if it is still possible to use the .hc files already generated for the OpenBSD/amd64 port, and use those to do the port to NetBSD/amd64. http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/ghc/ If nobody tries, we'll never know. Ciao, Kili -- Do with this info and this argument what u will - as u always do. Delete it. -- Jeffrey Lim and Theo de Raadt in The famous t-shirt thread ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] seeking advice on my POSIX wrapper
Hello, Last night I sent out an announcement about some POSIX work that I have been doing. In any case, one of the FFI wrappers is driving me crazy, i.e. the one for mq_receive: http://opengroup.org/onlinepubs/007908799/xsh/mq_receive.html . When I call this function (mqReceive), I get message too long. In my test cases I am sending and receiving messages that are only 11 bytes! The wrapper seems really straightforward. Perhaps I am looking right at the problem and don't see. I need other eyes on the wrapper to help me ;^). Please see below. Regards, V. --- -- mqReceive is still being debugged!! -- | Retrieve a message from mqueue designated by mqd -- mqReceive :: Fd - ByteCount - Maybe Int - IO (String, Int) mqReceive (Fd mqd) len (Just prio) = do allocaBytes (fromIntegral len) $ \ p_buffer - do with (fromIntegral prio) $ \ p_prio - do rc - throwErrnoIfMinus1 mqReceive (c_mq_receive mqd p_buffer (fromIntegral len) p_prio) case fromIntegral rc of 0 - ioError (IOError Nothing EOF mqReceive EOF Nothing) n - do s - peekCStringLen (p_buffer, fromIntegral n) return (s, n) mqReceive (Fd mqd) len Nothing = do allocaBytes (fromIntegral len) $ \ p_buffer - do rc - throwErrnoIfMinus1 mqReceive (c_mq_receive mqd p_buffer (fromIntegral len) nullPtr) case fromIntegral rc of 0 - ioError (IOError Nothing EOF mqReceive EOF Nothing) n - do s - peekCStringLen (p_buffer, fromIntegral n) return (s, n) foreign import ccall unsafe mqueue.h mq_receive c_mq_receive :: CInt - Ptr CChar - CSize - Ptr CInt - IO CInt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] seeking advice on my POSIX wrapper
Hello Vasili, Sunday, May 11, 2008, 12:47:52 AM, you wrote: . When I call this function (mqReceive), I get message too long. you can divide-and-conquer the problem by trying 1) write the C code that calls mq_receive with the same params 2) call your own function instead of mq_receive and printf parameters it receives -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] seeking advice on my POSIX wrapper
On 2008 May 10, at 16:47, Galchin, Vasili wrote: Last night I sent out an announcement about some POSIX work that I have been doing. In any case, one of the FFI wrappers is driving me crazy, i.e. the one for mq_receive:http://opengroup.org/onlinepubs/007908799/xsh/mq_receive.html . When I call this function (mqReceive), I get message too long. In my test cases I am sending and receiving messages that are only 11 bytes! The wrapper seems really straightforward. Perhaps I am looking right at the problem and don't see. I need other eyes on the wrapper to help me ;^). Please see below. What's the other end sending? I suspect most implementations of mq_receive() layer it on top of msgrcv(), which can return E2BIG (== EMSGSIZE) if the message to be received is larger than the receiving buffer --- a condition which I note mq_receive() does not document (unless mq_msgsize means a given queue only supports fixed size messages, which seems odd). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell compiler on NetBSD amd64
On Sat, 10 May 2008 12:13:16 -0700 Don Stewart [EMAIL PROTECTED] wrote: I wonder if it is still possible to use the .hc files already generated for the OpenBSD/amd64 port, and use those to do the port to NetBSD/amd64. http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/ghc/ That sounds fine to me, if I understand you right - I managed to install an OpenBSD partition this afternoon, but if I can skip that step, that's fine with me. I don't see any .hc files at that link, though. Actually, with headers starting to diverge, it might make more sense to just generate the amd64/netbsd .hc files from i386/netbsd -- where there's already a working ghc. I have ghc 6.4.1 on NetBSD 3.0 i386. That's the idea, right? as apparently 6.8 is known to not build from .hc files. I don't understand `with headers starting to diverge'. Donn Cave, [EMAIL PROTECTED] -- Donn Cave [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell compiler on NetBSD amd64
On Sat, May 10, 2008 at 02:36:43PM -0700, Donn Cave wrote: I wonder if it is still possible to use the .hc files already generated for the OpenBSD/amd64 port, and use those to do the port to NetBSD/amd64. http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/ghc/ That sounds fine to me, if I understand you right - I managed to install an OpenBSD partition this afternoon, but if I can skip that step, that's fine with me. I don't see any .hc files at that link, though. Here you go: http://openbsd.dead-parrot.de/distfiles/ghc-6.6.1-amd64-unknown-openbsd-hc.tar.bz2 I've to admit that the ghc port for OpenBSD is a little bit weird ;-) (but not as weird as my current work on ghc-6.8 for OpenBSD) Actually, with headers starting to diverge, it might make more sense to just generate the amd64/netbsd .hc files from i386/netbsd -- where there's already a working ghc. I have ghc 6.4.1 on NetBSD 3.0 i386. That's the idea, right? If possible, start with ghc 6.6.1, even if that means to install a newer version of NetBSD. as apparently 6.8 is known to not build from .hc files. I don't understand `with headers starting to diverge'. Nor do I, but I guess Don meant significant differences in system libraries (between NetBSD and OpenBSD). Ciao, Kili -- Weg mit dieser verfluchten Demokratie wo alles das Wort führen will. -- Georg Christoph Lichtenberg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell compiler on NetBSD amd64
kili: http://openbsd.dead-parrot.de/distfiles/ghc-6.6.1-amd64-unknown-openbsd-hc.tar.bz2 I've to admit that the ghc port for OpenBSD is a little bit weird ;-) (but not as weird as my current work on ghc-6.8 for OpenBSD) What's your plan for the OpenBSD port, Kili? as apparently 6.8 is known to not build from .hc files. I don't understand `with headers starting to diverge'. Nor do I, but I guess Don meant significant differences in system libraries (between NetBSD and OpenBSD). That's what I meant. When you take the .hc files from OpenBSD to NetBSD, there's going to be some breakages in the C layer. So better to do the x86 - amd64 port, staying on NetBSD, I think. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe a, The Rationale
Paul: Hi folks data Maybe a = Nothing | Just a What is the underlying rationale for the Maybe data type? is it the safe style of programming it encourages/ Something tells me this is going to start a lengthy discussion. :-) Bob: Pure and simple -- it allows you to represent partial functions. Looking up a map will only sometimes find a value, so we either return Nothing, or Just that value. Paul: Would yu like to demonstrate this in an example? Cheers, Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe a, The Rationale
On 2008 May 10, at 18:56, PR Stanley wrote: Paul: Hi folks data Maybe a = Nothing | Just a What is the underlying rationale for the Maybe data type? is it the safe style of programming it encourages/ Something tells me this is going to start a lengthy discussion. :-) Bob: Pure and simple -- it allows you to represent partial functions. Looking up a map will only sometimes find a value, so we either return Nothing, or Just that value. Paul: Would yu like to demonstrate this in an example? Um, I was encountering and recognizing times when I really needed an out-of-band null, and the pain of representing such in C, shortly after I started serious programming in C (call it 1984-5). Is this really difficult? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe a, The Rationale
Paul: Hi folks data Maybe a = Nothing | Just a What is the underlying rationale for the Maybe data type? is it the safe style of programming it encourages/ Something tells me this is going to start a lengthy discussion. :-) Bob: Pure and simple -- it allows you to represent partial functions. Looking up a map will only sometimes find a value, so we either return Nothing, or Just that value. Paul: Would yu like to demonstrate this in an example? Um, I was encountering and recognizing times when I really needed an out-of-band null, and the pain of representing such in C, shortly after I started serious programming in C (call it 1984-5). Is this really difficult? Paul: Hmm, I'm not quite sure what you're driving at. Cheers, Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] seeking advice on my POSIX wrapper
sender ..
main = do
fd - mqOpen /myipc ReadWrite (Just nullFileMode) (Just
(MQAttributes 0 128 128 0))
mqSend fd Hello world 11 1
(MQAttributes flags maxMsgNum maxMsgSize curNumMsgs) -
mqGetAttributes fd
putStrLn (attrs flags- ++ (show flags) ++ maxMsgNum - ++
(show maxMsgNum) ++ maxMsgSize - ++ (show maxMsgSize) ++ curNumMsgs
- ++ (show curNumMsgs))
mqClose fd
return fd
~
-
receiver
main = do
fd - mqOpen /myipc ReadWrite (Just nullFileMode) (Just
(MQAttributes 0 128 128 0))
(MQAttributes flags maxMsgNum maxMsgSize curNumMsgs) -
mqGetAttributes fd
putStrLn (attrs flags- ++ (show flags) ++ maxMsgNum - ++
(show maxMsgNum) ++ maxMsgSize - ++ (show maxMsgSize) ++ curNumMsgs
- ++ (show curNumMsgs))
(MQAttributes flags maxMsgNum maxMsgSize curNumMsgs) -
mqSetAttributes fd (MQAttributes{flags=0, maxMsgNum=127, maxMsgSize=127,
curNumMsgs=7})
putStrLn (attrs flags- ++ (show flags) ++ maxMsgNum - ++
(show maxMsgNum) ++ maxMsgSize - ++ (show maxMsgSize) ++ curNumMsgs
- ++ (show curNumMsgs))
(s, n) - mqReceive fd 60 Nothing
putStrLn (dump ++ s)
(s, n) - mqReceive fd 11 (Just 1)
putStrLn s
mqClose fd
-- mqUnlink /myipc
return fd
~
-
Thanks, Vasili
On Sat, May 10, 2008 at 4:09 PM, Brandon S. Allbery KF8NH
[EMAIL PROTECTED] wrote:
On 2008 May 10, at 16:47, Galchin, Vasili wrote:
Last night I sent out an announcement about some POSIX work that I
have been doing. In any case, one of the FFI wrappers is driving me crazy,
i.e. the one for mq_receive:
http://opengroup.org/onlinepubs/007908799/xsh/mq_receive.html . When I
call this function (mqReceive), I get message too long. In my test cases I
am sending and receiving messages that are only 11 bytes! The wrapper seems
really straightforward. Perhaps I am looking right at the problem and don't
see. I need other eyes on the wrapper to help me ;^). Please see below.
What's the other end sending?
I suspect most implementations of mq_receive() layer it on top of msgrcv(),
which can return E2BIG (== EMSGSIZE) if the message to be received is larger
than the receiving buffer --- a condition which I note mq_receive() does not
document (unless mq_msgsize means a given queue only supports fixed size
messages, which seems odd).
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] seeking advice on my POSIX wrapper
The Linux version of mqueue that I am using is implemented as a Linux filesystem. I am reading now, Brandon. V. On Sat, May 10, 2008 at 4:09 PM, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: On 2008 May 10, at 16:47, Galchin, Vasili wrote: Last night I sent out an announcement about some POSIX work that I have been doing. In any case, one of the FFI wrappers is driving me crazy, i.e. the one for mq_receive: http://opengroup.org/onlinepubs/007908799/xsh/mq_receive.html . When I call this function (mqReceive), I get message too long. In my test cases I am sending and receiving messages that are only 11 bytes! The wrapper seems really straightforward. Perhaps I am looking right at the problem and don't see. I need other eyes on the wrapper to help me ;^). Please see below. What's the other end sending? I suspect most implementations of mq_receive() layer it on top of msgrcv(), which can return E2BIG (== EMSGSIZE) if the message to be received is larger than the receiving buffer --- a condition which I note mq_receive() does not document (unless mq_msgsize means a given queue only supports fixed size messages, which seems odd). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe a, The Rationale
On Sat, May 10, 2008 at 3:10 PM, PR Stanley [EMAIL PROTECTED] wrote: Paul: Hi folks data Maybe a = Nothing | Just a What is the underlying rationale for the Maybe data type? is it the safe style of programming it encourages/ Something tells me this is going to start a lengthy discussion. :-) Bob: Pure and simple -- it allows you to represent partial functions. Looking up a map will only sometimes find a value, so we either return Nothing, or Just that value. Paul: Would yu like to demonstrate this in an example? Um, I was encountering and recognizing times when I really needed an out-of-band null, and the pain of representing such in C, shortly after I started serious programming in C (call it 1984-5). Is this really difficult? Paul: Hmm, I'm not quite sure what you're driving at. Me neither. Cheers, Paul ___ 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] Maybe a, The Rationale
On Sat, May 10, 2008 at 11:36 PM, PR Stanley [EMAIL PROTECTED] wrote: Hi folks data Maybe a = Nothing | Just a What is the underlying rationale for the Maybe data type? is it the safe style of programming it encourages/ Something tells me this is going to start a lengthy discussion. :-) Cheers, Paul Sometimes you want to express things that can either be a value, or nothing. In some languages all or most values (using that term loosely) can be nullable. E.g. in C# any reference can be nullable, so you can just return null to signify no value (e.g. when looking someting up in a dictionary). The problem with this is that every single dereference can no potentially cause a runtime error, which pushes a whole lot of problems to the runtime, when they really could be statically eliminated at compile time. Most functions, after all, really do need all their parameters to exist and aren't defined for null, and they really do return a result and never null, so it's useful to know for sure that a Map Int String really is a map, and not null, while you still have the ability to deal with optional values in the tiny minority of cases that need it. Also, since it's impossible to actualy use a value without inspecting the constructors of Maybe, you avoid even more runtime errors (unless you use things like fromJust). IME nullable by default is one of the biggest sources of runtime crashes in high level OOP languages like C#, which is a shame because it really isn't that difficult to statically eliminate the vast majority of them, especially when you're sort of hand-waving the semantics of your language anyway and don't require it to be super rigorous... -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe a, The Rationale
On 2008 May 10, at 20:41, Philip Weaver wrote: On Sat, May 10, 2008 at 3:10 PM, PR Stanley [EMAIL PROTECTED] wrote: Um, I was encountering and recognizing times when I really needed an out-of-band null, and the pain of representing such in C, shortly after I started serious programming in C (call it 1984-5). Is this really difficult? Paul: Hmm, I'm not quite sure what you're driving at. Me neither. Null pointers, EOF markers, didn't find specified key in some tree, etc. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe a, The Rationale
IME nullable by default is one of the biggest sources of runtime crashes in high level OOP languages like C#, which is a shame because it really isn't that difficult to statically eliminate the vast majority of them, especially when you're sort of hand-waving the semantics of your language anyway and don't require it to be super rigorous... I definitely agree. After I'd been learning Haskell for 6 months and then wrote a program in Java C++, almost the first thing I did was code up a generic MaybeT class in each language. It is so much clearer and more obvious to _explicitly_ have no value (Maybe.Nothing()) as opposed to _implicitly_ having no value (null). Now I find my Java C++ MaybeT class indispensable when I am programming in those languages. Eric ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe a, The Rationale
On Sun, May 11, 2008 at 02:59:32AM +0100, Eric Stansifer wrote: I definitely agree. After I'd been learning Haskell for 6 months and then wrote a program in Java C++, almost the first thing I did was code up a generic MaybeT class in each language. It is so much clearer and more obvious to _explicitly_ have no value (Maybe.Nothing()) as opposed to _implicitly_ having no value (null). Now I find my Java C++ MaybeT class indispensable when I am programming in those languages. You may want to take a peek at the Boost.Optional [1] library in C++, which provides a lovely Maybe-like class template called optional. [1] http://www.boost.org/doc/libs/1_35_0/libs/optional/doc/html/index.html -- Lars Viklund | [EMAIL PROTECTED] | 070-310 47 07 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
