[Haskell-cafe] Undo records

2013-01-06 Thread Casey Basichis
Hi,

I am still getting a hang of Haskell.  Sorry if the answer is obvious.

What sorts of packages and approaches should I be looking at if I was
looking to store something like an Undo stack into a database.

Each table would refer to a function.
Each records input and outputs would specify both a table ID and record ID.

The records would also have a data and a Process ID to associate all
functions to a specific process and give them an order.

No records are ever deleted.  Rolling something back is instead a process
of recreating a new, modified graph by taking the old graph from the
database.

I should note that while I can generate some of the boiler parts from
template haskell in advance I'm ultimately using a stage 1 compiler with no
GHCI o template haskell.

Thanks,
Casey

-- 
Casey James Basichis
Composer - Cartoon Network
http://www.caseyjamesbasichis.com
caseybasic...@gmail.com
310.387.7540
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Announce: Leksah 0.13.1.1 (a bit experimental)

2013-01-06 Thread Hamish Mackenzie
I fixed some annoying issues with 0.13.1.0 and
added Panes-HLint.

OS X (using Gtk3)
-
Choose the version that matches your installed GHC
http://leksah.org/packages/leksah-0.13.1.1-ghc-7.0.3.dmg
http://leksah.org/packages/leksah-0.13.1.1-ghc-7.0.4.dmg
http://leksah.org/packages/leksah-0.13.1.1-ghc-7.4.1.dmg
http://leksah.org/packages/leksah-0.13.1.1-ghc-7.4.2.dmg
http://leksah.org/packages/leksah-0.13.1.1-ghc-7.6.1.dmg
(probable needs OS X 10.7)

Windows (still Gtk2)

Choose the version that matches your installed GHC
http://leksah.org/packages/leksah-0.13.1.1-ghc-7.0.3.exe
http://leksah.org/packages/leksah-0.13.1.1-ghc-7.0.4.exe
http://leksah.org/packages/leksah-0.13.1.1-ghc-7.4.1.exe
http://leksah.org/packages/leksah-0.13.1.1-ghc-7.4.2.exe
http://leksah.org/packages/leksah-0.13.1.1-ghc-7.6.1.exe

On 6 Jan 2013, at 15:16, Hamish Mackenzie hamish.k.macken...@gmail.com wrote:

 This has mostly bug fixes, GHC 7.4.2, GHC 7.6.1 and Gtk3
 support.
 
 I have not uploaded it to Hackage as it uses Gtk2Hs patches
 that are not in Hackage.
 
 New features include View-Dark (OS X only) and
 View-Fullscreen.
 
 Linux
 -
 Follow the steps in the .travis.yml file...
 https://github.com/leksah/leksah/blob/master/.travis.yml
 Should go something like this...
 https://travis-ci.org/leksah/leksah


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Weird problem: Couldn't read cabal file hashable/1.2.0.0/hashable.cabal

2013-01-06 Thread Eugene Kirpichov
Hi,

A friend of mine is trying to install my timeplotters (see email
signature).
He's getting a weird error: one of the tools installs fine but the other
one fails with the error Couldn't read cabal file hashable/
1.2.0.0/hashable.cabal; curiously, so does running cabal install
cabal-install.

Even more curiously, hashable 1.2.0.0 does not appear anywhere in the list
of dependencies, even indirect. Look:

$ cabal -v3 install cabal-install
searching for ghc in path.
found ghc at /usr/bin/ghc
(/usr/bin/ghc,[--numeric-version])
/usr/bin/ghc is version 7.0.3
looking for tool ghc-pkg near compiler in /usr/bin
found ghc-pkg in /usr/bin/ghc-pkg
(/usr/bin/ghc-pkg,[--version])
/usr/bin/ghc-pkg is version 7.0.3
(/usr/bin/ghc,[--supported-languages])
(/usr/bin/ghc,[--info])
Reading installed packages...
(/usr/bin/ghc-pkg,[dump,--global,-v2])
(/usr/bin/ghc-pkg,[dump,--user,-v2])
(/usr/bin/ghc,[--print-libdir])
Reading available packages...
Resolving dependencies...
cabal: Couldn't read cabal file hashable/1.2.0.0/hashable.cabal

He's using haskell platform on Ubuntu 12.04.
$ ghc —version
The Glorious Glasgow Haskell Compilation System, version 7.0.3
$ cabal —version
cabal-install version 0.10.2
using version 1.10.1.0 of the Cabal library

He *did* try erasing ~/.cabal, ~/.ghc and /usr/lib/ghc and then
reinstalling haskell-platform package - it didn't change anything. He
doesn't remember ever having Haskell installed before, but that can't be
completely ruled out.

