First of all, sorry if the english is not that clear, it's not my first language. Hey guys, I'm pretty new to haskell and so far I love it! I got a couple of easy classes that I'm using my algorithm analysis class to practice a little Haskell and it's working out fine. The issue i'm having now is I don't know how to time my programs runtime. Just have to measure the time it takes for mergesort, insertionsort and selectionsort to get the answer for x items.
How can I get that value in HS?submitted by Gran-Tizoc
[link] [7 comments]
For each package, create a list of all the other packages it imports, the functions, types etc. that it imports from those packages, and their types. Also a list of all the functions etc. the package itself exports, and their types.
Then, if package foo exports function qux with type int -> bool, and package bar imports foo.qux, expecting it to have type int -> IO bool, running cabal install foo bar fails with an error "the function qux defined in package foo doesn't match that expected by package bar". As opposed to downloading both, compiling foo, beginning to compile bar, then failing with a type error.submitted by logicchains
[link] [9 comments]
When I try to install wxcore in a sandbox I get this error http://lpaste.net/115319 Can someone help me?submitted by nocte_aeterna
[link] [1 comment]
I've been coding in Haskell for about 4 years now, and I'm realizing that perhaps I've fallen into a rut with the way I debug my programs. After hoping and failing to learn better methods I eventually fell into a pattern of just importing a library of self rolled trace functions.
In an effort to grow and maybe code faster, I'm hoping to start a discussion here about how you actually debug your programs.
The most common functions I use are:-- m stands for message, x is the value, f is a utility function -- tr is like trace but includes the value of what's being evaluated tr m x = trace (m++":"++show x) x trWith f m x = trace (m++":"++show (f x)) x -- tc shows a trace before and after the value is evaluated -- helpful for tracking down infinite recursion. tc m x = trace (m++"-->") $ trace ("-->"++m++" "++(show x)) x tcWith f m x = trace (m ++"-->") $ trace ("-->"++m++" "++show (f x)) x
I have some others that work inside specific monads and etc. I've even gone so far as to colorize certain data structure traversals using the System.Console.ANSI module.
I find that the deeper the program logic is inside abstractions the more difficult and befuddling it can be to debug.
I'm curious about what methods folks use to hunt and prevent bugs on a daily basis?submitted by biglambda
[link] [56 comments]
I wrote a small utility that displays project structure visually (think tree mixed with ag) and I'd appreciate criticism. https://github.com/hakujin/leaves
Known deficiencies are very crude parsing of .gitignore/.hginore files and that the Tree filesystem structure is built fully in memory before being rendered to the screen. Profiling shows reasonable performance on average with the degenerate case being a large number of top-level ignore patterns with deep subtrees (git clone https://github.com/Valloric/YouCompleteMe; cd YouCompleteMe; git submodule init --recursive; leaves); regex-tdfa matching occupies the overwhelming majority of time. ag handles this worst-case situation with more grace so there is clearly room for improvement.
I want to continue learning and welcome any commentary (including more appropriate venues for criticism). Thanks in advance.submitted by hakujin_
An important aspect of studying evolution is the construction of phylogenetic trees, graphically representing the relationship between current and historic species. These trees are usually calculated based on similarities and differences between genetic material of current species, and one particular challenge is that the topology of the resulting trees depend on the selection of genes used to construct them. Quite often, the species tree based on one set of genes differ substantially from the tree based on another set of genes.
The phylogenetic tree is usually presented as a simple tree of species. The end points of brances at the bottom of the tree (leaves) represent current species, and branching points higher up (internal nodes) represent the most recent common ancestor, or MRCA, for the species below it.
A very simple example could look something like this:
Here you have two current species, and you can trace back their lineage to a MRCA, and further back to some ancient origin. Varying colors indicate that gradual change along the branches has introduced differences, and that the current species now have diverged from each other, and their origin.
This representation has the advantage of being nice and simple, and the disadvantage of being misleading. For instance, one might get the impression that a species is a well-defined concept, and ask questions like: when the first member of a species diverged from its ancestor species, how did it find a mate?Species are populations
But we are talking about species here - that is, not individuals but populations of individuals. So a more accurate representation might look like this:
Circles now represent individuals, and it should perhaps be clearer that there is no such thing as the “first” of anything. At the separation point, there is no difference between the two populations, and it is only after a long period of separation that differences can arise. (Of course, if there are selective pressure favoring specific properties - perhaps redness is very disadvantageous for species B, for instance - this change will be much quicker. Look at how quickly we have gotten very different breeds of dogs by keeping populations artificially separate, and selecting for specific properties.)
The so-called “speciation” is nothing more than a population being split into two separate parts. Typically, this can be geographically - a few animals being carried to Madagascar on pieces of driftwood - but anything that prevents members of one branch from mating with members of the other one will suffice. At he outset, the two branches are just indistinguishable subpopulations of the same species, but if the process goes on long enough, differences between the two populations can become large enough that they can no longer interbreed, and we can consider them different species.
In practice, such a separation is often not complete, some individuals can stray between the groups. In that case, speciation is less likely to happen, since the property of being unable to breed with the other group represents a reproductive disadvantage, and it would therefore be selected against. In other words, if your neighbor is able to have children with more members of the population than you, his chances of having children are better than yours. Your genes get the short end of the stick. Kind of obvious, no?Populations consist of genes
But we can also view evolution as working on populations, not of individuals, but of individual genes. This is illustrated in the next picture:
The colored circles now represent genes, and an individual is here just a sample from the population of genes - illustrated by circling three gene circles. (Note that by “gene”, we here mean an abstract unit of inheritance. In other fields of biology, the word might be synonymous with a genetic region that codes for a protein, or is transcribed to (possibly non-coding) RNA.)
Here, we see that although the genes themselves do not change (in reality they are subject to mutations), the availability of the different genes vary over time, and some might disappear from one of the branches entirely - like red genes from species B here. This kind of genetic drift can still cause distinct changes in individuals.Ancestry of individual genes
Each individual typically gets half its genes from each parent, one fourth from each grandparent, and so on, so after a few generations, all genes come from essentially different ancestors. This means you can calculate the MRCA for each gene individually, and this is exactly what has been done to estimate the age our “mitochondrial Eve” and “Y-chromosomal Adam”. Here is the example lineage for the green gene:
We see that the green-gene MRCA is much older than the speciation event. In addition, each gene has its unique history. This means that when we try to compute the MRCA, different genes will give different answers, and it can be difficult to construct a sensible consensus.
For example, bits of our genome appear to come from the Neanderthal, and those bits will have a MRCA that predates the time point where Neanderthal branched from H. sapiens (possibly 1-2 million years ago). (Interestingly, “Adam” and “Eve” are both estimated to have lived in the neighborhood of 200000 years ago. This means that although 20% of the Neanderthal genome is claimed to have survived, all Neanderthal mitochondria and Y-chromosomes have been eradicated.)
There have been many debates recently about fundamentally changing the Prelude. I am going to ignore all specifics and simply ask the following question: why don't we support multiple Preludes? Of course not for everyday switching, but for forward compatibility and project-wide semantic stuff. I'm thinking the new standard practice would be to add a "no implicit prelude" pragma and then manually "import FAMPrelude" or "import GenericPrelude" whatever version you want.
First, the cons. Please feel free to add more. If different people use different preludes, it will dramatically reduce the predictability of Haskell source files. People could think a beloved function behaves one way when it really doesn't. (But if they see the prelude used at the top, at least they have somewhere to go look things up). People would probably be tempted to bloat their own preludes with their favorite functions from data.list or whatever. (Perhaps people should be discouraged from writing their own preludes and all variations should come from GHC).
Now, pros. Forward compatibility is the main thing I'm thinking of. Today, we're debating over a particular typeclass structure, but there's no telling what change could be proposed tomorrow. If we support multiple prelude, old code can still work with its implicit prelude, yet new code can be freed from historical mistakes. Second, there are functions I use in every single source file (namely x -$ f = f x and f -. g = g . f) simply because I code in a particular style. Companies should all use the same prelude, whichever fits best for the style they want to code with.
I suppose most of this is already possible (with such projects as the numeric prelude, which in my opinion is too vast of a change for what I am proposing). However, what I would really like is for GHC to support multiple preludes as our knowledge evolves and our tastes change.submitted by AlephOmega1
[link] [24 comments]