Re: [Haskell-cafe] Re: capture of idioms and patterns

a...@spamcop.net wrote: G'day all. Quoting Johannes Waldmann : you got this backwards: what some folks call "idioms and (design) patterns" actually *is* FP, because it is just this: higher order functions. And it's been there some decades (lambda calculus). That also explains the absence of a

[Haskell-cafe] ANN: GlomeTrace raytracing library

I have uploaded to hackage a new version of my ray-tracer, Glome. In previous releases, Glome was a monolithic application. In this release, the core algorithms have been abstracted out into a pair of libraries, GlomeVec and GlomeTrace. GlomeVec is a vector library. It's not necessarily any

Re: [Haskell-cafe] Data.Ring -- Pre-announce

My first thoughts are that you could implement a Ring type using Data.Sequence [1], which is a sort of balanced binary tree where you can insert or remove elements at the beginning or end in amortized O(1) time. You might have a data type like this: data Ring a = Empty | Ring (Seq a) a The

[Haskell-cafe] ANN: GlomeVec, IcoGrid

I just uploaded two packages to hackage. The first package [1] is the vector library used by my haskell ray-tracer, Glome, which has been neglected of late. It's one of the first things I ever wrote in Haskell, so some of the code looks a little strange to me now, but it works pretty well for

Re: [Haskell-cafe] IORef memory leak

Don Stewart wrote: dvde: Don Stewart schrieb: It is not possible to write a modifyIORef that *doesn't* leak memory! Why? Or can one read about it somewhere? Try writing a version of this program, using modifyIORef only, such that it doesn't exhaust the heap: i

Re: [Haskell-cafe] IORef memory leak

Luke Palmer wrote: On Thu, Jun 18, 2009 at 9:55 PM, Ross Mellgren > wrote: It looks offhand like you're not being strict enough when you put things back in the IORef, and so it's building up thunks of (+1)... With two slight mods: go 0 = return

[Haskell-cafe] IORef memory leak

I'm having some trouble with excessive memory use in a program that uses a lot of IORefs. I was able to write a much simpler program which exhibits the same sort of behavior. It appears that "modifyIORef" and "writeIORef" leak memory; perhaps they keep a reference to the old value. I tried

Re: [Haskell-cafe] IORef vs TVar performance: 6 seconds versus 4 minutes

Thanks, that's good to know. I tried incrementally loading the graph one node per transaction. It's faster: about 38 seconds instead of 4 minutes, but I think I'll stick with IORefs and one thread for the present. -jim Ryan Ingram wrote: Both readTVar and writeTVar are worse than O(1); the

[Haskell-cafe] IORef vs TVar performance: 6 seconds versus 4 minutes

I decided to try to implement a graph algorithm using STM. Each node in the graph has a set of TVar-protected lists of the nodes it links to and the nodes that link to it. Also, there is a global TVar-protected Data.Map that contains all the nodes in the graph, indexed by name (which is pol

Re: [Haskell-cafe] OT: Haskell desktop wallpaper?

Magnus Therning wrote: Very nice indeed. You don't have any images in aspect 8x5 that don't include the window decorations? ;-) (Yes, I'm lazy!) I replaced the sphereflake image with one without window decorations: http://syn.cs.pdx.edu/~jsnow/glome/sphereflake5-720p.png I don't have any

Re: [Haskell-cafe] OT: Haskell desktop wallpaper?

Ray tracing about a million spheres in a regular grid with reflections: lattice = let n = 50 :: Flt in bih [sphere (vec x y z) 0.2 | x <- [(-n)..n], y <- [(-n)..n], z <- [(-n)..n]] http://syn.cs.pdx.edu/~jsnow/glome/Glome.hs-latti

Re: [Haskell-cafe] Re: [ANN] bloomfilter 1.0 - Fast immutable and mutable Bloom filters

Achim Schneider wrote: Aaron Denney <[EMAIL PROTECTED]> wrote: On 2008-05-30, Achim Schneider <[EMAIL PROTECTED]> wrote: Bryan O'Sullivan <[EMAIL PROTECTED]> wrote: A Bloom filter is a probabilistic data structure that provides a fast set membership querying capability. It doe

[Haskell-cafe] Announce: glome-hs-0.51 (Haskell raytracer, now with type classes)

A new version of my raytracer has been posted: http://syn.cs.pdx.edu/~jsnow/glome/ http://hackage.haskell.org/cgi-bin/hackage-scripts/package/glome-hs-0.51 (This should really be named 0.5.1, but I didn't think of that until after I uploaded it to hackage.) There's not much new functionality,

Re: [Haskell-cafe] Glome.hs-0.3 (bounding objects, heterogeneous lists)

assume that users know how to use it sensibly. http://www.haskell.org/haskellwiki/Glome_tutorial#Bounding_Objects As for the maintenance issues, that is still a problem. It would be nice to split all the individual primitives into their own modules. Sebastian Sylvan wrote: On 4/27/08, Jim

Re: [Haskell-cafe] announce: Glome.hs-0.3 (ray tracing digression, glome tutorial)

David48 wrote: On Sat, Apr 26, 2008 at 9:33 AM, Andrew Coppin <[EMAIL PROTECTED]> wrote: > Personally, I don't see the point in rendering a couple of million > mathematically flat surfaces, What about speed ? That is a good point. Ray tracing may give you a better image approximati

Re: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer)