I just tried installing a fresh Ubuntu 12.04 onto a VM and I did not have
this problem that he has.

What additional information can I ask him for? Maybe somebody already
encountered this problem?

(Actually, I have a whole strace cabal install cabal-install, but it's 33Mb
- I can upload it somewhere if it could be helpful).

-- 
Eugene Kirpichov
http://www.linkedin.com/in/eugenekirpichov
http://jkff.info/software/timeplotters - my performance visualization tools
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Weird problem: Couldn't read cabal file hashable/1.2.0.0/hashable.cabal

2013-01-06 Thread Eugene Kirpichov
The curious thing about that strace is that it doesn't ever attempt to open
hashable.cabal - in fact, it isn't attempting to open *any* .cabal file
whatsoever before failing!
So I'm totally confused as to why cabal might be complaining that it can't
open hashable.cabal.

On Sun, Jan 6, 2013 at 10:05 PM, Eugene Kirpichov ekirpic...@gmail.comwrote:

 Couldn't read cabal file




-- 
Eugene Kirpichov
http://www.linkedin.com/in/eugenekirpichov
http://jkff.info/software/timeplotters - my performance visualization tools
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Weird problem: Couldn't read cabal file hashable/1.2.0.0/hashable.cabal

2013-01-06 Thread Brandon Allbery
On Mon, Jan 7, 2013 at 1:05 AM, Eugene Kirpichov ekirpic...@gmail.comwrote:

 A friend of mine is trying to install my timeplotters (see email
 signature).
 He's getting a weird error: one of the tools installs fine but the other
 one fails with the error Couldn't read cabal file hashable/
 1.2.0.0/hashable.cabal; curiously, so does running cabal install
 cabal-install.


That's a symptom of too old cabal-install that crashes when it encounters
certain newer cabal file features.  I believe you need to upgrade
cabal-install manually (since cabal-install itself will crash trying to do
so...).

It's not opening a cabal file directly, it is trying to parse entries in
the compressed package list.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] help diagnosing space leak with IORef/STRef, just incrementing a million times.

2013-01-06 Thread Albert Y. C. Lai

On 13-01-07 12:12 AM, Thomas Hartman wrote:

I have a space leak in a function that increments a number inside
IORef or STRef (either lazy or strict).


IORef and STRef operations do not automatically evaluate contents. 
writeIORef r (x + 1) simply stores a pointer to the expression (thunk) 
x + 1 into the mutable cell. readIORef just reports back a pointer. 
modifyIORef just calls readIORef and writeIORef. No evaluation throughout.


modifyIORef incr where

incr !x = x + 1

does not make a difference because it is just writeIORef r (incr x)), 
i.e., simply stores a pointer to the expression (thunk) incr x into 
the mutable cell. The whole process doesn't even care about how many 
bangs are in incr.


(It is illuminating to consider how const True (incr x) does not 
evaluate x. A pointer to True and a pointer to incr x are passed to 
const, then const throws away the latter without even looking. See also 
const True undefined. One day, you will thank writeIORef r 
undefined; I certainly did.)


Same for both Data.STRef.Strict and Data.STRef.Lazy. They do not mean 
what you think. Here is what they mean:


Data.STRef.Strict means what Control.Monad.ST.Strict means
Data.STRef.Lazy means what Control.Monad.ST.Lazy means

Control.Monad.ST.Strict means that the following hangs:

x = head (runST list) where
  list :: ST s [Bool]
  list = do {xs - list; return (True : xs)}

Control.Monad.ST.Lazy means that the above terminates and gives the 
answer True.


(Up to this point, same story for Control.Monad.State.Strict and 
Control.Monad.State.Lazy.)


I still have not understood Control.Monad.ST.Lazy enough to articulate 
its full semantics, but I have some more examples to show what it does:


http://hpaste.org/63925

By understanding what Lazy in Control.Monad.ST.Lazy means, you also 
see what Strict does *not* mean.


In IO or Control.Monad.ST.Strict, use

  let y = x+1 in y `seq` write[IO/ST]Ref r y

to expedite the evaluation of x+1. Using the same idea, you may write 
your own modify[IO/ST]RefNOW to evaluate while updating.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Announce: Leksah 0.13.1.1 (a bit experimental)

2013-01-06 Thread Darren Grant
Thank you kindly for this release!  System-wide package metadata is working
with my platform install now. :)

Cheers,
d




