Re: [Haskell-cafe] Re: Installing Haskell on OSX
On 23 Jun 2010, at 10:25, Giuseppe Luigi Punzi Ruiz wrote:
I uninstalled all ports and macports, to try with gtk-osx
Once I did all of this, leksah builds, but leksah-server don't, with problems
with version of libgthread2.
I am confused leksah depends on leksah-server so I am not sure how leksah could
build but not leksah-server, unless leksah were using some old version of
leksah-server installed earlier.
I'm at jhbuild build meta-gtk-osx-bootstrap step of GTK-OSX.
Once the next step (jhbuild build meta-gtk-osx-core) is finished, and all
is fine (and really I hope it), there are some consideration, before directly
reinstall cabal gtk packages, and reinstall leksah? I ask because it sais
thath jhbuild is needed to build gtk apps.
You will also need to
jhbuild build gtksourceview
jhbuild build ige-mac-integration
As for building gtk2hs, I have the following in them .profile and that seems to
be enough.
export PATH=/Users/hamish/gtk/inst/bin:~/.cabal/bin:$PATH
export XDG_DATA_DIRS=~/gtk/inst/share
export PKG_CONFIG_PATH=~/gtk/inst/lib/pkgconfig:/usr/lib/pkgconfig
Alternatively you could probably use 'jhbuild shell' to set up the environment
for you.
Then of course you will need to run...
cabal install --reinstall glib
cabal install --reinstall gio
cabal install --reinstall cairo
cabal install --reinstall pango
cabal install --reinstall gtk
cabal install --reinstall gtksourceview
If you do have half installed Leksah libs then run this...
cabal install --reinstall ltk
cabal install --reinstall leksah-server
cabal install --reinstall leksah
You can make Leksah look a bit nicer too with
jhbuild build gtk-engines
Then to your ~/.gtkrc-2.0 file (or your ~/.gtkrc.mine file if if appropriate)
add something like...
include /Users/hamish/gtk/inst/share/themes/Clearlooks/gtk-2.0/gtkrc
style leksah-close-button-style
{
GtkWidget::focus-padding = 0
GtkWidget::focus-line-width = 0
xthickness = 0
ythickness = 0
}
widget *.leksah-close-button style leksah-close-button-style
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] checking types with type families
I think your problem here is that there's no mention of `a' on the left-hand size of from_val's type signature; you either need to use MPTC+fundep to associate what result is compared to a, or else use a phantom type parameter of Val to make it data Val result a = ... and then from_val :: Val result a - Maybe a. Aha! Why didn't I think of plain old MPTC+fundep? For some reason type families feel a lot more fun. Turns out you can write 'instance Typecheck (SomeMonad result) result' and instead of complaining about a duplicate symbol it unifies 'result', exactly like I wanted. It appears to work like a charm, thanks so much! Though it says it fails the Coverage Condition and I need UndecidableInstances... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Huffman Codes in Haskell
Hello ajb, Wednesday, June 23, 2010, 6:58:30 AM, you wrote: build ((w1,t1):(w2,t2):wts) = build $ insertBy (comparing fst) (w1+w2, Node t1 t2) wts this algo is O(n^2). to be O(n) you should handle separate lists of leafs and nodes, adding new nodes to the tail of second list -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] checking types with type families
| I think your problem here is that there's no mention of `a' on the | left-hand size of from_val's type signature; you either need to use | MPTC+fundep to associate what result is compared to a, or else use a | phantom type parameter of Val to make it data Val result a = ... and | then from_val :: Val result a - Maybe a. | | Aha! Why didn't I think of plain old MPTC+fundep? For some reason | type families feel a lot more fun. Turns out you can write 'instance | Typecheck (SomeMonad result) result' and instead of complaining about | a duplicate symbol it unifies 'result', exactly like I wanted. I'm interested in situations where you think fundeps work and type families don't. Reason: no one knows how to make fundeps work cleanly with local type constraints (such as GADTs). If you think you have such as case, do send me a test case. Thanks Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] checking types with type families
I'm interested in situations where you think fundeps work and type families don't. Reason: no one knows how to make fundeps work cleanly with local type constraints (such as GADTs). If you think you have such as case, do send me a test case. Well, from looking at the documentation, it looks like I could maybe use a type family if I could write: class (DerivedOf a ~ derived) = Typecheck a derived where ... Presumably then I could combine functions 'Typecheck a derived' constraints without getting lots of Could not deduce (Typecheck a derived3) from the context (Typecheck a derived13) errors. I'm only guessing though, because it looks like it's not implemented yet as of 6.12.3. So is your question whether I have a use case for fundeps supposing equality constraints in superclass contexts were implemented and they do what I hope they do, or is it do I have a use for those equality constraints as a motivation to implement them? In either case, I can give you some code that works with mptc+fundep but not with type families, unless I'm not using type families correctly of course. But if the type equality thing is coming regardless, then I can just wait for 6.14 or whatever and switch over then. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] checking types with type families
I'm interested in situations where you think fundeps work and type families don't. Reason: no one knows how to make fundeps work cleanly with local type constraints (such as GADTs). If you think you have such as case, do send me a test case. Do you have a wiki page somewhere collecting these examples? I seem to recall that similar discussions have arisen before and test cases have been provided but I wouldn't know where to check for the currently recorded state of differences. Also, what is the difference between fundeps and type families wrt local type constraints? I had always assumed them to be equivalent, if fully implemented. Similar to logic vs functional programming, where Haskellers tend to find the latter more convenient. Functional logic programming shows that there are some tricks missing if one just drops the logic part. Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Installing Haskell on OSX
Hi Hamish, list...
El mié, 23-06-2010 a las 18:09 +1200, Hamish Mackenzie escribió:
On 23 Jun 2010, at 10:25, Giuseppe Luigi Punzi Ruiz wrote:
I uninstalled all ports and macports, to try with gtk-osx
Once I did all of this, leksah builds, but leksah-server don't, with
problems with version of libgthread2.
I am confused leksah depends on leksah-server so I am not sure how leksah
could build but not leksah-server, unless leksah were using some old version
of leksah-server installed earlier.
leksah starts with a blank window, asking for parameter to reindex, but
when Ok is pressed, then, a blank window appears, and closes with an
error leksah-server is not running.
leksah-server it suppose to be builded. I don't remember exactly, but
the error gives trying to execute is something like this
Dyld Error Message:Library not loaded:
/opt/lib/libgthread-2.0.0.dylib
Referenced from: /User/glpunzi/.cabal/bin/leksah-server
Reason: Incompatible library version: libgthread requires version
2501.0.0 or later, but libgthread-2.0.0.dylib provides version
2001.0.0
Now, with my mind cleared, I'm thinking, thath once I rebuilded macports
with quartz support, I reinstalled gtk related packages from cabal, but,
with leksah, I didn't a reinstall, only a cabal install leksah. Could
be the problem, leksah-server was builded before, and for this, later is
giving this kind of error?
I'm at jhbuild build meta-gtk-osx-bootstrap step of GTK-OSX.
Once the next step (jhbuild build meta-gtk-osx-core) is finished, and all
is fine (and really I hope it), there are some consideration, before
directly reinstall cabal gtk packages, and reinstall leksah? I ask because
it sais thath jhbuild is needed to build gtk apps.
You will also need to
jhbuild build gtksourceview
jhbuild build ige-mac-integration
As for building gtk2hs, I have the following in them .profile and that seems
to be enough.
export PATH=/Users/hamish/gtk/inst/bin:~/.cabal/bin:$PATH
export XDG_DATA_DIRS=~/gtk/inst/share
export PKG_CONFIG_PATH=~/gtk/inst/lib/pkgconfig:/usr/lib/pkgconfig
Alternatively you could probably use 'jhbuild shell' to set up the
environment for you.
Then of course you will need to run...
cabal install --reinstall glib
cabal install --reinstall gio
cabal install --reinstall cairo
cabal install --reinstall pango
cabal install --reinstall gtk
cabal install --reinstall gtksourceview
If you do have half installed Leksah libs then run this...
cabal install --reinstall ltk
cabal install --reinstall leksah-server
cabal install --reinstall leksah
You can make Leksah look a bit nicer too with
jhbuild build gtk-engines
Then to your ~/.gtkrc-2.0 file (or your ~/.gtkrc.mine file if if appropriate)
add something like...
include /Users/hamish/gtk/inst/share/themes/Clearlooks/gtk-2.0/gtkrc
style leksah-close-button-style
{
GtkWidget::focus-padding = 0
GtkWidget::focus-line-width = 0
xthickness = 0
ythickness = 0
}
widget *.leksah-close-button style leksah-close-button-style
Thanks a lot. I will check later at home. I throw jhbuild build
meta-gtk-osx-core, and, when I went to bed, it stopped with some error
AFAIR. I will check it :(
From Linux all ok. From Windows seems ok too, but Macos, always gives me
problems with this kind of things.. Seems thath something in the air,
stops me to learn haskell + GUI development :P
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Control.Alternative --- some and many?
On 23/06/10 06:54, Christopher Done wrote: I'm not sure how Alternative differs from MonadPlus, other than being defined for Applicative rather than Monad. They have the same laws (identity and associativity). Importantly, MonadPlus must satisfy some laws for (=) and (), whereas Alternative must only satisfy laws for the new (|) operator. There are plenty of monads that do not satisfy the laws for MonadPlus (particularly the difficult mzero-being-right-zero law), but do satisfy the laws when defining their (|) implementation. So they are different because MonadPlus overlaps with Monad, whereas Alternative does not (and thus, in my view, is much cleaner and more useful). Some and many are probably motivated by their usefulness in parsers. Hence optional, etc. I'm sure there are plenty of other uses for it. I wrote a little about some and many in Alternative in this blog post: http://chplib.wordpress.com/2010/05/05/choose-anything-adding-an-alternative-instance/ (scroll down to the Alternative heading). I think they are mainly useful with a left-biased choice operator. On 23 June 2010 05:22, Gregory Crosswhitegcr...@phys.washington.edu wrote: Hey everyone, Could someone explain to me (or point me to a reference explaining) the purpose of the some and many methods of the Alternative class? Also, there is a link posted in the documentation for Control.Applicative to a paper which describes the motivation behind the Applicative class; is there similarly a paper explaining the motivation behind the Alternative class? (The problem with Googling for Alternative is that this word is used a whole lot of the time, and very rarely does it refer to the Alernative class. :-) ) Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Weekly News?
I haven't seen HWN in a while. If there is still community interest, how can we help you with this? -deech On Wed, Apr 28, 2010 at 2:45 AM, Joe Fredette jfred...@gmail.com wrote: While I would not be opposed to being paid, I don't think it's at all necessary or even really appropriate. I liken the job to volunteering at a local community action group -- not really the kind of thing you get paid for. That said, if any of you have time machines/time dilation devices in the works, I'm happy to beta test. One more week... /Joe On Apr 28, 2010, at 2:40 AM, David Virebayre wrote: On Wed, Apr 28, 2010 at 7:47 AM, David Sankel cam...@gmail.com wrote: I'm wondering if a monetary incentive would keep the person who does this work more accountable. I personally would be willing to contribute to continue getting this service. I wonder if there are others as well. I don't think money would be an incentive for someone that has 7 classes worth of finals and papers to do Now a time machine. David. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Weekly News?
2010/6/23 aditya siram aditya.si...@gmail.com: I haven't seen HWN in a while. If there is still community interest, how can we help you with this? It will come back, see this thread: http://www.reddit.com/r/haskell/comments/cdw38/hwn_it_will_be_back_promise/ Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Weekly News?
Neat. Thanks! -deech On Wed, Jun 23, 2010 at 10:06 AM, Vo Minh Thu not...@gmail.com wrote: 2010/6/23 aditya siram aditya.si...@gmail.com: I haven't seen HWN in a while. If there is still community interest, how can we help you with this? It will come back, see this thread: http://www.reddit.com/r/haskell/comments/cdw38/hwn_it_will_be_back_promise/ Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Huffman Codes in Haskell
From: Max Rabkin max.rab...@gmail.com This seems like an example of list-chauvinism -- what Chris Okasaki calls a communal blind spot of the FP community in Breadth-First Numbering: Lessons from a Small Exercise in Algorithm Design -- http://www.eecs.usma.edu/webs/people/okasaki/icfp00.ps Thanks for sharing; this was an interesting (and short!) read. I would like to see other Haskeller's responses to this problem. I'll restate it here hoping to get replies from those who haven't read the paper yet: Assume you have a type of labeled binary trees: data Tree a = E | T a (Tree a) (Tree a) and you are to produce a function bfnum :: Tree a - Tree Int that performs a breadth-first numbering of the tree (starting with 1), preserving the tree structure. How would you implement bfnum? (If you've already read the paper, what was your first answer?) For the record, my solution doesn't rely on any other data structures or laziness AFAICT, and I think it would fit into the Level-Oriented category of solutions. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Huffman Codes in Haskell
I made (presumably) inefficient huffman algorithm not too long ago: http://www.hpaste.org/fastcgi/hpaste.fcgi/view?id=26484#a26484 I guess it doesn't normally need to be terribly efficient as the result can be stored in a map of some sort. On Wed, Jun 23, 2010 at 10:41 PM, John Lato jwl...@gmail.com wrote: From: Max Rabkin max.rab...@gmail.com This seems like an example of list-chauvinism -- what Chris Okasaki calls a communal blind spot of the FP community in Breadth-First Numbering: Lessons from a Small Exercise in Algorithm Design -- http://www.eecs.usma.edu/webs/people/okasaki/icfp00.ps Thanks for sharing; this was an interesting (and short!) read. I would like to see other Haskeller's responses to this problem. I'll restate it here hoping to get replies from those who haven't read the paper yet: Assume you have a type of labeled binary trees: data Tree a = E | T a (Tree a) (Tree a) and you are to produce a function bfnum :: Tree a - Tree Int that performs a breadth-first numbering of the tree (starting with 1), preserving the tree structure. How would you implement bfnum? (If you've already read the paper, what was your first answer?) For the record, my solution doesn't rely on any other data structures or laziness AFAICT, and I think it would fit into the Level-Oriented category of solutions. John ___ 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] Huffman Codes in Haskell
On Wed, Jun 23, 2010 at 03:41:29PM +0100, John Lato wrote: How would you implement bfnum? (If you've already read the paper, what was your first answer?) This was my first answer, and it is wrong, but I thought it was slightly clever, so here it is: bfnum :: Tree a - Tree Int bfnum tree = bfnum' tree 1 where bfnum' E _ = E bfnum' (T _ l r) i = T i (bfnum' l (i*2)) (bfnum' r ((i*2)+1)) If you have an incomplete tree, it will skip though. I didn't realize it was wrong until I finished reading the paper though, so I don't have a better solution that actually works. -- Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Huffman Codes in Haskell
On Wed, Jun 23, 2010 at 4:35 PM, Daniel Lyons fus...@storytotell.org wrote: On Wed, Jun 23, 2010 at 03:41:29PM +0100, John Lato wrote: How would you implement bfnum? (If you've already read the paper, what was your first answer?) This was my first answer, and it is wrong, but I thought it was slightly clever, so here it is: bfnum :: Tree a - Tree Int bfnum tree = bfnum' tree 1 where bfnum' E _ = E bfnum' (T _ l r) i = T i (bfnum' l (i*2)) (bfnum' r ((i*2)+1)) If you have an incomplete tree, it will skip though. I didn't realize it was wrong until I finished reading the paper though, so I don't have a better solution that actually works. That was my first try too. If this answer did work, I don't think the question would be interesting. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Huffman Codes in Haskell
On Wed, Jun 23, 2010 at 05:41:17PM +0100, John Lato wrote: If this answer did work, I don't think the question would be interesting. We don't have to be mean. - Buckaroo Banzai. -- Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
On Tue, Jun 22, 2010 at 4:54 PM, Gregory Crosswhite gcr...@phys.washington.edu wrote: There is no reason that your program couldn't link to multiple versions of the same package so that each library can access the version that it needs. In fact, GHC already does this, doesn't it? For example, I use a mixture of libraries in my programs that link to QuickCheck 1 and QuickCheck 2, and this works just fine. This works fine as long as no detail of the embedded library leaks into the public API. QuickCheck is typically the least painful library to mix, since you don't typically use the quickcheck properties from multiple quickcheck versions drawn from other packages at runtime. The only problem I've had is with cabal, which when resolving dependencies seems to only be able to pick out one version of a package; in some cases instead of running cabal install A B where A and B depended on different versions of the same package (QuickCheck) I had to instead separately run cabal install A and cabal install B. This isn't a big deal, but I could imagine cases where it could fail to automatically install a package entirely due to conflicting version requirements. This, however, is not because there is an intrinsic problem with installing multiple versions of a library, but simply because cabal sometimes seems to get confused about what it needs to do. cabal is the only mechanism that the vast majority of Haskell-users know how to use these days. Resolving diamond dependencies safely relies on knowing tha tthe use of different libraries is entirely internal to the library in question -- a detail that is not currently exposed through the cabal file. You can use PackageImports to try and hack around common package names at least in GHC, but it then further confuses purpose and provenance. So in short, I see no problem with there being multiple versions of a package floating around, and to the extent that an implementation of something can't handle this it seems like this is arguably a bug in that implementation rather than a bug in the package system for allowing the possibility. There are multiple potential implementation semantics that can be assigned to a diamond dependency. The types could be incompatible. They could be compatible, and the most recent version should be used by all (in case of minor API changes). They could be somewhere in between. I suppose where we differ is in how big of a concern we view 'just cabal having a problem with it' is. All I can say is that every time there has been a major API change where half the community hasn't moved, it has been a practical problem. It become yet another implementation detail that every subsequent developer has needed to consider, and providing support and instances for both is impractical. So while in theory, just bumping the major version number would be sufficient, in practice, I think picking a new package name and namespace would: * fit more closely with the spirit of a ground-up redesign * allow it to succeed or fail on its own merits * avoid torturing new users with cabal install warnings they won't understand * allow libraries that want or need to be agnostic with respect to the change the ability to provide instances for both libraries, providing a smoother upgrade path for their users. Which in the end, seems to be a net positive over: * requiring folks to use one version of fgl entirely internally without exposing it through their API or splinter their user base * causing cabal to panic * ultimately adding yet another hack to the hackage config which indicates implied upper bounds on the stable version of the package, since the current fgl is part of the haskell platform and the new design will not be stable for some time If fgl wasn't part of the haskell platform or the changes were less radical, the balance of net good might go the other way. -Edward Kmett ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] FastCGI, new maintainer
I'm the new maintainer of the FastCGI package[1]. Please upgrade to the latest version, 3001.0.2.3. It includes a fix for a special but real case in which the library throws an exception when the httpd server unexpectedly closes the connection[2], and the base version and exceptions have been upgraded to the latest versions.[3] Any problems, get in touch, or post an issue on this github project: http://github.com/chrisdone/fastcgi If you have patches preferably fork the fastcgi project on github and do a Pull request. Alternatively just send me a diff. Cheers [1]: http://hackage.haskell.org/package/fastcgi [2]: http://github.com/chrisdone/fastcgi/commit/de8d303b30dec097a1d24a8991da85d331871a96 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
On 6/23/10 2:13 PM, Edward Kmett wrote: On Tue, Jun 22, 2010 at 4:54 PM, Gregory Crosswhite gcr...@phys.washington.edu mailto:gcr...@phys.washington.edu wrote: There is no reason that your program couldn't link to multiple versions of the same package so that each library can access the version that it needs. In fact, GHC already does this, doesn't it? For example, I use a mixture of libraries in my programs that link to QuickCheck 1 and QuickCheck 2, and this works just fine. This works fine as long as no detail of the embedded library leaks into the public API. QuickCheck is typically the least painful library to mix, since you don't typically use the quickcheck properties from multiple quickcheck versions drawn from other packages at runtime. Yes, but if details of the package you are using are leaking out into the interface then you will have the same kind of problems whenever that package conflicts with any other package, regardless of whether the conflict is with a package of the same name. For example, for a while there was a conflict between mtl and transformers because they shared a package name, and the fact that the two packages had different names didn't make the problem any better. The only problem I've had is with cabal, which when resolving dependencies seems to only be able to pick out one version of a package; in some cases instead of running cabal install A B where A and B depended on different versions of the same package (QuickCheck) I had to instead separately run cabal install A and cabal install B. This isn't a big deal, but I could imagine cases where it could fail to automatically install a package entirely due to conflicting version requirements. This, however, is not because there is an intrinsic problem with installing multiple versions of a library, but simply because cabal sometimes seems to get confused about what it needs to do. cabal is the only mechanism that the vast majority of Haskell-users know how to use these days. Resolving diamond dependencies safely relies on knowing tha tthe use of different libraries is entirely internal to the library in question -- a detail that is not currently exposed through the cabal file. You can use PackageImports to try and hack around common package names at least in GHC, but it then further confuses purpose and provenance. But cabal can see with exactly which packages each of the dependencies requires, right? So what is stopping it from just walking through the dependencies and constructing the dependency graph? It should have all of the information it needs to do this. To the extent that the full information that cabal needs exists and yet it is not capable of recognizing this, I would view this as a bug in cabal that we should fix, rather than deciding just to live with this bug and limiting ourselves to a subset of the package dependency functionality. So in short, I see no problem with there being multiple versions of a package floating around, and to the extent that an implementation of something can't handle this it seems like this is arguably a bug in that implementation rather than a bug in the package system for allowing the possibility. There are multiple potential implementation semantics that can be assigned to a diamond dependency. The types could be incompatible. They could be compatible, and the most recent version should be used by all (in case of minor API changes). They could be somewhere in between. Yes, but again this will happen whenever you use two packages that conflict, regardless of whether they just happen to have the same name or not, as it did for a while with mtl and transformers. Renaming fgl to newfgl won't actually make this situation any better. I suppose where we differ is in how big of a concern we view 'just cabal having a problem with it' is. All I can say is that every time there has been a major API change where half the community hasn't moved, it has been a practical problem. It become yet another implementation detail that every subsequent developer has needed to consider, and providing support and instances for both is impractical. My point isn't that it is not a big deal that cabal has a problem with it, it is that this is something that we should fix *in cabal* since there is nothing intrinsically intractable about it. Furthermore, the kinds of problems that people encounter in such transitions won't be fixed merely by changing the name of the package since conflicts can still appear with the old package. If we really are worried so much about these kinds of conflicts, then the real solution is to make sure that none of the modules exported by the new package share the same name as the modules in the old package. And if one is going to do that anyway, then from the perspective of resolving conflicts there isn't any additional
[Haskell-cafe] In other words is there a good place to post stuff like the following?
-- Algorithms From: Selected Papers on Design of Algorithms, Donald Knuth, 2010 -- Chapter 10 Addition Machines -- Haskell version by Casey Hawthorne -- Note this is only a skeleton of the chapter, -- so as to wet your interest to buy the book. -- Addition Machine -- The only operations allowed are the following: -- read x -- x - y -- x - x + y -- x - x - y -- if x = y -- write x -- Can all functional versions be tail recursive? --- --- -- Modulus -- Assuming without loss of generality x=0 and y0, -- since one can use various identities for other cases. -- Performs floor(x/y) subtractions. modulusNaive x y | x = y= modulusNaive (x-y) y | otherwise = x -- Can we do better? -- Uses a doubling procedure to subtract larger multiplies of y. -- Bounded by O(log(x/y))^2 modulusByDoubling x y | x = y= helper y y | otherwise = x where helper w z | x z = helper z z+z | otherwise = modulusByDoubling (x-w) y -- Can we do better? -- Want bounded by O(log(x/y)). -- Addition Machine, so cannot divide by 2. -- Implicitly use the Fibonacci representation of floor(x/y) -- instead of its the binary representation. -- F0 = 0; F1 = 1; Fn = F(n-1) + F(n-2), n =2 -- Every nonnegative integer n can be uniquely represented in the form -- n = F(m1) + F(m2) + ... + F(mt), m1 m2 ... mt 0 -- where t = 0 and m m' means that m - m' = 2 -- If n 0 this representation can be found by choosing m1 such that -- F(m1) = n F(m1+1) --- -- Furthermore Fibonacci numbers grow exponentially, -- about 69% as fast as powers of 2. -- They have been used as power-of-2 analogs in a variety of algorithms. --- modulusFib x y | x = y= helper x y y | otherwise = x where helper x y z | x z = helper x z y+z | otherwise = helper2 x y z helper2 x y z | x = y= helper2 (x-y) y z | y z = helper2 x (z-y) y | otherwise = x ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] In other words is there a good place to post stuff like the following?
-- Algorithms From: Selected Papers on Design of Algorithms, Donald Knuth, 2010 -- Chapter 10 Addition Machines -- Haskell version by Casey Hawthorne -- Note this is only a skeleton of the chapter, -- so as to wet your interest to buy the book. -- Addition Machine -- The only operations allowed are the following: -- read x -- x - y -- x - x + y -- x - x - y -- if x = y -- write x -- Can all functional versions be tail recursive? --- --- -- Modulus -- Assuming without loss of generality x=0 and y0, -- since one can use various identities for other cases. -- Performs floor(x/y) subtractions. modulusNaive x y | x = y= modulusNaive (x-y) y | otherwise = x -- Can we do better? -- Uses a doubling procedure to subtract larger multiplies of y. -- Bounded by O(log(x/y))^2 modulusByDoubling x y | x = y= helper y y | otherwise = x where helper w z | x z = helper z z+z | otherwise = modulusByDoubling (x-w) y -- Can we do better? -- Want bounded by O(log(x/y)). -- Addition Machine, so cannot divide by 2. -- Implicitly use the Fibonacci representation of floor(x/y) -- instead of its the binary representation. -- F0 = 0; F1 = 1; Fn = F(n-1) + F(n-2), n =2 -- Every nonnegative integer n can be uniquely represented in the form -- n = F(m1) + F(m2) + ... + F(mt), m1 m2 ... mt 0 -- where t = 0 and m m' means that m - m' = 2 -- If n 0 this representation can be found by choosing m1 such that -- F(m1) = n F(m1+1) --- -- Furthermore Fibonacci numbers grow exponentially, -- about 69% as fast as powers of 2. -- They have been used as power-of-2 analogs in a variety of algorithms. --- modulusFib x y | x = y= helper x y y | otherwise = x where helper x y z | x z = helper x z y+z | otherwise = helper2 x y z helper2 x y z | x = y= helper2 (x-y) y z | y z = helper2 x (z-y) y | otherwise = x ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In other words is there a good place to post stuff like the following?
Hello! On Wed, Jun 23, 2010 at 2:19 PM, cas...@istar.ca wrote: -- Algorithms From: Selected Papers on Design of Algorithms, Donald Knuth, 2010 -- Chapter 10 Addition Machines -- Haskell version by Casey Hawthorne -- Note this is only a skeleton of the chapter, -- so as to wet your interest to buy the book. Why not the Haskell Wiki? That makes it pretty easy to contribute, no? Paulo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
On Wed, Jun 23, 2010 at 2:57 PM, Gregory Crosswhite gcr...@phys.washington.edu wrote: On 6/23/10 2:13 PM, Edward Kmett wrote: On Tue, Jun 22, 2010 at 4:54 PM, Gregory Crosswhite gcr...@phys.washington.edu wrote: There is no reason that your program couldn't link to multiple versions of the same package so that each library can access the version that it needs. In fact, GHC already does this, doesn't it? For example, I use a mixture of libraries in my programs that link to QuickCheck 1 and QuickCheck 2, and this works just fine. This works fine as long as no detail of the embedded library leaks into the public API. QuickCheck is typically the least painful library to mix, since you don't typically use the quickcheck properties from multiple quickcheck versions drawn from other packages at runtime. Yes, but if details of the package you are using are leaking out into the interface then you will have the same kind of problems whenever that package conflicts with any other package, regardless of whether the conflict is with a package of the same name. For example, for a while there was a conflict between mtl and transformers because they shared a package name, and the fact that the two packages had different names didn't make the problem any better. Yes, and that problem still isn't resolved in another since, since they share the same module names, but as of yet, still provide an incompatible API. I can't (yet) provide 'RightSemiNearRing' instances that work with both the monad transformers from transformers and mtl without deep mojo. The resolution there seems to be to bring transformers and mtl into close enough alignment that we'll be able to finally release a version of the mtl that just imports transformers and monads-fd, and provide a set of guidelines about the fact that in the switch to the next major version of mtl, the non-transformer versions of the monad-transformer stack are just type aliases. In that case the APIs are close enough that with a few breaking changes to existing users on each side, the APIs can be reconciled and the community unfractured. That said, we've had this plan waiting in the wings for months. ;) But cabal can see with exactly which packages each of the dependencies requires, right? So what is stopping it from just walking through the dependencies and constructing the dependency graph? It should have all of the information it needs to do this. This becomes somewhat tricky. You can do this more or less with data types and classes, but with instances it is less clear how to do so. Instances (necessarily) kind of silently infect your public interface, and so this form of reasoning is at best global, not local. There has been some chatter about splitting up build dependencies into internal and external dependencies, although I don't know how serious it was, but that would be a move in this direction. To the extent that the full information that cabal needs exists and yet it is not capable of recognizing this, I would view this as a bug in cabal that we should fix, rather than deciding just to live with this bug and limiting ourselves to a subset of the package dependency functionality. Regardless, it is unlikely to be fixed before Ivan goes to release his shiny new type-family-driven FGL. =) So in short, I see no problem with there being multiple versions of a package floating around, and to the extent that an implementation of something can't handle this it seems like this is arguably a bug in that implementation rather than a bug in the package system for allowing the possibility. There are multiple potential implementation semantics that can be assigned to a diamond dependency. The types could be incompatible. They could be compatible, and the most recent version should be used by all (in case of minor API changes). They could be somewhere in between. Yes, but again this will happen whenever you use two packages that conflict, regardless of whether they just happen to have the same name or not, as it did for a while with mtl and transformers. Renaming fgl to newfgl won't actually make this situation any better. [...] If we really are worried so much about these kinds of conflicts, then the real solution is to make sure that none of the modules exported by the new package share the same name as the modules in the old package. And if one is going to do that anyway, then from the perspective of resolving conflicts there isn't any additional benefit to also renaming the package. Actually, once you've given them different module names keeping the same package name _is_ an impediment. Because with different package names you could import both and provide instances for both, say, fgl's Graph, and for Ivan's very different type-family driven Graph, but you needlessly sacrifice that upgrade path for your users if you force both packages to have the same name. Another very different consideration is that
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
On 6/23/10 3:29 PM, Edward Kmett wrote: Yes, and that problem still isn't resolved in another since, since they share the same module names, but as of yet, still provide an incompatible API. I can't (yet) provide 'RightSemiNearRing' instances that work with both the monad transformers from transformers and mtl without deep mojo. The resolution there seems to be to bring transformers and mtl into close enough alignment that we'll be able to finally release a version of the mtl that just imports transformers and monads-fd, and provide a set of guidelines about the fact that in the switch to the next major version of mtl, the non-transformer versions of the monad-transformer stack are just type aliases. In that case the APIs are close enough that with a few breaking changes to existing users on each side, the APIs can be reconciled and the community unfractured. That said, we've had this plan waiting in the wings for months. ;) Oh, cool, so that's the plan? Grr, if I had fewer projects I would volunteer to help out with this. :-) But cabal can see with exactly which packages each of the dependencies requires, right? So what is stopping it from just walking through the dependencies and constructing the dependency graph? It should have all of the information it needs to do this. This becomes somewhat tricky. You can do this more or less with data types and classes, but with instances it is less clear how to do so. Instances (necessarily) kind of silently infect your public interface, and so this form of reasoning is at best global, not local. There has been some chatter about splitting up build dependencies into internal and external dependencies, although I don't know how serious it was, but that would be a move in this direction. But does cabal even need to do an analysis that is that sophisticated? All it needs to see are the package dependencies in order to note that, Oh, this package requires version X, and this package requires version Y, so therefore I need to install both! rather than saying, Hold on, these two packages require *different versions* of the same package? I give up! And conflicts between instances and things need to be taken care of before the package can even be built, let alone uploaded to Hackage. So while I agree that these are problems, they are not really cabal's problem to worry about since by the time cabal has been brought into the picture they must have already been resolved. To the extent that the full information that cabal needs exists and yet it is not capable of recognizing this, I would view this as a bug in cabal that we should fix, rather than deciding just to live with this bug and limiting ourselves to a subset of the package dependency functionality. Regardless, it is unlikely to be fixed before Ivan goes to release his shiny new type-family-driven FGL. =) Fair point. :-) So in short, I see no problem with there being multiple versions of a package floating around, and to the extent that an implementation of something can't handle this it seems like this is arguably a bug in that implementation rather than a bug in the package system for allowing the possibility. There are multiple potential implementation semantics that can be assigned to a diamond dependency. The types could be incompatible. They could be compatible, and the most recent version should be used by all (in case of minor API changes). They could be somewhere in between. Yes, but again this will happen whenever you use two packages that conflict, regardless of whether they just happen to have the same name or not, as it did for a while with mtl and transformers. Renaming fgl to newfgl won't actually make this situation any better. [...] If we really are worried so much about these kinds of conflicts, then the real solution is to make sure that none of the modules exported by the new package share the same name as the modules in the old package. And if one is going to do that anyway, then from the perspective of resolving conflicts there isn't any additional benefit to also renaming the package. Actually, once you've given them different module names keeping the same package name _is_ an impediment. Because with different package names you could import both and provide instances for both, say, fgl's Graph, and for Ivan's very different type-family driven Graph, but you needlessly sacrifice that upgrade path for your users if you force both packages to have the same name. Okay, so the assumption is that although dependencies could use different versions of a package with the same name, when you yourself use a package you can only use one particular version of the package. Given this assumption I see your point, though perhaps it would be a good idea to allow package imports to also allow
Re: [Haskell-cafe] Haskell Weekly News?
Yah, this is gonna sound like a crappy thing -- but my computer is still broken. What I thought was a faulty SATA port seems to actually be an issue with the harddrive, so -- one more week is the punchline. I'm really sorry guys... /Joe On Jun 23, 2010, at 10:13 AM, aditya siram wrote: Neat. Thanks! -deech On Wed, Jun 23, 2010 at 10:06 AM, Vo Minh Thu not...@gmail.com wrote: 2010/6/23 aditya siram aditya.si...@gmail.com: I haven't seen HWN in a while. If there is still community interest, how can we help you with this? It will come back, see this thread: http://www.reddit.com/r/haskell/comments/cdw38/hwn_it_will_be_back_promise/ Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] CnC Haskell
Hello, I have been reading work done at Rice University: http://habanero.rice.edu/cnc. Some work has been done by http://www.cs.rice.edu/~dmp4866/ on CnC for .Net. One component that David wrote a CnC translator that translates CnC textual form to the underlying language, e.g. F#. Is anybody working on a CnC textual form translator for Haskell so a Haskell user of CnC Haskell can write in a higher level?? Thanks, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] CnC Haskell
vigalchin: Hello, I have been reading work done at Rice University: http:// habanero.rice.edu/cnc. Some work has been done by http://www.cs.rice.edu/ ~dmp4866/ on CnC for .Net. One component that David wrote a CnC translator that translates CnC textual form to the underlying language, e.g. F#. Is anybody working on a CnC textual form translator for Haskell so a Haskell user of CnC Haskell can write in a higher level?? Ah, so a translator from high level CnC form to this: http://hackage.haskell.org/packages/archive/haskell-cnc/latest/doc/html/Intel-Cnc.html ? Do you have a reference for the CnC textual form? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Huffman Codes in Haskell
On Wed, Jun 23, 2010 at 11:50 AM, Daniel Lyons fus...@storytotell.org wrote: On Wed, Jun 23, 2010 at 05:41:17PM +0100, John Lato wrote: If this answer did work, I don't think the question would be interesting. We don't have to be mean. - Buckaroo Banzai. I certainly didn't want to upset anyone, and I'm sorry if I did. After all, I did say that was my first attempt too. I just meant that the reason the given solution doesn't work is exactly what leads to a more involved approach. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] When the unknown is unknown
Hello all, I am currently playing with Paul Hudak's Euterpea (a music program, formely called Haskore) and I am trying to teach it about rhythm. I said that a rhythm is a series of Moments (or Beats), each expressed as fractions of a bar. But each Moment also has volume. So I could model rhythm as Pairs of (Moment, Volume). However I certanly do not want to specify both the Moments and the Volume, but rather compute one from the other. Often the Moments are known and I need to compute the Volumes, but this is not always the case. I might as well start with the volume and compute the moments. The latter would be particularly interesting when trying to find rhythms which are suitable for certain lyrics. In that case I must even be prepared to find more than one series-of-moments which fit to the given series-of-volumes. There are countless other problems like this, e.g. when trying to match harmony, melody and tension. In that case I even have three variables and I may want to specify tension first, then melody and have the harmony computed. At first glance this looks like a Prolog-like problem to me. I could say that certain things are always true for [(Moment, Volume)] and let an inference engine figure out the options which are still in consideration. From which angle would you approach problems like this? Should I get my hands on a prolog-in-haskel implementation (which indeed seems to exist)? Or should I roll my own poor-man's prolog? Or is this a constraint-satisfaction-problem? Or is there even a more straight-forward more haskellish pattern, which solves such problems? Any pointers would be much appreciated. -- Martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] CnC Haskell
On Wed, Jun 23, 2010 at 3:47 PM, Don Stewart d...@galois.com wrote: vigalchin: Hello, I have been reading work done at Rice University: http:// habanero.rice.edu/cnc. Some work has been done by http://www.cs.rice.edu/ ~dmp4866/ on CnC for .Net. One component that David wrote a CnC translator that translates CnC textual form to the underlying language, e.g. F#. Is anybody working on a CnC textual form translator for Haskell so a Haskell user of CnC Haskell can write in a higher level?? Ah, so by a translator from high level CnC form to this: http://hackage.haskell.org/packages/archive/haskell-cnc/latest/doc/hml/Intel-Cnc.htmlhttp://hackage.haskell.org/packages/archive/haskell-cnc/latest/doc/html/Intel-Cnc.html ^^ exactly what I mean ? Do you have a reference for the CnC textual form? ^^ if you mean something like a context-free grammatical definition of the CnC textual form ,,, the answer is I haven't seen such a reference. V. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Accounting Engine in Haskell
On 15/06/10 09:08, Amiruddin Nagri wrote: I wanted some insight as to how Haskell is going to help me with my project. Also there has been some concerns because of lazy evaluation in Haskell and memory leaks associated with it. http://jlouisramblings.blogspot.com/2010/04/haskell-vs-erlang-for-bittorent-clients.html In this talk: http://www.galois.com/blog/2009/04/27/engineering-large-projects-in-haskell-a-decade-of-fp-at-galois/ Don Stewart says that memory leaks are a tractable problem. Just profile and look for the retainers. Lazy evaluation is a big win for large projects because it lets you modularise your solution; one function generates a data structure, and another function (or several) consume it. If the data structure is big or infinite then conventional languages force you to either interleave the generator and consumer, or else jump through lots of hoops re-inventing lazy evaluation on a case-by-case basis. With Haskell you just say what you mean and let the compiler worry about implementing it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Huffman Codes in Haskell
This seems like an example of list-chauvinism -- what Chris Okasaki calls a communal blind spot of the FP community in Breadth-First Numbering: Lessons from a Small Exercise in Algorithm Design -- http://www.eecs.usma.edu/webs/people/okasaki/icfp00.ps Thanks for sharing; this was an interesting (and short!) read. I would like to see other Haskeller's responses to this problem. .. How would you implement bfnum? (If you've already read the paper, what was your first answer?) That paper is indeed a useful read, provided one does try to solve the puzzle as well as carefully check any imagined solutions. I happened on it when I was working on the first GHood prototype, so my struggles happen to be documented (together with the popular foldl vs foldl' strictness) in the GHood paper and online examples: http://community.haskell.org/~claus/GHood/ The observation tool and problem turned out to be well suited for each other: by observing both the input and the result tree, one can see how traversal of the result tree drives evaluation of the input tree (or not, if one gets the strictness wrong;-). You might find this useful when testing your solutions or trying to get an intuition about dynamic strictness. Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] When the unknown is unknown
On Jun 23, 2010, at 1:50 PM, Martin Drautzburg wrote: I said that a rhythm is a series of Moments (or Beats), each expressed as fractions of a bar. But each Moment also has volume. So I could model rhythm as Pairs of (Moment, Volume). However I certanly do not want to specify both the Moments and the Volume, but rather compute one from the other. How about something like: type RhythmScheme = [(Maybe Moment, Maybe Volume)] type Rhythm = [(Moment, Volume)] -- The resolution function will then be a function with type: rhythm_from_scheme :: RhythmScheme - Rhythm -- Though you might want something like -- rhythm_from_scheme :: RhythmScheme - IO Rhythm -- or -- rhythm_from_scheme :: Seed - RhythmScheme - Rhythm -- so that you can get and use random numbers, for example. I guess the point of my suggestion is to let pattern matching in function definitions deal with unification of constraints. Beta reduction and unification are two sides of a coin.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
Edward Kmett ekm...@gmail.com writes: One much weaker consideration is that out of the 23+ direct dependencies on fgl, fully half of them don't bother to specify an upper bound on the fgl version and would break immediately. That said, those packages are out of compliance with package versioning policy. =) I've contacted all the maintainers of those packages, and have received replies from all but two maintainers promising to fix theirs (still haven't heard from Aditya Mahajan for teams and John Morrice for esotericbot). Note that I'm just as guilty in this regard as I have three packages that depend on fgl without upper bounds... _ I don't know how many of them have released fixed versions yet (I know I haven't), but with the whole two versions of FGL needed thing: we're going to work hard to help maintainers of packages that use FGL to upgrade to the new version once we're satisfied with it and decide to make the release official. As such, we shouldn't have any problems of packages depending transitively on two versions of FGL because most if not all of them will get upgraded. With FGL, we also have the situation where we have a famous library that isn't actually used much: * Out of those 23 direct dependencies on Hackage, 3 of them were by old versions of packages (i.e. they no longer use fgl); these are mpc, jhc and lhc. * One is officially deprecated (scenegraph). * 10 are pure libraries (note that some of these have no reverse dependencies, or if they do it's only by a few packages) (note that I included a package here if its executable seemed to only be for tests). * 6 are executables only. * 3 seem to be a library + an executable; only one of these has a reverse dependency and even then by one other package. Out of the 25 indirect reverse dependencies: * 20 (some of which are older versions only and thus not the latest) may transitively depend upon the old version of mps (either directly or via the hack library); because the dependencies on mps, etc. are open-ended for many of these it's difficult to tell if a new install will still transitively require fgl (as in to actually get it to work). * 1 dependency on cabal-macosx * 2 dependencies on lambdacube-engine (other lambdacube projects) * 2 satchmo projects depending (transitively in one case) upon funsat. As such, if we only consider transitive dependencies, then this issue of one package using new and another old fgl is a non-issue as in all cases as there's only a single point of contact with fgl. From what I can tell, fgl is more often used for internal projects or executables rather than to create actual libraries. So the whole problem of worrying about multiple versions appears to be (no offense to anyone) scare-mongering (or looking for possible problems due to bad experiences with parsec, etc.). With the 4 transitive dependencies on fgl above, I'm not sure how many of them actually see any aspects of fgl or if its all hidden inside the internal API of whatever package they use. Thus, once packages have proper reverse dependencies in their .cabal files (as they should), then we should not really have a problem here if a few packages don't upgrade at the same time or at all (except for cases where a distribution only ships one version of each library and wants to ship two different packages that depend upon different versions of fgl). Once again: we're going to do our very best to avoid the issues that arose when parsec, QuickCheck, etc. had new major versions released and packages transitively depended upon two different versions; however if it does arise then it's going to be a very small localised problem. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] offtopic - installing archlinux as a domU
I know some haskell people out there have done what I am trying to do, and I hope you can help me out. I've got access to a debian server which is running a Xen Hypervisor 3.0.3 I believe. I would like to install archlinux as a paravirtual machine (or HVM if I must) in order to get a more supportive haskell environment than my current OS. Could someone point me to some updated documentation on this process? Much thanks. Michael Litchard ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: bitspeak 0.0.1
On Jun 22, 2010, at 1:26 PM, Maurí cio CA wrote: Sure, Huffman was actually my first tought. But I couldn't think of a pratical display for the result of Huffman encoding that could be easily followed by a human looking at the screen. Since it's an optimal code, letters would not be grouped in alphabetical order. There is a compromise. There is such a thing as an ORDERED Huffman code. Consider a set of strings. If they call begin with the same first letter, assume that letter and consider the suffixes instead. Otherwise, choose a letter L such that as close as possible to half of the strings begin with a letter preceding L in the alphabet as close as possible to half of the strings begin with the letter L or a later letter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Accounting Engine in Haskell
On Wed, Jun 23, 2010 at 2:30 PM, Paul Johnson p...@cogito.org.uk wrote: On 15/06/10 09:08, Amiruddin Nagri wrote: I wanted some insight as to how Haskell is going to help me with my project. Also there has been some concerns because of lazy evaluation in Haskell and memory leaks associated with it. http://jlouisramblings.blogspot.com/2010/04/haskell-vs-erlang-for-bittorent-clients.html In this talk: http://www.galois.com/blog/2009/04/27/engineering-large-projects-in-haskell-a-decade-of-fp-at-galois/ Don Stewart says that memory leaks are a tractable problem. Just profile and look for the retainers. Lazy evaluation is a big win for large projects because it lets you modularise your solution; one function generates a data structure, and another function (or several) consume it. If the data structure is big or infinite then conventional languages force you to either interleave the generator and consumer, or else jump through lots of hoops re-inventing lazy evaluation on a case-by-case basis. With Haskell you just say what you mean and let the compiler worry about implementing it. I think there are times when, in Haskell, you end up jumping through hoops to get specific performance characteristics (iteratees for example), but it appears to be the exception. Usually evaluation on demand gives you what you want and typically adding strictness in a few places fixes any leakiness. So, while Haskell is not perfect it gives you what you want more often than not. This translate directly into productivity gains. It also means that programmers tend to be happier using Haskell as they are fighting the notation less. Happy and productive is a win, even if you have to have a period of optimization at the end of the release cycle. I'd rather optimize correct code than start with a fast buggy version. I think at this point, the biggest weakness is that the tools for ensuring properties about space and time usage are far less mature than our tools for ensuring correctness. How would you formally specify your space or other performance needs? On the other hand, our profiling tools are quite good (ghc heap profiler, threadscope, criterion, etc) so as Don says, the problem is tractable. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
On 23 June 2010 19:57, Gregory Crosswhite gcr...@phys.washington.edu wrote: cabal is the only mechanism that the vast majority of Haskell-users know how to use these days. Resolving diamond dependencies safely relies on knowing tha tthe use of different libraries is entirely internal to the library in question -- a detail that is not currently exposed through the cabal file. You can use PackageImports to try and hack around common package names at least in GHC, but it then further confuses purpose and provenance. But cabal can see with exactly which packages each of the dependencies requires, right? So what is stopping it from just walking through the dependencies and constructing the dependency graph? It should have all of the information it needs to do this. To the extent that the full information that cabal needs exists and yet it is not capable of recognizing this, I would view this as a bug in cabal that we should fix, rather than deciding just to live with this bug and limiting ourselves to a subset of the package dependency functionality. Actually cabal-install does not have enough information to distinguish when the diamond dependencies are definitely safe and where they might be unsafe. Consider an example where we want to avoid using two versions of a dependency: The htar program depends on the tar and zlib packages. The tar and zlib packages depend on bytestring. Both tar and zlib export functions that use the type ByteString. The htar program takes composes functions from the two packages together, passing a bytestring from one to the other. In this situation it is essential that the tar and zlib packages share exactly the same version of the bytestring package. If they do not then we will get a type error when compiling the htar program. Now another example where using two versions of a dependency would be ok: Suppose the tar and zlib packages have QC tests in the library but they are not exported. It would be fine to have the two using different versions of the QC package, they could not interfere because no types from QC are passed between the two packages. However, as far as Cabal is concerned these two situations are indistinguishable. Cabal does not have enough information to tell them apart. It does not know that the QC deps are private, it must assume the worst. If it did know that some deps were private then in principle we could do better. In the medium term I would like to see private dependencies added to the .cabal package description and to have that used by cabal-install (it'd also have to be enforced). In the mean time, I suggest continuing to make new major versions of packages as normal. The tools will eventually catch up. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Network of GUI Controls - using MonadFix?
Hello list, let's say I would like to create 4 buttons where any one button can respond to a click and notify every other button. Ie. where the 1st button is wired with the 2nd, the 2nd with the 3rd ... and the 4th button with the 1st. In short I would like these buttons to be connected as in a cyclic list. Is that something that MonadFix is meant to be used for? Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Network of GUI Controls - using MonadFix?
On Thu, Jun 24, 2010 at 02:35:55AM +0200, Günther Schmidt wrote: Is that something that MonadFix is meant to be used for? In current Gtk libraries, no. You'll do something like do btns - mapM createBtn [1..4] mapM_ connect $ zip btns (tail $ cycle btns) However, if some library required you to supply the action while constructing the button, then I guess the answer would be yes. Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
On 6/23/10 8:06 PM, Duncan Coutts wrote: Consider an example where we want to avoid using two versions of a dependency: The htar program depends on the tar and zlib packages. The tar and zlib packages depend on bytestring. Both tar and zlib export functions that use the type ByteString. The htar program takes composes functions from the two packages together, passing a bytestring from one to the other. Okay, I hadn't considered this, though it seems like the real problem in this situation is that someone violated the package version policy: if tar is upgraded to use a newer, incompatible version of bytestring, then it should have an appropriate version bump that causes htar to ignore the new version and use the older version instead. I am getting the impression from these discussions that what we really need in the long term to solve a lot of these problems is to enforce the package versioning policy. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
On Wed, 2010-06-23 at 21:05 -0400, Gregory Crosswhite wrote: On 6/23/10 8:06 PM, Duncan Coutts wrote: Consider an example where we want to avoid using two versions of a dependency: The htar program depends on the tar and zlib packages. The tar and zlib packages depend on bytestring. Both tar and zlib export functions that use the type ByteString. The htar program takes composes functions from the two packages together, passing a bytestring from one to the other. Okay, I hadn't considered this, though it seems like the real problem in this situation is that someone violated the package version policy: if tar is upgraded to use a newer, incompatible version of bytestring, then it should have an appropriate version bump that causes htar to ignore the new version and use the older version instead. It's nothing to do with a version policy. Letting people opt-in and then enforcing a package versioning policy would be great, but it is orthogonal to this problem. Suppose both the zlib and tar packages specify build-depends: bytestring-0.9.*. It's entirely possible for me to install zlib, then upgrade to a new bugfix release of bytestring, install tar (using the new bytestring) and then build htar depending on tar+zlib. In this case none of the developers of these packages have done anything wrong. It is situations like this that cabal-install tries to avoid. You could construct similar examples involving major versions rather than bugfix versions. All you need is for someone to have tested with two major versions and to mark their package as being able to work with either. I think what you mean is that cabal-install should infer from the situation where package A needs 'C 2' and package B needs 'C = 2' that it is safe for a package to depend on both A and B and to be built indirectly depending on two versions of C. The fact that people can and often do make packages that work with either C 1 or 2 makes this situation less common. Also, it's not necessarily true, perhaps all it means is that the latest version of B now needs a later C and so my package now cannot use that later version of C because it did indeed pass values of types defined in C between functions defined in A and B (that is, my package has been busted by the latest release of B). Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: bitspeak 0.0.1
Sure, Huffman was actually my first tought. But I couldn't think of a pratical display for the result of Huffman encoding that could be easily followed by a human looking at the screen. Since it's an optimal code, letters would not be grouped in alphabetical order. There is a compromise. There is such a thing as an ORDERED Huffman code. Consider a set of strings. If they call begin with the same first letter, assume that letter and consider the suffixes instead. Otherwise, choose a letter L such that as close as possible to half of the strings begin with a letter preceding L in the alphabet as close as possible to half of the strings begin with the letter L or a later letter. I believe that's what I've done. I use this file to give weight to letters: http://bitbucket.org/mauricio/bitspeak/src/tip/src/Corpora.hs After each letter is selected I keep only sufixes after that letter, and then I use 'splitData' to find the point where I'll separate both halves: http://bitbucket.org/mauricio/bitspeak/src/tip/src/Main.hs Best, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Relating generated asm to Core
Hi Rami, You'll want to first look at the Cmm (C minus minus) code, which is the imperative intermediate language that GHC uses before conversion to assembly. Do something like ghc -c Whatever.hs -ddump-cmm. The names of the blocks of cmm code should match the ones in core. If not, then you might want to also look at the output of -ddump-stg. Keep in mind that the assembly output by GHC will not look like that output by, say, GCC, because of the lazy evaluation method. You'll want to try and ignore the vast swathes thunking code and just focus on the inner loops of your particular algorithm. Ben. On 23/06/2010, at 1:35 PM, Rami Mukhtar wrote: Hi, Can anyone tell me a way to identify the generated assembly (as found in the intermediate files produced by GHC) corresponding to a particular fragment of Core code. Thanks, Rami The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments. ___ 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