Andrew Coppin wrote: Wow. The POV-Ray guys are talking about Haskell [or rather, my personal addiction to it] and the Haskell guys are talking about POV-Ray... on the same day... How unlikely is that? ;-) That's odd; I had a personal addiction to POV-Ray for a few years, and just now have s

Re: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer)

Derek Elkins wrote: Ingo Wald's work on interactive coherent raytracing springs to mind. http://www.sci.utah.edu/~wald/Publications/ "Interactive Rendering with Coherent Raytracing" http://graphics.cs.uni-sb.de/~wald/Publications/EG2001_IRCRT/InteractiveRenderingWithCoherentRayTracing.pdf is a

[Haskell-cafe] announce: Glome-hs-0.4.1 (Haskell raytracer, now with cabal support)

Don Stewart wrote: jsnow: A new version of my raytracer is out... Very impressive. Did you consider cabalising the Haskell code, so it can be easily distributed from hackage.haskell.org? ... -- Don A new version is up on hackage now: http://hackage.haskell.org/cgi-bin/hackage-

Re: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer)

David Roundy wrote: On Fri, Apr 18, 2008 at 02:09:28PM -0700, Jim Snow wrote: On a particular scene with one instance of the single-threaded renderer running, it takes about 19 seconds to render an image. With two instances running, they each take about 23 seconds. This is on an Athlon-64

Re: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer)

David Roundy wrote: On Sat, Apr 19, 2008 at 12:19:19AM +0400, Bulat Ziganshin wrote: Saturday, April 19, 2008, 12:10:23 AM, you wrote: The other problem I had with concurrency is that I was getting about a 50% speedup instead of the 99% or so that I'd expect on two cores. I 2

Re: [Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer)

Don Stewart wrote: jsnow: A new version of my raytracer is out. ... Very impressive. Did you consider cabalising the Haskell code, so it can be easily distributed from hackage.haskell.org? I note on the website you say: "no threading (shared-memory concurrency is not supported

[Haskell-cafe] announce: Glome.hs-0.3 (Haskell raytracer)

A new version of my raytracer is out. It now supports cones, cylinders, disks, boxes, and planes as base primitives (previously it only supported triangles and spheres), as well as transformations of arbitrary objects (rotate, scale, translate) and the CSG operations difference and intersectio

Re: [Haskell-cafe] Glome raytracer bug: bad output with -O2 -fasm

Luke Palmer wrote: On Fri, Mar 28, 2008 at 6:28 AM, Jim Snow <[EMAIL PROTECTED]> wrote: I was trying to get Blinn highlights working with my raytracer, and kept getting ugly artifacts. After trying a bunch of things, I finally compiled without -O2, and the artifacts went away.

[Haskell-cafe] Glome raytracer bug: bad output with -O2 -fasm

I was trying to get Blinn highlights working with my raytracer, and kept getting ugly artifacts. After trying a bunch of things, I finally compiled without -O2, and the artifacts went away. Here's what I mean: http://syn.cs.pdx.edu/~jsnow/glome/Glome.hs-noartifact.png http://syn.cs.pdx.edu/~js

Re: [Haskell-cafe] announce: Glome.hs raytracer (memory leak with parMap)

pepe wrote: On 27/03/2008, at 3:49, Ian Lynagh wrote: On Wed, Mar 26, 2008 at 02:33:20PM -0700, Jim Snow wrote: -Memory consumption is atrocious: 146 megs to render a scene that's a 33k ascii file. Where does it all go? A heap profile reports the max heap size at a rather more reaso

Re: [Haskell-cafe] announce: Glome.hs raytracer

David Roundy wrote: On Wed, Mar 26, 2008 at 05:07:10PM -0700, Don Stewart wrote: droundy: On Thu, Mar 27, 2008 at 01:09:47AM +0300, Bulat Ziganshin wrote: -Collecting rendering stats is not easy without global variables. It occurs to me that it would be neat if there were some

[Haskell-cafe] announce: Glome.hs raytracer

I have recently posted a haskell port of my ocaml raytracer, Glome: http://syn.cs.pdx.edu/~jsnow/glome/ It supports spheres and triangles as base primitives, and is able to parse files in the NFF format used by the standard procedural database (http://tog.acm.org/resources/SPD/). It uses a bo