On Sun, Jan 6, 2013 at 9:34 PM, Hamish Mackenzie 
hamish.k.macken...@gmail.com wrote:

 I fixed some annoying issues with 0.13.1.0 and
 added Panes-HLint.

 OS X (using Gtk3)
 -
 Choose the version that matches your installed GHC
 http://leksah.org/packages/leksah-0.13.1.1-ghc-7.0.3.dmg
 http://leksah.org/packages/leksah-0.13.1.1-ghc-7.0.4.dmg
 http://leksah.org/packages/leksah-0.13.1.1-ghc-7.4.1.dmg
 http://leksah.org/packages/leksah-0.13.1.1-ghc-7.4.2.dmg
 http://leksah.org/packages/leksah-0.13.1.1-ghc-7.6.1.dmg
 (probable needs OS X 10.7)

 Windows (still Gtk2)
 
 Choose the version that matches your installed GHC
 http://leksah.org/packages/leksah-0.13.1.1-ghc-7.0.3.exe
 http://leksah.org/packages/leksah-0.13.1.1-ghc-7.0.4.exe
 http://leksah.org/packages/leksah-0.13.1.1-ghc-7.4.1.exe
 http://leksah.org/packages/leksah-0.13.1.1-ghc-7.4.2.exe
 http://leksah.org/packages/leksah-0.13.1.1-ghc-7.6.1.exe

 On 6 Jan 2013, at 15:16, Hamish Mackenzie hamish.k.macken...@gmail.com
 wrote:

  This has mostly bug fixes, GHC 7.4.2, GHC 7.6.1 and Gtk3
  support.
 
  I have not uploaded it to Hackage as it uses Gtk2Hs patches
  that are not in Hackage.
 
  New features include View-Dark (OS X only) and
  View-Fullscreen.
 
  Linux
  -
  Follow the steps in the .travis.yml file...
  https://github.com/leksah/leksah/blob/master/.travis.yml
  Should go something like this...
  https://travis-ci.org/leksah/leksah


 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] help diagnosing space leak with IORef/STRef, just incrementing a million times.

2013-01-06 Thread Thomas Bereknyei
I have had issues like this with modifySTRef before. Try to make a strict
version modifySTRef'

If memory serves, something like this worked for me.
modifySTRef' r f =
  do
a - readSTRef r
writeSTRef r $! f a
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] help diagnosing space leak with IORef/STRef, just incrementing a million times.

2013-01-06 Thread Christopher Done
A similar use-case and same solution with IORefs:
http://hpaste.org/diff/80055/80058 Guess which one threw a
stackoverflow and which one ran indefinitely when given a few hundred
million lines of input.

On 7 January 2013 07:35, Albert Y. C. Lai tre...@vex.net wrote:
 On 13-01-07 12:12 AM, Thomas Hartman wrote:

 I have a space leak in a function that increments a number inside
 IORef or STRef (either lazy or strict).


 IORef and STRef operations do not automatically evaluate contents.
 writeIORef r (x + 1) simply stores a pointer to the expression (thunk) x
 + 1 into the mutable cell. readIORef just reports back a pointer.
 modifyIORef just calls readIORef and writeIORef. No evaluation throughout.

 modifyIORef incr where

 incr !x = x + 1

 does not make a difference because it is just writeIORef r (incr x)),
 i.e., simply stores a pointer to the expression (thunk) incr x into the
 mutable cell. The whole process doesn't even care about how many bangs are
 in incr.

 (It is illuminating to consider how const True (incr x) does not evaluate
 x. A pointer to True and a pointer to incr x are passed to const, then
 const throws away the latter without even looking. See also const True
 undefined. One day, you will thank writeIORef r undefined; I certainly
 did.)

 Same for both Data.STRef.Strict and Data.STRef.Lazy. They do not mean what
 you think. Here is what they mean:

 Data.STRef.Strict means what Control.Monad.ST.Strict means
 Data.STRef.Lazy means what Control.Monad.ST.Lazy means

 Control.Monad.ST.Strict means that the following hangs:

 x = head (runST list) where
   list :: ST s [Bool]
   list = do {xs - list; return (True : xs)}

 Control.Monad.ST.Lazy means that the above terminates and gives the answer
 True.

 (Up to this point, same story for Control.Monad.State.Strict and
 Control.Monad.State.Lazy.)

 I still have not understood Control.Monad.ST.Lazy enough to articulate its
 full semantics, but I have some more examples to show what it does:

 http://hpaste.org/63925

 By understanding what Lazy in Control.Monad.ST.Lazy means, you also see
 what Strict does *not* mean.

 In IO or Control.Monad.ST.Strict, use

   let y = x+1 in y `seq` write[IO/ST]Ref r y

 to expedite the evaluation of x+1. Using the same idea, you may write your
 own modify[IO/ST]RefNOW to evaluate while updating.


 ___
 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