Re: [Haskell-cafe] Help optimising a Haskell program
You use a lot of (linked lists). Are they all used to represent streams or are they actually manifest during runtime? If it's the latter switch to a better data structure, like Vector. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help optimising a Haskell program
On Tue, Mar 22, 2011 at 00:59, David MacIver wrote: > It's for rank aggregation - taking a bunch of partial rankings of some > items from users and turning them into an overall ranking (aka "That > thing that Hammer Principle does"). Two questions immediately begs themselves: * Can we go parallel? :P * What does +RTS -s -RTS say? Specifically, what is the current productivity? Do we get an improvement with +RTS -A2m -H128m -RTS ? (Force the heap to be somewhat up there from day one, perhaps try -H256m. -- J. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Help optimising a Haskell program
Hi, I have a Haskell program I'm trying to optimise, and could use some assistance. It's for rank aggregation - taking a bunch of partial rankings of some items from users and turning them into an overall ranking (aka "That thing that Hammer Principle does"). The code is here: https://github.com/DRMacIver/hs-rank-aggregation. The interesting code lives in the Algorithms.RankAggregation module. The sample data I'm running it on is samples/electornot (voting data from http://electornot.org.uk/). Here's a profile: https://gist.github.com/1ee9356f45330e9f8caa Here's a recent profile: https://gist.github.com/1ee9356f45330e9f8caa It's doing pretty well on this data, in that it's taking 8 seconds for 180k records (down from about 80 seconds earlier today) on my computer, but I'd like it to be faster - ideally under a second. Admittedly this is an arbitrary figure and I will just move the goal posts if I achieve it, but it would still be nice. :-) I suspect that it may be hitting the limits of what can be improved without actually changing the algorithm (which I'm open to doing, but not if it makes the results significantly worse), but the last 3 or 4 times I've thought that it was shortly followed by an optimisation which halved the runtime or better. In particular the most likely culprit for improvement is to deal with the fact that it allocates nearly 5GB of data (that appears to be mostly transient - watching the process as it runs the memory usage never seems to raise above 150MB, which is large but unproblematic). The biggest culprit for this is divideAndConquer which is probably generating a silly number of intermediate lists, but it's not obvious how to fix that - maybe by making the tree structure in the recursion more explicit? Don't know. Suggestions very welcome. Regards, David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Anyone recommend a VPS?
Thanks for the info, it sounds reassuring. One question: is machine performance stable? Do you ever see your virtual machines slowing significantly? My experience in running virtual machines locally is that it is easy to use too much memory and end up with the machine badly swapping for a while. Have you ever seen this happening on EC2? Thanks, titto On 19 March 2011 12:52, Neil Davies wrote: > Hi > > We run a the whole of our distributed file system (AFS) on a single AWS > micro instance with linux containers inside. > > We then use other instances for various things as/when needed (using > kerberos to distributed the management and control to the appropriate > people). For example we have a EC2 machine that we power up and down as > needed (still have to pay for the filestore when not being used - but that > is very small) for GHC - used it this morning to upgrade our shared (via > AFS) development environment to 7.0.2. All our other systems read of that > (we are completely distributed operation). > > They've been great - had a physical processor go bad once - and also they > had a h/w problem on one the machines once, that is in last 2 years or so > about 6 operational system years. > > Neil > > > > > > On 19 Mar 2011, at 11:36, Pasqualino Titto Assini wrote: > >> If you need to run your server continuously you might be better off >> with a cheap dedicated server. >> >> To run my quid2.org site, a rather complex setup with a web server and >> a number of background haskell processes, I use a server from the >> French provider OVH/Kimsufi (http://www.kimsufi.co.uk/ and >> http://www.ovh.co.uk/products/dedicated_offers.xml ,main site is >> ovh.com). >> >> You can get a decent box for 15 euro a month and a hell of a machine >> for 50/60 euros. >> >> They also have some Cloud/VPS options, that I have not used. >> >> >> Does anyone have first-hand experience with Amazon EC2? >> >> They also look very tempting. >> >> >> Best, >> >> titto >> >> >> On 19 March 2011 10:12, Lyndon Maydwell wrote: >>> >>> Does anyone have any Binaries that are built to run on EC2? >>> >>> That would be super! >>> >>> On Tue, Feb 2, 2010 at 1:11 AM, Jason Dusek >>> wrote: 2010/01/31 Marc Weber : > > If all you want is standard debian or such it does'nt matter. > However I tried installing NixOS Linux and I've had lot's of > trouble until switching to linode. NixOS was up and running > within 30min then.. How did you get NixOS on your Linode system? They don't seem to offer it, last I checked. I'm looking in to doing this with PRGMR, which has pretty good pricing though it's not nearly as featureful as Linode. -- Jason Dusek ___ 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 >>> >> >> >> >> -- >> Dr. Pasqualino "Titto" Assini >> http://quid2.org/ >> >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Dr. Pasqualino "Titto" Assini http://quid2.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Uncertainty analysis library?
On Mon, 21 Mar 2011, Tom Nielsen wrote: sampler = do x <- gauss 0.0 1.0 y <- gauss 0.0 1.0 return $ (2*x, x+y) main = do xys <- take 10 `fmap` runSamplerIO sampler print $ runStat (both (before varF fst) (before varF snd)) $ xys => (3.9988971177326498,2.0112123117664975) that is, (variance of 2*x, variance of x+y) Variances of independent random variables (here x and y) are additive, for dependent variables (say, x and x) this does not hold. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Uncertainty analysis library?
i'm now seeing that they've been moved to github, never mind! On Mon, Mar 21, 2011 at 6:01 PM, Carter Schonwald < carter.schonw...@gmail.com> wrote: > by the way, the link to the patch-tag repo for your intervals lib seems to > be dead / patch-tag gets confused, > is it that the link is outdated or that there are problems on patch-tag? > > -Carter > > On Mon, Mar 21, 2011 at 4:57 PM, Edward Kmett wrote: > >> >> On Mon, Mar 21, 2011 at 2:42 PM, Edward Amsden wrote: >> >>> >>> So I'm feeling a bit elated that I've sparked my first theoretical >>> discussion in cafe, though I don't have much to contribute. :\ >>> >>> However in the interests of the original question, I guess I should >>> clarify. >>> >>> What we do in our physics class seems to be what is being called >>> "interval analysis" in this discussion. We have experimental values >>> with absolute uncertainties, and we need to propagate those >>> uncertainties in a deterministic way through formulas. I don't think >>> my professor would take kindly to a random sampling approach. >>> >>> The intervals library seemed a bit like what I'm looking for, except >>> that it appears to be broken for the later ghc 6 versions and ghc 7. >> >> >> The package should build fine, but hackage was flipping out because I >> commented out a pattern guard, and it looked like a misplaced haddock >> comment. >> >> I've pushed a new version of intervals to mollify hackage. >> >> It (or the old version) should cabal install just fine. >> >> -Edward Kmett >> >> ___ >> 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] Uncertainty analysis library?
by the way, the link to the patch-tag repo for your intervals lib seems to be dead / patch-tag gets confused, is it that the link is outdated or that there are problems on patch-tag? -Carter On Mon, Mar 21, 2011 at 4:57 PM, Edward Kmett wrote: > > On Mon, Mar 21, 2011 at 2:42 PM, Edward Amsden wrote: > >> >> So I'm feeling a bit elated that I've sparked my first theoretical >> discussion in cafe, though I don't have much to contribute. :\ >> >> However in the interests of the original question, I guess I should >> clarify. >> >> What we do in our physics class seems to be what is being called >> "interval analysis" in this discussion. We have experimental values >> with absolute uncertainties, and we need to propagate those >> uncertainties in a deterministic way through formulas. I don't think >> my professor would take kindly to a random sampling approach. >> >> The intervals library seemed a bit like what I'm looking for, except >> that it appears to be broken for the later ghc 6 versions and ghc 7. > > > The package should build fine, but hackage was flipping out because I > commented out a pattern guard, and it looked like a misplaced haddock > comment. > > I've pushed a new version of intervals to mollify hackage. > > It (or the old version) should cabal install just fine. > > -Edward Kmett > > ___ > 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] Uncertainty analysis library?
> The danger here is, of course, the side-condition of independence, which can > make inhabitants of that type very difficult to reason about. e.g. x + x and > 2*x in that world are very different. Yes. I was surprised (maybe i shouldn't have been): sampler = do x <- gauss 0.0 1.0 y <- gauss 0.0 1.0 return $ (2*x, x+y) main = do xys <- take 10 `fmap` runSamplerIO sampler print $ runStat (both (before varF fst) (before varF snd)) $ xys => (3.9988971177326498,2.0112123117664975) that is, (variance of 2*x, variance of x+y) The problem is that when you say x+x you don't really mean it; you mean something like liftM2(+) xdist xdist in a probability monad. Had I changed "x+y" to "x+x", I would obviously have gotten identical variances. So maybe referential transparency is not lost after all. Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Uncertainty analysis library?
On Mon, Mar 21, 2011 at 2:42 PM, Edward Amsden wrote: > > So I'm feeling a bit elated that I've sparked my first theoretical > discussion in cafe, though I don't have much to contribute. :\ > > However in the interests of the original question, I guess I should > clarify. > > What we do in our physics class seems to be what is being called > "interval analysis" in this discussion. We have experimental values > with absolute uncertainties, and we need to propagate those > uncertainties in a deterministic way through formulas. I don't think > my professor would take kindly to a random sampling approach. > > The intervals library seemed a bit like what I'm looking for, except > that it appears to be broken for the later ghc 6 versions and ghc 7. The package should build fine, but hackage was flipping out because I commented out a pattern guard, and it looked like a misplaced haddock comment. I've pushed a new version of intervals to mollify hackage. It (or the old version) should cabal install just fine. -Edward Kmett ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subsets and supersets
Andrew Coppin schrieb: > Haskell has ADTs. Most of the time, these work great. As I've written in > several other places (but possibly not here), OO languages tend to > "factor" the problem the other way. That is, if I want a binary tree, an > OO language makes me split the type and all of its operations into three > parts (an abstract base class, a branch subclass, and a leaf subclass). > Adding each new operation requires adding an abstract version of it to > the abstract base class, and putting half of the implementation into > each concrete subclass. I think, that's known as the 'expression problem'. http://en.wikipedia.org/wiki/Expression_problem ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsing Haskell in Parsec
Thank you, everyone, for the suggestions. On Mon, Mar 21, 2011 at 12:28 PM, Johannes Waldmann < waldm...@imn.htwk-leipzig.de> wrote: > Alex Rozenshteyn gmail.com> writes: > > > as part of a larger project of porting > > http://www.cs.jhu.edu/~scott/pl/book/dist/ from ocaml to Haskell. > > Nice idea. I was using a similar approach (interpreters for > various semantic domains) in a course on semantics(+ compilation). > > I modelled it after the Turbak/Gifford book > http://mitpress.mit.edu/catalog/item/?ttype=2&tid=11656 > (in fact after the book had been praised in this here mailing list, > about two years ago). > > In fact the contents of these two books seem largely similar, > and the following remark holds true: > > Using Haskell as an implementation language, you get a very nice addition: > you can model the semantics domains by Monads, and it's very natural, > (Identity monad = naive interpreter, Maybe monad = for exceptions e.g. > division > by zero, State monad = for assignment, Continuation passing monad = > for CPS style programming). > > Now, neither of the books dare to use the M-word. > Although Turbak is really "doing monads": he is clearly > defining several "bind" and "return", he's just not naming them as such. > > You may browse my source code (quite unpolished) here > http://dfa.imn.htwk-leipzig.de/cgi-bin/gitweb.cgi?p=ws10-cb/.git;a=tree > and there's a parser as well (in the Exp directory). > > I'd be happy to get comments on my code as well. > Would it look better with Monad transformers? > And there's some amount of (tree walking) boilerplate > that could perhaps be replaced by some template haskell magic. > But then, magic is no good in teaching... > > Best regards, J.W. > > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Alex R ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Monad.Reader special Poetry and Fiction Edition
Andrew Coppin schrieb: > On 16/03/2011 03:05 PM, Brent Yorgey wrote: > >> This kind of "knot-tying" approach is nice for static graphs. > > I think we should have a wiki page somewhere which explains what all the > various Haskell-related terms mean. Terms like "typing the knot" and > "finally tagless". (Not to mention "Oleg rating"...) http://www.haskell.org/haskellwiki/Category:Glossary ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Uncertainty analysis library?
>> PS if you're a scientist and your accuracy estimate is on the same >> order as your rounding error, your are doing pretty well :-) At least >> in my field... > > > True enough, but in the case of interval arithmetic I like to be able to > preserve the invariant that if I am working with intervals (even if only to > collect accumulated rounding error in a Taylor model) that the answer lies > within the interval, and doesn't escape due to some tight boundary condition > or accumulated rounding error from when I was working too close to a pole. > > In the case of Taylor models we try to keep the size of the intervals as > small as possible by using the first k terms of a Taylor polynomial and only > catching the slop in an interval.This is important because of course adding > and multiplying intervals will cause the size of the intervals to baloon > very quickly. Since the intervals in question are very close to the scale of > floating point rounding error as possible, and we often have to > conservatively slop the rounding error over from the Taylor coefficients > into the interval, accurate handling of tight corner cases is critical. > > -Edward So I'm feeling a bit elated that I've sparked my first theoretical discussion in cafe, though I don't have much to contribute. :\ However in the interests of the original question, I guess I should clarify. What we do in our physics class seems to be what is being called "interval analysis" in this discussion. We have experimental values with absolute uncertainties, and we need to propagate those uncertainties in a deterministic way through formulas. I don't think my professor would take kindly to a random sampling approach. The intervals library seemed a bit like what I'm looking for, except that it appears to be broken for the later ghc 6 versions and ghc 7. -- Edward Amsden Student Computer Science Rochester Institute of Technology www.edwardamsden.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Uncertainty analysis library?
On Sun, Mar 20, 2011 at 5:46 PM, Tom Nielsen wrote: > Interval arithmetic is of course not the same as uncertainty, although > computer scientists like to pretend that is the case. (and uncertainty > estimates do not have the be "rough".) > Very true. > In general the propagation of errors depends on whether the errors are > independent or not. The rules are given in Taylor: An introduction to > Error analysis (1997). Interval artihmetic corresponds to the worst > case of non-independent and non-random errors. In the case of > independent of random errors, you get: > > data Approximately a = a :+/-: a > > instance Num a => Num (Approximately a) where > (m1 :+/-: err1) + (m2 :+/-: err2) = (m1+m2) :+/-: (sqrt(err1^2+err2^2) > (m1 :+/-: err1) - (m2 :+/-: err2) = (m1-m2) :+/-: (sqrt(err1^2+err2^2) > (m1 :+/-: err1) * (m2 :+/-: err2) = (m1*m2) :+/-: > (sqrt((err1/m1)^2+(err2/m2)^2) > > the general rule is > > if y = f xs where xs :: [Approximately a], i.e f :: [Approximately a] > -> Approximately a > > the error term= sqrt $ sum $ map (^2) $ map (\(ym :+/-: yerr) -> > partial-derivative-of-yerr-with-respect-to-partial-ym * yerr) xs > The danger here is, of course, the side-condition of independence, which can make inhabitants of that type very difficult to reason about. e.g. x + x and 2*x in that world are very different. In this sense the interval arithmetic bounds _are_ safer to work with in the absence of sharing information even if they are less useful in the hands of an expert. > You can verify these things by running your calculation through soem > sort of randomness monad (monte-carlo or random-fu packages) Anyways, > I ended up not going down this route this because probabilistic data > analysis gives you the correct error estimate without propagating > error terms. We are in total agreement here. =) > Tom > > PS if you're a scientist and your accuracy estimate is on the same > order as your rounding error, your are doing pretty well :-) At least > in my field... True enough, but in the case of interval arithmetic I like to be able to preserve the invariant that if I am working with intervals (even if only to collect accumulated rounding error in a Taylor model) that the answer lies within the interval, and doesn't escape due to some tight boundary condition or accumulated rounding error from when I was working too close to a pole. In the case of Taylor models we try to keep the size of the intervals as small as possible by using the first k terms of a Taylor polynomial and only catching the slop in an interval.This is important because of course adding and multiplying intervals will cause the size of the intervals to baloon very quickly. Since the intervals in question are very close to the scale of floating point rounding error as possible, and we often have to conservatively slop the rounding error over from the Taylor coefficients into the interval, accurate handling of tight corner cases is critical. -Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Installation of Haskell Platform on CentOS 5.5
frode k writes: > (Note: I also installed GCC 4.4 (as mentioned by Mr Peterson) before I > retried installing Cabal and the Haskell Platform , but I do not think that > affected the build / compile process at all, since GHC and not GCC is used > here. And GCC 4.4 is also installed next to 4.1 that presumably would be > used by default (or am I wrong about this?)) I got gcc44 (RHEL package) installed, but the suggested (by ./configure --help) "./configure CC=gcc44" doesn't seem to do anything, this seems to be a documentation bug. I made a link from ~/bin/gcc to the gcc44 binary, and that let the configure script find it, at least. Running 'make -j 8 install' crashed with an error, in order to make sense of the output (which tends to be hard to read when running make with parallelism), I reran, this time without -j. But then it ran to completion... Although the install process still has room for improvement, especially on archaic^Wconservative systems, I'm now the happy owner of a GHC 7.0.2 installation. Now, time to install libraries... -k PS: I guess I should report the issues I encountered on trac, but somehow the trac interface never made sense to me, and my searches always seem to result in heaps of completely unrelated stuff. -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] unregisterised plan9 port
I'd also love to see GHC on Plan 9. I don't have a lot of time to contribute to such an effort really though I do wish you well! On Mon, Mar 21, 2011 at 1:20 AM, * wrote: > Hi there. > > I am trying to get an unregisterised build of ghc 7.0.2 working and am > having problems turning mangling off. > > When I build the compiler with > > GhcUnregisterized = YES > GhcWithNativeCodeGen = NO > SplitObjs = NO > BeConservative = YES > > The 'evil mangler' is still used. When I disable it at the command line > with -fno-asm-mangling the FB_ macro is still put into the > generated C. > > > I just want to turn everything related to this dreaded "evil mangler" off, > and still produce working executables. > Are there things that I could set in the build.mk file to do this, or is > it more involved? > > I have read some things in the mailing list and the bug tracker that (to my > ignorant and slightly confused ears) > seem to suggest that this unregisterised is problematic or depreciated or > something. > > If this is the case I would be perfectly happy using an older version of > the compiler, and would be grateful if someone > could point me to a specific older version number where this stuff builds > with less hassel. I don't care how out of date > it is. > > In case you are wondering, I am attempting to get an unregisterised port of > ghc working in plan9, an operating system that > has yet to be blessed with a haskell implementation (hugs doesn't count :P) > > Plan 9 has a gcc port, an older one, but it should be fine. > > ___ > 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] Parsing Haskell in Parsec
Alex Rozenshteyn gmail.com> writes: > as part of a larger project of porting > http://www.cs.jhu.edu/~scott/pl/book/dist/ from ocaml to Haskell. Nice idea. I was using a similar approach (interpreters for various semantic domains) in a course on semantics(+ compilation). I modelled it after the Turbak/Gifford book http://mitpress.mit.edu/catalog/item/?ttype=2&tid=11656 (in fact after the book had been praised in this here mailing list, about two years ago). In fact the contents of these two books seem largely similar, and the following remark holds true: Using Haskell as an implementation language, you get a very nice addition: you can model the semantics domains by Monads, and it's very natural, (Identity monad = naive interpreter, Maybe monad = for exceptions e.g. division by zero, State monad = for assignment, Continuation passing monad = for CPS style programming). Now, neither of the books dare to use the M-word. Although Turbak is really "doing monads": he is clearly defining several "bind" and "return", he's just not naming them as such. You may browse my source code (quite unpolished) here http://dfa.imn.htwk-leipzig.de/cgi-bin/gitweb.cgi?p=ws10-cb/.git;a=tree and there's a parser as well (in the Exp directory). I'd be happy to get comments on my code as well. Would it look better with Monad transformers? And there's some amount of (tree walking) boilerplate that could perhaps be replaced by some template haskell magic. But then, magic is no good in teaching... Best regards, J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mime / Mail library
> From: Christopher Done > > On 20 March 2011 15:05, Pieter Laeremans wrote: > > > Hi all, > > > > The MIME package that can be found on hackage, uses String as input. > > Would i be considered better if there would be a version based on Text, > or > > ByteString ? > > > > I think the solution to this problem is a generic `string' package which > just provides a few classes. The MIME library would export an interface > that > only deals with instances of these classes, and whether you're using Text, > String, ByteString/Lazy/Char8, ropes, whatever, it's not the library > writer's concern or assumptions to make. > > We already have: > > http://hackage.haskell.org/packages/archive/string-combinators/0.6/doc/html/Data-String-Combinators.html > < > http://hackage.haskell.org/packages/archive/string-combinators/0.6/doc/html/Data-String-Combinators.html > > > Which works on Monoid and IsString, but there needs to be a class like "can > be read/outputted via IO" and one for read/show/serialize, both of which > are > important for speed. > > Anyone already done work on this? The Data.ByteString modules could export > some instances. It's fair enough that people who need fine-grained speed > use > the concrete types and all their special-purposes functions, but in the > general having to choose arbitrarily (often defaulting to String) is a > burden. Can't we standardize on a default set of String classes to use? > > I suppose I could try reducing Data.ByteString's function set into a set of > essential core methods, seeing as the ByteString modules are a very good > spec of what's required for a String type to be completely usable. > Data.ListLike (http://hackage.haskell.org/package/ListLike) provides this via the "StringLike" class (and StringLikeIO). There are built-in instances for Strings and ByteStrings, with orphan Text instances in http://hackage.haskell.org/package/listlike-instances. Probably the StringLike class could be extended to provide more (high-performance) methods, but I don't have a good idea of what's necessary. Suggestions are welcome! John L. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] unregisterised plan9 port
Hi there. I am trying to get an unregisterised build of ghc 7.0.2 working and am having problems turning mangling off. When I build the compiler with GhcUnregisterized = YES GhcWithNativeCodeGen = NO SplitObjs = NO BeConservative = YES The 'evil mangler' is still used. When I disable it at the command line with -fno-asm-mangling the FB_ macro is still put into the generated C. I just want to turn everything related to this dreaded "evil mangler" off, and still produce working executables. Are there things that I could set in the build.mk file to do this, or is it more involved? I have read some things in the mailing list and the bug tracker that (to my ignorant and slightly confused ears) seem to suggest that this unregisterised is problematic or depreciated or something. If this is the case I would be perfectly happy using an older version of the compiler, and would be grateful if someone could point me to a specific older version number where this stuff builds with less hassel. I don't care how out of date it is. In case you are wondering, I am attempting to get an unregisterised port of ghc working in plan9, an operating system that has yet to be blessed with a haskell implementation (hugs doesn't count :P) Plan 9 has a gcc port, an older one, but it should be fine. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
