Re: [Haskell-cafe] [C Binding] Turning the mutable to immutable?
On Wed, Jul 7, 2010 at 2:24 PM, Yves Parès wrote: > > 2010/7/7 Liam O'Connor > > > Making an immutable API from a mutable one generally damages performance > (on von neumann architectures) somewhat, the goal is to minimize that > impact. > > In fact, I would like to determine if an EFFICIENT way to make images and > such immutable exists, or if it is impossible. > Both OpenGL and DirectX, while supporting updates to images, make it slow enough that any image data is effectively immutable. Each animation step a completely fresh frame buffer is created, without overwriting any of the inputs, by combining these immutable images in interesting ways. You're expected to combine multiple immutable data sources in the shader to produce the final output (which will be a different image from the inputs). Examples of data sources would be images, transformation matrices, colours etc. It's extremely rare to see people poke values individually into a mutable buffer (in fact, the capability of doing this on the GPU is very recent, and even then it's highly limited). You do a big purely functional transform from inputs to outputs instead. HLSL and GLSL may not look like functional languages, but they essentially are, in that each kernel runs independently with no shared mutable state, producing outputs from immutable inputs. So, if you want to do it on the CPU, I would mimic the way GPUs have been doing it for ages. Define what operations you want to perform in terms of the inputs, and then do them all "in bulk" to produce the output image. You don't want people to go in and arbitrarily set pixels to anything they want at any time they want. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bulk Synchronous Parallel
On Mon, Apr 19, 2010 at 11:03 PM, Gregory Crosswhite < gcr...@phys.washington.edu> wrote: > Hey everyone, > > Has anyone done any work with bulk synchronous parallel computing in > Haskell? The idea behind the model is that you divide your computation into > a series of computation and communication phases, and it has recently > occurred to me that this might be an ideal setup for parallelizing a pure > language like Haskell because you can think of it as alternating between a > stage that independently applies a bunch of functions to a bunch of > independent chunks of data and a stage that applies a big function to all of > the chunks that recombines them into new chunks for the next parallel phase, > so that all stages are conceptually pure even if eventually the second stage > is turned into something involving communication and hence side-effectful > under the hood. > > Experiences? Thoughts? > > You may want to check out NDP, e.g. here: http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell <http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell>It's at a higher level of abstraction, in a way. You don't need to worry about the dicing up and recombining, the compiler takes care of it for you. You just write things in terms of parallel arrays (which can be small, e.g. 2 element wide) and the compiler will fuse/flatten these together into big bulk parallel computations with communication between them. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Garbage collecting pointers
On Fri, Mar 26, 2010 at 10:52 PM, Mads Lindstrøm wrote: > Hi > > On Fri, 2010-03-26 at 21:33 +, Sebastian Sylvan wrote: > > > > > > > Reorganizing data on the fly sounds like it may be a pretty sensible > > idea now that cache misses are so bad (in comparison). The fact that > > Haskell data is generally immutable helps too. > > However, I think your scheme sounds a bit complicated for my tastes, > > and I don't really understand the idea of "lengths", what would "n > > consecutive elements" mean for a tree? Surely this wouldn't work just > > for list-like data structures? > > First of all, I had assumed that a data type's memory footprint was > independent of its value. Similarly to how a C-union always occupies the > same amount of memory. After reading your post, I reevaluated my > assumption and my assumption might just be wrong. > Take the Maybe data type. The Nothing value occupies no space other than the Nothing-tag, the Just part occupies more (potentially a lot more, if it too has been collapsed!). It's conceivable that you would force the size to be the same a la C' unions, and have some thresholding where if one of the possible alternatives is too big then it would always use a pointer for that one alternative, to minimize padding. > What do "heavily quantized lookup table" mean? It is the "heavily > quantized" part I do not get. > E.g. store a small number of bits of offset information per field in a record at the top, let's say 8 bits per field. Now, that means you can have 256 unique values, and therefore fields, but it nothing says that the offset value needs to refer to "bytes", it could just as easily refer to "multiples of 16 bytes" for larger structures. This means you would need to align all your fields to 16-byte boundaries, which may need padding, but lets you refer to fields with a larger offset without using a full pointer per field. Maybe your gain is wasted by doing too much logic here. Perhaps a more conservative suggestion would be to keep the pointers, so the runtime code is the same, but store a little tag indicating that a value has an optional memory extent for the purposes of GC. This way you could compact the leaves of a data graph (still keeping the pointers), which lets the GC stop following pointers once it hits the tag and reads the memory extent saying "this is a some data totalling 612 bytes, and I promise that any pointers in this memory block are all internal to the block". You'd reduce GC work, and more importantly cache misses, but not overall memory usage. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Garbage collecting pointers
teresting to me, but then I'm hardly an expert. I like the notion of using the fact that the language is free to change the data representation at runtime to improve performance by "collapsing" an immutable (recursive) data structure once it's been created. Partly because it's something that would be harder to do in other languages! -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Garbage collecting pointers
On Fri, Mar 26, 2010 at 9:21 PM, Brandon S. Allbery KF8NH < allb...@ece.cmu.edu> wrote: > On Mar 26, 2010, at 16:28 , Mads Lindstrøm wrote: > >> For some time I have been thinking about an idea, which could limit >> Haskell's memory footprint. I don't know if the idea is crazy or clever, >> > > This is called pointer tagging. The original STG design avoided it because > of the perceived performance loss in removing the tags before using the > pointer, but as I understand it the current GHC design uses limited tagging. I don't think that's what he's talking about. He's saying the data that would normally be on the other side of the pointer would instead be stored "inline", if I understand him correctly. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Real-time garbage collection for Haskell
On Sun, Feb 28, 2010 at 5:20 AM, Luke Palmer wrote: > I have seen some proposals around here for SoC projects and other > things to try to improve the latency of GHC's garbage collector. I'm > currently developing a game in Haskell, and even 100ms pauses are > unacceptable for a real-time game. I'm calling out to people who have > seen or made such proposals, because I would be willing to contribute > funding and/or mentor a project that would contribute to this goal. > Also any ideas for reducing this latency in other ways would be very > appreciated. > Since we're talking games here (my profession), I'd point out that it would be cool to be able to supply "hints" to the GC about when might be a good time to do a GC (without unconditionally forcing it), games in particular have some pretty specific properties that may be exploitable. Presumably a non-trivial portion of the objects copied from the nursery/G0 are actually short-lived objects that just happened to have their short life-span overlap with the collection. So really, copying them to the next generation is a "mistake" in some sense. For games, though, we have a very good point that occurs regularly where we know that all/most short-lived objects will no longer be referenced - at the start of a fresh frame. So if we could do as many as possible of our G0 collections at that point we'd avoid "accidental copying" of objects that are actually short-lived into the older generation (which should reduce pressure on that older generation, as well as speed up G0 collection). Ideally we'd have some way of telling the GC to try to avoid running during the actual frame itself, too, by for example tuning the heap region sizes automatically. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language simplicity
On Wed, Jan 13, 2010 at 12:55 AM, Eduard Sergeev wrote: > > > Andrew Coppin wrote: > > > > OK people, it's random statistics time! > > OK, my version of meaningless statistics: > > C++ (ISO/IEC 14882:1998(E)): 325 pages (712 including standard libraries) > C# (ECMA-334): 505 pages (language only) > Java: 450 pages (language only?) > Scala (2.7): 125 pages (157 including standard library) > Eiffel (ECMA-367): 160 pages (language only) > ANSI SQL-92: 685 pages (language only) > Haskell-98: 77 pages (247 including Prelude) > Erlang (4.7.3) 162 pages (251 including builtin functions) > Scheme (R5RS): 17 pages (45 including standard procedures) > Oberon: 16 pages, including table of contents and Appendix (containing EBNF grammar). -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Installing Haskell on Windows 7
On Sun, Dec 27, 2009 at 9:06 AM, Thomas Hühn wrote: > > > Has anyone who is *not* a Haskell/ghc/cabal expert been able to > install Haskell satisfactorily on Windows 7? > It worked fine for me, but then I didn't try to do anything fancy. The data-dir and prefix you mention is where cabal installs all my packages, FWIW. Not being able to access them would be a problem! You can customize it with --data-dir and --prefix on the cabal install command line, I think. Not sure if that's the reason your initial installation wasn't working though... Also, if a library fails to build because of your ghc version, you can install a specific version of that library instead. E.g. for haddock you see that the failing version was 2.4.2 but if you leave out the version number cabal will fetch the latest one for you, which isn't compatible with GHC 6.10. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why?
On Thu, Dec 10, 2009 at 3:30 PM, John D. Earle wrote: > My intuition says that laziness and purity are distinct whereas yours says > that purity is a necessary condition. This is what needs to be reconciled. > I think laziness requires purity to make sense. Laziness implies that the order of evaluation is highly unpredictable and depends strongly on the implementation details of libraries and such (which you may not have access to). So it's fickle. Someone adds an if statement somewhere and all of a sudden a variable gets evaluated earlier than it used to. It would be madness to write any code which depends on this unpredictable behaviour. In other words, the expressions that get evaluated lazily must not have side effects. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why?
On Thu, Dec 10, 2009 at 4:15 PM, John D. Earle wrote: > To elaborate there is another language that is also a functional > language. I won't mention the name so as not to offend anyone. It too is > effect free, that is what makes it functional and it is a functional > language in the true sense of the term, but it is not effect free in the > sense that Haskell is effect free. This other language is effect free in > every practical sense whereas Haskell is effect free in a strict sense. > Why would anyone be offended? I'd prefer if you tried to be clear about what you mean, rather than intentionally obscure your points to avoid causing offence. Be specific. What language? How is it different than Haskell w.r.t. purity? -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: killer app, again
On Thu, Dec 10, 2009 at 1:38 PM, Bulat Ziganshin wrote: > Hello Sebastian, > > Thursday, December 10, 2009, 4:27:49 PM, you wrote: > > The killer app for that, IMO, is parallelism these days > > btw, are you seen Google App Engine? it's python/java ATM, but i think > that haskell will be ideal fit there. it's all about > computations-in-cloud, or more precisely hosting-in-a-cloud, like > Amazon EC2 > > so, both individual cpus and largest servers now are multi-threaded, > it just need some time so EC2/GAP developers will realize Haskell > potential Indeed. Something like Windows Azure could be a good fit too (as it more directly supports native code than GAE does). -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why?
On Thu, Dec 10, 2009 at 12:01 PM, John D. Earle wrote: > This is a matter that I genuinely at the present time do not grasp and I > am hoping that some of you who are more familiar with the Haskell language > may be able to help enlighten me. I feel the question to be an important > one. What material benefit does Haskell derive from being a "pure" > functional language as opposed to an impure one? Please provide examples as > I require instruction. > The killer app for that, IMO, is parallelism these days.In large applications it's very hard to know for sure that a function truly has no side effects, so if the language can actually guarantee it for you then that certainly has immense value if you're trying to run things in parallel. Of course, various forms of lazy processing is becoming popular even in mainstream languages (especially with LINQ etc.), which also requires that the expressions to be pure. Currently mainstream languages rely on programmers being Very Careful, but again these kinds of assumptions aren't scalable. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell job opportunity
On Tue, Dec 8, 2009 at 5:54 PM, Tom Tobin wrote: > On Tue, Dec 8, 2009 at 11:09 AM, siki wrote: > > I've posted this before but did not get a whole lot of responses, so here > it > > is again: > [...] > > You should have at least a bachelor’s degree in computer science from a > top > > university > > Might I humbly suggest that this is going to severely limit your > hiring options? You're looking for the intersection of sets of people > who: > > - Have a BS in computer science (cuts out a fair number of people) > - Graduated from a "top university" (cuts out a *lot* of people) > - Is familiar with Java (cuts out some people) > - Is skilled with Haskell (a fair bet for many on this mailing list, at > least) > - Can work in the Manhattan area (cuts out a *lot* of people) > - Is looking for a job. Haskell is still exotic enough that it has a disproportionate amount of Giant Brains among its practitioners. Companies tend to want to hang on to these, even in a recession. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is Haskell a Fanatic?
On Thu, Dec 3, 2009 at 5:09 PM, John D. Earle wrote: > See "[Haskell-cafe] Optimization with Strings ?" for background. > > Don Stewart wrote, "the guarantees of purity the type system provides are > extremely > useful for verification purposes". My response to this is in theory. This > is what caught my attention initially, but the language lacks polish and > does not appear to be going in a direction where it shows signs where it > will self-correct. It may even be beyond repair. I care about others and I > don't want people to be misled. > > I am already well aware of the numbers. They do not impress me. I have > written on this already. I have given Haskell the benefit of the doubt and > said, What's wrong with being uncompromising? There is something wrong with > it, if it has taken you off the path of truth. This is not uncompromising. > This is something else. It is called fanaticism and this is the opinion that > I have come to after due consideration. > > If you are going to argue your case, be constructive. Tell me how the type > system is not flawed and how the Haskell language is rigorous. What proof do > you have of this? Explain to me how Haskell has been merely uncompromising > in its pursuit of perfection and did not manage to step over the threshold > into fanaticism. Please remain on topic and on point. > I honestly don't understand what your beef is. Could you explain what you mean with some specifics? In what way does Haskell lack polish? What makes you think it's not going in a direction where it will self correct? What's the "path of truth" and in what way is Haskell not on it? I would very much appreciate if you could try to explain what you mean using specific examples. I read the other thread and the post of yours didn't really seem to make much sense to me there either. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] You are in a twisty maze of concurrency libraries, all different ...
On Fri, Dec 4, 2009 at 12:28 PM, Patrick Caldon wrote: > Neil Brown wrote: > >> Patrick Caldon wrote: >> >>> >>> I'm looking for the "right" concurrency library/semantics for what should >>> be a reasonably simple problem. >>> >>> I have a little simulator: >>> >>> runWorldSim :: MTGen -> SimState -> IO SimState >>> >>> it takes about a second to run on a PC. It's functional except it whacks >>> the rng, which needs IO. I run 5-10 of these jobs, and then use: >>> >>> mergeWorld :: [SimState] -> SimState >>> >>> to pick the best features of the runs and build another possible world >>> (state). Then I use this new world to run another 5-10 jobs and so on. I >>> run this through ~2 iterations. >>> >>> It's an obvious place for parallelism. >>> >>> I'm looking for a concurrency library with something like: >>> >>> forkSequence :: Int -> [IO a] -> IO [a] >>> >>> which I could call with something like this: >>> >>> forkSequence 4 (take 10 (repeat (runWorldSim g ss))) >>> >>> this would construct 4 threads, then dispatch the 10 jobs onto the >>> threads, and pack up the >>> results into a list I could run through my merger. >>> >> Why particularly do you want to run the 10 jobs on 4 threads? Haskell's >> run-time is quite good at spreading out the lightweight threads onto all >> your cores, so the easiest thing to do is run the 10 jobs on 10 >> (light-weight) threads and let the run-time sort out the rest. >> > > Thanks so much for that! I'll give it a go. > > Different threads is just because some of the jobs are memory hogs, and I > want to minimize the number running simultaneously. I'll see what happens > with a runPar-like approach, and use a queue-based approach if it becomes a > problem. > > So if what you want is a function: >> >> runPar :: [IO a] -> IO [a] >> >> you can easily construct this. Shameless plug: my CHP library effectively >> has this function already, runParallel :: [CHP a] -> CHP [a] (CHP being a >> slight layer on top of IO). But you can do it just as easily with, say, >> STM. Here is a version where order doesn't matter (apologies for the >> point-free style): >> >> import Control.Concurrent >> import Control.Concurrent.STM >> import Control.Monad >> >> modifyTVar :: TVar a -> (a -> a) -> STM () >> modifyTVar tv f = readTVar tv >>= writeTVar tv . f >> >> runPar :: [IO a] -> IO [a] >> runPar ps >> = do resVar <- newTVarIO [] >> mapM_ (forkIO . (>>= atomically . modifyTVar resVar . (:))) ps >> atomically $ do res <- readTVar resVar >> when (length res < length ps) retry >> return res >> >> If order does matter, you can zip the results with an index, and sort by >> the index afterwards. If efficiency matters, you can perform other tweaks. >> But the principle is quite straightforward. Or you can refactor your code >> to take the IO dependency out of your random number generation, and run the >> sets of pure code in parallel using the parallel library. If all you are >> using IO for is random numbers, that's probably the nicest approach. >> >> Good, fast random numbers are unfortunately necessary - I had a nice > implementation using System.Random, but had to rewrite it because > performance was poor :( . Have you tried this, pure, library? http://hackage.haskell.org/package/mersenne-random-pure64 <http://hackage.haskell.org/package/mersenne-random-pure64> -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] faster compiling for ghc
On Thu, Nov 12, 2009 at 12:39 PM, Bulat Ziganshin wrote: > Hello Peter, > > Thursday, November 12, 2009, 3:26:21 PM, you wrote: > > incremental is just a word. what exactly we mean? Incremental linking means the general idea of reusing previous linking results, only patching it up with respect to changed obj files. So it's about reducing link times, not compile times. This has various consequences for executable size etc. so not something you'd want to do for release builds I think... Here's the documentation for VC's incremental linking option: http://msdn.microsoft.com/en-us/library/4khtbfyf(VS.80).aspx -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the "code-reuse" destiny of OOP?
On Sun, Nov 1, 2009 at 2:00 AM, Michael Vanier wrote: > Gregory Collins wrote: > >> Tom Davie writes: >> >> >> >>> On 10/31/09, Magicloud Magiclouds >>> wrote: >>> >>> >>>> After all, I never think OO as an oppsite way to all other things. The >>>> idea is so general that if you say I cannot use it in Haskell at all, >>>> that would make me feel weird. The only difference between languages >>>> is, some are easy to be in OO style, some are not. >>>> >>>> >>> Wow, someone drank the cool aid! >>> >>> >> >> Doing OO-style programming in Haskell is difficult and unnatural, it's >> true (although technically speaking it is possible). That said, nobody's >> yet to present a convincing argument to me why Java gets a free pass for >> lacking closures and typeclasses. >> >> G. >> >> > Because most programmers have never heard of closures and typeclasses, and > thus have no idea how useful they are? :-( > > BTW using existential types in Haskell you can mimic OO to a pretty decent > degree, at least as far as interfaces are concerned. > I kind of wish we had some convenience notation for doing value-based dispatch like that Something like foo :: [ ] -> String foo xs = concatMap show xs > foo [ 5, True, 1.3 ] "5True1.3" (where wrapping a class up in angle brackets makes it into an existentially qualified wrapper, which is instantiated in the class itself -- maybe we need explicit conversion from e.g. Int to though...) You don't need it very often, but I wonder if that's because there genuinely isn't a need, or if you tend to avoid writing code in ways which would need it (ask a Java programmer, and they'll probably tell you that the need for type classes and closures don't come up very often - which is clearly untrue for a Haskell programmer). -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] error on "--++ bla bla bla"
On Thu, Oct 1, 2009 at 12:52 AM, Hong Yang wrote: > Hi, > > I got an error if one of lines reads "--++ bla bla bla" where I tried to > comment, but "-- ++ bla bla bla" (notice the space after "--") is OK. > > Do you think this revealed a tiny bug in the GHC compiler (I am using > Windows Haskell Platform 2009.2.0.2)? > Line comments start with "-- ", not just "--". -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
On Wed, Sep 30, 2009 at 8:32 AM, Andrew Coppin wrote: > > > (Mr C++ argues that homo sapiens fundamentally think in an imperative way, > and therefore functional programming in general will never be popular. We > shall see...) You could use the same argument against, say, utensils. Being "natural" or "intuitive" is a 100% irrelevant metric for any tool. What matters is if it's effective or not. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strong duck typing / structural subtyping / type class aliases / ??? in Haskell
On Fri, Sep 25, 2009 at 10:55 PM, Casey Hawthorne wrote: > On Fri, 25 Sep 2009 23:25:21 +0200, you wrote: > > >On Fri, Sep 25, 2009 at 8:14 PM, Job Vranish wrote: > > > >> Supposedly OCaml has an OO feature that does this but I haven't tried it > >> out. > >> > > > >Indeed, OCaml has stuctural polymorphism, it's a wonderful feature. > > > >*# let f myobj = myobj#foo "Hi !";; > >val f : < foo : string -> 'a; .. > -> 'a = * > > > >IIRC, there has been work on Template Haskell for structural polymorphism. > > Structural subtyping/polymorphism: > > Pros: > - an object can be coerced to any compatible type, the types do not > have to be specified ahead of time, that is at compile time. > > Cons: > - may be overly permissive; some coercions might not make sense > semantically. > > I wonder how Haskell will minimize the cons, since it is strongly > typed. > > I kind of think there's no real problem here. If you say that you can accept any record with a given set of fields, then you have to make sure you make no other assumptions. This is, in principle, no different from passing a speed Double to a function that expects a mass Double (e.g. it may produce garbage for negative values). In both cases a function that requires extra invariants can enforce it by using a newtype that's constructed and manipulated in a way which preserves the extra semantic rules. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal install on Windows 7
On Thu, Sep 10, 2009 at 10:58 AM, Duncan Coutts wrote: > On Wed, 2009-09-09 at 20:19 +0100, Sebastian Sylvan wrote: > > > > > > On Wed, Sep 9, 2009 at 1:28 PM, Duncan Coutts > > wrote: > > > > > If the Windows users can come to a consensus on whether the > > default should be global or user, then we can easily switch > > it. The same applies for the default global or user > > installation paths. > > > I think it's morally right to run as user by default. Yes, the windows > > culture has some legacy that may, on occasion, make it slightly harder > > to use "well behaved" programs, but it's fairly minor these days. > > So is it just a matter of switching the default, or do the default user > paths have to change too? Is there any recommended/sensible place for > installing per-user applications on Windows? (I think there wasn't on > XP, but perhaps that's changed on Vista/Win7) > > I think it's %LOCALAPPDATA% -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal install on Windows 7
On Wed, Sep 9, 2009 at 1:28 PM, Duncan Coutts wrote: > On Tue, 2009-09-08 at 09:58 -0500, Jeff Wheeler wrote: > > On Tue, Sep 8, 2009 at 9:17 AM, Peter Verswyvelen > wrote: > > > > > Ouch, right, I forgot the default is global. It works fine with cabal > > > install --user. And of course I could have edited the default config > > > file, setting user-install: True > > > > > > Well, maybe for newbies this might be a bit confusing. > > > > Yep, I agree. I'm not sure why Cabal defaults to --global on Windows, > > but I found it quite counter-intuitive having come from a Linux > > environment. I forgot about the different default for some time. > > It was because last time we discussed this, the Windows users seemed to > be of the opinion that things were simpler with global installs since > the %PATH% would be right by default and "everyone runs as Administrator > anyway". That may well be different now. > > If the Windows users can come to a consensus on whether the default > should be global or user, then we can easily switch it. The same applies > for the default global or user installation paths. > I think it's morally right to run as user by default. Yes, the windows culture has some legacy that may, on occasion, make it slightly harder to use "well behaved" programs, but it's fairly minor these days. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
On Sat, Aug 22, 2009 at 3:20 PM, staafmeister wrote: > > > Thank you for the reply. > > > Thomas ten Cate wrote: > > > > Although you most certainly can use a State monad, in most problems > > this isn't necessary. Most algorithms that you need to solve > > programming contest problems can be written in a purely functional > > style, so you can limit monadic code to just a few helper functions. > > > > Yes I know but there are a lot of problems requiring O(1) array updates > so then you are stuck with IO again Not necessarily. The ST monad will usually do just as well. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
On Fri, Aug 21, 2009 at 11:42 PM, Stavenga, G.C. wrote: > > > Hi, I'm just started to learn Haskell. Coming from a programming contest > background (where it is important to be able to solve problems in a small > amount of code) I'm wondering what the best way is for simple IO. > > A typical input file (in a programming contest) is just a bunch of numbers > which you want to read one by one (sometimes interspersed with strings). In > C/C++ this is easily done with either scanf or cin which reads data > separated by spaces. In Haskell I have not found an equally satisfactionary > method. The methods I know of > > 1) Stay in the IO monad and write your own readInt readString functions. A > lot > of code for something easy. > > 2) Use interact together with words and put the list of lexemes in a State > monad and define getInt where at least you can use read. > > 3) Use ByteString.Char8 which has readInt (but I couldn't find a > readString). But one has to put it also in a State monad. > > I think that there must be standard function that can do this. What do > experienced Haskellers use? > I usually just whip up a quick parser using Text.ParserCombinators.Parsec<http://www.haskell.org/ghc/docs/latest/html/libraries/parsec/Text-ParserCombinators-Parsec.html> -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] gbp sign showing as unknown character by GHC
Both of these happen on Windows 7 64-bit for me too. On Wed, Aug 19, 2009 at 7:08 PM, Iain Barnett wrote: > > > 2009/8/19 David Leimbach > >> Interesting... GHCI bug? Didn't the readline dependency go away not too >> long ago? Could it be related? >> > > I just tried this > > Prelude> putStrLn "\£" > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.4 for i386-unknown-linux): > charType: '\163' > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > So perhaps I should put in a bug report, as that shouldn't happen (it > doesn't with some other characters I tried), unless anyone has a different > idea? I'm running Arch Linux with xmonad and using roxterm, so perhaps it's > something to do with my setup? > > Iain > > > > _______ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
On Sun, Aug 16, 2009 at 2:50 PM, John A. De Goes wrote: > On Aug 15, 2009, at 5:32 PM, Sebastian Sylvan wrote: > > On Sun, Aug 16, 2009 at 12:18 AM, John A. De Goes > wrote: > >> You must think I'm arguing for some kind of low-level analog of C, >> augmented with an effect system. I'm not. You can't do that. >> > > No, I don't. I think you're arguing for making access to mutable state > commutative. Are you not? > > > There are many cases when mutation to state _is_ commutative. I can't argue > that certain operations are _always_ commutative without talking about the > language. > > Pretend I'm arguing for a mostly functional language and effect system that > maximize the opportunities for parallelizing code. > > I'm not saying you shouldn't parallelise them in very specific > circumstances *where it's safe*, I'm just saying that you shouldn't assume > that it's safe unless you know it is. If you want to do a transformation > that's unsafe in general, but safe in a specific circumstance, then of > course, go ahead! > To my reading it seems like you're arguing that memory/file access should > *always* be considered commutative though, which is what I'm objecting too. > > > In the right language, many times of memory (and possibly file) operations > _always_ commute. In the wrong language, they _sometimes_ commute or _never_ > provably commute. I'm not arguing for the assumption in any language where > it is false. > Well now I'm confused. Earlier you said: "In the case of a file system, you can commute two sequential reads from two different files. This has no effect on the result of the computation, assuming no interference from other programs -- and if there _is_ interference from other programs, then guarantees go out the window, _with or without_ commuting." It's the "assuming no interference form other programs" that bugs me, because when you're reading outside data you kind of have to assume that there *is* outside interference because you can't really protect yourself against it. Furthermore, that "interference" is often more like cooperation/communication so you're actually *counting* on "outside interference". E.g. consider durable storage that have to survive random reboots etc., I'm sure there are quite a few very carefully considered sequential steps that need to happen in just the right order to get a consistent view of the data when you read it back in. That earlier quote seems to imply that you're arguing for just treating all file reads as commutative and just ignoring that this is an unsafe assumption. If you no longer think this then I guess we're in agreement. My point is that *if* there is any chance for outside access to anything you're reading, then ordering *does* matter. This is the case for file reads, and may be the case for memory reads. For the latter the compiler could *potentially* figure out when memory can't be touched by other threads and make them commute, but I still think the semantics for mutable code should be sequential (since it unifies the two scenarios), and then the compiler might make them commutative in scenarios where it's guaranteed to be safe. For file reads, I don't think there's a way of knowing that two file reads are independent, especially since this dependency might live *outside* the program (e.g. the dependency might only exist for the human reading the output of the program). So really, if there's any chance something else might touch your data, the only reasonably safe way to deal with it is to enforce sequentiality. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
On Sun, Aug 16, 2009 at 12:18 AM, John A. De Goes wrote: > On Aug 15, 2009, at 4:59 PM, Sebastian Sylvan wrote: > > >> Your point about safety in C has no relation to safety in a functional >> language with a sophisticated effect system. >> >> I'm sorry, but I think it does. You're advocating that modifications to >> mutable state shouldn't have sequential semantics, >> > > You must think I'm arguing for some kind of low-level analog of C, > augmented with an effect system. I'm not. You can't do that. No, I don't. I think you're arguing for making access to mutable state commutative. Are you not? > In such conditions, multiple sequential writes can be safely parallelized, > in addition to a host of other optimizations. I'm not saying you shouldn't parallelise them in very specific circumstances *where it's safe*, I'm just saying that you shouldn't assume that it's safe unless you know it is. If you want to do a transformation that's unsafe in general, but safe in a specific circumstance, then of course, go ahead! To my reading it seems like you're arguing that memory/file access should *always* be considered commutative though, which is what I'm objecting too. > I'm pointing out that this is the case today in C on many CPUs and it's a >> royal pain to work with in practice (causing many almost-impossible-to-debug >> crashes). I would not want functional languages to adopt something that's >> proven to be insanity-inducingly difficult to use. >> > > Please don't ever bring up C again. You can't do anything interesting in C. I bring up C until you can explain how what you're suggesting is any different from the current state in C w.r.t. the ordering of memory access. >From what you've said so far I can't see how it is, and it would be instructive to look at the problems with the approach you're advocating since we're dealing with its pitfalls *today* in the real world. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
On Sat, Aug 15, 2009 at 11:45 PM, John A. De Goes wrote: > > Effect system optimizations are about taking programs that are correct, and > transforming them to faster but equivalent programs that are still correct. And since reordering access to externally modifiable data (external includes memory if it's visible to other therads) is *not* safe, that shouldn't be done. You're arguing for doing unsafe (i.e. they can cause a functioning program to become non-functioning) transformations! That said, your reasoning precludes the use of file read buffering, and > other similar operations that are routinely done. It's only an illusion that > such programs are "safe", with or without transformation of sequential read > operations. Yes, you do have to be very careful about abstractions like that, but the fact that we have some of that now, which can cause very hard-to-catch bugs when you rely on ordering, is no good argument that we should add even more of it! -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
On Sat, Aug 15, 2009 at 11:54 PM, John A. De Goes wrote: > On Aug 14, 2009, at 9:34 PM, Sebastian Sylvan wrote: > > On Sat, Aug 15, 2009 at 3:55 AM, John A. De Goes wrote: >> >> If you don't like the file system, consider mutable memory. An effect >> system will tell me I can safely update two pieces of non-overlapping, >> contiguous memory concurrently, even in different threads if the complexity >> so justifies it. > > > I'd like to point out that this relaxation of sequencing for memory > operations is already in effect in C on many CPUs. Even though you write > things sequentially, it doesn't actually happen sequentially unless you > explicitly say so with memory barriers. This causes massive head-aches and > horrible bugs that are almost impossible to track down whenever you actually > do depend on the order (usually in multi-threading scenarios, e.g. lockless > data structures). > > > That's because C has no effect system and is too low-level for an effect > system. That's no argument against one in a high-level language similar in > syntax to Haskell. > ... > > Your point about safety in C has no relation to safety in a functional > language with a sophisticated effect system. > I'm sorry, but I think it does. You're advocating that modifications to mutable state shouldn't have sequential semantics, I'm pointing out that this is the case today in C on many CPUs and it's a royal pain to work with in practice (causing many almost-impossible-to-debug crashes). I would not want functional languages to adopt something that's proven to be insanity-inducingly difficult to use. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
On Sat, Aug 15, 2009 at 3:55 AM, John A. De Goes wrote: > > If you don't like the file system, consider mutable memory. An effect > system will tell me I can safely update two pieces of non-overlapping, > contiguous memory concurrently, even in different threads if the complexity > so justifies it. I'd like to point out that this relaxation of sequencing for memory operations is already in effect in C on many CPUs. Even though you write things sequentially, it doesn't actually happen sequentially unless you explicitly say so with memory barriers. This causes massive head-aches and horrible bugs that are almost impossible to track down whenever you actually do depend on the order (usually in multi-threading scenarios, e.g. lockless data structures). The point is, the safer option is to enforce a sequential model (like Haskell does), since that way you can always rely on ordering even if you don't even realise you need to, and there's plenty of practical experience indicating that the other option (explicit barriers to indicate when something isn't commutative) is sheer madness. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
On Sat, Aug 15, 2009 at 3:55 AM, John A. De Goes wrote: > On Aug 14, 2009, at 8:21 PM, Sebastian Sylvan wrote: > > But you can't! I can easily envisage a scenario where there's a link >> between two pieces of data in two different files, where it's okay if the >> data in file A is "newer" (in a versioning sense, not a timestamp sense) >> than the corresponding data in file B, but the opposite doesn't hold. So if >> you have another program writing that data it will write first to A, and >> then to B. The program reading this *must* then read the files in the >> correct order (B then A, to ensure the data from A is always newer or at the >> same "version" as the data in B). >> > > That's nonsense. Because what happens if your program reads A while the > other program is writing to A Depends on the file system. For example, the file could be locked so you would just block. Or the file system might be transactional. I used files as an example, the point wasn't to get bogged down in exact semantics of concurrent access - assume all reads/writes are atomic (or can be viewed as such from the apps POV) for the purposes of discussion. > , or reads B just after the other program has written to A, but before it > has written to B? This is precisely the scenario that would be legal in that case. You'd end up with data from A that's newer than B, which we said was okay, but for some app-specific reason the opposite is *not* okay. In order for you not to crash you *have* to make sure you read from B first, because otherwise you could read from A right before it's updated, and then read B right after both A and B have been updated which means B is now newer than A and your program goes boom. The point is that the ordering of reads are not arbitrary. > As I said before, you cannot make any guarantees in the presence of > interference, _with or without_ commuting. That's a separate issue. The problem is that if you *do* depend on outside "interference", then the sequence of operations matters. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
On Fri, Aug 14, 2009 at 9:41 PM, John A. De Goes wrote: > > Hmmm, my point (perhaps I wasn't clear), is that different effects have > different commutability properties. In the case of a file system, you can > commute two sequential reads from two different files. > But you can't! I can easily envisage a scenario where there's a link between two pieces of data in two different files, where it's okay if the data in file A is "newer" (in a versioning sense, not a timestamp sense) than the corresponding data in file B, but the opposite doesn't hold. So if you have another program writing that data it will write first to A, and then to B. The program reading this *must* then read the files in the correct order (B then A, to ensure the data from A is always newer or at the same "version" as the data in B). Anytime you talk to the outside world, there may be implicit ordering that you need to respect, so I really think that needs to be serialized. Of course, there may be things in the IO monad that doesn't talk to the outside world that could be commutative. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
On Thu, Aug 13, 2009 at 2:19 PM, John A. De Goes wrote: > What if you have another program, written in C or something, that > monitors a file for changes, and if so changes the contents of another file? > Surely to catch that you must mark *all* file system access as > "interefering"? Even worse, another program could monitor the state of a > file and conditionally disable thet network driver, now file access > interferes with network access. > > > A compiler or runtime system can't know about these kinds of things -- > unless perhaps you push the effect system into the operating system > (interesting idea). The best you can do is ensure the program itself is > correct in the absence of interference from other programs > I think the best you can do is make sure any code which is vulnerable to such interference won't be subject to unsafe transformations (like changing the order of evaluation). So I do think pretty much anything that relies on the outside world needs to go into one big effects "category" so the compiler/runtime will "stay out" and let the programmer explicitly define the ordering of those operations, precisely because the compiler has no way of knowing anything about what kind of assumptions are in effect. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
On Thu, Aug 13, 2009 at 4:56 AM, John A. De Goes wrote: > > The next step is to distinguish between reading file A and reading file B, between reading file A and writing file A, between reading one part of file > A and writing another part of file A, etc. When the effect system can carry > that kind of information, and not just for files, but network, memory, etc., > then you'll be able to do some extremely powerful parallelization & > optimization. > What if you have another program, written in C or something, that monitors a file for changes, and if so changes the contents of another file? Surely to catch that you must mark *all* file system access as "interefering"? Even worse, another program could monitor the state of a file and conditionally disable thet network driver, now file access interferes with network access. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Basic questions about concurrency in Haskell
Bringing the cafe back in. If I remember correctly tuning the GC is one of the things they worked on for the next release (in relation to parallelism).Here's a link to the paper: http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/multicore-ghc.pdf You can allocate dynamic memory on the C heap using the Foreign.Marshal.Alloc stuff. The Storable class allows you to specify alignment. However it's not clear you will need it in all cases. Most of the time IME all you really need is for "the business end" of object A and B to end up on different cache lines, padding them with the size of a cache line will accomplish that even if each object starts in the middle of a cache line. In other words, as long as you ensure that there's at least CACHE_LINE bytes difference between the last bit of data in A and the first bit of data in B, they won't exhibit false sharing. I'm not sure if any of the "standard" mutable references etc. respect this. Maybe someone can clarify? If you modify a thread-local IORef will that cause another thread to stall because it has it's own thread-local IORef on the same cache line? On Fri, Aug 7, 2009 at 12:42 PM, Thomas Witzel wrote: > I have not yet been able to get the dev version compiled, but I'm > looking into it (basically compiles to 99% and then stops because of a > missing or defective .mk file). Anyhow, I played more with the release > version and one thing I noticed is that the GC time increases almost > linearly with the number of cores. Is there somewhere a document that > explains the overall architecture of the GHC/RTS and how in especially > the GC acts in concurrent situations ? > > As for your comment regarding the padding the data-structures, I'll of > course also need to control the alignment in such a case. Is there > such a thing as explicit dynamic memory allocation in Haskell ? > > Thanks, Thomas > > On Wed, Aug 5, 2009 at 3:16 PM, Sebastian > Sylvan wrote: > > GHC doesn't have per-thread allocation so it's probably a bit tricky to > get > > that working. Plus, for parallelism it's not clear that a piece of data > is > > necessarily "owned" by one thead, since it could be produced by a spark > and > > consumed by another spark, those two independent sparks may not > necessarily > > occupy the same thread, which means that any *other* data accessed by the > > firs thread could thrash the cache. So really you'd need per-spark > > allocation areas which would probably make sparks very heavy weight. > > In other words, I think there's plenty of research that needs to be done > > w.r.t. scheduling things in time and space so as to avoid false sharing. > You > > could, of course, always chunk your work manually, and make sure that > each > > "chunk" works on a big block that won't share cache lines with anything > else > > (e.g. by padding the data structures). > > Also, while GHC does a fair bit of mutation on its own internal data > (thunks > > etc.), most of the "user data" is read-only, which should help. I.e. once > a > > cache line has been filled up, there won't be any synchronisation needed > on > > that data again. > > > > On Wed, Aug 5, 2009 at 8:04 PM, Thomas Witzel > > wrote: > >> > >> I'll try that. I'd like to stick with it. As for the memory, although > >> its probably quite a bit of work, it should be doable to have code > >> generated where the threads have their own, non-overlapping, memory > >> pages, so that the CPUs don't go into a cache-thrashing death-match. > >> I'll spend some more time with Haskell and then go from there. > >> > >> On Wed, Aug 5, 2009 at 3:01 PM, Sebastian > >> Sylvan wrote: > >> > > >> > > >> > On Wed, Aug 5, 2009 at 6:59 PM, Thomas Witzel < > witzel.tho...@gmail.com> > >> > wrote: > >> >> > >> >> 2. I started with the very simple nfib example given in the manual > for > >> >> Control.Parallel (Section 7.18). On my systems using multiple cores > >> >> makes the code actually slower than just using a single core. While > >> >> the manual cautions that this could be the case for certain > >> >> algorithms, I'm wondering whether this is the desired behaviour for > >> >> this example. > >> >> > >> >> I'm using ghc 6.10.4 right now. > >> > > >> > IIRC the development version of GHC has some major work to optimize > >> > concurrency, so it may be worth trying that. In particular I believe > it > >> > executes sparks in batches, to reduce the overhead (which hopefully > >> > fixes > >> > your issue). > >> > > >> > -- > >> > Sebastian Sylvan > >> > > > > > > > > > -- > > Sebastian Sylvan > > > -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Basic questions about concurrency in Haskell
On Wed, Aug 5, 2009 at 6:59 PM, Thomas Witzel wrote: > > > 2. I started with the very simple nfib example given in the manual for > Control.Parallel (Section 7.18). On my systems using multiple cores > makes the code actually slower than just using a single core. While > the manual cautions that this could be the case for certain > algorithms, I'm wondering whether this is the desired behaviour for > this example. > > I'm using ghc 6.10.4 right now. > IIRC the development version of GHC has some major work to optimize concurrency, so it may be worth trying that. In particular I believe it executes sparks in batches, to reduce the overhead (which hopefully fixes your issue). -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing a pnm file
On Mon, Aug 3, 2009 at 11:17 AM, CK Kashyap wrote: > Thanks Sebastian, > Array/accumArray sounds like what I am looking for. > > Int -> ( a -> a ) -> [a] -> [a] > approach, would it not be expensive on memory as well? Or is it just speed? > Well memory will be garbage collected fairly quickly so I don' think that's an issue, other than the effects on speed that the extra allocations would have. It's probably mainly speed because each pixel would have time complexity O(n+m) rather than O(1) for an n*m image... -- 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] Writing a pnm file
On Mon, Aug 3, 2009 at 6:38 AM, CK Kashyap wrote: > Thanks Sebastian, > ppm module is indeed very useful. So, I guess my question then just boils > down to, how can I write a function to mimic the setPixel function -> > > Basically, a blank white image would look like this (as per ppm module) > [ >[ (255, 255, 255) , (255, 255, 255) , (255, 255, 255) ] , -- 3 columns > of row 1 >[ (255, 255, 255) , (255, 255, 255) , (255, 255, 255) ]--- 3 > columns of row 2 > ] > > setPixel x y r g b when called like this - setPixel 0,0,255,0,0 > > [ >[ (255, 0, 0) , (255, 255, 255) , (255, 255, 255) ] , -- 3 columns of > row 1 >[ (255, 255, 255) , (255, 255, 255) , (255, 255, 255) ]--- 3 > columns of row 2 > ] > > What would be a good way to implement such a function? > Well you could start by writing a function like: adjustElem :: Int -> ( a -> a ) -> [a] -> [a] That would basically apply a function to a specific element in a list (indexed by the first parameter). Look at splitAt in Data.List, it may be useful. Then you can use this in a nested way, by calling adjustElem to modify the row you're interested in, and the function you pass in to adjust that row would in turn call adjustElem on the specific pixel in that row). However, this may be very slow. If you don't care about speed it'll work fine, but if you really do want to build up an image by successive single-pixel modifications, you should consider first using an Array and accumArray, this will be much faster as internally accumArray can use a mutable array (while the external interface is still pure). Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing a pnm file
On Sun, Aug 2, 2009 at 4:00 PM, CK Kashyap wrote:
> Hi,
> Now that I've understood how to generate raster points of a line in Haskell
> - the next thing I want to do is generate a pnm file with it. I've done it
> in perl as of now. In perl, I can have a scalar variable $x contain a string
> of 256*256*3 bytes (for 24-bit 256x256 image) and set pixels using substr on
> LHS. I was wondering how I could do something similar in Haskell?
>
> sub setPixel{
> my($x,$y,$red,$green,$blue)=...@_;
> my$pixel=pack "CCC",$red,$green,$blue;
> my$offset=$WIDTH*$y*3 + $x*3;
> substr($image,$offset,3) = $pixel;
> }
>
There's a library on hackage which does this
http://hackage.haskell.org/package/ppm
You can install this by doing
>cabal install ppm
Here's an example usage (this uses the binary version of ppm, the docs for
ppm has an example for the ASCII version):
writePPM fname img = withBinaryFile fname WriteMode (\h -> hPutStr h (ppm_p6
img) )
If you're looking for the learning experience, you could always read the
source for the library (which is pretty tiny).
--
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] Performance of functional priority queues
Is that not what I said? On Mon, Jun 15, 2009 at 2:12 PM, Lennart Augustsson wrote: > A priority queue can't have all operations being O(1), because then > you would be able to sort in O(n) time. So O(log n) deleteMin and > O(1) for the rest is as good as it gets. > > On Mon, Jun 15, 2009 at 10:40 AM, Sebastian > Sylvan wrote: > > > > > > On Mon, Jun 15, 2009 at 4:18 AM, Richard O'Keefe > wrote: > >> > >> There's a current thread in the Erlang mailing list about > >> priority queues. I'm aware of, for example, the Brodal/Okasaki > >> paper and the David King paper. I'm also aware of James Cook's > >> priority queue package in Hackage, have my own copy of Okasaki's > >> book, and have just spent an hour searching the web. > >> > >> One of the correspondents in that thread claims that it is > >> provably impossible to have an efficient priority queue implementation > > > > > > A priority queue based on skewed binomial heaps is asymptotically optimal > > (O(1) for everything except deleteMin which is O(log n)), so if that's > what > > he means by "efficient" then he's most definitely wrong. If he's talking > > about "small constant factors" then it's harder to understand what he's > > referring to more precisely, and therefore what he means by "provably". > > > > -- > > Sebastian Sylvan > > +44(0)7857-300802 > > UIN: 44640862 > > > > ___ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > -- 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] Performance of functional priority queues
On Mon, Jun 15, 2009 at 4:18 AM, Richard O'Keefe wrote: > There's a current thread in the Erlang mailing list about > priority queues. I'm aware of, for example, the Brodal/Okasaki > paper and the David King paper. I'm also aware of James Cook's > priority queue package in Hackage, have my own copy of Okasaki's > book, and have just spent an hour searching the web. > > One of the correspondents in that thread claims that it is > provably impossible to have an efficient priority queue implementation A priority queue based on skewed binomial heaps is asymptotically optimal (O(1) for everything except deleteMin which is O(log n)), so if that's what he means by "efficient" then he's most definitely wrong. If he's talking about "small constant factors" then it's harder to understand what he's referring to more precisely, and therefore what he means by "provably". -- 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] Convert IO Int to Int
On Wed, Jun 10, 2009 at 2:10 PM, Sebastian Sylvan < sebastian.syl...@gmail.com> wrote: > > > On Wed, Jun 10, 2009 at 2:08 PM, Sebastian Sylvan < > sebastian.syl...@gmail.com> wrote: > >> >> >> randomList :: (RandomGen g) -> Int -> g -> [Integer] >> > > Just spotted this typo, it should be: > > randomList :: (RandomGen g) = Int -> g -> [Integer] > > There may be other minor typos as I don't have a compiler handy. > Oh come on! randomList :: (RandomGen g) => Int -> g -> [Integer] -- 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] Convert IO Int to Int
On Wed, Jun 10, 2009 at 2:08 PM, Sebastian Sylvan < sebastian.syl...@gmail.com> wrote: > > > randomList :: (RandomGen g) -> Int -> g -> [Integer] > Just spotted this typo, it should be: randomList :: (RandomGen g) = Int -> g -> [Integer] There may be other minor typos as I don't have a compiler handy. -- 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] Convert IO Int to Int
On Wed, Jun 10, 2009 at 12:55 PM, ptrash wrote: > > Hi, > > I have tried on the console to write > > x <- randomRIO(1,10) > :t x > > Everythings fine and the type of x is > x :: Integer > The type of x *in the context of an IO computation* is Integer. GHCi is basically an IO computation. Another example: foo :: Integer -> Integer foo x = x+1 main :: IO () main = do x <- randomRIO (1,10) print (foo x) This is fine. In the context of the IO computation "main", x is bound to the result of "randomRIO (1,10)", and you can pass it to functions expecting Integer values (not IO Integer!). So in this way, and this way only, you can access the Integer returned by an IO action. You can *not* access the Integer returned by an IO action from within a normal function, *only* by by binding it to a variable (with "<-") inside *another IO action*. I'm not sure what text you're using to learn Haskell, but a very basic and fundamental property of Haskell (and indeed 99% of why it's cool, IMO) is that code which does side effects (like reading from a global random number seed), and code which does not do side effects (i.e. functions which always return the same result given the same input) are kept extremely separate. This appears to be the source of your confusion. It's simply not possible to do side effect inside a normal function, just like it's not possible to cast an arbitrary integer to a pointer in Java - the language is designed to not require it, and the benefits of being able to trust that your program obeys certain properties are worth it. >randomList :: Int -> [Integer] >randomList 0 = [] >randomList n = do >r <- randomRIO (1, 10) >r:randomList(n-1) In this code you're trying to do side effects from within a pure function. This is *not* allowed. You must either make randomList an IO action (i.e returning IO [Integer]), or remove any impurities from its implementation. For example you can make randomList take a randon number generator and use the random number generator to produce random values: randomList :: (RandomGen g) -> Int -> g -> [Integer] randomList 0 _ = [] randomList n generator = r : randomList (n-1) newGenerator where (r, newGenerator) = randomR (1,10) generator This is totally pure, since if you pass in the same random number generator multiple times, you'll get the exact same result. Note that randomR returns a random values and a new random number generator (you wouldn't want to pass along the same one in the recursive call to randomList as that would give you an identical random number each time you use it!). So where do you get the random number generator from? Well one way is to make your own using "mkStdGen", which produces one from a seed (it will give you an identical one given an identical seed). Another way is to use "newStdGen" to generate one from within an IO action: main :: IO () main = do generator <- newStdGen print ( randomList 10 generator ) The point, though, is that things having side effects (such as newStdGen) can only be used in the context of something else having side effects. So the "IO" type is "contagious", as soon as you use it in a function, then that function must also return IO, and so on for anything using *that* function and son. -- 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] Concurrent Haskell Actions with Timeout
On Sat, May 30, 2009 at 10:32 PM, Cetin Sert wrote: > Thank you for your reply, I'd come up with the following: > > timed :: Int → IO a → b → IO (Either b a) > timed max act def = do > > r ← new > > t ← forkIO $ do > a ← act > r ≔ Right a > > s ← forkIO $ do > wait max > e ← em r > case e of > True → do > kill t > r ≔ Left def > > False → return () > > takeMVar r > > - > > *Network.Port.Scan> timed 500 (wait 5 >> return 0) 'x' > Left 'x' > *Network.Port.Scan> timed 50 (wait 5 >> return 0) 'x' > Right 0 > > - > > before reading your reply: > > timed timeout act fallback = do >res <- newEmptyMVar >tid <- forkIO $ act >>= writeMVar res >threadDelay timeout >stillRunning <- isEmptyMVar res >if stillRunning then killThread tid >> return fallback else takeMVar res > > - > > *Network.Port.Scan> timed2 500 (wait 5 >> return 0) 'x' > > :1:33: > No instance for (Num Char) > arising from the literal `0' at :1:33 > Possible fix: add an instance declaration for (Num Char) > In the first argument of `return', namely `0' > In the second argument of `(>>)', namely `return 0' > In the second argument of `timed2', namely > `(wait 5 >> return 0)' > Right, I forgot about the "Either" bit so you'd have to make sure the action's result and the default has the same type (or modify it to return an Either). -- 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] Concurrent Haskell Actions with Timeout
2009/5/30 Cetin Sert > Hi how could one implement a function in concurrent haskell that either > returns 'a' successfully or due timeout 'b'? > > timed :: Int → IO a → b → IO (Either a b) > timed max act def = do > Something like (warning, untested code - no compiler atm). timed timeout act fallback = do res <- newEmptyMVar tid <- forkIO $ act >>= writeMVar res threadDelay timeout stillRunning <- isEmptyMVar res if stillRunning then killThread tid >> return fallback else takeMVar res -- 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] using haskell for a project
On Sat, May 2, 2009 at 6:17 PM, Nicolas Martyanoff wrote:
> Hi,
>
> I don't think I already presented myself; I'm Nicolas, a 23y french
> student, trying to learn and use haskell.
>
> I've been using C for years, for all sort of tasks, and am quite
> comfortable with it. I'm also using it 40h a week in my internship for
> network systems, so I kind of know how to use it.
>
> I discovered Haskell some monthes ago, bought `Real World Haskell',
> quickly read, and enjoyed it.
>
> So now I'd want to use it for a small project of mine, a simple
> multiplayer roguelike based on telnet. I wrote a minimal server in C, and
> it took me a few hours. Now I'm thinking about doing the same in Haskell,
> and I'm in trouble.
>
> I don't really know how to map my ideas in haskell code. For example, a
> character can cast spells, so I'd have something like this in C:
>
>struct hashtable spells;
>
>struct character {
>int n_spells;
>struct spell **spells;
>};
>
> I thought I could do something like this in haskell:
>
>spells = Data.Map.Map Int Spell
>
>data Character = Character { charSpells :: [Int] }
>
> But now I don't know how to dynamically add new spells (new spells can be
> created in my gameplay). Since I can't assign a new value to the `spells'
> variable (Data.Map.insert returns a new map), I just don't know where to
> go.
I'm not sure I understand how your C version and Haskell version are
similar?
Wouldn't the character just have a list of Spells (since this is what the C
version seems to do)? That global spells variable should probably be put in
some sort of "game state" data type that encapsulates the game world.
Then consider writing updates as a function that takes the old value, and
produces a new value. Indeed, consider letting the following function be
your main "update" for the game state.
gameTick :: Time -> PlayerInput -> GameState -> GameState
That function would update all parts of your game state, and if you want to
change some property of a character, you simply compute a new character from
the old one with the field you want to change updated. Because values are
immutable, any data you don't touch will just refer to the old stuff so it's
actually quite efficient.
You main loop could then be something like:
gameLoop oldTime gameState = do
time <- getTime
let dt = time - oldTime
input <- processInput gameState
gsNew <- gameTick dt input gameState
renderGame gsNew
gameLoop time gsNew
>
> I just wanted a 2d array to store a zone, for example, dead simple in C,
> but this kind of link
> http://greenokapi.net/blog/2009/03/10/rough-grids-in-haskell make me
> shiver.
Try a list of lists, or better yet just an Array. Make sure you update the
grid "in bulk" though, as modifying just a single element at a time is slow
with immutable arrays.
> Point is, I'd like to use haskell, but I don't know how, it seems totally
> alien.
>
> How did you manage to change the way you map ideas to code, from
> imperative to pure functional ?
Massive brain-rewiring. Keep at it, don't think in terms of modifying state,
think of it as computing new values from old values. I find that the payoff
of learning to think ,like this is massive, as it's usually much easier to
reason about.
If you really do lots of "state" in a program, consider using a state monad
like someone else already mentioned, but honestly I'd try to stay away from
it and stick to a more "functional" style as far as possible.
--
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] Parallel combinator, performance advice
This is a random idea, that's probably not going to work, but I don't have a way of testing it so I'll just post it! How about using unsafeInterleaveIO to get a lazy suspension of the result of each action, and then using par to spark off each of them? If that works you can reuse the existing task-parallel system of GHC to do the heavily lifting for you, instead of having to write your own. On Tue, Apr 7, 2009 at 11:25 AM, Neil Mitchell wrote: > Hi, > > I've written a parallel_ function, code attached. I'm looking for > criticism, suggestions etc on how to improve the performance and > fairness of this parallel construct. (If it turns out this construct > is already in a library somewhere, I'd be interested in that too!) > > The problem I'm trying to solve is running system commands in > parallel. Importantly (unlike other Haskell parallel stuff) I'm not > expecting computationally heavy Haskell to be running in the threads, > and only want a maximum of n commands to fire at a time. The way I'm > trying to implement this is with a parallel_ function: > > parallel_ :: [IO a] -> IO () > > The semantics are that after parallel_ returns each action will have > been executed exactly once. The implementation (attached) creates a > thread pool of numCapabililties-1 threads, each of which reads from a > task pool and attempts to do some useful work. I use an idempotent > function to ensure that all work is done at most one, and a sequence_ > to ensure all work is done at least once. > > Running a benchmark of issuing 1 million trivial tasks (create, > modify, read and IO ref) the version without any parallelism is really > fast (< 0.1 sec), and the version with parallelism is slow (> 10 sec). > This could be entirely due to space leaks etc when queueing many > tasks. > > I'm useful for any thoughts people might have! > > Thanks in advance, > > Neil > > _______ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- 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] Re: [Haskell-beginners] appropriateness of haskell for GUIs
2009/3/21 Adrian Neumann > > Am 21.03.2009 um 13:30 schrieb Michael Mossey: > > >> >> Thomas Davie wrote: >> >>> On 21 Mar 2009, at 00:16, Michael P Mossey wrote: >>> >>>> Hello, I'm totally new to Haskell. I'm thinking of using it for a >>>> personal project, which is a gui-based musical score editor. >>>> >>> The rough situation of GUI programming on Haskell is that it works just >>> as well as in any imperative programming language. This is rather >>> disappointing, simply because so many other things are massively easier in >>> Haskell, and this isn't true of GUI programming (yet). >>> >> >> Hi Bob, >> >> I can imagine that GUI programming is no easier (yet). It is inherently >> very "stateful." GUI's have modes, such as which screens are displayed, >> which dialogs are displayed, which options within those dialogs are valid >> given the other state of the program, etc. When I write GUIs, I often >> diagram them as state machines to get a handle on what's going on. >> >> So, I'm not familiar with GUI programming on Haskell, but would you say >> the statefulness of GUIs (in their typical implementations) is the reason >> they are no easier on Haskell? >> >> I strongly prefer to use qtHaskell because I'm familiar with Qt, and Qt is >> extremely capable. For example, it can draw text and shapes with >> antialiasing, which will be great for a music score editor. Music scores >> have lots of small shapes to fit on the screen, and antialiasing will >> provide ease of reading. I don't know how much of Qt is implemented in >> qtHaskell, or whether the latest version of Qt (4.4) is implemented. >> >> Thanks, >> Mike >> > > The main problem is, as far as I know, the complete lack of any usable GUI > designer. You have to type everything yourself. That's very annoying. It's a > lot easier in other languages because your tools take away the cumbersome > twiddling with widgets. http://en.wikipedia.org/wiki/Glade_Interface_Designer -- 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] Haskell Logo Voting has started!
On Tue, Mar 17, 2009 at 9:35 PM, John Meacham wrote: > May I recommend 'approval voting' as an alternative? It doesn't require > ordering, has nice theoretial properties, and is dead simple to > implement. everyone just votes yes on the ones they approve of, you add > up the numbers and the highest one wins. Voting yes on everything > doesn't help since then all your votes cancel out. You can do that with condorcet by just selecting the ones you approve of and making them tied for first... -- 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] Re: Haskell Logo Voting has started!
On Tue, Mar 17, 2009 at 2:24 PM, Heinrich Apfelmus < apfel...@quantentunnel.de> wrote: > Eelco Lempsink wrote: > > Hi there! > > > > I updated a couple of logo versions and ungrouped and regrouped the > > (former) number 31. Other than that, there was nothing standing in the > > way of the voting to begin imho, so I started up the competition. > > > > By now, I suppose everybody should have received their ballot. If you > > think you should have received it but didn't, please report it, I can > > resend the invitation. Also, for people not directly subscribed to the > > haskell-cafe mailing list, you can still send ballot requests until the > > end of the competition (March 24, 12:00 UTC). Make sure the message > > contains 'haskell logo voting ballot request' (e.g. in the subject). > > > > Depending on the winner of this voting round we can decide whether we > > need to continue with variations. Jared Updike already offered to > > donate a bit of time to help create several variations. But for now, > > good luck with sorting those options! :) > > Thanks for organizing this, finally I can choose ... Oh my god! How am I > supposed to make a vote? > > > I can barely remember 3 of the 113 logos, let alone memorize that #106 > is the narwhal. There are lots of very good or just good candidates and > I would like to order them all to my liking, but without instant visual > feedback on the voting ballot, this is a hopeless task. Indeed, I thought each entry would contain a thumbnail for the logo itself, but I guess it doesn't support HTML? This is pretty arduous... -- 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] Most elegant funciton for removing adjacent duplicates from a list using foldl and foldr
2009/3/15 R J > I need to write an implementation using foldl, and a separate > implementation using foldr, of a function, "remdups xs", that removes > adjacent duplicate items from the list xs. For example, remdups > [1,2,2,3,3,3,1,1]= [1,2,3,1]. > > My approach is first to write a direct recursion, as follows: > >remdups :: (Eq a) => [a] -> [a] >remdups []= [] >remdups (x : []) = [x] >remdups (x : xx : xs) = if x == xx then remdups (x : xs) else x : > remdups (xx : xs) > > This code works, but it has three cases, not usual two, namely [] and (x : > xs). > > What, if any, is the implementation using only two cases? > > Also, if three cases are required, then how can it be implemented using > foldr, and how using foldl? > > Thanks. > Perhaps it would be helpful to define a helper function with this signature: prepend :: (Eq a) => a -> [a] -> [a] Which for "prepend x xs" will put x at the front of the list, so long as the first element of the list xs is different from x. Once you have this function, take a look at the type signature for foldr. -- 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: Re[4]: [Haskell-cafe] Logo Preferences
On Mon, Mar 9, 2009 at 10:38 PM, Sebastian Sylvan < sebastian.syl...@gmail.com> wrote: > > > On Mon, Mar 9, 2009 at 10:21 PM, Bulat Ziganshin < > bulat.zigans...@gmail.com> wrote: > >> Hello Sebastian, >> >> Tuesday, March 10, 2009, 1:08:38 AM, you wrote: >> > It just seems like duplicated work to me. They're still few enough >> > that I can scan through them and multi-select the ones I like and >> > then click "move to top" in a pretty short amount of time (and then >> refine the ranking if I care). >> >> and if none of them will be among 10 most popular - it is no >> difference for you which one will be finally selected? > > > Clearly not, because if I did have a preference among them I would've > ranked them - if I didn't then I must not care either way. > I suspect 99% will have a few favourites, and then they will have a few > that they object to, and for the rest they just don't care which ones win. > Expressing that with the proposed system is easy. > Also, let's be realistic. We can all look at the list and figure out which logos are likely to be popular - so just make sure you rank those. Adding even more time and hassle for the people who are already donating their time to arrange this for free isn't going to improve things significantly, I think. -- 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: Re[4]: [Haskell-cafe] Logo Preferences
On Mon, Mar 9, 2009 at 10:21 PM, Bulat Ziganshin wrote: > Hello Sebastian, > > Tuesday, March 10, 2009, 1:08:38 AM, you wrote: > > It just seems like duplicated work to me. They're still few enough > > that I can scan through them and multi-select the ones I like and > > then click "move to top" in a pretty short amount of time (and then > refine the ranking if I care). > > and if none of them will be among 10 most popular - it is no > difference for you which one will be finally selected? Clearly not, because if I did have a preference among them I would've ranked them - if I didn't then I must not care either way. I suspect 99% will have a few favourites, and then they will have a few that they object to, and for the rest they just don't care which ones win. Expressing that with the proposed system is easy. -- 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: Re[2]: [Haskell-cafe] Logo Preferences
On Mon, Mar 9, 2009 at 5:26 PM, Luke Palmer wrote: > 2009/3/9 Sebastian Sylvan > >> >> >> On Mon, Mar 9, 2009 at 10:30 AM, Bulat Ziganshin < >> bulat.zigans...@gmail.com> wrote: >> >>> Hello Sebastian, >>> >>> Monday, March 9, 2009, 1:08:50 PM, you wrote: >>> >>> i think we should make 2-stage voting, like in F1 >>> >>> after 1st stage we will know which logos are most popular and >>> therefore are real candidates, so we can select among them >>> >>> >> >> One of the reasons condorcet voting is good is that this isn't needed. If >> everyone is consistent in which logos they prefer the results from second >> voting stage will be identical to just picking the condorcet voting from the >> first stage. >> >> The interface to the condorcet voting site is actually pretty good (try >> out one of the samples), so it's pretty easy to just "move to top" the ones >> you prefer and move the ones you dislike to the bottom. Then you can ignore >> the vast majority of "don't care" logos in the middle, and just fine tune >> your ranking at the top and bottom. >> > > With so many candidates, I think a two-stage process would be helpful. For > example, what if a variant of a logo I liked ended up being popular, but I > missed that one and didn't rank it (not unreasonable, there are a hundred > logos). After the top candidates have been selected, I will surely notice > it up there. > > Of course, introducing multi-stage voting breaks some of the properties > we'd like a voting system to have. But, alas, you (provably) can't have it > all :-) > It just seems like duplicated work to me. They're still few enough that I can scan through them and multi-select the ones I like and then click "move to top" in a pretty short amount of time (and then refine the ranking if I care). Having to vote twice just seems like a lot of extra effort for questionable added benefit. Maybe one vote requires people to be more careful about their rank (though you'd hope that any minor mistakes, such as the one you describe, would be random and therefore roughly cancel out over a few hundred votes), but at least it won't require them to vote twice. I say leave the plan the way it is. It's Good Enough (TM). The hassles of more delays while we go through an arduous processes isn't worth any theoretical minor gains. -- 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] Re: Logo Preferences
On Mon, Mar 9, 2009 at 6:13 AM, Benjamin L. Russell
wrote:
> On Sun, 08 Mar 2009 16:19:43 -0700, Ashley Yakeley
> wrote:
>
> >[...]
> >
> >I'm currently liking
> >
> >30 (specifically, 30.7)
> >58
> >61 (specifically, the second image)
> >62
>
> It would be nice to be able to specify a specific member image of a
> group of images; for example, the second image in group 61. Currently,
> none of the member images in group 61 is individually numbered; will
> we be able to choose a specific image from this kind of group?
Another reason condorcet voting is nice is that there is no need to group
"similar" items together. Condorcet voting eliminates the "spoiler
candidate" effect, so having N almost identical entries won't adversely
affect that "group" (by spreading out the votes for that "group" among more
"sub-entries" than for "groups" with only one entry in it).
So actually I don't understand whey the logos are grouped at all, they could
all just be listed individually, and then people can put them all at the
same rank ("make tie" in the interface) if they don't care which one of the
group they want, or they can differentiate between them if they like. You
could possibly name them "60 a", "60 b" etc. to indicate that they are
similar, but there's no reason not to allow people to differentiate between
them if tehy so choose.
--
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: Re[2]: [Haskell-cafe] Logo Preferences
On Mon, Mar 9, 2009 at 10:52 AM, Sebastian Sylvan < sebastian.syl...@gmail.com> wrote: > > > On Mon, Mar 9, 2009 at 10:30 AM, Bulat Ziganshin < > bulat.zigans...@gmail.com> wrote: > >> Hello Sebastian, >> >> Monday, March 9, 2009, 1:08:50 PM, you wrote: >> >> i think we should make 2-stage voting, like in F1 >> >> after 1st stage we will know which logos are most popular and >> therefore are real candidates, so we can select among them >> >> > > One of the reasons condorcet voting is good is that this isn't needed. If > everyone is consistent in which logos they prefer the results from second > voting stage will be identical to just picking the condorcet voting from the > first stage. > "picking the condorcet winner" -- 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: Re[2]: [Haskell-cafe] Logo Preferences
On Mon, Mar 9, 2009 at 10:30 AM, Bulat Ziganshin wrote: > Hello Sebastian, > > Monday, March 9, 2009, 1:08:50 PM, you wrote: > > i think we should make 2-stage voting, like in F1 > > after 1st stage we will know which logos are most popular and > therefore are real candidates, so we can select among them > > One of the reasons condorcet voting is good is that this isn't needed. If everyone is consistent in which logos they prefer the results from second voting stage will be identical to just picking the condorcet voting from the first stage. The interface to the condorcet voting site is actually pretty good (try out one of the samples), so it's pretty easy to just "move to top" the ones you prefer and move the ones you dislike to the bottom. Then you can ignore the vast majority of "don't care" logos in the middle, and just fine tune your ranking at the top and bottom. -- 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] Logo Preferences
On Sun, Mar 8, 2009 at 11:19 PM, Ashley Yakeley wrote: > Eelco Lempsink wrote: > > The list with options can be found here (for now): >> http://community.haskell.org/~eelco/poll.html Notice that some (very) >> similar logos are grouped as one option (thanks to Ian Lynagh) All >> submissions compete, so that still makes more than a 100 options! >> >> The voting system we'll use is the Condorcet Internet Voting System ( >> http://www.cs.cornell.edu/andru/civs.html). >> > > So ranking all 100+ items on the Condorcet ballot is a bit of a daunting > task. However, if we get a rough idea of the favourites, we can each cut > down a bit on the work. > > For instance, suppose 82 and 93 are very popular. You might not like either > of them, but it's worth ranking them on your ballot (after the ones you do > like) if you have a preference between them. But there's less need to rank > the ones no-one likes. I'm pretty sure this is precisely how the system works. You bring the ones you care about to the top and rank them, and everything else shares a rank at the bottom (or you could pick a few of those that you really dislike and put them even lower than the default rank). But the point is that you shouldn't need to rank every single logo, just the ones you care about and then you leave the rest at the default rank. -- 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] Threading and Mullticore Computation
On Tue, Mar 3, 2009 at 5:31 PM, wrote: > In both runs the same computations are done (sequentially resp. > parallel), so the gc should be the same. But still using 2 cores is > much slower than using 1 core (same program - no communication). Might there not be contention in the allocator/GC that's worsened by having two threads? What happens with -O2? -- 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: Re[7]: [Haskell-cafe] Re: speed: ghc vs gcc
On Sun, Feb 22, 2009 at 12:10 AM, Bulat Ziganshin wrote: > Hello Sebastian, > > Sunday, February 22, 2009, 2:55:38 AM, you wrote: > > yes, you are right. Don also compared results of 64x-reduced > > computation with full one. are you think that these results are more > > fair? > > > Yes. Clearly so. > > It still computes the result from scratch - it just uses a trick > > which generates better code. This is clearly a useful and worthwhile > > exercise as it shows A) A neat trick with TH, B) A reasonably > > practical way to produce fast code for the critical parts of a > > Haskell app, C) a motivating example for implementing a compiler > > optimization to do it automatically. > > yes, but does you know why his last program is 64x faster than simple > code? it's because *gcc* optimize it this way. the first program i > published there does it by mistake, then i fixed it by using 'xor' > instead of (+) and published here that i've considered most fair > comparison > > OTOH Don used this gcc optimization to generate faster code for > haskell. he doesn't used this trick for C++ and doesn't omitted > unoptimized gcc results from the chart. as a result people who don't > analyzed details made conclusion that ghc outperformed gcc here > > so i have made experiment with cheating the same way, but in more > obvious manner. and i got 3 angry answers in 5 minutes. so what are > the difference? you don't catched details of Don comparison or you > bothered only by gcc-related cheating? > Bulat, please stop insulting everyone whenever you discuss something. Was that sentence really necessary? You really think it's productive to insinuate that I'm intellectualy dishonest? I'm afraid I don't understand what you're talking about, could you try being a bit clearer? As I understand it you compared a gcc version which printed the precomputed result, with a GHC version which computed the result at runtime, and got the "150x" figure from that. Is this incorrect? If so, say so. Don't accuse everyone who disagrees with you of being dishonest. NOBODY in this thread has said anything to even remotely suggest that they think it's okay to "cheat" in favour of Haskell and consider it fair, yet you jump to this conclusion every single time. Please, give people the benefit of the doubt? Just because someone disagrees with you does not make them stupid or dishonest. Maybe they're actually right, or maybe you didn't make your point clear enough, or maybe they just misunderstood you. Either way, please try to be civil. The only argument anyone made towards "cheating" on the gcc side is that ANY program which just prints a precomputed result is worthless for comparisoin (regardless of which side is doing it). -- 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: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc
No, he asked if comparing the D64 version with the straight gcc one was "more fair" then comparing a version that precomputes the result with one that doesn't. That's what I responded to. On Sat, Feb 21, 2009 at 11:59 PM, Louis Wasserman wrote: > Sebastian, that's not Bulat's point. He's saying that if we make that > optimization in Haskell, we should at least make the same optimization in > GCC for fair comparison. (Though I'm not entirely sure that that > optimization would be of any use to GCC, but that's a linguistic concern, no > more.) > > His point is valid. But Don's results *not* obtained by optimizing in this > fashion are valid comparisons, and the results obtained with this > optimization are useful for other reasons. > > Louis Wasserman > wasserman.lo...@gmail.com > > > On Sat, Feb 21, 2009 at 5:55 PM, Sebastian Sylvan < > syl...@student.chalmers.se> wrote: > >> >> >> On Sat, Feb 21, 2009 at 11:35 PM, Bulat Ziganshin < >> bulat.zigans...@gmail.com> wrote: >> >>> Hello Louis, >>> >>> Sunday, February 22, 2009, 2:30:23 AM, you wrote: >>> >>> yes, you are right. Don also compared results of 64x-reduced >>> computation with full one. are you think that these results are more >>> fair? >>> >> >> Yes. Clearly so. >> It still computes the result from scratch - it just uses a trick which >> generates better code. This is clearly a useful and worthwhile exercise as >> it shows A) A neat trick with TH, B) A reasonably practical way to produce >> fast code for the critical parts of a Haskell app, C) a motivating example >> for implementing a compiler optimization to do it automatically. >> >> Just outputting the precomputed result means nothing. >> >> >> >> -- >> Sebastian Sylvan >> +44(0)7857-300802 >> UIN: 44640862 >> > > -- 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: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc
On Sat, Feb 21, 2009 at 11:35 PM, Bulat Ziganshin wrote: > Hello Louis, > > Sunday, February 22, 2009, 2:30:23 AM, you wrote: > > yes, you are right. Don also compared results of 64x-reduced > computation with full one. are you think that these results are more > fair? Yes. Clearly so. It still computes the result from scratch - it just uses a trick which generates better code. This is clearly a useful and worthwhile exercise as it shows A) A neat trick with TH, B) A reasonably practical way to produce fast code for the critical parts of a Haskell app, C) a motivating example for implementing a compiler optimization to do it automatically. Just outputting the precomputed result means nothing. -- 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: Re[2]: [Haskell-cafe] Re: speed: ghc vs gcc
I was intending to send this privately but clicked the wrong button. Apologies for adding even more noise to this discussion. On Sat, Feb 21, 2009 at 12:47 AM, Sebastian Sylvan < syl...@student.chalmers.se> wrote: > > > On Sat, Feb 21, 2009 at 12:16 AM, Bulat Ziganshin < > bulat.zigans...@gmail.com> wrote: > >> Hello Sebastian, >> >> Saturday, February 21, 2009, 2:42:33 AM, you wrote: >> >> > Bulat, please, you're missing the point. >> >> actually you are missing the point. i mirror Don's >> "non-attacking" style of comments on my person. are you mentioned >> those Don letter? sure - no >> >> > Nobody is saying that the >> > template-haskell trick was somehow a viable general strategy right >> > now that everyone should use by default. It was used as a >> > proof-of-concept that a simple technique can lead to massive >> > performance improvements - and we get numbers for how massive it >> > would be (beating gcc for this benchmark). >> >> sorry, but you was fooled too. the situation was the following: i >> wrote non-optimal code for 64-bit platforms (using 32-bit int) and Don >> don't corrected it. then he compiled TH-generated code via *gcc* that >> used "fusion" technique - the same that was used by 32-bit C++ code >> >> are you wondered why -D64 version is 8 times faster than -D8 one? it's >> exactly because *gcc* reduced 64 additions to just one operation. so >> this "fair" comparison used TH+gcc to generate faster code than gcc >> with improper data type definitions. if Don will fix C++ program, he >> will find that it's speed reduced in the same proportion - without TH >> tricks >> >> > >> > This isn't about "faking" a benchmark, it's about investigating the >> > reasons for why the benchmark looks they way it does, doing testing >> > to verify the assumptions (in this case using TH), and making >> > constructive suggestions (add loop-unrolling to the compiler). This >> > investigation tells us that in this case a compiler could beat gcc, >> > if only it were to do loop unrolling in the way the TH code does. That's >> a result! >> >> yes, in the cases when *gcc* "fuse" loops and you don't allow it do it >> for C++ code but allows for Haskell - you will win >> >> >> > I would ask you to note the simple fact that every single >> > constructive message in this thread has come from people other than >> > you. >> >> you are ignore, though, the fact that every destructive message in >> this thread comes against me. it seems that it's a crime here to write >> about ghc speed anything but praise. in best case people will said >> that these tests are destructive :lol: >> >> >> > I hope this leads you reconsider your tone and general approach >> > in the future. Haskell people in general are always pretty good at >> > accepting criticism IME (they tend to want to fix the problem), >> >> that criticism??? cows can't fly, and ghc cannot beat gcc in 2 >> months. that bothers me is people that attack me just for comparing >> compilers head-to-head >> > > I'm not going to debate all these points with you because I don't think you > actually responded to mine, but let me just say that MY impression of this > thread is that people attack you not because you compare compilers > head-to-head, but because you do it in an incredibly abrasive and hostile > manner (your messages read much more like "Haha! I told you so, look how > stupid/dishonest you are!", than "Here's a case where GHC produces bad code, > here's some analysis, and here's a ticket/patch for it"). > Just because you put a smiley at the end of a thinly veiled ad hominem > doesn't mean you get to pretend that you're just a victim when people get > understandably ticked off at your tone and respond in kind. > > Search the archives, performance discussions come up all the time, often > with quite vigorous criticism of GHC's current results, but somehow those > threads manage to stay civil and on point. Please, do a little introspection > and see if you can stick to a more constructive and friendly tone in the > future - I would be willing to bet that if you did, you wouldn't get > "attacked". > > -- > Sebastian Sylvan > +44(0)7857-300802 > UIN: 44640862 > -- 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: Re[2]: [Haskell-cafe] Re: speed: ghc vs gcc
On Sat, Feb 21, 2009 at 12:16 AM, Bulat Ziganshin wrote: > Hello Sebastian, > > Saturday, February 21, 2009, 2:42:33 AM, you wrote: > > > Bulat, please, you're missing the point. > > actually you are missing the point. i mirror Don's > "non-attacking" style of comments on my person. are you mentioned > those Don letter? sure - no > > > Nobody is saying that the > > template-haskell trick was somehow a viable general strategy right > > now that everyone should use by default. It was used as a > > proof-of-concept that a simple technique can lead to massive > > performance improvements - and we get numbers for how massive it > > would be (beating gcc for this benchmark). > > sorry, but you was fooled too. the situation was the following: i > wrote non-optimal code for 64-bit platforms (using 32-bit int) and Don > don't corrected it. then he compiled TH-generated code via *gcc* that > used "fusion" technique - the same that was used by 32-bit C++ code > > are you wondered why -D64 version is 8 times faster than -D8 one? it's > exactly because *gcc* reduced 64 additions to just one operation. so > this "fair" comparison used TH+gcc to generate faster code than gcc > with improper data type definitions. if Don will fix C++ program, he > will find that it's speed reduced in the same proportion - without TH > tricks > > > > > This isn't about "faking" a benchmark, it's about investigating the > > reasons for why the benchmark looks they way it does, doing testing > > to verify the assumptions (in this case using TH), and making > > constructive suggestions (add loop-unrolling to the compiler). This > > investigation tells us that in this case a compiler could beat gcc, > > if only it were to do loop unrolling in the way the TH code does. That's > a result! > > yes, in the cases when *gcc* "fuse" loops and you don't allow it do it > for C++ code but allows for Haskell - you will win > > > > I would ask you to note the simple fact that every single > > constructive message in this thread has come from people other than > > you. > > you are ignore, though, the fact that every destructive message in > this thread comes against me. it seems that it's a crime here to write > about ghc speed anything but praise. in best case people will said > that these tests are destructive :lol: > > > > I hope this leads you reconsider your tone and general approach > > in the future. Haskell people in general are always pretty good at > > accepting criticism IME (they tend to want to fix the problem), > > that criticism??? cows can't fly, and ghc cannot beat gcc in 2 > months. that bothers me is people that attack me just for comparing > compilers head-to-head > I'm not going to debate all these points with you because I don't think you actually responded to mine, but let me just say that MY impression of this thread is that people attack you not because you compare compilers head-to-head, but because you do it in an incredibly abrasive and hostile manner (your messages read much more like "Haha! I told you so, look how stupid/dishonest you are!", than "Here's a case where GHC produces bad code, here's some analysis, and here's a ticket/patch for it"). Just because you put a smiley at the end of a thinly veiled ad hominem doesn't mean you get to pretend that you're just a victim when people get understandably ticked off at your tone and respond in kind. Search the archives, performance discussions come up all the time, often with quite vigorous criticism of GHC's current results, but somehow those threads manage to stay civil and on point. Please, do a little introspection and see if you can stick to a more constructive and friendly tone in the future - I would be willing to bet that if you did, you wouldn't get "attacked". -- 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] Re: speed: ghc vs gcc
On Fri, Feb 20, 2009 at 10:33 PM, Bulat Ziganshin wrote: > Hello Achim, > > Saturday, February 21, 2009, 1:17:08 AM, you wrote: > > >> nothing new: what you are not interested in real compilers comparison, > >> preferring to demonstrate artificial results > >> > > ...that we have a path to get better results than gcc -O3 > > -funroll-loops, and it's within reach... we even can get there now, > > albeit not in the most hack-free way imaginable? > > well, can this be made for C++? yes. moreover, gcc does this trick > *automatically*, while with ghc we need to write 50-line program using > Template Haskell and then run it through gcc - and finally get exactly > the same optimization we got automatic for C code > > so, again: this confirms that Don is always build artificial > comparisons, optimizing Haskell code by hand and ignoring obvious ways > to optimize Haskell code. unfortunately, this doesn't work in real > live. and even worse - Don reports this as fair Haskell vs C++ > comparison > Bulat, please, you're missing the point. Nobody is saying that the template-haskell trick was somehow a viable general strategy right now that everyone should use by default. It was used as a proof-of-concept that a simple technique can lead to massive performance improvements - and we get numbers for how massive it would be (beating gcc for this benchmark). This isn't about "faking" a benchmark, it's about investigating the reasons for why the benchmark looks they way it does, doing testing to verify the assumptions (in this case using TH), and making constructive suggestions (add loop-unrolling to the compiler). This investigation tells us that in this case a compiler could beat gcc, if only it were to do loop unrolling in the way the TH code does. That's a result! I would ask you to note the simple fact that every single constructive message in this thread has come from people other than you. I hope this leads you reconsider your tone and general approach in the future. Haskell people in general are always pretty good at accepting criticism IME (they tend to want to fix the problem), don't you think it's odd that it's only *your* criticism that gets so much flak? Maybe some part of the reason almost every discussion you're in here usually ends up hostile is *your* approach? Regards, -- 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] Error installing pkg 'HDBC-sqlite3'
I thin you need to use the following two options to point cabal configure to the right include and lib directories:--extra-include-dirs=*dir* --extra-lib-dirs=*dir* On Fri, Feb 20, 2009 at 8:20 PM, David wrote: > I think you're right. I didn't realize I had to install Sqlite before > installing and building the HDBC-sqlite package. So I did that, but > now I'm getting a different error, because the DLL for Sqlite isn't > getting found. How do I tell the build process where the DLL is? > > Here's the new error message: > > D:\Apps\ghc\ghc-6.10.1\HDBC-sqlite3-2.1.0.0>runghc Setup build > Preprocessing library HDBC-sqlite3-2.1.0.0... > D:\Apps\ghc\ghc-6.10.1\gcc-lib\ld.exe: cannot find -lsqlite3 > collect2: ld returned 1 exit status > linking dist\build\Database\HDBC\Sqlite3\Statement_hsc_make.o failed > > Thanks for your help! > > David. > > On Fri, Feb 20, 2009 at 2:25 PM, Sebastian Sylvan > wrote: > > I think you need to install sqlite3 first. This is just a binding to the > C > > library. > > > > On Fri, Feb 20, 2009 at 7:16 PM, David wrote: > >> > >> I've encountered another problem while trying to install > >> 'HDBC-sqlite3'. I did the install "manually", instead of using Cabal, > >> and during the build phase, received the following error message: > >> > >> D:\Apps\ghc\ghc-6.10.1\HDBC-sqlite3-2.1.0.0>runghc Setup build > >> Preprocessing library HDBC-sqlite3-2.1.0.0... > >> Database\HDBC\Sqlite3\Statement.hsc:41:21: sqlite3.h: No such file or > >> directory > >> Database\HDBC\Sqlite3\Statement.hsc: In function `main': > >> Database\HDBC\Sqlite3\Statement.hsc:137: error: `SQLITE_NULL' > >> undeclared (first use in this function) > >> Database\HDBC\Sqlite3\Statement.hsc:137: error: (Each undeclared > >> identifier is reported only once > >> Database\HDBC\Sqlite3\Statement.hsc:137: error: for each function it > >> appears in.) > >> Database\HDBC\Sqlite3\Statement.hsc:148: error: `SQLITE_ROW' > >> undeclared (first use in this function) > >> Database\HDBC\Sqlite3\Statement.hsc:149: error: `SQLITE_DONE' > >> undeclared (first use in this function) > >> Database\HDBC\Sqlite3\Statement.hsc:150: error: `SQLITE_ERROR' > >> undeclared (first use in this function) > >> compiling dist\build\Database\HDBC\Sqlite3\Statement_hsc_make.c failed > >> > >> Is the file 'sqlite3.h' missing? Or am I doing something wrong? > >> > >> Thanks, > >> David. > >> ___ > >> Haskell-Cafe mailing list > >> Haskell-Cafe@haskell.org > >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > > > -- > > Sebastian Sylvan > > +44(0)7857-300802 > > UIN: 44640862 > > > -- 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] Error installing pkg 'HDBC-sqlite3'
I think you need to install sqlite3 first. This is just a binding to the C library. On Fri, Feb 20, 2009 at 7:16 PM, David wrote: > I've encountered another problem while trying to install > 'HDBC-sqlite3'. I did the install "manually", instead of using Cabal, > and during the build phase, received the following error message: > > D:\Apps\ghc\ghc-6.10.1\HDBC-sqlite3-2.1.0.0>runghc Setup build > Preprocessing library HDBC-sqlite3-2.1.0.0... > Database\HDBC\Sqlite3\Statement.hsc:41:21: sqlite3.h: No such file or > directory > Database\HDBC\Sqlite3\Statement.hsc: In function `main': > Database\HDBC\Sqlite3\Statement.hsc:137: error: `SQLITE_NULL' > undeclared (first use in this function) > Database\HDBC\Sqlite3\Statement.hsc:137: error: (Each undeclared > identifier is reported only once > Database\HDBC\Sqlite3\Statement.hsc:137: error: for each function it > appears in.) > Database\HDBC\Sqlite3\Statement.hsc:148: error: `SQLITE_ROW' > undeclared (first use in this function) > Database\HDBC\Sqlite3\Statement.hsc:149: error: `SQLITE_DONE' > undeclared (first use in this function) > Database\HDBC\Sqlite3\Statement.hsc:150: error: `SQLITE_ERROR' > undeclared (first use in this function) > compiling dist\build\Database\HDBC\Sqlite3\Statement_hsc_make.c failed > > Is the file 'sqlite3.h' missing? Or am I doing something wrong? > > Thanks, > David. > _______ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- 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] Amazing
2009/2/14 Peter Verswyvelen > One of the things I liked a lot when working with C# was that as soon as my > code compiled, it usually worked after an iteration of two.At least if we > forget about the nasty imperative debugging that is needed after a while > because of unanticipated and unchecked runtime side effects. > After heaving read about Haskell and having written some small programs for > the last year or so, I'm now finally writing a bigger program with it. It is > not so easy yet since learning a language and trying to reach a deadline at > the same time is hard :) > > However, it is just amazing that whenever my Haskell program compiles > (which to be fair can take a while for an average Haskeller like me ;-), it > just... works! I have heard rumors that this was the case, but I can really > confirm it. > > A bit hurray for strong typing! (and if you don't like it, you can still > use Dynamic and Typeable ;-) > I've found the same thing. An interesting observation is that (for me) the vast majority of the type errors are things that would've happened in *any* statically typed language (like C#), but somehow Haskell manages to be a lot better at catching errors at compile time. So my conclusion is that it's not just static typing, it's functional programming in conjunction with static strong type checking. When all you're writing are expressions, then *everything* goes through some level of "sanity checking". When you're writing imperative code, a lot of the meaning of your program comes from the ordering of statements - which usually isn't checked at all (aside from scope). So IMO static typing is good, but it's only with functional programming that it really shines. -- 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] Re: Can this be done?
On Wed, Feb 11, 2009 at 5:41 PM, Achim Schneider wrote: > Evan Laforge wrote: > > > On Wed, Feb 11, 2009 at 9:34 PM, Alistair Bayley > > wrote: > > > 2009/2/11 Cristiano Paris : > > >> I wonder whether this can be done in Haskell (see muleherd's > > >> comment): > > >> > > >> > http://www.reddit.com/r/programming/comments/7wi7s/how_continuationbased_web_frameworks_work/ > > > > > > WASH did/does something similar. You can certainly write > > > applications in a similar, workflow-ish style (rather than like a > > > state machine). > > > > To hijack the subject, what happened to WASH? The paper seemed like > > it was full of interesting ideas, but the implementation seems to have > > failed to capture many hearts. Now it seems like a stagnant project. > > What were the fatal flaws? > > > I got curious and made two pages point to each other, resulting in as > many stale continuations as your left mouse button would permit. While > the model certainly is cool, I'm not aware of any implementation that > even comes close to having production-safe (that is, non-abusable) > semantics. Shouldn't the following WASH function help? once :: (Read a, Show a) => CGI a -> CGI a -- 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: Re[2]: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
On Wed, Feb 11, 2009 at 9:40 AM, Bulat Ziganshin wrote: > Hello Jamie, > > Wednesday, February 11, 2009, 5:54:09 AM, you wrote: > > > Seems like it is ok to write H.264 in Haskell and released via GPL > > license? > > anyway it's impossible due to slow code generated by ghc > Impossible? Really? How does performance relate to it being possible to write? I would be surprised if it was indeed impossible to get something that runs fine one *some* machine. It may be difficult to beat C, but that doesn't mean it's impossible to write something useful. -- 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] Can this be done?
On Wed, Feb 11, 2009 at 1:41 PM, Cristiano Paris wrote: > On Wed, Feb 11, 2009 at 2:30 PM, Peter Verswyvelen > wrote: > > I haven't looked at the details, but I think this is what a library like > > Reactive from Conal Elliott could do, but as far as I understand it, it > is > > still work in progress. > > I'm interested in the possibility of > stopping/pickling/unpickling/resuming a computation. > I think that would be difficult. You could probably store the continuation in a server-side cache if you aren't doing CGI but have a persistent server process, but eventually you'll need to discard unused continuations to avoid running out of memory. You may be able to use a WASH style continuation model in conjunction with this. So you store the session logs on disk, and if the continuation does not exist in memory you'd fetch the session log from disk, replay the whole session from that, and reproduce the continuation that way. That way most sessions would just work directly off of the cache and never touch disk, but if someone waits too long (or, say, bookmarks a page in the middle of the session!) there's still a fallback stored on disk. -- 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] 1,000 packages, so let's build a few!
-- From: "Duncan Coutts" Sent: Sunday, February 01, 2009 2:59 PM To: "Don Stewart" Cc: Subject: Re: [Haskell-cafe] 1,000 packages, so let's build a few! On Sat, 2009-01-31 at 14:02 -0800, Don Stewart wrote: >not really :) e.g. my output on a Windows Vista system with GHC 6.10.1 >cabal install sdl >Configuring SDL-0.5.4... >setup.exe: sh: runGenProcess: does not exist (No such file or > directory) Isn't this missing C library dependencies, which cabal head now warns about? No, it's about packages using configure scripts which require MSYS on Windows. In principle we should be able to notice this while doing the package dependency planning and report that we cannot install the package because it needs sh.exe. I wonder *why* packages need sh though? Isn't cabal supposed to allow you to do that kind of scripting in Haskell rather than calling into platform-dependent shell scripts? Are there any specific reasons why people feel the need to use sh? If the package is unix-only for other reasons (e.g. bindings to X or whatever) then it's obviously not a problem, but it appears to me that there's lots of packages that should be portable in principle that won't build on windows because it needs to run sh... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1,000 packages, so let's build a few!
-- From: "Don Stewart" Sent: Saturday, January 31, 2009 8:35 PM To: "Andrew Coppin" Cc: Subject: Re: [Haskell-cafe] 1,000 packages, so let's build a few! andrewcoppin: In celebration of Hackage reachin over 1,000 unique packages, I decided that I would re-visit the problem of attempting to build them on Windows. Ah yes, I already have the tarball for stream-fusion-0.1.1, but I see that the latest release is 0.1.2.1. (Unfortunately, there doesn't appear to be any way to determine what the difference is between the two versions...) the true way to install all of hackage is: cabal install $(all my packages) where cabal install solves it all. If that had actually worked it would be great I must say that my own not-so-random sampling (basically "ooh that looks cool, let's try it") is probably at a 20% success rate or so... It's great when it does work, but it usually doesn't. Usually it fails because some part of it tries to run unix shell scripts (and I try to avoid things which seem like they're unix only, even though they're no easy way of determining this, so these are packages that at least to me seemed like they could be perfectly portable if not for unix-specific installation procedures). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Monades - I've got it! (hopefully)
On Wed, Dec 24, 2008 at 12:05 PM, Johannes Waldmann <
waldm...@imn.htwk-leipzig.de> wrote:
>
> > > About the prestress, that's one of the motivations behind renaming
> > > them ("warm fuzzy thing" is the current tongue-in-cheek alternative).
>
> in F# they renamed "Monad" to "Workflow",
> see e.g. Chapter 9 (p. 230) in the "Expert F#" book.
> http://www.expert-fsharp.com/default.aspx
I thought it was called "computation expressions",and workflow was just a
special case (e.g. asynchronous work flows for the async monad)?
See e.g.
http://blogs.msdn.com/dsyme/archive/2007/09/22/some-details-on-f-computation-expressions-aka-monadic-or-workflow-syntax.aspx
--
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] MySQL and HDBC?
2009/1/23 Galchin, Vasili > Hello, > > "Real World Haskell" seems to say that the abstraction layer HDBC > doesn't support MySQL. If so, in what sense doesn't HDBC support > MySQL?? It doesn't have a MySQL backend. However, it does have an ODBC backend which should work fine with MySQL. -- 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] Processor availability
2009/1/22 Louis Wasserman > How might I go about finding out how many processors are available in a > concurrent GHC program? I have some code I'd like to parallelize, but I > don't want to spawn a separate (even lightweight) thread for each of > thousands of minor tasks. Consider using Contorl.Parallel.Strategies which allows you to spark of lightweight jobs that get run on a pool of threads. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: hledger 0.3 released
The cabal file still includes the vty dependency, but simply removing it made it compile. -- From: "Simon Michael" Sent: Sunday, January 18, 2009 7:04 PM To: "Sebastian Sylvan" Cc: ; Subject: Re: ANN: hledger 0.3 released I've pushed a patch which should omit the vty dependency and ui command on windows. Sebastian, could you darcs get the latest code from http://joyful.com/repos/hledger and see if cabal configure and build works for you on windows ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] runghc Setup.hs doitall
On a similar note, would it not be nice if cabal install understood about platforms and could tell you straight away that a package won't install under e.g. windows, rather then spending ages trying and then failing because a package tries to run a unix command? I always get a bit annoyed trying to do anything in windows with Haskell libraries, at the very least I'd like it to be clear from the start that something won't work (if it's by design) so I don't waste time trying. Ideally the hackage website would even allow you to filter packages by the OS you're using and would remove packages that won't build on that OS (by recursively checking dependencies too). -- From: "Duncan Coutts" Sent: Sunday, January 18, 2009 6:20 PM To: "Sebastian Sylvan" Cc: "Jeff Wheeler" ; Subject: Re: [Haskell-cafe] runghc Setup.hs doitall On Sun, 2009-01-18 at 16:48 +, Sebastian Sylvan wrote: Doesn't work on windows. http://haskell.org/~duncan/cabal/cabal.exe It's not the latest version but you can use it to self-update. I'll post a more recent build after the next release. I might also put it in a slightly more discoverable place ;-) Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: hledger 0.3 released
Yeah looks like it depends on unix. Also, looks like the terminfo package isn't cross-platform either. Perhaps we need a better tool to mark packages which are platform-specific, so people don't accidentally use them, especially if they're a few levels away in the dependency graph. -- From: "Simon Michael" Sent: Sunday, January 18, 2009 6:08 PM To: "Sebastian Sylvan" Cc: ; Subject: Re: ANN: hledger 0.3 released On 1/18/09 9:39 AM, Sebastian Sylvan wrote: I was interested in actually using this "for real", but unfortunately it seems like you have a dependency on the unix package. Would it be possible to use something portable (specifically to windows) instead? Darn, thanks for the heads up. I guess we need to make the vty requirement (and ui command) optional. (I thought vty was cross-platform. :/) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hledger 0.3 released
I was interested in actually using this "for real", but unfortunately it seems like you have a dependency on the unix package. Would it be possible to use something portable (specifically to windows) instead? From: Simon Michael Sent: Saturday, January 17, 2009 11:42 PM To: hled...@googlegroups.com ; haskell-cafe@haskell.org Subject: [Haskell-cafe] ANN: hledger 0.3 released I'm pleased to announce another hledger release. Happy new year, all! hledger is a partial haskell clone of John Wiegley's "ledger" text-based accounting tool. It generates transaction & balance reports from a plain text ledger file, and demonstrates a functional implementation of ledger. For more information, see hledger's home page: http://joyful.com/hledger News for 0.3 Fixes: * count timelog sessions on the day they end, like ledger, for now * when options are repeated, use the last instead of the first * builds with ghc 6.10 as well as 6.8 * runs much faster than 0.2:: $ bench hledger-0.2 hledger ledger || hledger-0.2 | hledger | ledger ==++=+=+=== -f 2008.ledger -s balance ||2.59 |0.26 | 0.11 -f 1entries.ledger -s balance || 566.68 |2.72 | 0.96 Features: * a simple ui for interactive report browsing: hledger ui * accept smart dates everywhere (MMDD, Y/M/D, Y, M/D, D, jan, today, last week etc.) * --period/-p flag accepting period expressions like "in 2008", "weekly from last month".. * -W/-M/-Y convenience flags to summarise register weekly, monthly, yearly * --depth and -E flags also affect summarised register reports (including depth=0) * --display/-d flag supporting date predicates (like "d<[DATE]", "d>=[DATE]") * !include directive to include additional ledger files * !account directive to set a default parent account * Added support for reading historical prices from files * timelog and ledger entries can be intermixed in one file * modifier and periodic entries can appear anywhere (but are still ignored) * help and readme improvements Contributors: * Simon Michael * Nick Ingolia * Tim Docker * Corey O'Connor & the vty team Stats: * Known errors: 1 * Tests: 58 * Lines of non-test code: 2123 Installation hledger requires GHC. It is known to build with 6.8 and 6.10. If you have cabal-install, do:: cabal update cabal install hledger Otherwise, unpack the latest tarball from http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hledger and do:: runhaskell Setup.hs configure runhaskell Setup.hs build sudo runhaskell Setup.hs install This will complain about any missing libraries, which you can download and install manually from hackage.haskell.org. (The Build-Depends: in hledger.cabal has the full package list.) To get the latest development code do:: darcs get http://joyful.com/repos/hledger ___ 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] runghc Setup.hs doitall
Doesn't work on windows. -- From: "Jeff Wheeler" Sent: Sunday, January 18, 2009 4:27 PM To: Subject: Re: [Haskell-cafe] runghc Setup.hs doitall On Sun, 2009-01-18 at 16:22 +0000, Sebastian Sylvan wrote: Is there some sort of bundle that you can use to install cabal-install easily? Because it looks to me like I'd have to spend the better part of an evening manually downloading and installing the gazillion of dependencies it has, which is far too much work when I just wanted to spend ten minutes playing with some package... There's a bootstrap.sh file in root of the cabal-install that can do this automatically. In my experience, it usually fails because of missing dependencies like zlib-dev on my own system, but those are easy to fix, at which point I can rerun the bootstrap script. Jeff Wheeler ___ 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] runghc Setup.hs doitall
Is there some sort of bundle that you can use to install cabal-install easily? Because it looks to me like I'd have to spend the better part of an evening manually downloading and installing the gazillion of dependencies it has, which is far too much work when I just wanted to spend ten minutes playing with some package... -- From: "Daniel Fischer" Sent: Saturday, January 17, 2009 10:35 PM To: "Alberto G. Corona " ; Subject: Re: [Haskell-cafe] runghc Setup.hs doitall Am Samstag, 17. Januar 2009 23:20 schrieb Alberto G. Corona: Hi guys: I don´t know how difficult really is, but it seens that it could be done because all the necessary elements are there (except perhaps the mapping package name-hackage url): Why hasn´t been done yet Is unknown to me. It would be very useful and a big save of time to have a cabal commad "chech-dependencies-and-install-them-by-downloading-them-from-hackage-then- configure-build-and-install-this-package?. The unix installers do is t from binaries and are obsolete, so I have to do it manually with cabal everytime when i download a new compiler version from haskell.org. Cheers Alberto. Use cabal-install: cabal update && cabal install foo checks for dependencies, downloads and builds them automatically (if possible). ___ 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] Comments from OCaml Hacker Brian Hurt
On Thu, Jan 15, 2009 at 7:46 PM, Andrew Coppin wrote: > The sad thing is, it's not actually complicated. The documentation just > makes it seem like it is! :-( > This is so true for a heck of a lot of things. Existential quantification being just one of them. Loads of things in Haskell have big powerful (but scary) names which I really think intimidate people, the situation isn't helped when a lot of tutorials use the theoretical basis for the construct as a starting point, rather then actually describing the construct from the perspective of a programmer first (see Monads). Haskell really isn't that difficult compared to other languages, but people still get the impression that you need to be a big brain on a stick to use it, terminology is certainly part of the equation. This doesn't mean that making up new words is always better, but we should certainly strive to exploit any opportunity to clarify the issue and (this means that haddock comments and language books/tutorials shouldn't refer to academic papers first and foremost, but use common English and practical examples to describe what's being used, and academic nerds can consult the footnotes for their fill of papers containing pages of squiggly symbols!). -- 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] Re: How do we decide on the new logo?
On Sat, Jan 3, 2009 at 3:15 AM, wrote: > On Sat, 3 Jan 2009, Achim Schneider wrote: > > Step 2: Determine the winner by polling preferences, same-level >> preference (ambivalence) allowed >> (eg. place 1 for logos C and D, place 2 for A and place 3 for B) >> > > The only reasonable method of voting using this ranking data is one of the > Condorcet methods. How you break ties doesnt matter much to me. Wikimedia, > Debian, Gentoo, and Software in the Public Intrest all use Schulze method > for what that is worth. > Yes. Condorcet voting picks the best compromise and is IMO the way to do this - we won't all agree on the best logo, but at least we can pick the least disliked one. It doesn't need to be super sophisticated, just a box next to each logo where you can enter a rank in any range you like (1 being most preferred, empty boxing being equivalent to +Inf), allowing multiple entries to share the same rank. -- 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] The Haskell re-branding exercise
I am very shortly travelling abroad for several weeks and will not have (reliable access to) a computer, but isn't this a task for one of the haskell web-apps people (HSP, HAppS, Turbinado, etc.) to show us once and for all why *their* library is better than the competition? :-) On Sun, Dec 21, 2008 at 9:23 PM, Don Stewart wrote: > Would you be willing to set up a little online voting system (or do you > know of one) so we can implement this? > > Assume there'll be < 10 candidates. > > -- Don > > sylvan: > >2008/12/21 Paul Johnson <[1]p...@cogito.org.uk> > > > > This suggests that the current effort to find a new logo for Haskell > > needs to go back to the basics. Its no good expecting consensus on > one > > of the suggestions because there are too many options and everyone > has > > their favourite. Nothing will attract a majority of the community. > > > >I agree with this, which I why I would propose using Condorcet-voting. > >Personally I find the current logo horrendous. I think it's ugly and > >intimidating at the same time. I don't really care too much which one > of > >the proposals should win, just so long as I can weed out some of the > ones > >I really hate. > >Condorcet voting will pick a good compromise, where someone like me > could > >just put all the acceptable ones at shared #1, and all the ones I > dislike > >at #2., and someone with stronger opinions could flesh it out some > more. > >The point being that the "least disliked" logo wins out. Maybe nobody > will > >be happy, but hopefully most people won't be deeply unhappy with it. > >It would be a shame if there's lots of votes that are spread out over > a > >large group of fairly similar logos that are good, and then a crappy > one > >wins out with 6% of the vote because there weren't any others like it > so > >the votes for that "style" weren't spread out over multiple entries. > >Wikipedia: > >[2]http://en.wikipedia.org/wiki/Condorcet_voting > > > >-- > >Sebastian Sylvan > >+44(0)7857-300802 > >UIN: 44640862 > > > > References > > > >Visible links > >1. mailto:p...@cogito.org.uk > >2. http://en.wikipedia.org/wiki/Condorcet_voting > > > ___ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- 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] The Haskell re-branding exercise
2008/12/21 Paul Johnson > > > > This suggests that the current effort to find a new logo for Haskell needs > to go back to the basics. Its no good expecting consensus on one of the > suggestions because there are too many options and everyone has their > favourite. Nothing will attract a majority of the community. > I agree with this, which I why I would propose using Condorcet-voting. Personally I find the current logo horrendous. I think it's ugly and intimidating at the same time. I don't really care too much which one of the proposals should win, just so long as I can weed out some of the ones I really hate. Condorcet voting will pick a good compromise, where someone like me could just put all the acceptable ones at shared #1, and all the ones I dislike at #2., and someone with stronger opinions could flesh it out some more. The point being that the "least disliked" logo wins out. Maybe nobody will be happy, but hopefully most people won't be deeply unhappy with it. It would be a shame if there's lots of votes that are spread out over a large group of fairly similar logos that are good, and then a crappy one wins out with 6% of the vote because there weren't any others like it so the votes for that "style" weren't spread out over multiple entries. Wikipedia: http://en.wikipedia.org/wiki/Condorcet_voting -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Data parallelism doesn't seem to work on windows...
Hi,I can't seem to get DPH to work on 6.10.1 on Vista-64. I run the executables with +RTS -N2, and to verify that I'm doing it correctly I checked with a simple benchmark using forkIO and that does indeed use both my cores: -- compiler command line: ghc --make -O2 -threaded parr.hs -- execution command line: parr.exe +RTS -N2 main = do forkIO $ print [ True | n <- [ 1000 .. 3000], fac n == 0 ] forkIO $ print [ True | n <- [ 1000 .. 3000], fac n == 0 ] getLine return () This, on the other hand does not use more than one core: -- compiler command line (from shootout code): ghc --make -fcpr-off -threaded -fdph-par -package dph-base -Odph -XPArr parr2.hs -- execution as before main = print $ [: True | n <- [: 1000 .. 5000 :], fac n == 0 :] That's 4000 items of work there, so surely it should kick off plenty of sparks to overcome the "sparks bug"? -- 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] Memory efficiency questions for real-time graphics
On Mon, Nov 3, 2008 at 3:45 PM, Svein Ove Aas <[EMAIL PROTECTED]> wrote: > On Mon, Nov 3, 2008 at 11:31 AM, Tobias Bexelius > <[EMAIL PROTECTED]> wrote: > > Before Direct3D 10, its too costly to read back the updated vertex data > > in every frame, which force you to make this kind of operations on the > > CPU. > > With D3D 10 however, you should use the new Stream-Output stage which is > > used to return updated vertex data directly to a vertex buffer on the > > GPU. So if you can afford a new graphics card and likes Vista, that's > > the way to go :) > > > Or you could use OpenGL, which has supported that since the first GPUs > that did were released. I think that came with OpenGL 3.0. Unless you're counting vendor-specific extensions... -- 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] Memory efficiency questions for real-time graphics
2008/10/28 T Willingham <[EMAIL PROTECTED]>
>
> As my first Haskell exposure, I've been working through Real World
> Haskell.
>
> I am considering converting some of my C++ graphics libraries to
> Haskell. I've done a fair amount of googling on the subject, however
> I haven't quite been able to find clear answers to some of following
> issues.
>
> (1) Using an OpenGL vertex array (a contiguous chunk of memory which
> is handed to the graphics card) is important. I see the source code
> of Frag does this, so it looks like we're good. Check.
>
> (2) In-place modification of the vertex array is important. Every
> vertex changes on each frame update. And we always want more
> vertices.
>
> (3) Growing and shrinking the vertex array efficiently is important.
> Here the behavior of C++ std::vector happens to be ideal. When
> growing, extend the array in-place if possible (using reserved space
> if any), otherwise allocate a new chunk ("amortized constant time").
> When shrinking, do nothing but record the smaller size; the unused
> memory chunk is reserved for possible future growth.
>
> (4) Doing little to no allocations each frame update is important. In
> the current C++ version, zero allocations occur during a normal frame
> update. When the vertex array changes, that is the only allocation
> which happens.
>
> To give a context for all of this, I am applying a non-linear
> transformation to an object on every frame. (Note: non-linear, so a
> matrix transform will not suffice.)
>
Any reason why you can not do this in the vertex shader? You really should
avoid trying to touch the vertices with the CPU if at all possible.
--
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: Re[8]: [Haskell-cafe] Climbing up the shootout...
On Tue, Sep 23, 2008 at 2:52 PM, Bulat Ziganshin <[EMAIL PROTECTED]>wrote: > Hello John, > > Tuesday, September 23, 2008, 5:39:17 PM, you wrote: > > > Probably not, but I think you completely missed my point. Perhaps I > > should have originally written "my original C equivalents" rather > > than "the". You're probably just a better C programmer than me. > > well, i don't say about me personnaly or someone else. my points is that > > 1) modern C compilers allows to get close-to-asm performance. Haskell don't > 2) fastest Haskell code is very hard to write, much harder than C one This is only true for tiny toy benchmarks, not for real applications. For real applications you're going to have bottle necks in small parts of the code. So what if that 5-20% of the code has to be written using specialized techniques to get speed, when you get several times more productivity/correctness/maintainability in the 80-95% of the code which is not the bottle neck? If you're involved in a game where everyone tries to show off how their programming language deals with the bottle necks then obviously you'd use these "ugly" techniques to optimize things. It may be that it's more convenient to write this low level code in C (though I wouldn't say it's "much" more convenient, slightly more for some cases, less for others), but the price you pay is that you have to use this low level style for *everything*. Most of the inconvenience, IMO, is due to syntax not semantics (specifically having to do "<-" on separate lines in order to read mutable memory rather than being able to extract the value at the usage site - though I do believe some syntactic sugar was on the way for that?) So I think you're wrong to criticize people for showing that Haskell can be fast. Yes it takes effort (though you can increasingly avoid most of it by using libraries like ByteString), but nobody is saying that it doesn't. You're arguing against a straw man. The point is that you *can* get good performance in Haskell for the parts of your programs which is a bottle neck. The shootout only tests these parts, which is why the Haskell code in those submissions is sometimes a bit obscure (though not nearly to the extent you make out). But that's not how *real* applications look! In real applications that kind of code would be only a fraction of the total code base, most of it would be perfectly ordinary Haskell! (whereas in C everything would be, well C) Cheers, -- 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] Line noise
On Mon, Sep 22, 2008 at 1:50 PM, Daniel Fischer <[EMAIL PROTECTED]>wrote: > Am Montag, 22. September 2008 08:32 schrieb Andrew Coppin: > > > However, I will grant you that Map k v, could have used longer type > > > variables. But we are not alone with using one letter type variable > > > names http://java.sun.com/javase/6/docs/api/java/util/HashMap.html . > And > > > frankly, in this specific case, I think most programmers (Haskell or > > > non-Haskell) will be able to guess what k and v means, when they are > > > standing right after Map. > > > > Only if you can figure out that "Map" means what every other programming > > language on the face of the Earth calls a "dictionary". (This took me a > > while!) > > So, when did Java leave the face of the earth? At the same time as C++ presumably. I hadn't really noticed, but I'll be the first to say: Good riddance! -- 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] nooby question on typing
On Sat, Sep 13, 2008 at 2:49 PM, Han Joosten <[EMAIL PROTECTED]>wrote: > > Hi, > > I have a question about types in Haskell. I feel that I am overlooking some > obvious solution, but I do not manage to get it right. Here is the plot: > > I have got 4 different types of 'rules', each with it's own constructor. > So > i defined: > > > type Rules = [Rule] > > data Rule = RuRule > >| SgRule > >| GcRule > >| FrRule > >deriving (Eq,Show) This effectively creates an enum type. I.e. each case here doesn't contain any data other than the "tag". I think you're getting confused because the constructor is named the same as the type you're expecting to store. Try something like: > type Rules = [Rule] > data Rule = RuRule >| MkSgRule SgRule >| MkGcRule GcRule >| MkFrRule FrRule >deriving (Eq,Show) So MkSgRule is a "tag" or a "label" deciding which version of Rule you're building, and it also has a value of type SgRule. Now you can create a list or Rule like so: >mylist :: [Rule] >mylist = [ MkSgRule mysgrule, MkGcRule mygcrule ] where mysgrule :: SgRule and mygcrule :: GcRule. -- 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] Re: Can you do everything without shared-memory concurrency?
On Fri, Sep 12, 2008 at 4:07 PM, Bruce Eckel <[EMAIL PROTECTED]> wrote: > OK, let me throw another idea out here. When Allen Holub first > explained Actors to me, he made the statement that Actors prevent > deadlocks. In my subsequent understanding of them, I haven't seen > anything that would disagree with that -- as long as you only use > Actors and nothing else for parallelism. I think you need to specify what you mean by actors, because I can't see how they would eliminate deadlocks as I understand them. Could you not write an actor that holds a single cell mailbox (both reads and writes are blocking), then set up two classes that shuffles values from the same two mailboxes in the opposite direction? -- 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] Can you do everything without shared-memory concurrency?
2008/9/9 Bruce Eckel <[EMAIL PROTECTED]> > So this is the kind of problem I keep running into. There will seem to be > consensus that you can do everything with isolated processes message passing > (and note here that I include Actors in this scenario even if their > mechanism is more complex). And then someone will pipe up and say "well, of > course, you have to have threads" and the argument is usually "for > efficiency." > I make two observations here which I'd like comments on: > > 1) What good is more efficiency if the majority of programmers can never > get it right? My position: if a programmer has to explicitly synchronize > anywhere in the program, they'll get it wrong. This of course is a point of > contention; I've met a number of people who say "well, I know you don't > believe it, but *I* can write successful threaded programs." I used to think > that, too. But now I think it's just a learning phase, and you aren't a > reliable thread programmer until you say "it's impossible to get right" > (yes, a conundrum). > I don't see why this needs to be a religious either-or issue? As I said, *when* isolated threads maps well to your problem, they are more attractive than shared memory solutions (for correctness reasons), but preferring isolated threads does not mean you should ignore the reality that they do not fit every scenario well. There's no single superior concurrency/parallelism paradigm (at least not yet), so the best we can do for general purpose languages is to recognize the relative strengths/weaknesses of each and provide all of them. > > 2) What if you have lots of processors? Does that change the picture any? > That is, if you use isolated processes with message passing and you have as > many processors as you want, do you still think you need shared-memory > threading? > Not really. There are still situations where you have large pools of *potential* data with no way of figuring out ahead of time what pieces you'll need to modify . So for explicit synchronisation, e.g. using isolated threads to "own" the data, or with locks, you'll need to be conservative and lock the whole world, which means you might as well run everything sequentially. Note here that implementing this scenario using isolated threads with message passing effectively boils down to simulating locks and shared memory - so if you're using shared memory and locks anyway, why not have native (efficient) support for them? As I said earlier, though, I believe the best way to synchronize shared memory is currently STM, not using manual locks (simulated with threads or otherwise). > > A comment on the issue of serialization -- note that any time you need to > protect shared memory, you use some form of serialization. Even optimistic > methods guarantee serialization, even if it happens after the memory is > corrupted, by backing up to the uncorrupted state. The effect is the same; > only one thread can access the shared state at a time. > Yes, the difference is that with isolated threads, or with manual locking, the programmer has to somehow figure out which pieces lock ahead of time, or write manual transaction protocols with rollbacks etc. The ideal case is that you have a runtime (possibly with hardware support) to let you off the hook and automatically do a very fine-grained locking with optimistic concurrency. Isolated threads and locks are on the same side of this argument - they both require the user to ahead of time partition the data up and decide how to serialize operations on the data (which is not always possible statically, leading to very very complicated code, or very low concurrency). -- 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] Can you do everything without shared-memory concurrency?
On Mon, Sep 8, 2008 at 8:33 PM, Bruce Eckel <[EMAIL PROTECTED]> wrote: > As some of you on this list may know, I have struggled to understand > concurrency, on and off for many years, but primarily in the C++ and > Java domains. As time has passed and experience has stacked up, I have > become more convinced that while the world runs in parallel, we think > sequentially and so shared-memory concurrency is impossible for > programmers to get right -- not only are we unable to think in such a > way to solve the problem, the unnatural domain-cutting that happens in > shared-memory concurrency always trips you up, especially when the > scale increases. > > I think that the inclusion of threads and locks in Java was just a > knee-jerk response to solving the concurrency problem. Indeed, there > were subtle threading bugs in the system until Java 5. I personally > find the Actor model to be most attractive when talking about > threading and objects, but I don't yet know where the limitations of > Actors are. > > However, I keep running across comments where people claim they "must" > have shared memory concurrency. It's very hard for me to tell whether > this is just because the person knows threads or if there is truth to > it. For correctness, maybe not, for efficiency, yes definitely! Imagine a program where you have a huge set of data that needs to be modified (in some sense) over time by thousands of agents. E.g. a game simulation. Now, also imagine that every agent could *potentially* modify every single piece of data, but that every agent *typically* only touches two or three varibles here and there. I.e. the collisions between the potential read/write sets is 100%, while the collisions for the actual read/write sets is very very low. How would you do this with threads and message passing? Well you could have one big thread owning all of your data that takes "update" messages, and then "updates" the world for you (immutably if you wish, by just replacing its "world" variable with a new one containing your update), but now you've effectively serialized all your interactions with the "world", so you're not really concurrent anymore! So you could decompose the world into multiple threads using some application-specific logical sudivision, but then you're effectively just treating each thread as a mutable variable with an implicit lock (with the risks of deadlock that comes with it - remember we don't know the read/write set in advance - it could be the entire world - so we can't just order our updates in some global way here), so you're really just doing shared mutable state again, and gain little from having threads "simulate" your mutable cells... What you really need for this is some way for each agent to update this shared state *in parallel*, without having to block all other agents pessimistically, but instead only block other agents if there was an *actual* conflict. STM seems to be the only real hope for that sort of thing right now. IMO my list of preferred methods goes like this: 1. Purely functional data parallelism 2. Purely functional task parallelism (using e.g. strategies) 3. Message passing with no (or very minimal) shared state (simulated using threads as "data servers" or otherwise) (3.5. Join patterns? Don't have enough experience with this, but seems sort of nice?) 4. Shared state concurrency using STM 5. Shared state concurrency using locks 6. Lockless programming. So while I wouldn't resort to any shared state concurrency unless there are good reasons for why the other methods don't work well (performance is a good reason!), there are still situations where you need it, and a general purpose language had better supply a way of accessing those kinds of facilities. -- 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] Haskell Propeganda
On Mon, Aug 25, 2008 at 7:54 PM, Niels Aan de Brugh <[EMAIL PROTECTED]>wrote: > Christopher Lane Hinson wrote: > >> Here's an error the Haskell run-time system might throw: >>> *** Exception: Prelude.head: empty list >>> (or whatever) >>> >>> So now what? Action plan = []. >>> >> >> rgrep " head " . >> >> Lists 17 items for three projects I've been working on summing to 1 >> lines of haskell. Use listToMaybe or pattern matching and -Wall, and raise >> an explicit (error "with explanation"), which is all good practice in the C >> world as well. Please, don't make undocumented use of partial functions in >> serious code. >> > You're absolutely right, and the compiler can warn the programmer for such > mistakes. However, I've found that analysing the run-time behaviour/errors > (if they do occur) in a Haskell program to be harder than in a language like > C(++) which has many very mature engineering tools available. No doubt this > is a matter of time and money, not which language is better suited for "real > work". > I sort of agree with this, but I don't think that the total amount of time spent on that activity is even comparable for the two languages. In C/C++ breaking into the debugger and stepping through code is often the easiest way to even understand working code. That's both a testament to the high quality of the visual studio debugger, but it's also an indictment of how difficult it is to understand code written in the language. In Haskell, on the other hand, everything is much more modular and "direct" and if you can't work out what the program does, a little poking in an interactive session will usually get you there far faster then anything you could do in C++. The same goes for tracking down bugs, IMO. It would be nicer to have better traditional debugging tools of course (particularly something that ties into a nice IDE), and I do think this should be a priority, but even then they wouldn't need to be used nearly as often as for C/C++. -- 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] ANNOUNCE: vector 0.1 (efficient arrays with lots of fusion)
On 7/12/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote: > > Hi all, > > the vector library will eventually provide fast, Int-indexed arrays with a > powerful fusion framework. It's very immature at the moment (I haven't > tested most of the code) and implements just a few combinators but I > thought releasing early wouldn't hurt. Use at your own risk and expect > things to break horribly! > > What it provides: > > * Boxed and unboxed arrays with a generic interface and a very basic >set of combinators. > > * A powerful loop fusion framework. It is based on stream fusion but >already goes beyond that (in particular, it can do some things >in-place) and will be significantly extended in the future. > (moving to cafe) Is there any more (easily-digested, like a paper) information available about this? Specifically what things can happen in-place, and future extensions... -- 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] Haskell, Microsoft, and interview questions
On 6/26/08, Andrew Wagner <[EMAIL PROTECTED]> wrote: > > > Did they score you on coding or on geometry? > > > > > It was definitely more on coding and my ability to think about the problem. > > > > For what it's worth, a 3-dimensional kd tree really flew on this problem. > > > > > I did some reading up on this, and it seems interesting. It would be > need to implement something like this in Haskell, but I can't seem to > find any detailed specs on the data-structure. Got any > recommendations? http://en.wikipedia.org/wiki/Kd_tree -- 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] How to do this in FP way?
On 6/16/08, Magicloud Magiclouds <[EMAIL PROTECTED]> wrote:
>
> Hello,
> I am getting familiar with FP now, and I have a "program design" kind
> of question.
> Say I have something like this in C:
> static int old;
> int diff (int now) { /* this would be called once a second */
> int ret = now - old;
> old = now;
> return ret;
> }
> Because there is no "variable" in Haskell. So how to do this in a FP
> way?
The short answer is that your question amounts to "How do I do imperative
programming in an FP way", to which the answer is "you really should try to
avoid it".
Longer answer:
I think you'll be bette served if you describe your problem on a much higher
level than this. Chances are that if you write your program in an FP way,
you wouldn't need a function like your diff.
That said, Haskell do have variables (in this case an IORef would do what
you want), but again, you probably don't want that, so if you post what
problem you're trying to solve using "diff", then it will be easier to help
you design it in an FP way. Doing things in an FP way tend to impact your
program a lot more than just some minor changes to the functions at the
"bottom", it will change the whole design.
--
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
