Re: [Haskell-cafe] [Haskell] ANNOUNCE: genprog-0.1
Andrew Coppin andrewcop...@btinternet.com writes: A change to a gene does not make you to have a extra bone. It can make you to have your hand slighltly longer. or shorter. Actually I suspect it does - or at least can do. It's just a rather rare event. Bodily development is regulated by a cluster of genes (the HOX cluster). The modern-day Galvani experiment is reshuffling this in fruit fly to make antenna into legs. I don't think it happens all that much in nature, and I guess any resulting offspring would have reduced fitness. -k -- 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] Offer to mirror Hackage
On 08/12/10 20:25, Luke Palmer wrote: I could upload a new version of mtl if I wanted. Plenty of people would install it. Correct me if i'm wrong; You would appear in the UploadedBy, and then you might be challenged by the traditional uploaders or attentive users (most users wouldn't know of course) to give a reason of doing the upload. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: genprog-0.1
Mitar mmi...@gmail.com writes: Neither Haskell nor any conventional language has [evolved to evolve] True. Well - thinking about it, there's no fundamental difference between genetic algorithms - where you have a genome in the form of a set of parameters and genetic programming - where the genome is a program of some sort, typically Lisp code, since the syntax tree is so accessible and malleable. In either case, you have an interpreter that interprets the genome, the difference is mainly in the expressive power of the language. I haven't looked closely, but I suspect you might not want Turing-completeness in either case (Alberto?). But yes, by designing the language to evolve, we can get a head start compared to nature. -k -- 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] ANNOUNCE: mime-mail 0.1.0
On Wed, Dec 8, 2010 at 19:11, Michael Snoyman mich...@snoyman.com wrote: Hi all (again), I'm happy to announce the second major release of the mime-mail[1] package. mime-mail is a package providing support for rendering multipart emails. This new release introduces: Very nice! Are you working on a parser to accompany the renderer? ;-) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: mime-mail 0.1.0
On Thu, Dec 9, 2010 at 11:48 AM, Magnus Therning mag...@therning.org wrote: On Wed, Dec 8, 2010 at 19:11, Michael Snoyman mich...@snoyman.com wrote: Hi all (again), I'm happy to announce the second major release of the mime-mail[1] package. mime-mail is a package providing support for rendering multipart emails. This new release introduces: Very nice! Are you working on a parser to accompany the renderer? ;-) /M I'm not currently, though that is definitely a direction the project could expand to. I've already written some multipart-parsing code in wai-extra, though that code probably wouldn't help here too much. The quoted-printable decoding is simple enough to write, and base64-decoding has already been solved. Is this a challenge anyone out there wants to undertake? Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] dot-ghci files
Tony Morris tonymor...@gmail.com writes: I teach haskell quite a lot. I recommend using .ghci files in projects. Today I received complaints about the fact that ghci will reject .ghci if it is group-writeable. Huh? That's pretty weird. I am wondering if these complaints have legitimate grounds i.e. maybe you want to have group write on that file for some reason. Well - one common setup is to create users along with their own group, and optional membership in other groups, combined with an umask of 002 (i.e., files are created group-writeable) or perhaps 027 (group-readable, but not accessible at all to others). This way, a group-shared directory can have the setgid bit set, and when a user writes a file in this directory, the file will inherit the group from the directory, and be writeable by other people of the group. Unless it also has the sticky bit set. (Hmm, aren't Unix permissions supposed to be the *simple* solution? It's been a while since I looked at this, so please correct if I got the details wrong. :-) -k -- 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] Offer to mirror Hackage
On 08/12/10 10:41, Ketil Malde wrote: Yes. And you should start with assessing how much cost and inconvenience you are willing to suffer for the improvement in security you gain. In this case, my assertion is that the marginal worsening of security by having a mirror of hackage even without signing of packages etc., is less than the marginal improvement in usability. I'm a bit surprised to find that there seems to be a lot of opposition to this view, but perhaps the existing structure is more secure than I thought? Or the benefit of a mirror is exaggerated - I can see how it would be annoying to have hackage down, but it hasn't happened to my, so perhaps those complaining about it just were very unlucky. You might have misunderstood what I was talking about. I'm proposing signing on the hackage server on reception of the package, where it can be verified by cabal that the package hasn't been signed properly. This is not about all the way signing of every uploaders, with chain of trust and such (which has been proposed by wren). The implication on the users should be minimal. I mean they shouldn't even know about it. It would only complain if the signature isn't valid. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] dot-ghci files
Am 09.12.2010 08:01, schrieb Tony Morris: I teach haskell quite a lot. I recommend using .ghci files in projects. Today I received complaints about the fact that ghci will reject .ghci if it is group-writeable. I didn't offer an opinion on the matter. I am wondering if these complaints have legitimate grounds i.e. maybe you want to have group write on that file for some reason. I'd appreciate some comments on this issue. Thanks. Indeed I get: GHCi, version 7.0.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. *** WARNING: /home/maeder/.ghci is writable by someone else, IGNORING! and I'm surprised! Cheers Christian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] dot-ghci files
On 09/12/10 07:01, Tony Morris wrote: I teach haskell quite a lot. I recommend using .ghci files in projects. Today I received complaints about the fact that ghci will reject .ghci if it is group-writeable. I didn't offer an opinion on the matter. I am wondering if these complaints have legitimate grounds i.e. maybe you want to have group write on that file for some reason. I'd appreciate some comments on this issue. Thanks. You can insert *any* commands in the ghci file. including some system commands, to delete everything. That's probably the reason to deny a file to be group writable (anyone in a group could write bad thing in there) you can try putting the following in the .ghci to check for example: readFile somefileyouwanttoread = writeFile /tmp/apublicplace -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: mime-mail 0.1.0
On Thu, 09 Dec 2010 01:10:59 +, Maciej Piechotka uzytkown...@gmail.com wrote: On Wed, 2010-12-08 at 21:11 +0200, Michael Snoyman wrote: Hi all (again), I'm happy to announce the second major release of the mime-mail[1] package. mime-mail is a package providing support for rendering multipart emails. This new release introduces: * A partHeaders record, allowing you to place arbitrary headers on individual parts of a message. This is especially useful for ContentID * Support for quoted-printable. There are two new Encoding constructors added: QuotedPrintableText and QuotedPrintableBinary. They differ in how they treat newline characters: the latter outputs CRs and LFs in an escaped form, while the former strips all CRs and outputs LFs as the ASCII codes for \r\n. * Support for encoded-word for header values. This is a completely transparent change: now if you use non-ASCII characters in your header values, mime-mail will automatically encode appropriately. Enjoy! Michael [1] http://hackage.haskell.org/package/mime-mail Sorry I'm asking here (I know it is slightly off-topic) - does anyone knows package to parse MIME messages operating on ByteString/Text instead of String (reverse of mime-mail)? I have a fork of the mime library to work on bytestring, it worked for me but didn't took the time to release it. (I sent multiple mails to the original author though). I've just setup a repo on github [1], feel free to test, fork, polish... Have fun, [1]: https://github.com/np/mime-bytestring -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Offer to mirror Hackage
My take on the issue is that we should make it possible to easily mirror hackage (what the OP asked for), so that people could use it when they wanted to, and have a list of the mirrors on the wiki. This way those who are interested can use them. Like when the mirror is faster/closer to them or to help out when hackage is temporarily down. Those who need the security can choose not to use mirrors, or make their own (private), or develop a secure scheme, when it doesn't exist yet. It's perfectly understandable, that people doing work/serious stuff need the guarantees, but I bet a many of us are just playing around and developing things for themselves. -- Markus Läll ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Offer to mirror Hackage
On 9 December 2010 20:55, Vincent Hanquez t...@snarc.org wrote: You might have misunderstood what I was talking about. I'm proposing signing on the hackage server on reception of the package, where it can be verified by cabal that the package hasn't been signed properly. By cabal, are you referring to Cabal or cabal-install? If the former, then I'm not sure how exactly it would do such verification since it doesn't have any notion of the internet as far as I'm aware; if the latter then it means absolutely nothing for those of us that do not use cabal-install for most packages. -- 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
Re: [Haskell-cafe] Offer to mirror Hackage
On Thu, Dec 09, 2010 at 10:45:39PM +1100, Ivan Lazar Miljenovic wrote: On 9 December 2010 20:55, Vincent Hanquez t...@snarc.org wrote: You might have misunderstood what I was talking about. I'm proposing signing on the hackage server on reception of the package, where it can be verified by cabal that the package hasn't been signed properly. By cabal, are you referring to Cabal or cabal-install? If the former, then I'm not sure how exactly it would do such verification since it doesn't have any notion of the internet as far as I'm aware; if the latter then it means absolutely nothing for those of us that do not use cabal-install for most packages. I don't really know the difference between Cabal and cabal-install, but Something is downloading the .tar.gz, and that thing can always download an extra .tar.gz.sign file which contains a way to verify that's the .tar.gz is genuinely the one that has been received by hackage. For those not using the thing-that-download-archive to get their package from hackage, they can build the same mechanism that download an extra file, and check the signature. Or they can even choose not to bother, and just download the package as they just did before. Note that, I'm not actually inventing anything new here, this is a common way to distribute software (linux distributions, many opensource softwares, etc). -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Enhancing the security of hackage
Vincent Hanquez t...@snarc.org writes: You might have misunderstood what I was talking about. I'm proposing signing on the hackage server on reception of the package, Okay, fair enough. You can't *enforce* this, of course, since I might work without general internet access but a local mirror, but you could require me to run 'cabal --dont-check-signatures' or similar, so this would still make a hostile-operated mirror less useful. OTOH, if I should suggest improving the security of Hackage, I would prioritize: a) email the maintainer whenever a new upload is accepted - preferably with a notice about whether the build works or fails. Mabye also highlight the case when maintainer differs from uploader - if that doesn't give a ton of false positives. b) email the *previous* maintainer when a new upload is accepted and the maintainer field has changed. This way, somebody is likely to actually *notice* when some evil person uploads a trojan mtl or bytestring or whatever. The downside is more mail, and the people who run Hackage have been wary about this. So perhaps even this is on the wrong side of the cost/benefit fence. (People with admin privileges (staff or hackers) to hackage can of course still work around everything - crypto signatures or email-schemes.) -k -- 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] Enhancing the security of hackage
On Thu, Dec 9, 2010 at 7:04 AM, Ketil Malde ke...@malde.org wrote: Vincent Hanquez t...@snarc.org writes: You might have misunderstood what I was talking about. I'm proposing signing on the hackage server on reception of the package, Okay, fair enough. You can't *enforce* this, of course, since I might work without general internet access but a local mirror, but you could require me to run 'cabal --dont-check-signatures' or similar, so this would still make a hostile-operated mirror less useful. OTOH, if I should suggest improving the security of Hackage, I would prioritize: a) email the maintainer whenever a new upload is accepted - preferably with a notice about whether the build works or fails. Mabye also highlight the case when maintainer differs from uploader - if that doesn't give a ton of false positives. b) email the *previous* maintainer when a new upload is accepted and the maintainer field has changed. This way, somebody is likely to actually *notice* when some evil person uploads a trojan mtl or bytestring or whatever. The downside is more mail, and the people who run Hackage have been wary about this. So perhaps even this is on the wrong side of the cost/benefit fence. (People with admin privileges (staff or hackers) to hackage can of course still work around everything - crypto signatures or email-schemes.) -k Also, perhaps put the signatures on a separate machine from the one containing .tar.gz. For a 3rd party to corrupt a package, they'd need to hack 2 machines. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Enhancing the security of hackage
On 9 December 2010 23:04, Ketil Malde ke...@malde.org wrote: [snip] This way, somebody is likely to actually *notice* when some evil person uploads a trojan mtl or bytestring or whatever. The downside is more mail, and the people who run Hackage have been wary about this. So perhaps even this is on the wrong side of the cost/benefit fence. Whilst we're wishfully thinking, why not register a package to an individual or a group, and only allow them to upload it? Possibly linking this to a group on community.haskell.org or something. -- 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] ICFP 2011: Call for papers
= Call for Papers ICFP 2011: International Conference on Functional Programming Tokyo, Japan, Monday 19 -- Wednesday 21 September 2011 http://www.icfpconference.org/icfp2011 = Important Dates ~~~ Titles, abstracts keywords due: Thursday 17 March 2011 at 14:00 UTC Submissions due: Thursday 24 March 2011 at 14:00 UTC Author response: Tuesday Wednesday 17-18 May Notification: Monday 30 May 2011 Final copy due: Friday 01 July 2011 Conference: Monday-Wednesday 19-21 September 2011 Scope ~ ICFP 2011 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Particular topics of interest include * Language Design: type systems; concurrency and distribution; modules; components and composition; metaprogramming; relations to imperative, object-oriented, or logic programming; interoperability * Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; memory management; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources * Software-Development Techniques: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling * Foundations: formal semantics; lambda calculus; rewriting; type theory; mathematical logic; monads; continuations; delimited continuations; global, delimited, or local effects * Transformation and Analysis: abstract interpretation; partial evaluation; program transformation; program calculation; program proofs; normalization by evaluation * Applications and Domain-Specific Languages: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed-systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; multimedia programming; scripting; system administration; security; education * Functional Pearls: elegant, instructive, and fun essays on functional programming * Experience Reports: short papers that provide evidence that functional programming really works or describe obstacles that have kept it from working in a particular application Abbreviated instructions for authors * By 17 March 2011, 14:00 UTC, submit a title, an abstract of at most 300 words, and keywords. * By 24 March 2011, 14:00 UTC, submit a full paper of at most 12 pages (6 pages for a Functional Pearl and for an Experience Report), including bibliography and figures. The deadlines will be strictly enforced and papers exceeding the page limits will be summarily rejected. * Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. * Each submission must adhere to SIGPLAN's republication policy, as explained on the web at http://www.acm.org/sigplan/republicationpolicy.htm In addition, authors of resubmitted (but previously rejected) papers have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the program chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no rewiewer will read the annotated copies of the previous reviews. Overall, a submission will be evaluated according to its relevance, correctness, significance, originality, and clarity. It should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. Functional Pearls and Experience Reports are separate categories of papers that need not report original research results and must be marked as such at the time of submission. Detailed guidelines on both categories are on the conference web site. Proceedings will be published by ACM Press. Authors of accepted submissions are expected to transfer the copyright to the ACM. Presentations
Re: [Haskell-cafe] [Haskell] ANNOUNCE: genprog-0.1
Hi Ketil, 2010/12/9 Ketil Malde ke...@malde.org Mitar mmi...@gmail.com writes: Neither Haskell nor any conventional language has [evolved to evolve] True. Well - thinking about it, there's no fundamental difference between genetic algorithms - where you have a genome in the form of a set of parameters and genetic programming - where the genome is a program of some sort, typically Lisp code, since the syntax tree is so accessible and malleable. In either case, you have an interpreter that interprets the genome, the difference is mainly in the expressive power of the language. I haven't looked closely, but I suspect you might not want Turing-completeness in either case (Alberto? ). I´m not sure. (answer at the bottom). There are some characteristics on DNA code that are there just to evolve some parts of the code while maintaining safe some others. There are sequences that are extraordinarily stable for millions of years across species, while others change very often. Some others are in the middle. This is not arbitrary. Let´s say that the stable parts are the IF statements while the changing parts are the parameter values. Doing so, the species explores the safe part of the fitness landscape without wasting effort in experiments that have 99% chance to fail. Females will evolve whatever mechanism to avoid these experiments as soon as possible. However risky experiments shoud be taken from time to time, to explore new zones of the fitness landscape. Another characteristic of evolution, is its multilevel nature. There are selection of genes. Selection of gene replication alternatives, selection of reproduction alternatives. procariotic, eucariotic, multicelular (individual), social levels of selection. Not only that. During ovulation there is a selection of good eggs, as I mentioned. And this selection is related with the stability of critical gene sequences. this test for stability is regulated by other supervisor genes that test with different degrees of accuracy the absence of mutations in these protected sequences. This internal checking for consistency can be considered a level of selection, or autoselection if you like. . selective checking has evolved as a metalevel. But you can alternatively consider this consistency check as a set of rules written in the genetic code by selection itself . Rules are a form ofselection mechanisms after all. All of these Rules have evolved because the genetic code executes over itself using its own code as data: Some genes activate others. some others check for absence of mutations and so on. That is, some metalevel selection are carried out by the same code that is evolving. Moreover some rules are different for each genera or specie son it is not possible to extract (and abstract) out certain chekings from the code that is checked. If evolution is search for local maximums in a tree, the rules/metalevels are heuristic rules that guide the strategy of exploration. Another But yes, by designing the language to evolve, we can get a head start compared to nature. Yes. What means what I said above for evolving programs? First that a simple genetic algorithm operating on auto modifying code can generate any solution if we wait a few billion of years. But we can help to do it faster by studying the DNA code, learn their already evolved techniques and use them to design languages, assign rates of mutation for each statement, discover rules, selection mechanism, species of programs (or design patterns) that acts as templates for each problem etc. Species of programs means that the seed of the genetic algoritm must not be turing comoplete I guess. It must be specific for each problem. -k -- 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 7.0.1 developer challenges
On 08/12/2010 16:34, Andrew Coppin wrote: On 08/12/2010 03:29 PM, Brandon S Allbery KF8NH wrote: Then build your CGIs restricted. Restricting the runtime by default, *especially* when setting runtime options at compile time is so much of a pain, is just going to cause problems. I'm already thinking that I may have to skip ghc7. With current versions of GHC, to set the default RTS options you need to do some insanity with linking in a C stub or something absurd like that. However, take a look at this: http://www.haskell.org/ghc/docs/7.0-latest/html/users_guide/runtime-control.html#id3095435 It appears that with GHC 7, you can just say something like |-with-rtsopts=-H128m -K1m| while compiling your program, and now that will forever be the default RTS settings for your program. I haven't actually tried this myself, however. In particular, I'm not sure if you have to turn on the full RTS options before this will work... Nice! I didn't notice Ian had added that flag, and we totally forgot to mention it in the 7.0.1 release notes. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 7.0.1 developer challenges
On 09/12/2010 12:48 PM, Simon Marlow wrote: On 08/12/2010 16:34, Andrew Coppin wrote: It appears that with GHC 7, you can just say something like |-with-rtsopts=-H128m -K1m| while compiling your program, and now that will forever be the default RTS settings for your program. Nice! I didn't notice Ian had added that flag, and we totally forgot to mention it in the 7.0.1 release notes. Heh. It can't be very often that an outsider gets to tell one of the core product developers about one of their own product's new features... ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: genprog-0.1
Hi! On Thu, Dec 9, 2010 at 1:48 PM, Alberto G. Corona agocor...@gmail.com wrote: assign rates of mutation for each statement, This could be assigned by evolution itself. If if will have high probability of mutation then resulting programs will not survive. So those probabilities can be assigned by evolution itself and be also something which is passed on with generations (with again possibility of mutations of those probabilities itself). What would be interesting is to have an evolution algorithm which would allow such protections to evolve during its run. So some kind of protection which would lower the rate of mutation for some code part. Species of programs means that the seed of the genetic algoritm must not be turing comoplete I guess. It must be specific for each problem. I do not see this as necessity. Just that those specimens which would use this power too much would probably not survive. (If they would remove protection for some sentences they have build before.) Mitar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Rather off topic: An ab initio universe simulation?
In order to simulate nature, you need to have the mutation and selection process itself be part of the programs (and not the interpreter). How about you have a world consisiting of some memory, bombard this world with cosmic radiation, and add some enzymatic activity in the form of an interpreter that interprets a location of the world as a simple language (that allows observation and modification of the world, as well as forking new threads of execution) - which is randomly started at random points. After some time, you might have threads that reproduce themselves, perhaps forming species, cooperation, pathogens, genders, and if you wait four billion years, civilizations... Life is really just core wars without the programmers :-) -k -- 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] ANN: hledger 0.13
On Dec 9, 2010, at 3:35 AM, Peter Simons wrote: you said that a dependency of one of those packages would require process = 1.0.1.4. Now, what I don't understand is why you added that restriction to hledger then? Picture this common scenario, which I saw during installability testing - you install hledger to try it out. Cabal builds it with process 1.0.1.3. You get enthusiastic and later try to cabal install hledger-X, but this fails (can not install hledger-X because hledger requires process-1.0.1.3). (In other, similar-seeming cases I have seen cabal rebuild the installed depender; I don't understand all of cabal's behaviour.) I presume the user could work around this by - ghc-pkg unregister hledger; cabal install hledger-X - installing hledger the first time with --constraint process-1.0.1.4 but I figured a low-impact to make things just work was to bump hledger's process dependency. Is it making sense ? I welcome further insights or better solutions. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: genprog-0.1
Hi! On Thu, Dec 9, 2010 at 1:48 PM, Alberto G. Corona agocor...@gmail.com wrote: assign rates of mutation for each statement, This could be assigned by evolution itself. If if will have high probability of mutation then resulting programs will not survive. So those probabilities can be assigned by evolution itself and be also something which is passed on with generations (with again possibility of mutations of those probabilities itself). As any part in a genetic algoritm, it is a trading of flexibility for huge gains of speed. take into accout that some of these tricks neded a subtantial fraction of the age of the universe to evolve using massively paralell hardware (ecosystems). What would be interesting is to have an evolution algorithm which would allow such protections to evolve during its run. So some kind of protection which would lower the rate of mutation for some code part. Species of programs means that the seed of the genetic algoritm must not be turing comoplete I guess. It must be specific for each problem. I do not see this as necessity. Just that those specimens which would use this power too much would probably not survive. (If they would remove protection for some sentences they have build before.) The mutation weigths are something conventional for coventional languages. Another option is to design an automodifying evolving language from scratch. That software DNA I guess, should follow closely the techniques of the real DNA. Your idea fits more here In the conventional approach, the turing incomplete templates can have pre-assigned mutation weights for each statement. These mutation rates can evolve too. However, nothing prevents from having an additional level for selecting the appropriate template for each problem. Mitar Alberto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rather off topic: An ab initio universe simulation?
Hi Ketil, In order to simulate nature, you need to have the mutation and selection process itself be part of the programs (and not the interpreter). Hence the interpreter can itself be modified? How about you have a world consisiting of some memory, bombard this world with cosmic radiation, and add some enzymatic activity in the form of an interpreter that interprets a location of the world as a simple language (that allows observation and modification of the world, as well as forking new threads of execution) - which is randomly started at random points. To be honest, I did not understand the location part... Life is really just core wars without the programmers :-) I'll quote you if I have the opportunity. - Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rather off topic: An ab initio universe simulation?
You can do all sorts of fun things with computers. Assuming that you are interested in modeling really real life, how will you estimate parameters (e.g. mutation rates) based on real data? How will you quantify whether this a good or a bad model? I think living in a fact-free world is a bit pointless, but there are plenty of people who got tenure that way... There's tons of this stuff in Artificial Life and a book with that title by Stephen Levy which make many grand claims. Tom On Thu, Dec 9, 2010 at 2:09 PM, Ketil Malde ke...@malde.org wrote: In order to simulate nature, you need to have the mutation and selection process itself be part of the programs (and not the interpreter). How about you have a world consisiting of some memory, bombard this world with cosmic radiation, and add some enzymatic activity in the form of an interpreter that interprets a location of the world as a simple language (that allows observation and modification of the world, as well as forking new threads of execution) - which is randomly started at random points. After some time, you might have threads that reproduce themselves, perhaps forming species, cooperation, pathogens, genders, and if you wait four billion years, civilizations... Life is really just core wars without the programmers :-) -k -- 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hledger 0.13
On Dec 9, 2010, at 7:34 AM, Peter Simons wrote: I can tell it's doing more harm than good. The situation right now is that it's impossible to install hledger on ArchLinux -- not because Why ? I haven't yet heard why depending on the higher process version is a problem. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hledger 0.13
On Dec 9, 2010, at 7:39 AM, Simon Michael wrote: On Dec 9, 2010, at 7:34 AM, Peter Simons wrote: that it's impossible to install hledger on ArchLinux -- not because Why ? I haven't yet heard why depending on the higher process version is a problem. Oh, is it because you are avoiding use of cabal-install and hackage entirely ? If so, how did hledger-0.13 get into the Arch packaging system, and why couldn't the same be done for process-1.0.1.4 ? I don't know how Arch works. Thanks for pursuing this and helping to flush out the issues. FWIW I'm still in process of re-testing cabal install of all five packages with process==1.0.1.3, that's currently stalled because cabal mysteriously insists on using the hledger from hackage. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hledger 0.13
Hi Simon, [Are you] avoiding use of cabal-install and hackage entirely? yes, I'm trying to provide a package for hledger 0.13 that can be installed using ArchLinux's native package manager. The current version is available here: http://aur.archlinux.org/packages.php?ID=20762. How did hledger-0.13 get into the Arch packaging system [...]. It isn't, but I'm trying to get it in. :-) Take care, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rather off topic: An ab initio universe simulation?
The good fact about evolutionary simulations is that all is theoretically possible . The bad fact is that in practice is very hard to achieve results. Biota.org has links to some artificial life projects.Some of them are naive, but some others may be interesting. http://www.biota.org/ http://www.biota.org/ 2010/12/9 Tom Nielsen taniel...@gmail.com You can do all sorts of fun things with computers. Assuming that you are interested in modeling really real life, how will you estimate parameters (e.g. mutation rates) based on real data? How will you quantify whether this a good or a bad model? I think living in a fact-free world is a bit pointless, but there are plenty of people who got tenure that way... There's tons of this stuff in Artificial Life and a book with that title by Stephen Levy which make many grand claims. Tom On Thu, Dec 9, 2010 at 2:09 PM, Ketil Malde ke...@malde.org wrote: In order to simulate nature, you need to have the mutation and selection process itself be part of the programs (and not the interpreter). How about you have a world consisiting of some memory, bombard this world with cosmic radiation, and add some enzymatic activity in the form of an interpreter that interprets a location of the world as a simple language (that allows observation and modification of the world, as well as forking new threads of execution) - which is randomly started at random points. After some time, you might have threads that reproduce themselves, perhaps forming species, cooperation, pathogens, genders, and if you wait four billion years, civilizations... Life is really just core wars without the programmers :-) -k -- 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 ___ 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] Monads in the 'hood
Dear Haskellians, Keepin' it light. For your amusement this weekend: monads in the hoodhttp://www.youtube.com/watch?v=rYANU61J5eY . Best wishes, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 1219 NW 83rd St Seattle, WA 98117 +1 206.650.3740 http://biosimilarity.blogspot.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] dot-ghci files
Perhaps ghc should also ignore all group-writable *.hs, *.lhs, *.c, *.o, *.hi files. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] dot-ghci files
Perhaps ghc should also ignore all group-writable *.hs, *.lhs, *.c, *.o, *.hi files. dot-ghci files are *run* if you just start ghci (or ghc -e) in that directory (even if you don't intend to compile, load, or run any Haskell code). Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] dot-ghci files
On 10-12-09 01:57 PM, Claus Reinke wrote: Perhaps ghc should also ignore all group-writable *.hs, *.lhs, *.c, *.o, *.hi files. dot-ghci files are *run* if you just start ghci (or ghc -e) in that directory (even if you don't intend to compile, load, or run any Haskell code). Haskell developers don't just run ghci. They go ahead to run arbitrary Haskell code too. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Operator #
What does # mean in this code ? (from Data.List) findIndices p ls = loop 0# ls where loop _ [] = [] loop n (x:xs) | p x = I# n : loop (n +# 1#) xs | otherwise = loop (n +# 1#) xs -- View this message in context: http://haskell.1045720.n5.nabble.com/Operator-tp3299360p3299360.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A home-brew iteration-alike library: some extension quiestions
Hi. I Wrote a simple iteration library. It was not intensively tested, so it MAY contatin bugs, but it is very unlikely. The library is currently on github: https://github.com/permeakra/iteration I'm not ready to upload it to hackage, as some testing and extension is really needed. However, I'd like to know about possible flaws. Current goal is addition of byte-stream (de)compression and IO functions extenstion. After this package will be cabalized and uploaded to hackage. So, while design is not frozen yet, I'm interested in criticism -)/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A home-brew iteration-alike library: some extension quiestions
I only have some surface level questions/comments - What existing packages is this similar to? How is it different from any previous work in the area? Also, likes looks like you don't need the 'Monad m' constraint on your various Monad and Functor instances in Data.Iteration.Types, which I think is one of the nicest properties of the continuation-based approach to something like this. It's a mater of taste which way to go, but I prefer importing modules qualified rather than have type-suffixes on functions - so I would rather use 'I.next' and 'A.next' instead of 'nextI' and 'nextA'. But reasonable people can disagree on this. Take care, Antoine On Thu, Dec 9, 2010 at 1:42 PM, Permjacov Evgeniy permea...@gmail.com wrote: Hi. I Wrote a simple iteration library. It was not intensively tested, so it MAY contatin bugs, but it is very unlikely. The library is currently on github: https://github.com/permeakra/iteration I'm not ready to upload it to hackage, as some testing and extension is really needed. However, I'd like to know about possible flaws. Current goal is addition of byte-stream (de)compression and IO functions extenstion. After this package will be cabalized and uploaded to hackage. So, while design is not frozen yet, I'm interested in criticism -)/ ___ 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] A home-brew iteration-alike library: some extension quiestions
Original Message Subject:Re: [Haskell-cafe] A home-brew iteration-alike library: some extension quiestions Date: Thu, 09 Dec 2010 23:07:49 +0300 From: Permjacov Evgeniy permea...@gmail.com To: Antoine Latter aslat...@gmail.com On 12/09/2010 10:54 PM, Antoine Latter wrote: I only have some surface level questions/comments - What existing packages is this similar to? How is it different from any previous work in the area? Main idea was taken from Iteratees invented by Oleg Kiselev (there are two packages on hackage implementing this ideas: data-iteraties and enumerator packages) The difference is, that I wished haskell-2010 compilant package for left-foldable streams, including support for easy builing, transcoding, merging and folding of streams relying on do-notation (see Data.Iteration.Unicode.* for examples of transcoding streams: it is quite clean and easily understandable) and ability to specify easily monadic actions in stream processors. Also, likes looks like you don't need the 'Monad m' constraint on your various Monad and Functor instances in Data.Iteration.Types, which I think is one of the nicest properties of the continuation-based approach to something like this. Errgh. That may be true, but I did not consider non-monadic context at all, so I enforced this constrain mindlessly It's a mater of taste which way to go, but I prefer importing modules qualified rather than have type-suffixes on functions - so I would rather use 'I.next' and 'A.next' instead of 'nextI' and 'nextA'. But reasonable people can disagree on this. Take care, Antoine Thanks! On Thu, Dec 9, 2010 at 1:42 PM, Permjacov Evgeniy permea...@gmail.com wrote: Hi. I Wrote a simple iteration library. It was not intensively tested, so it MAY contatin bugs, but it is very unlikely. The library is currently on github: https://github.com/permeakra/iteration I'm not ready to upload it to hackage, as some testing and extension is really needed. However, I'd like to know about possible flaws. Current goal is addition of byte-stream (de)compression and IO functions extenstion. After this package will be cabalized and uploaded to hackage. So, while design is not frozen yet, I'm interested in criticism -)/ ___ 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] A home-brew iteration-alike library: some extension quiestions
Also, one thing that tripped me up is that your Stream type is fundamentally different from the Stream types in the iteratee/enumerator libraries - yours is more of a monadic list in the inner monad, with explicit errors. How does this change the operation of the Iterator type? I hope I am not pestering you too much :-) I think it is really fascinating how many different approaches people have to the left-fold-enumerator idea, and it is hard for me to grasp which differences are fundamental and what the differences mean. Also, in what way are the other libraries not Haskell-2010 compliant? I haven't experimented too much with this sort of thing, since Cabal defaults to the Haskell '98 language, and that's how I install most things. Thanks for your response, Antoine On Thu, Dec 9, 2010 at 2:07 PM, Permjacov Evgeniy permea...@gmail.com wrote: On 12/09/2010 10:54 PM, Antoine Latter wrote: I only have some surface level questions/comments - What existing packages is this similar to? How is it different from any previous work in the area? Main idea was taken from Iteratees invented by Oleg Kiselev (there are two packages on hackage implementing this ideas: data-iteraties and enumerator packages) The difference is, that I wished haskell-2010 compilant package for left-foldable streams, including support for easy builing, transcoding, merging and folding of streams relying on do-notation (see Data.Iteration.Unicode.* for examples of transcoding streams: it is quite clean and easily understandable) and ability to specify easily monadic actions in stream processors. Also, likes looks like you don't need the 'Monad m' constraint on your various Monad and Functor instances in Data.Iteration.Types, which I think is one of the nicest properties of the continuation-based approach to something like this. Errgh. That may be true, but I did not consider non-monadic context at all, so I enforced this constrain mindlessly It's a mater of taste which way to go, but I prefer importing modules qualified rather than have type-suffixes on functions - so I would rather use 'I.next' and 'A.next' instead of 'nextI' and 'nextA'. But reasonable people can disagree on this. Take care, Antoine Thanks! On Thu, Dec 9, 2010 at 1:42 PM, Permjacov Evgeniy permea...@gmail.com wrote: Hi. I Wrote a simple iteration library. It was not intensively tested, so it MAY contatin bugs, but it is very unlikely. The library is currently on github: https://github.com/permeakra/iteration I'm not ready to upload it to hackage, as some testing and extension is really needed. However, I'd like to know about possible flaws. Current goal is addition of byte-stream (de)compression and IO functions extenstion. After this package will be cabalized and uploaded to hackage. So, while design is not frozen yet, I'm interested in criticism -)/ ___ 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] Operator #
On Thu, Dec 9, 2010 at 8:31 PM, c8h10n4o2 asaferibei...@ymail.com wrote: What does # mean in this code ? (from Data.List) It's a magic hash denoting here on the one hand unboxed machine ints (0#) and on the other the constructor wrapping such a raw machine int to a Haskell boxed Int (I#). GHC uses the magic hash to mark raw unboxed stuff (which you'll rarely need to use). In the libraries, sometimes using the raw machine data types (Int#, Word#, Double#, Float# and a few more) is needed for better performance. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A home-brew iteration-alike library: some extension quiestions
On 12/09/2010 11:17 PM, Antoine Latter wrote: Also, one thing that tripped me up is that your Stream type is fundamentally different from the Stream types in the iteratee/enumerator libraries - yours is more of a monadic list in the inner monad, with explicit errors. How does this change the operation of the Iterator type? The problem was that I wished Zippee. It means that external enumerator must be suspended at some points so Zippee can process elements from both left and right streams in desired order. It makes any other approach I considered impossible to use. Also, in what way are the other libraries not Haskell-2010 compliant? I haven't experimented too much with this sort of thing, since Cabal defaults to the Haskell '98 language, and that's how I install most things. Haskell-2010 does not include functional dependencies (wich are considered evil by many) and, as I recall, type families. This makes mtl haskell-2010 and haskell-98 uncompilant -(. Functional dependencies and type familes are tricky things, so it is better to avoid them. Thanks for your response, Antoine On Thu, Dec 9, 2010 at 2:07 PM, Permjacov Evgeniy permea...@gmail.com wrote: On 12/09/2010 10:54 PM, Antoine Latter wrote: I only have some surface level questions/comments - What existing packages is this similar to? How is it different from any previous work in the area? Main idea was taken from Iteratees invented by Oleg Kiselev (there are two packages on hackage implementing this ideas: data-iteraties and enumerator packages) The difference is, that I wished haskell-2010 compilant package for left-foldable streams, including support for easy builing, transcoding, merging and folding of streams relying on do-notation (see Data.Iteration.Unicode.* for examples of transcoding streams: it is quite clean and easily understandable) and ability to specify easily monadic actions in stream processors. Also, likes looks like you don't need the 'Monad m' constraint on your various Monad and Functor instances in Data.Iteration.Types, which I think is one of the nicest properties of the continuation-based approach to something like this. Errgh. That may be true, but I did not consider non-monadic context at all, so I enforced this constrain mindlessly It's a mater of taste which way to go, but I prefer importing modules qualified rather than have type-suffixes on functions - so I would rather use 'I.next' and 'A.next' instead of 'nextI' and 'nextA'. But reasonable people can disagree on this. Take care, Antoine Thanks! On Thu, Dec 9, 2010 at 1:42 PM, Permjacov Evgeniy permea...@gmail.com wrote: Hi. I Wrote a simple iteration library. It was not intensively tested, so it MAY contatin bugs, but it is very unlikely. The library is currently on github: https://github.com/permeakra/iteration I'm not ready to upload it to hackage, as some testing and extension is really needed. However, I'd like to know about possible flaws. Current goal is addition of byte-stream (de)compression and IO functions extenstion. After this package will be cabalized and uploaded to hackage. So, while design is not frozen yet, I'm interested in criticism -)/ ___ 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] A home-brew iteration-alike library: some extension quiestions
On Thu, Dec 9, 2010 at 10:32 PM, Permjacov Evgeniy permea...@gmail.com wrote: On 12/09/2010 11:17 PM, Antoine Latter wrote: Also, one thing that tripped me up is that your Stream type is fundamentally different from the Stream types in the iteratee/enumerator libraries - yours is more of a monadic list in the inner monad, with explicit errors. How does this change the operation of the Iterator type? The problem was that I wished Zippee. It means that external enumerator must be suspended at some points so Zippee can process elements from both left and right streams in desired order. It makes any other approach I considered impossible to use. Also, in what way are the other libraries not Haskell-2010 compliant? I haven't experimented too much with this sort of thing, since Cabal defaults to the Haskell '98 language, and that's how I install most things. Haskell-2010 does not include functional dependencies (wich are considered evil by many) and, as I recall, type families. This makes mtl haskell-2010 and haskell-98 uncompilant -(. Functional dependencies and type familes are tricky things, so it is better to avoid them. For the record, enumerator (and I believe iteratee as well) uses transformers, not mtl. transformers itself is Haskell98; all FunDep code is separated out to monads-fd. Michael Thanks for your response, Antoine On Thu, Dec 9, 2010 at 2:07 PM, Permjacov Evgeniy permea...@gmail.com wrote: On 12/09/2010 10:54 PM, Antoine Latter wrote: I only have some surface level questions/comments - What existing packages is this similar to? How is it different from any previous work in the area? Main idea was taken from Iteratees invented by Oleg Kiselev (there are two packages on hackage implementing this ideas: data-iteraties and enumerator packages) The difference is, that I wished haskell-2010 compilant package for left-foldable streams, including support for easy builing, transcoding, merging and folding of streams relying on do-notation (see Data.Iteration.Unicode.* for examples of transcoding streams: it is quite clean and easily understandable) and ability to specify easily monadic actions in stream processors. Also, likes looks like you don't need the 'Monad m' constraint on your various Monad and Functor instances in Data.Iteration.Types, which I think is one of the nicest properties of the continuation-based approach to something like this. Errgh. That may be true, but I did not consider non-monadic context at all, so I enforced this constrain mindlessly It's a mater of taste which way to go, but I prefer importing modules qualified rather than have type-suffixes on functions - so I would rather use 'I.next' and 'A.next' instead of 'nextI' and 'nextA'. But reasonable people can disagree on this. Take care, Antoine Thanks! On Thu, Dec 9, 2010 at 1:42 PM, Permjacov Evgeniy permea...@gmail.com wrote: Hi. I Wrote a simple iteration library. It was not intensively tested, so it MAY contatin bugs, but it is very unlikely. The library is currently on github: https://github.com/permeakra/iteration I'm not ready to upload it to hackage, as some testing and extension is really needed. However, I'd like to know about possible flaws. Current goal is addition of byte-stream (de)compression and IO functions extenstion. After this package will be cabalized and uploaded to hackage. So, while design is not frozen yet, I'm interested in criticism -)/ ___ 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] Offer to mirror Hackage
On 10/12/2010, at 12:18 AM, Markus Läll wrote: My take on the issue is that we should make it possible to easily mirror hackage (what the OP asked for), so that people could use it when they wanted to, and have a list of the mirrors on the wiki. This way those who are interested can use them. Like when the mirror is faster/closer to them or to help out when hackage is temporarily down. Those who need the security can choose not to use mirrors, or make their own (private), or develop a secure scheme, when it doesn't exist yet. Have I misunderstood something? I thought X is a mirror of Y meant X would be a read-only replica of Y, with some sort of protocol between X and Y to keep X up to date. As long as the material from Y replicated at X is *supposed* to be publicly available, I don't see a security problem here. Only Y accepts updates from outside, and it continues to do whatever authentication it would do without a mirror. The mirror X would *not* accept updates. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANNOUNCE] haskell-mpi-1.0.0
Dear Haskellers, We are pleased to announce the release of haskell-mpi-1.0.0, a suite of Haskell bindings to the C MPI library and convenience APIs on top of it. About MPI - MPI, the Message Passing Interface, is a popular communications protocol for distributed parallel computing (http://www.mpi-forum.org/). MPI applications consist of independent computing processes which share information by message passing. It supports both point-to-point and collective communication operators, and manages much of the mundane aspects of message delivery. There are several high-quality implementations of MPI available, all of which conform to the standard API specification (the latest version of which is 2.2). The MPI specification defines interfaces for C, C++ and Fortran, and bindings are available for many other programming languages. About Haskell-MPI - As the name suggests, Haskell-MPI provides a Haskell interface to MPI, and thus facilitates distributed parallel programming in Haskell. It is implemented on top of the C API via Haskell's foreign function interface. Haskell-MPI provides three different ways to access MPI's functionality: * A direct binding to the C interface (see Control.Parallel.MPI.Internal). * A convenient interface for sending arbitrary serializable Haskell data values as messages (see Control.Parallel.MPI.Simple). * A high-performance interface for working with (possibly mutable) arrays of storable Haskell data types (see Control.Parallel.MPI.Fast). We do not currently provide exhaustive coverage of all the functions and types defined by MPI 2.2, although we do provide bindings to the most commonly used parts. In future we plan to extend coverage based on the needs of projects which use the library. The package is available from http://hackage.haskell.org/package/haskell-mpi. Examples and comprehensive testsuite are included in the source distribution. Code was tested on 32- and 64-bit platforms, with MPICH2 and OpenMPI. The Fast API shows performance comparable to C, and the Simple API is generally 2-7 time slower due to (de)serialization overhead and necessity to issue additional MPI requests behind the curtains in some cases. Bernie Pope started this project as a rewrite of hMPI which was written by Michael Weber and Hal Daume III. He was later joined by Dmitry Astapov, working on the library as part of Well-Typed LLP's Parallel Haskell Project. Development is happening on GitHub, in git://github.com/bjpop/haskell-mpi. Please join in! Sincerely yours, Dmitry Astapov, Bernie Pope -- Dmitry Astapov Well-Typed LLP, http://www.well-typed.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Offer to mirror Hackage
Richard O'Keefe o...@cs.otago.ac.nz wrote: I thought X is a mirror of Y meant X would be a read-only replica of Y, with some sort of protocol between X and Y to keep X up to date. As long as the material from Y replicated at X is *supposed* to be publicly available, I don't see a security problem here. Only Y accepts updates from outside, and it continues to do whatever authentication it would do without a mirror. The mirror X would *not* accept updates. At the very least, this assumes that you trust all the mirror operators. Sure, I'm trustworthy, but how about those other guys? :) -=rsw ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Offer to mirror Hackage
On Thu, Dec 9, 2010 at 11:04 PM, Richard O'Keefe o...@cs.otago.ac.nz wrote: On 10/12/2010, at 12:18 AM, Markus Läll wrote: My take on the issue is that we should make it possible to easily mirror hackage (what the OP asked for), so that people could use it when they wanted to, and have a list of the mirrors on the wiki. This way those who are interested can use them. Like when the mirror is faster/closer to them or to help out when hackage is temporarily down. Those who need the security can choose not to use mirrors, or make their own (private), or develop a secure scheme, when it doesn't exist yet. Have I misunderstood something? I thought X is a mirror of Y meant X would be a read-only replica of Y, with some sort of protocol between X and Y to keep X up to date. As long as the material from Y replicated at X is *supposed* to be publicly available, I don't see a security problem here. Only Y accepts updates from outside, and it continues to do whatever authentication it would do without a mirror. The mirror X would *not* accept updates. Yes, that's what I think of mirrors too. I don't know if that was what you meant, but yes those mirrors would be just passive copies of the real hackage server (no updates from a user), and serve as a place to download packages from until the original hackage comes back. But for the security issue, ofcourse any host of a mirror could abuse that. But I think for non-critical stuff I wouldn't mind using the mirror if it has shown to be trustworthy. And for people using Haskell a lot, if the making of your own mirror is as simple as installing some package on your webserver and running it, then this would be a great remedy against those hours when something has happened to hackage.. -- Markus Läll ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rather off topic: An ab initio universe simulation?
Michael Lesniak mlesn...@uni-kassel.de writes: Hence the interpreter can itself be modified? Well - the interpreter in nature is chemistry. Living organisms are just chemistry programs. -k -- 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] Rather off topic: An ab initio universe simulation?
Have you read: Fontana Buss : What would be conserved if 'the tape were played twice'? in PNAS? It's quite fun - they model chemical reaction as alpha-reduction in the lambda calculus and look at evolution. Tom On Thu, Dec 9, 2010 at 10:15 PM, Ketil Malde ke...@malde.org wrote: Michael Lesniak mlesn...@uni-kassel.de writes: Hence the interpreter can itself be modified? Well - the interpreter in nature is chemistry. Living organisms are just chemistry programs. -k -- 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Digestive functors 0.0.2.0
Hello all, I'm very glad to announce the 0.0.2.0 release of the digestive functors library. The library provides a general API to input consumption, and is an upgrade of formlets. I've written an announcing blogpost and tutorial with more information here: http://jaspervdj.be/posts/2010-12-09-digestive-functors-0.0.2.html You can get it on hackage here: http://hackage.haskell.org/package/digestive-functors As always, all feedback is welcome. Kindest regards, Jasper Van der Jeugt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: mime-mail 0.1.0
On Thu, 2010-12-09 at 11:53 +0200, Michael Snoyman wrote: On Thu, Dec 9, 2010 at 11:48 AM, Magnus Therning mag...@therning.org wrote: On Wed, Dec 8, 2010 at 19:11, Michael Snoyman mich...@snoyman.com wrote: Hi all (again), I'm happy to announce the second major release of the mime-mail[1] package. mime-mail is a package providing support for rendering multipart emails. This new release introduces: Very nice! Are you working on a parser to accompany the renderer? ;-) /M I'm not currently, though that is definitely a direction the project could expand to. I've already written some multipart-parsing code in wai-extra, though that code probably wouldn't help here too much. The quoted-printable decoding is simple enough to write, and base64-decoding has already been solved. Is this a challenge anyone out there wants to undertake? Michael Hmm. Probably no. I wanted to write a proper parser for MIME for nntp package but I gave up in the middle of RFC and concentrated on more interesting problems. Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Offer to mirror Hackage
On 9 December 2010 21:04, Richard O'Keefe o...@cs.otago.ac.nz wrote: On 10/12/2010, at 12:18 AM, Markus Läll wrote: My take on the issue is that we should make it possible to easily mirror hackage (what the OP asked for), so that people could use it when they wanted to, and have a list of the mirrors on the wiki. This way those who are interested can use them. Like when the mirror is faster/closer to them or to help out when hackage is temporarily down. Those who need the security can choose not to use mirrors, or make their own (private), or develop a secure scheme, when it doesn't exist yet. Have I misunderstood something? I thought X is a mirror of Y meant X would be a read-only replica of Y, with some sort of protocol between X and Y to keep X up to date. As long as the material from Y replicated at X is *supposed* to be publicly available, I don't see a security problem here. Only Y accepts updates from outside, and it continues to do whatever authentication it would do without a mirror. The mirror X would *not* accept updates. That's certainly what we've been planning on, that anyone can run a mirror, no permissions needed. The issue people have raised is what about having public mirrors that are used automatically or semi-automatically by clients. The suggestion about DNS round robin is transparent to clients but requires all the mirrors to be a master, or to have some forwarding system. Any transparent system also needs trust. My opinion is that at this stage it is not really worth doing anything complicated. We do not yet have a bandwidth problem. Once there are more (unpriviledged) public and private mirrors then temporary downtime on the main server is less problematic. Eventually we'll get a bandwidth problem but I think we've got a fair bit of time to prepare and in the mean time we can get simple unpriviledged mirroring working. That is mostly an issue of specifications and tools. The spec for package archives is not as clear or as good as we'd like. We've been discussing it recently on the cabal-devel mailing list. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell2010 and state question.
On Wed, Dec 8, 2010 at 6:46 PM, Henk-Jan van Tuyl hjgt...@chello.nl wrote: On Wed, 08 Dec 2010 10:03:40 +0100, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hi, Formerly, I had IORef and some state monad to do the task of keeping states. Now in haskell 2010, I cannot find anything about it. Do I have to use ghc base package for this function? These are not standard Haskell '98 or Haskell 2010. You can find IORef in the base package; the state monad is in both the mtl and the transformers package (mtl is deprecated). The state monad uses the multi-parameter type class extension and is therefore not in standard Haskell '98 or Haskell 2010 code. IORef also uses non-standard code. Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html -- First to notice that. So standard-wise, there is no way to do state thing? -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Offer to mirror Hackage
On 10/12/2010, at 10:50 AM, Riad S. Wahby wrote: Richard O'Keefe o...@cs.otago.ac.nz wrote: I thought X is a mirror of Y meant X would be a read-only replica of Y, with some sort of protocol between X and Y to keep X up to date. As long as the material from Y replicated at X is *supposed* to be publicly available, I don't see a security problem here. Only Y accepts updates from outside, and it continues to do whatever authentication it would do without a mirror. The mirror X would *not* accept updates. At the very least, this assumes that you trust all the mirror operators. Sure, I'm trustworthy, but how about those other guys? :) See the words some sort of protocol between X and Y? This means that Y has to be authenticated to X and X to Y and they use some sort of encryption scheme that prevents man-in-the-middle attacks. Right now, of course, nothing whatever stops someone building a 'robot' at X to visit Y periodically and update X; the missing piece is any kind of accreditation at Y. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell2010 and state question.
On 10 December 2010 01:40, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: On Wed, Dec 8, 2010 at 6:46 PM, Henk-Jan van Tuyl hjgt...@chello.nl wrote: On Wed, 08 Dec 2010 10:03:40 +0100, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hi, Formerly, I had IORef and some state monad to do the task of keeping states. Now in haskell 2010, I cannot find anything about it. Do I have to use ghc base package for this function? These are not standard Haskell '98 or Haskell 2010. You can find IORef in the base package; the state monad is in both the mtl and the transformers package (mtl is deprecated). The state monad uses the multi-parameter type class extension and is therefore not in standard Haskell '98 or Haskell 2010 code. IORef also uses non-standard code. Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html -- First to notice that. So standard-wise, there is no way to do state thing? It's not hard to create your own state monad. You are right, though, that there is no standard library support for this in the Haskell2010 standard. -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Digestive functors 0.0.2.0
Very nice. I like the addition of the CLI interface. I was inspired by this library and Chris Eidhof's Formlets to try to port this idea to Scala. https://github.com/wrwills/scormlets It's not as elegant or as complete as this but it helped me to get my head around this very cool idea. -Rob On Thu, Dec 9, 2010 at 10:46 PM, Jasper Van der Jeugt jasper...@gmail.com wrote: Hello all, I'm very glad to announce the 0.0.2.0 release of the digestive functors library. The library provides a general API to input consumption, and is an upgrade of formlets. I've written an announcing blogpost and tutorial with more information here: http://jaspervdj.be/posts/2010-12-09-digestive-functors-0.0.2.html You can get it on hackage here: http://hackage.haskell.org/package/digestive-functors As always, all feedback is welcome. Kindest regards, Jasper Van der Jeugt ___ 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] GHC 7.0.1 developer challenges
I found out how to compute a good memory limit for the GHC runtime on
Linux systems. One opens /proc/meminfo, and sums the free memory with
the reclaimable memory. The memory allocated to file buffers and the
disk cache are reclaimable, and can be added to the memory of a
growing GHC process. Once you get beyond that memory size, thrashing
is in your futures.
I have enclosed a short lex program that computes the limit. It's
basically what is done by the procpc program called free, except that
I printed only the number of interest to a GHC runtime.
John
/* Compute the free memory on a Linux system with /proc/meminfo */
%{
#include stdio.h
#include stdlib.h
static int mem_free = 0, buffers = 0, cached = 0;
%}
DIGITS [0-9]+
SP [ \t]+
%%
^MemFree:{SP}{DIGITS} { mem_free = atoi(yytext + 8); }
^Buffers:{SP}{DIGITS} { buffers = atoi(yytext + 8); }
^Cached:{SP}{DIGITS}{ cached = atoi(yytext + 7); }
.|\n{ }
%%
int main(void)
{
const char meminfo[] = /proc/meminfo;
yyin = fopen(meminfo, r);
if (!yyin) {
fprintf(stderr, Cannot open %s\n, meminfo);
return 1;
}
int rc = yylex();
if (rc) return rc;
printf(%dm\n, (mem_free + buffers + cached) 10);
return 0;
}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A home-brew iteration-alike library: some extension quiestions
On Thu, Dec 9, 2010 at 12:43, Michael Snoyman mich...@snoyman.com wrote: For the record, enumerator (and I believe iteratee as well) uses transformers, not mtl. transformers itself is Haskell98; all FunDep code is separated out to monads-fd. Michael iteratee also uses 'transformers', but requires several extensions; see http://hackage.haskell.org/packages/archive/iteratee/0.6.0.1/doc/html/src/Data-Iteratee-Base.html It seems silly to avoid extensions, though; every non-trivial package on Hackage depends on them, either directly or via a dependency. For example, though 'enumerator' requires no extensions itself, it depends on both 'text' and 'bytestring', which require a ton of them. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Missing Functor instances in GHC 7?
Hello, according to http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html Control.Monad exports 20 Functor instance declarations in base-4.3.0.0. However: bash# ghc-pkg list | grep base base-4.3.0.0 bash# ghci --version The Glorious Glasgow Haskell Compilation System, version 7.0.1 bash# ghci Prelude import Control.Monad Prelude Control.Monad :i Functor class Functor f where fmap :: (a - b) - f a - f b (GHC.Base.$) :: a - f b - f a -- Defined in GHC.Base instance Functor Maybe -- Defined in Data.Maybe instance Functor [] -- Defined in GHC.Base instance Functor IO -- Defined in GHC.Base There are only 3 instances instead of 20. Importing Control.Applicative gives 3 more instances but for example the instance for ((-) r) is still missing. Is my installation broken? Or has anybody similar problems finding Functor instances in GHC 7? Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Missing Functor instances in GHC 7?
Hi Sebastian, I imagine that many of the instances are defined in the module that defines the data type. For example, the STM instance is defined in the same module as the STM type. Are there any particular ones you're running into problems with? Take care, Antoine On Thu, Dec 9, 2010 at 11:10 PM, Sebastian Fischer fisc...@nii.ac.jp wrote: Hello, according to http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html Control.Monad exports 20 Functor instance declarations in base-4.3.0.0. However: bash# ghc-pkg list | grep base base-4.3.0.0 bash# ghci --version The Glorious Glasgow Haskell Compilation System, version 7.0.1 bash# ghci Prelude import Control.Monad Prelude Control.Monad :i Functor class Functor f where fmap :: (a - b) - f a - f b (GHC.Base.$) :: a - f b - f a -- Defined in GHC.Base instance Functor Maybe -- Defined in Data.Maybe instance Functor [] -- Defined in GHC.Base instance Functor IO -- Defined in GHC.Base There are only 3 instances instead of 20. Importing Control.Applicative gives 3 more instances but for example the instance for ((-) r) is still missing. Is my installation broken? Or has anybody similar problems finding Functor instances in GHC 7? Sebastian ___ 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] Missing Functor instances in GHC 7?
Hi Antoine, On Thu, 2010-12-09 at 23:20 -0600, Antoine Latter wrote: Are there any particular ones you're running into problems with? Yes, I cannot find the instance for ((-) r). Even if I import Control.Monad Control.Monad.Reader Control.Applicative Data.Functor Data.Function I still get ghci ((+) $ id * id) 21 interactive:1:1: No instance for (Functor ((-) a)) Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Missing Functor instances in GHC 7?
On Fri, 2010-12-10 at 14:35 +0900, Sebastian Fischer wrote: Yes, I cannot find the Functor instance for ((-) r). As the Applicative instance for ((-) r) depends on the Functor instance I only needed to go through the imports of Control.Applicative to find that the Functor instance of ((-) r) is defined in Control.Monad.Instances. If I import this module into GHCi, it finds the instance. Interestingly, if I import only Control.Applicative from within GHCi, it does not find the instances defined in Control.Monad.Instances although this module is imported in Control.Applicative. On the other hand, if I write a file containing the line 'import Control.Applicative' and load this file in GHCi then the instances from Control.Monad.Instances are visible. Apparently, importing a module in GHCi differs from importing it in a Haskell file and loading this into GHCi. Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] haskell-2010 binary IO
Does haskell 2010 include binary IO? If no, what was the reason? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
