[Haskell-cafe] ANNOUNCE: fgl-5.4.2.3
I'm pleased to present the first new release of fgl [1] since Thomas Bereknyei took over maintaining it from Martin Erwig. [1] http://hackage.haskell.org/package/fgl Before people start panicking, rioting, etc., please check the version number: this is just a bug-fix release, and not the complete re-write version which we've been talking about (since we got a little sidetracked, etc.). As such, the API hasn't changed, and this should fit right in to packages already using fgl (sorry to all those people who followed my advice and put fgl == 5.4.2.2 in the build-depends fields of their packages' .cabal files, but I didn't expect to make another 5.4.y release). The exact change that has been made is to fix a bug pointed out to me by Tristan Allwood, in that Data.Graph.Inductive.PatriciaTree didn't support multiple edges (and furthermore this wasn't specified in the documentation). This has now been rectified. As an indication of what these changes mean, see this sample call graph produced by my SourceGraph program; when using PatriciaTree from fgl-5.4.2.2 the lines were all the same thickness; now there is among other things a loop of width 32 on getExp and a line of width 7 from getExp to maybeEnt. -- 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] ANNOUCE: graphviz-2999.10.0.0
I'm pleased to announce a new version of my graphviz [1] library that provides bindings to the Graphviz [2] suite of tools for visualising graphs. [1]: http://hackage.haskell.org/package/graphviz [2]: http://graphviz.org/ Changes in this release: * I followed my own advice and put in bounds on the version of FGL it used... * Conversion of FGL-style graphs to `DotRepr` values is now achieved using the new `GraphvizParams` configuration type. This allows us to define a single parameter that stores all the conversion functions to pass around rather than having to pass around several functions. This also allows all the non-clustered and clustered functions to be collapsed together, whereas what used to be handled by the primed functions is now achieved by using the `setDirectedness` function. There are three default `GraphvizParams` available: - `defaultParams` provides some sensible defaults (no attributes or clustering). - `nonClusteredParams` is an alias of `defaultParams` where the clustering type is explicitly set to be `()` for cases where you don't want any clustering at all (whereas `defaultParams` allows you to set your own clustering functions). - `blankParams` sets all fields to be `undefined`; this is useful for situations where you have functions that will set some values for you and there is no sensible default you can use (mainly for the clustering function). * Expansion of the `DotRepr` class: - More common functions are now defined as methods (`getID`, etc.). - The ability to get more information about the structure of the `DotRepr` graph, as well as where all the `DotNode`s are, etc. - `graphNodes` now returns `DotNode`s defined only as part of `DotEdge`s, and will also merge duplicate `DotNode`s together. - `graphNodes` and `graphEdges` also return `GlobalAttributes` that apply to them. * The `Point` type now only has one constructor: `Point Double Double`. The `Int`-only constructor was present due to historical purposes and I thought that the `Pos` value for a `DotNode` would always be a pair of `Int`s; this turns out not to be the case (and accounted for some bugs in older versions of my SourceGraph tool; it's taken me this long to remember to fix this...). * `SortV` and `PrismOverlap` now only take `Word16` values rather than `Int`s, as they're not meant to allow negative values (the choice of using `Word16` rather than `Word` was arbitrary, and because it's unlikely those values will be large enough to require the larger values available in `Word`). * `NodeCluster` has been generalised to not have to take an `LNode` for the node type; the type alias `LNodeCluster` is available if you still want this. * Several documentation typos fixed, including one spotted by Kevin Quick. * The test-suite now allows running individual tests. -- 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] The site has been exploited (again)
On 11 July 2010 20:53, Don Stewart d...@galois.com wrote: It looks like after the Yale machine was repaved, and the mediawiki instance restored, some plugins (and templates) went missing, including those that previously prevented such spam accounts. A new machine has been purchased this week that will become the primary home for haskell.org, and work is just started to migrate everything to the new machine -- at which point we'll have a *current* MediaWiki for the first time in a long time, new templates etc. -- Don Fantastic news! I look forward to it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: SourceGraph-0.6.1.1 and Graphalyze-0.10.0.0
I'm pleased to announce updated versions of SourceGraph [1] (my graph-theoretic static analysis tool for Haskell) and Graphalyze [2] (a library for graph-theoretic analysis of relationships in discrete data). [1]: http://hackage.haskell.org/package/SourceGraph [2]: http://hackage.haskell.org/package/Graphalyze This version of SourceGraph now (should) only consider executables listed in .cabal files as being buildable, and both packages have been updated to use the latest versions of fgl (as well as following my own advice in putting an upper bound on the version of fgl being used...), graphviz and haskell-src-exts (SourceGraph only). Please note that SourceGraph-0.6.1.0 was a version I forgot to upload (and just realised this when I wondered why it wasn't appearing on Hackage...). The big change that should be apparent with this version of SourceGraph is that thanks to the changes I just made to the newly-uploaded fgl-5.4.2.3, multiple edges are finally being handled/visualised properly; for example see the nice thick lines in http://code.haskell.org/~ivanm/Sample_SourceGraph/SourceGraph/graphs/codeCore.svg (which represents among other things 32 recursive calls within getExp and 7 calls from getExp to maybeEnt). I forgot to put this in the TODOs, but here are my future plans for these packages. They're rather ambitious and I have no idea when I'll get around to them, but for all intents the only work I'm going to do on them until I do these splitting up goals is bug-fixes, etc. Graphalyze -- Graphalyze is going to fade away: I'm going to integrate its data - graph conversion utilities into either my new graph library I'm going to work on during AusHack or into the successor for fgl Thomas Bereknyei and are working on (whatever we'll end up calling it), the Data.Graph.Analysis.Algorithms modules into graph-algorithms and fgl-algorithms packages and the reporting stuff into its own reporting library with different backends (pandoc, blaze, etc.). SourceGraph --- I want to split out and formalise the whole call-graph definitions and concepts into its own library and have sub-libraries for different languages to be able to have their own code - call-graph conversions (so it can also be used for language-c, language-python, etc.). SourceGraph itself would then be more flexible in terms of what languages it can deal with (so it might even be possible to integrate C source files in a Haskell package into the call graph!). -- 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] Re: ANNOUCE: graphviz-2999.10.0.0
Something I forgot to mention (yes, I forgot to mention something here as well as for the fgl announcement): I sent out an email during the week asking people what they'd prefer in terms of semantics as a pure Haskell implementation for dot -Tcanon. I didn't end up getting around to implementing this yet (as I wanted to get all these packages out first and I'm still reverse-engineering all the corner cases dealing with what happens to nodes in a cluster that has the same name as another cluster), but the infrastructure for doing so is all there so there may be a 2999.10.1.0 release soon with this feature. Ivan Lazar Miljenovic ivan.miljeno...@gmail.com writes: I'm pleased to announce a new version of my graphviz [1] library that provides bindings to the Graphviz [2] suite of tools for visualising graphs. [1]: http://hackage.haskell.org/package/graphviz [2]: http://graphviz.org/ Changes in this release: * I followed my own advice and put in bounds on the version of FGL it used... * Conversion of FGL-style graphs to `DotRepr` values is now achieved using the new `GraphvizParams` configuration type. This allows us to define a single parameter that stores all the conversion functions to pass around rather than having to pass around several functions. This also allows all the non-clustered and clustered functions to be collapsed together, whereas what used to be handled by the primed functions is now achieved by using the `setDirectedness` function. There are three default `GraphvizParams` available: - `defaultParams` provides some sensible defaults (no attributes or clustering). - `nonClusteredParams` is an alias of `defaultParams` where the clustering type is explicitly set to be `()` for cases where you don't want any clustering at all (whereas `defaultParams` allows you to set your own clustering functions). - `blankParams` sets all fields to be `undefined`; this is useful for situations where you have functions that will set some values for you and there is no sensible default you can use (mainly for the clustering function). * Expansion of the `DotRepr` class: - More common functions are now defined as methods (`getID`, etc.). - The ability to get more information about the structure of the `DotRepr` graph, as well as where all the `DotNode`s are, etc. - `graphNodes` now returns `DotNode`s defined only as part of `DotEdge`s, and will also merge duplicate `DotNode`s together. - `graphNodes` and `graphEdges` also return `GlobalAttributes` that apply to them. * The `Point` type now only has one constructor: `Point Double Double`. The `Int`-only constructor was present due to historical purposes and I thought that the `Pos` value for a `DotNode` would always be a pair of `Int`s; this turns out not to be the case (and accounted for some bugs in older versions of my SourceGraph tool; it's taken me this long to remember to fix this...). * `SortV` and `PrismOverlap` now only take `Word16` values rather than `Int`s, as they're not meant to allow negative values (the choice of using `Word16` rather than `Word` was arbitrary, and because it's unlikely those values will be large enough to require the larger values available in `Word`). * `NodeCluster` has been generalised to not have to take an `LNode` for the node type; the type alias `LNodeCluster` is available if you still want this. * Several documentation typos fixed, including one spotted by Kevin Quick. * The test-suite now allows running individual tests. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com -- 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] Re: ANNOUNCE: fgl-5.4.2.3
A couple of points I meant to make here but forgot (I was busy hacking on this and my other three graph-related packages for over a week now, and especially this past weekend it cut into my sleeping...): * Apart from bug-fixes, I don't intend on touching the 5.4 series any more. That said, I believe that this version is suitable for replacing 5.4.2.2 in the platform (what's the process on that?). * After I get my generic graph class sorted out at AusHac this coming weekend, I intend to make a 5.5.0.0 release which extends the classes in this new library; this will probably _not_ be suitable for the platform and is intended to serve as a stepping stone to the replacement library Thomas Bereknyei and I are working on. With that last point: Thomas and I are willing to call this new version/replacement something like inductive-graphs if that is the preference of the community. Does anyone know of a website that would let us have a survey we can use to determine which option people would prefer? Note that even if we give it a new name (rather than just a new major version number), we still intend on using the Data.Graph.Inductive module namespace (as it makes even more sense with the new name), so there will still be clashes between this new version and fgl. Ivan Lazar Miljenovic ivan.miljeno...@gmail.com writes: I'm pleased to present the first new release of fgl [1] since Thomas Bereknyei took over maintaining it from Martin Erwig. [1] http://hackage.haskell.org/package/fgl Before people start panicking, rioting, etc., please check the version number: this is just a bug-fix release, and not the complete re-write version which we've been talking about (since we got a little sidetracked, etc.). As such, the API hasn't changed, and this should fit right in to packages already using fgl (sorry to all those people who followed my advice and put fgl == 5.4.2.2 in the build-depends fields of their packages' .cabal files, but I didn't expect to make another 5.4.y release). The exact change that has been made is to fix a bug pointed out to me by Tristan Allwood, in that Data.Graph.Inductive.PatriciaTree didn't support multiple edges (and furthermore this wasn't specified in the documentation). This has now been rectified. As an indication of what these changes mean, see this sample call graph produced by my SourceGraph program; when using PatriciaTree from fgl-5.4.2.2 the lines were all the same thickness; now there is among other things a loop of width 32 on getExp and a line of width 7 from getExp to maybeEnt. -- 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] haskell on suse?
Hello, cafeers! Are there OpenSuse repositories with ghc-6.12 maintained? Some months ago I installed 6.12.1 from someone's repository but now it's unavailable. My system is 11.2 (x86_64). Only ghc*6.10.4-7.1 packages are present. -- Iliya Kuznetsov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Actually loading a Cabal package in GHCi
d...@patriot.net writes: d...@hypno:~/haschorus-1.2.1$ ghci GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude :m Haskore No error message here? Haskore should now be in scope. Did you try ':i AbsPitch'? If that worked, and you still get the error below, you need to check HasScales's imports. Prelude Haskore :l HasScales [1 of 1] Compiling HasScales( HasScales.lhs, interpreted ) HasScales.lhs:33:16: Not in scope: type constructor or class `AbsPitch' And so on (lots of similar errors). Haskore defines AbsPitch. Did you try :browse Haskore to check that it does, in fact, export AbsPitch? I can't even load Haskore, because it is a package module, to wit: This is expected, you use :m to import those. -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] Re: Equivalence of two expressions
Grigory Sarnitskiy wrote: I'm not very familiar with algebra and I have a question. Imagine we have ring K. We also have two expressions formed by elements from K and binary operations (+) (*) from K. Can we decide weather these two expressions are equivalent? If there is such an algorithm, where can I find something in Haskell about it? If there is no such algorithm for a ring, maybe there is for a field? Deciding whether two elements are equal depends a lot on the ring K in question. For instance, if K is the ring of polynomials in one variable, you have, every element has the normal form a_0 + a_1 * x + a_2 * x^2 + .. + a_n * x^n and you can compare coefficients to decide whether equalities like (x-1)(x^2+x+1) = x^3 - 1 hold. For polynomial rings in several variables, things are trickier, but there is Buchberger's algorithm that can be used to solve such problems. As Michael already mentioned, the problem is undecidable in general since it includes group rings. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: Haskell 2010 Report (final)
On 08/07/2010 21:34, John Meacham wrote: On Tue, Jul 06, 2010 at 09:48:20PM +0300, Roman Cheplyaka wrote: Greetings! Now, can different compiler/interpreter authors make statements about support of this standard in their compilers please? Jhc supports all the language features of haskell 2010 except pattern guards. (ironic as I am a huge fan of said feature.) The library situation is more complicated, there is tension between haskell 98, haskell 2010, and supporting code in the wild, which often assumes some specific version of ghc's base, which doesn't quite conform to either. My current thinking is to give up supporting base directly as a clone of ghc's and rather support just haskell 98 and haskell 2010 modes natively, then compatability libraries (called things like ghc-base-4 and ghc-base-3 perhaps) would be independent projects and not tied to jhc releases. The story we tentatively plan to provide in GHC 6.14.1 is a haskell2010 package that provides exactly the API specified by the report (by definition, since the source was used to generate the report :-). The modules of haskell2010 overlap with base, so it will be impossible to depend on both haskell2010 and base, without using non-portable extensions like PackageImports. I hadn't realised before, but this situation is better for portability, because it discourages people from using base package modules in pure Haskell 2010 code. The downside is exactly the reverse: if you wanted to use modules from base, then you don't get to use the pure Haskell 2010 modules too (although the base versions are virtually identical at the moment). So, if things stay like this, then you can write pure Haskell 2010 with GHC in two ways: - using Cabal: say extensions: Haskell2010 and build-depends: haskell2010. Maybe Cabal should have a new language directive, because extensions is a bit strange. - using GHC standalone: say -package haskell2010 -hide-package base. -XHaskell2010 will be the default for standalone GHC, although for Cabal we'll probably require you to say what the language is, in the interests of being explicit and for backwards compatibility with existing packages. jhc 0.7.4 which supports garbage collection and a speedier runtime and better support for external build systems will be out soon. My goal is one more point release before 0.8.0 which will have full haskell 2010 and 98 support. I haven't looked at the new jhc yet, but I have a question about the GC support: is it conservative or accurate? If accurate, how are you finding the pointers - a shadow stack? Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Actually loading a Cabal package in GHCi
Hi Ketil Particularly to Haskore rather than package importing or Cabal in general, AbsPitch is not defined in Haskore i.e. Henning Thielemann's extended Haskore. AbsPitch in Paul Hudak's Haskore (i.e. haskore-vintage), it is a synonym for Int, I believe the replacement is Henning's Haskore is Absolute. From what I can gather, the original poster is using Haskore from Hackage (so they have Henning's version) but is trying to work with an old library HasChorus (installed from a source tar ball that is not on Hackage). HasChorus doesn't have a cabal file to distinguish dependencies, but it is written for Paul Hudak's original Haskore - i.e. haskore-vintage. The docs on Hackage show that Henning's Haskore doesn't export AbsPitch: http://hackage.haskell.org/packages/archive/haskore/0.1.0.4/doc/html/doc-index-A.html http://hackage.haskell.org/packages/archive/haskore-vintage/0.1/doc/html/doc-index-A.html Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: Haskell 2010 Report (final)
On Mon, Jul 12, 2010 at 10:07:28AM +0100, Simon Marlow wrote: The story we tentatively plan to provide in GHC 6.14.1 is a haskell2010 package that provides exactly the API specified by the report (by definition, since the source was used to generate the report :-). The modules of haskell2010 overlap with base, so it will be impossible to depend on both haskell2010 and base, without using non-portable extensions like PackageImports. The way Jhc handles module overlap with packages is that it allows re-exporting modules from different libraries transparently, and reports conflicts lazily, as with normal haskell identifiers. For example, the 'haskell98' package might have a field 'Reexport-Modules:' with an entry 'Compat.Haskell98.Prelude as Prelude', meaning that if you pass -phaskell98 on the command line, you get a 'Prelude' that is transparently remapped to 'Compat.Haskell98.Prelude' under the scenes. This means that you can happily have both -phaskell98 and -phaskell2010 and get access to all of both their modules because they have identical 'Prelude' modules so will both re-export the same underlying module (implemented in some common base package) and there will be no conflict reported. Just like it is okay if you import the same haskell function from two different modules as long as they refer to the same original function. Things are trickier if they do both -phaskell2010 and -pghc-base-3 since they conflict on some module names, there is nothing wrong with linking against both of them, but if you do an 'import Data.List' then a conflict will be reported as that particular module is different between the two. But if you only use the 'Prelude' or other modules that coincide, there will be no trouble. I think the ability for a package to define an 'interface' built up from other re-exported modules will be very useful going forward, I am not sure how hard something like that would be to implement in ghc, but it may be worth it in the future. I hadn't realised before, but this situation is better for portability, because it discourages people from using base package modules in pure Haskell 2010 code. The downside is exactly the reverse: if you wanted to use modules from base, then you don't get to use the pure Haskell 2010 modules too (although the base versions are virtually identical at the moment). I would worry that it would discourage people from using 'haskell2010' at all to some degree. Are there issues in ghc with one library being built on haskell2010 and another being built on base and a third wanting to use both of them? If not, then I don't think it will be too bad. The situation will be no worse than it is now, as it is, pretty much every library out there depends on 'base' making it theoretically incompatible with jhc. (in practice, most things compile just fine if I simply ignore the overly pedantic cabal dependencies and just add the obvious dependencies based on imports, aka, the franchise heuristic). jhc 0.7.4 which supports garbage collection and a speedier runtime and better support for external build systems will be out soon. My goal is one more point release before 0.8.0 which will have full haskell 2010 and 98 support. I haven't looked at the new jhc yet, but I have a question about the GC support: is it conservative or accurate? If accurate, how are you finding the pointers - a shadow stack? In the past I just had the boehm GC and the cross your fingers and hope static analysis can catch everything options. But as of 0.7.4 I have a real gc that I hope to make the new default in the next major release. (enabled with -fjgc on the command line) It is an accurate GC that is implemented in portable C. I am using something based on the paper 'Accurate garbage collection in an Uncooperative Environment'[1] though the technique was independently discovered. I always pass the GC parameter as the first argument to functions, which is mapped to the same register, so I effectively have a dedicated register without having to resort to a dedicated declared register in gcc. Plus I can omit the parameter in leaf functions that don't allocate and free up the register for normal use. I compile with -mregparm=2 on i386 so the first two arguments to a function get mapped to registers. I found that an independent shadow stack actually is faster than using the linked version described in the paper, (though, still passing around a pointer to the top of the stack as described), my theory being that taking the address of a stack allocated object will inhibit certain gcc optimizations. The underlying allocator is based on Bonwick's slab allocator[2] which works quite well for a haskell runtime, I have a slab for each type, so a slab of 'cons' cells, a slab of size 3 tuples, and so forth. [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.5570 [2] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.143.4374 John --
Re: [Haskell-cafe] Re: ANNOUNCE: fgl-5.4.2.3
On 12.07.2010 09:25, Ivan Lazar Miljenovic wrote: A couple of points I meant to make here but forgot (I was busy hacking on this and my other three graph-related packages for over a week now, and especially this past weekend it cut into my sleeping...): * Apart from bug-fixes, I don't intend on touching the 5.4 series any more. That said, I believe that this version is suitable for replacing 5.4.2.2 in the platform (what's the process on that?). * After I get my generic graph class sorted out at AusHac this coming weekend, I intend to make a 5.5.0.0 release which extends the classes in this new library; this will probably _not_ be suitable for the platform and is intended to serve as a stepping stone to the replacement library Thomas Bereknyei and I are working on. With that last point: Thomas and I are willing to call this new version/replacement something like inductive-graphs if that is the preference of the community. Does anyone know of a website that would let us have a survey we can use to determine which option people would prefer? how about http://doodle.com? have fun, keep hacking. martin Note that even if we give it a new name (rather than just a new major version number), we still intend on using the Data.Graph.Inductive module namespace (as it makes even more sense with the new name), so there will still be clashes between this new version and fgl. Ivan Lazar Miljenovicivan.miljeno...@gmail.com writes: I'm pleased to present the first new release of fgl [1] since Thomas Bereknyei took over maintaining it from Martin Erwig. [1] http://hackage.haskell.org/package/fgl Before people start panicking, rioting, etc., please check the version number: this is just a bug-fix release, and not the complete re-write version which we've been talking about (since we got a little sidetracked, etc.). As such, the API hasn't changed, and this should fit right in to packages already using fgl (sorry to all those people who followed my advice and put fgl == 5.4.2.2 in the build-depends fields of their packages' .cabal files, but I didn't expect to make another 5.4.y release). The exact change that has been made is to fix a bug pointed out to me by Tristan Allwood, in that Data.Graph.Inductive.PatriciaTree didn't support multiple edges (and furthermore this wasn't specified in the documentation). This has now been rectified. As an indication of what these changes mean, see this sample call graph produced by my SourceGraph program; when using PatriciaTree from fgl-5.4.2.2 the lines were all the same thickness; now there is among other things a loop of width 32 on getExp and a line of width 7 from getExp to maybeEnt. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: Haskell 2010 Report (final)
On 12/07/2010 12:43, John Meacham wrote: On Mon, Jul 12, 2010 at 10:07:28AM +0100, Simon Marlow wrote: The story we tentatively plan to provide in GHC 6.14.1 is a haskell2010 package that provides exactly the API specified by the report (by definition, since the source was used to generate the report :-). The modules of haskell2010 overlap with base, so it will be impossible to depend on both haskell2010 and base, without using non-portable extensions like PackageImports. The way Jhc handles module overlap with packages is that it allows re-exporting modules from different libraries transparently, and reports conflicts lazily, as with normal haskell identifiers. For example, the 'haskell98' package might have a field 'Reexport-Modules:' with an entry 'Compat.Haskell98.Prelude as Prelude', meaning that if you pass -phaskell98 on the command line, you get a 'Prelude' that is transparently remapped to 'Compat.Haskell98.Prelude' under the scenes. This means that you can happily have both -phaskell98 and -phaskell2010 and get access to all of both their modules because they have identical 'Prelude' modules so will both re-export the same underlying module (implemented in some common base package) and there will be no conflict reported. Just like it is okay if you import the same haskell function from two different modules as long as they refer to the same original function. Things are trickier if they do both -phaskell2010 and -pghc-base-3 since they conflict on some module names, there is nothing wrong with linking against both of them, but if you do an 'import Data.List' then a conflict will be reported as that particular module is different between the two. But if you only use the 'Prelude' or other modules that coincide, there will be no trouble. Right. I like the idea of packages being able to declare re-exported modules, indeed I considered doing this in GHC (when we needed base3) but decided not to mainly because we would still need PackageImports, and once you have PackageImports you can implement re-exports using that, albeit with more boilerplate. The advantage of direct re-exports, as you say, is that it avoids a conflict when the module is imported. However, since some of the modules would conflict anyway, there didn't seem to be much advantage in avoiding the conflict in some cases but not others. I think the ability for a package to define an 'interface' built up from other re-exported modules will be very useful going forward, I am not sure how hard something like that would be to implement in ghc, but it may be worth it in the future. Isn't that what PackageImports lets you do? I hadn't realised before, but this situation is better for portability, because it discourages people from using base package modules in pure Haskell 2010 code. The downside is exactly the reverse: if you wanted to use modules from base, then you don't get to use the pure Haskell 2010 modules too (although the base versions are virtually identical at the moment). I would worry that it would discourage people from using 'haskell2010' at all to some degree. Are there issues in ghc with one library being built on haskell2010 and another being built on base and a third wanting to use both of them? If not, then I don't think it will be too bad. No, there's no problem with mixing packages in that way. The situation will be no worse than it is now, as it is, pretty much every library out there depends on 'base' making it theoretically incompatible with jhc. (in practice, most things compile just fine if I simply ignore the overly pedantic cabal dependencies and just add the obvious dependencies based on imports, aka, the franchise heuristic). And hopefully things will improve over time, as fewer packages will need to depend on base. We could also start pulling out APIs that are currently in base into separate packages, without actually pulling out the code - e.g. concurrency, and that would be a good way to migrate people away from depending on base, but without breaking everything. In the past I just had the boehm GC and the cross your fingers and hope static analysis can catch everything options. But as of 0.7.4 I have a real gc that I hope to make the new default in the next major release. (enabled with -fjgc on the command line) It is an accurate GC that is implemented in portable C. I am using something based on the paper 'Accurate garbage collection in an Uncooperative Environment'[1] though the technique was independently discovered. I always pass the GC parameter as the first argument to functions, which is mapped to the same register, so I effectively have a dedicated register without having to resort to a dedicated declared register in gcc. Plus I can omit the parameter in leaf functions that don't allocate and free up the register for normal use. I compile with -mregparm=2 on i386 so the first two arguments to a function get mapped to registers. I found that an independent
Re: [Haskell-cafe] Re: Float instance of Data.Bits
On 22:02 Sat 10 Jul , Sam Martin wrote: Note that the Haskell report does not require IEEE 754 binary encodings. In fact, it permits 'Float' to be a decimal floating point type. True. Although I don't really understand why? Or rather, I don't understand why it can't be at least slightly more specific and at least state that Float is a 32-bit floating point value and Double is a 64-bit floating point value. The exact handling of various exceptions and denormals tends to vary across hardware, but this at least allows you to get at the representation. Because this precludes efficient Haskell implementations on platforms which do not support these formats in hardware (but might support other formats). Also, there are other problems if the Float and Double types do not match the corresponding types of the system's C implementation. I realise it'll be platform-specific (assuming isIEEE returns false), but then so is the behaviour of your code if you don't require IEEE support. IEEE 754 defines five basic floating point formats: binary32: 24 bits precision and a maximum exponent of 127. binary64: 53 bits precision and a maximum exponent of 1023. binary128: 113 bits precision and a maximum exponent of 16383. decimal64: 16 digits precision and a maximum exponent of 384. decimal128: 34 digits precision and a maximum exponent of 6144. Each of these formats has a specific binary representation (with the lovely storage hacks we all know and love). Additionally, there are two more interchange formats which are not intended for use in arithmetic: binary16: 11 bits precision and a maximum exponent of 15. decimal32: 7 digits precision and a maximum exponent of 96. Furthermore, there are so-called Extended and Extensible formats, which satisfy certain requirements of the standard, but are permitted to have any encoding whatsoever. A Haskell implementation tuned for development of financial applications would likely define Float as the decimal64 format, and Double as the decimal128 format. isIEEE would return True since these types and related operations conform to the IEEE floating point standard. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] PNG sample on haskellwiki
Hi, I tried out the code on this page http://haskell.org/haskellwiki/Library/PNGbut the png file that'e emitted does not seem to open properly with image viewing tools. Has anyone tried it out? I added this bit for supplying the data for image creation - count=100 row = take count (cycle [True,False]) rows = take 100 (repeat row) image = png rows main=writeFile hello.png image -- Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PNG sample on haskellwiki
I don't know about that code, but have had good experiences on two projects using the DevIL binding library found on hackage [1]. I tried pngload [2] originally, but that isn't full featured enough for real use. iirc, stb-image [3] had a similar issue of being too bare-bones; the haddock comments agree (PNG 8-bit only). In summary, thank you Luke for a good package. Cheers, Thomas [1] http://hackage.haskell.org/package/Codec-Image-DevIL [2] http://hackage.haskell.org/package/pngload [3] http://hackage.haskell.org/packages/archive/stb-image/0.2/doc/html/Codec-Image-STB.html On Mon, Jul 12, 2010 at 9:51 AM, C K Kashyap ckkash...@gmail.com wrote: Hi, I tried out the code on this page http://haskell.org/haskellwiki/Library/PNG but the png file that'e emitted does not seem to open properly with image viewing tools. Has anyone tried it out? I added this bit for supplying the data for image creation - count=100 row = take count (cycle [True,False]) rows = take 100 (repeat row) image = png rows main=writeFile hello.png image -- Regards, Kashyap ___ 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] Re: [Haskell] ANNOUNCE: Haskell 2010 Report (final)
On Mon, Jul 12, 2010 at 9:50 AM, Simon Marlow marlo...@gmail.com wrote: And hopefully things will improve over time, as fewer packages will need to depend on base. We could also start pulling out APIs that are currently in base into separate packages, without actually pulling out the code - e.g. concurrency, and that would be a good way to migrate people away from depending on base, but without breaking everything. Is the plan to stop using base and start using 'haskell2010', even if you use extensions that aren't Haskell 2010? Cheers! -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] darcs 2.5 beta 1 release
Hi, Op zondag 11 juli 2010 18:02 schreef Jason Dagit: On Sun, Jul 11, 2010 at 5:51 AM, Reinier Lamers tux_roc...@reinier.dewrote: If you have installed the Haskell Platform or cabal-install, you can install this beta release by doing: $ cabal update $ cabal install darcs-beta Did you forget to upload the 2.5 beta to hackage? The latest version I see is in the 2.4 series. I'm sorry. I intended to include a note explaining the relation between numerical (2.4.98.1) and beta/rc(2.5 beta 1) version names, but forgot to do so. This should be fixed for beta 2 :) Reinier 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] haskell platform questions
Hi, This is still happening with the current DMG on the website, my solution has been to install GHC from the DMG, then get the source for Haskell Platform (haskell-platform-2010.1.0.0.tar.gz) and build it myself. Cheers, G On 22 Mar 2010, at 04:02, Warren Harris wrote: I downloaded the new haskell-platform-2010.1.0.0-i386.dmg today... ran the uninstaller, ghc installer and the platform installer. When I run ghci, it seems to work fine, but when I try cabal, I get this crash: $ cabal --version dyld: unknown required load command 0x8022 Trace/BPT trap Any suggestions? (I'm on 10.5.8). Maybe I'll try the macport install process instead. Thanks for your help, Warren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: Haskell 2010 Report (final)
On Mon, Jul 12, 2010 at 01:50:01PM +0100, Simon Marlow wrote:
Right. I like the idea of packages being able to declare re-exported
modules, indeed I considered doing this in GHC (when we needed base3)
but decided not to mainly because we would still need PackageImports,
and once you have PackageImports you can implement re-exports using
that, albeit with more boilerplate. The advantage of direct re-exports,
as you say, is that it avoids a conflict when the module is imported.
However, since some of the modules would conflict anyway, there didn't
seem to be much advantage in avoiding the conflict in some cases but not
others.
Well, a main useful case is that I can do -phaskell98 and -phaskell2010
at the same time. So I can make the default jhc behavior be the union of
the two languages easily. However, another motivation is that I want to
be able to easily do things like provide modules like ghc-base-3 and
ghc-base-4 that are simple shims that provide compatible interfaces with
versions of ghc, however, those ghc bases also export some haskell98
modules, so being able to do -phaskell98 -pghc-base-3 at the same time
is important.
There is also some philosophy behind it. I don't like coupling things
that don't need to be coupled, such as the interface a library exports
and the place that interface is implemented.
I think the ability for a package to define an 'interface' built up from
other re-exported modules will be very useful going forward, I am not
sure how hard something like that would be to implement in ghc, but it
may be worth it in the future.
Isn't that what PackageImports lets you do?
Hmm.. maybe. Jhc doesn't have PackageImports, the idea being that you
re-export modules rather than importing them from a specific package and
exporting their interface. So, it sort of shifts the effort from the
interface makers to the implementors, as in, the Haskell 98 Prelude
will actually have to be in a module called Compat.Haskell98.Prelude and
just re-exported by the 'haskell98' and 'haskell2010' modules. In one
sense 'Compat.Haskell98' sort of acts as a package import, but it isn't
actually tied to a package, it just refers to the
Compat.Haskell98.Prelude in scope. I also have a large aversion to
allowing package names to infect source files carte blanche. It blurs
the line between the language itself and the environment the language
runs in. It may be neccesarry at some point, but I'll put it off until a
case comes up that makes it abundantly clear that it is needed.
In the past I just had the boehm GC and the cross your fingers and hope
static analysis can catch everything options. But as of 0.7.4 I have a
real gc that I hope to make the new default in the next major release.
(enabled with -fjgc on the command line)
It is an accurate GC that is implemented in portable C. I am using
something based on the paper 'Accurate garbage collection in an
Uncooperative Environment'[1] though the technique was independently
discovered. I always pass the GC parameter as the first argument to
functions, which is mapped to the same register, so I effectively have a
dedicated register without having to resort to a dedicated declared
register in gcc. Plus I can omit the parameter in leaf functions that
don't allocate and free up the register for normal use. I compile with
-mregparm=2 on i386 so the first two arguments to a function get mapped
to registers.
I found that an independent shadow stack actually is faster than using
the linked version described in the paper, (though, still passing around
a pointer to the top of the stack as described), my theory being that
taking the address of a stack allocated object will inhibit certain gcc
optimizations.
The underlying allocator is based on Bonwick's slab allocator[2] which
works quite well for a haskell runtime, I have a slab for each type, so
a slab of 'cons' cells, a slab of size 3 tuples, and so forth.
[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.5570
[2] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.143.4374
Interesting. This is quite a different set of decisions to the way GHC
does things, so I look forward to comparing some benchmarks. My
intuition is that if allocation is anything more complicated than reg
+= size; if (reg lim) { ... } then you have a lot of work to do to
make up for the overhead, but let's see!
Indeed, in certain places I quite conciously made different choices than
ghc, not necessarily because I thought they were better, but more
because I knew they would open up a new design space for me to explore.
Certain places like the RTS I felt much more comfortable being radically
different due to my embedded/operating systems background. Though a lot
of the middle end is pretty much analogous to what ghc does (though jhc
core is based on a PTS instead of system F). My Grin also diverged from
boquist's GRIN quite a bit. Modern architectures and my
[Haskell-cafe] cryptohash and an incremental API
Vincent, Due to spam-like comments on -cafe I hadn't been subscribed for a while and missed your cryptohash discussion! Particularly: The main reason for this library is the lack of incremental api exposed by current digest libraries, and filling the void about some missing digest algorithms; Also the speed comes as a nice bonus. I've been working on a new crypto library specifically to provide a unified API for packages implementing cryptographic algorithms. You can see the discussions on librar...@haskell.org [1] [2]. Please feel free to take a look, comment, contribute, and hopefully move to the interface. I should be finishing up BlockCipher modes and adding hash tests soon. Cheers, Thomas [1] http://www.haskell.org/pipermail/libraries/2010-May/013688.html [2] http://www.haskell.org/pipermail/libraries/2010-June/013782.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] DpH/repa cache locality
Hey everyone, Just out of curiosity, what work is being done in the data parallel haskell / repa projects regarding cache locality? The reason I am asking is because, as I understand it, the biggest bottleneck on today's processors are cache misses, and the reason why optimized platform-specific linear algebra libraries perform well is because they divide the data into chunks that are optimally sized for the cache in order to maximize the number of operations performed per memory access. I wouldn't expect data parallel haskell/repa to automatically know what the perfect chunking strategy should be on each platform, but are there any plans being made at all to do something like this? (To be explicit, this isn't meant as a criticism; I'm just curious and am interested in seeing discussion on this topic by those more knowledgeable than I. :-) ) Thanks! Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
On Jul 11, 2010, at 9:20 PM, Daniel Fischer wrote: * Prove the binomial theorem *without* the convention 0**0 := 1 Except that in the binomial theorem, one uses (^) and not (**). For (^), setting x ^ 0 = 1 is, as far as I'm aware, uncontested. This is not so: the exponent in the binomial theorem is a real number, not an integer. See http://mathworld.wolfram.com/BinomialTheorem.html Real numbers turn up in surprising places. I imagine most of us are familiar with the derivative operator D, and with iterations of it like second derivatives. But it's not just natural number powers of D that make sense; there are fractional derivatives, and D**(1/2) does find uses. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
On Sat, Jul 10, 2010 at 6:40 PM, Julian Fleischer julian.fleisc...@fu-berlin.de wrote: I guess I'm actually messing things up using the word natural - how can expand the multiplication of zero with itself zero times be natural? How could it not be? That is to say, what initial value would make sense for folding (*) over a list of numbers to compute the product? - C. p.s. -- [[mconcat]] = [[foldr mappend mempty]] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: jhc 0.7.4
On Jul 11, 2010, at 9:38 AM, wren ng thornton wrote: Generally OSX takes UTF16 to be the standard encoding (I don't recall if it's LE or BE), though UTF8 is supported almost everywhere. I haven't checked to see whether that would affect this particular task though. Mac OS X 10.5 came with a lot of locales, including a lot of UTF-8 ones. Indeed, the default was a UTF-8 one. But it didn't come with *any* UTF-16 locales. (As tested by 'locale -a'.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ghc-6.12 can't works with Cabal-1.8.0.4?
Hi all, I upload package http://hackage.haskell.org/package/poppler-0.11.1 I can compile it on my box, but it build failure at hackage with below error: -- error start -- *** setup configure Reading installed packages... /usr/local/bin/ghc-pkg dump --global /usr/local/bin/ghc-pkg dump --user /usr/local/bin/ghc --print-libdir Creating setup (and its parents) /usr/local/bin/ghc -package Cabal-1.8.0.4 --make Setup.hs -o setup/setup -odir setup -hidir setup command line: cannot satisfy -package Cabal-1.8.0.4 (use -v for more information) *** Trying again with preferred-versions *** setup configure Reading installed packages... /usr/local/bin/ghc-pkg dump --global /usr/local/bin/ghc-pkg dump --user /usr/local/bin/ghc --print-libdir Creating setup (and its parents) /usr/local/bin/ghc -package Cabal-1.8.0.4 --make Setup.hs -o setup/setup -odir setup -hidir setup command line: cannot satisfy -package Cabal-1.8.0.4 (use -v for more information) -- error end -- My poppler.cabal is -- poppler.cabal start -- Name: poppler Version:0.11.1 License:GPL-2 License-file: COPYING Copyright: (c) 2001-2010 The Gtk2Hs Team Author: Andy Stewart Maintainer: gtk2hs-us...@sourceforge.net Build-Type: Custom Cabal-Version: = 1.6 Stability: stable homepage: http://www.haskell.org/gtk2hs/ bug-reports:http://hackage.haskell.org/trac/gtk2hs/ Synopsis: Binding to the Poppler. Description:Poppler is a fork of the xpdf PDF viewer, to provide PDF rendering functionality as a shared library, to centralize the maintenance effort. And move to forward in a number of areas that don't fit within the goals of xpdf. Category: Graphics Tested-With:GHC == 6.12.3 Extra-Source-Files: Gtk2HsSetup.hs hierarchy.list template-hsc-gtk2hs.h x-Types-File: Graphics/UI/Gtk/Poppler/Types.chs x-Types-ModName: Graphics.UI.Gtk.Poppler.Types x-Types-Import:System.Glib.GObject x-Types-Lib: poppler x-Types-Prefix:poppler x-Types-Tag: poppler x-Types-Hierarchy: hierarchy.list Data-Dir: demo Data-Files: PdfViewer.hs Makefile Source-Repository head type: darcs location: http://patch-tag.com/r/AndyStewart/poppler Library build-depends: base = 4 5, array, containers, haskell98, mtl, bytestring, glib = 0.11 0.12, cairo = 0.11 0.12, gtk = 0.11 0.12 build-tools:gtk2hsC2hs, gtk2hsHookGenerator, gtk2hsTypeGen exposed-modules: Graphics.UI.Gtk.Poppler.Action Graphics.UI.Gtk.Poppler.Attachment Graphics.UI.Gtk.Poppler.Document Graphics.UI.Gtk.Poppler.FormField Graphics.UI.Gtk.Poppler.Layer Graphics.UI.Gtk.Poppler.Page Graphics.UI.Gtk.Poppler.Poppler other-modules: Graphics.UI.Gtk.Poppler.Enums Graphics.UI.Gtk.Poppler.Structs Graphics.UI.Gtk.Poppler.Types extensions: ForeignFunctionInterface include-dirs: . x-c2hs-Header: glib/poppler.h pkgconfig-depends: poppler-glib = 0.12.4, gobject-2.0, glib-2.0, cairo = 1.2.0, gdk-2.0, gdk-pixbuf-2.0, pango -- poppler.cabal end -- Something is wrong? Thanks, -- Andy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PNG sample on haskellwiki
Thanks Thomas for the resources ... particularly [3] ... it seems to have a link to a standalone 'C' code that does jpeg and png decoding! I'd actually like to see the example on Haskell wiki work - my agenda is two fold, familiarity with dealing with binary data in Haskell and also understanding PNG ... I think I'll have to do it the hard way now - look at the PNG spec and see what's wrong in the file. On Mon, Jul 12, 2010 at 10:41 PM, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: I don't know about that code, but have had good experiences on two projects using the DevIL binding library found on hackage [1]. I tried pngload [2] originally, but that isn't full featured enough for real use. iirc, stb-image [3] had a similar issue of being too bare-bones; the haddock comments agree (PNG 8-bit only). In summary, thank you Luke for a good package. Cheers, Thomas [1] http://hackage.haskell.org/package/Codec-Image-DevIL [2] http://hackage.haskell.org/package/pngload [3] http://hackage.haskell.org/packages/archive/stb-image/0.2/doc/html/Codec-Image-STB.html On Mon, Jul 12, 2010 at 9:51 AM, C K Kashyap ckkash...@gmail.com wrote: Hi, I tried out the code on this page http://haskell.org/haskellwiki/Library/PNG but the png file that'e emitted does not seem to open properly with image viewing tools. Has anyone tried it out? I added this bit for supplying the data for image creation - count=100 row = take count (cycle [True,False]) rows = take 100 (repeat row) image = png rows main=writeFile hello.png image -- Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] 64-bit #const with hsc2hs?
Does anyone know if I can bring a 64-bit (long long or unsigned long long) value from C-land into Haskell via hsc2hs? #const on such a value seems to provide only the low 32 bits, at least in my environment (Haskell Platform 2009.2.0.2 on Windows). I've tried to create a 64-bit variant of #const without success. Dean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: The site has been exploited (again)
On Sun, Jul 11, 2010 at 2:28 PM, Mike Dillon m...@embody.org wrote: begin Mike Dillon quotation: Being that there is only one active admin on the Haskell.org wiki (User:Ashley Y), I believe the fact that this page is editable by any user is a policy decision to allow the community to contribute. The page could be protected, but then only two administrators could edit it (assuming John Peterson decided to become active again after two years of not working on the wiki): http://www.haskell.org/haskellwiki/?title=Special%3AListusersgroup=sysop As for whether or not moving this particular wiki to a Haskell-based solution would be a good idea, I don't see it being a win. I don't know of any Haskell-based wikis that support MediaWiki syntax, so the effort would involve converting all the existing content to some other format. Being that MediaWiki's syntax is the most widespread wiki syntax at the moment, I don't see how that would do anything but make it harder for people to contribute. One more thing. On a wiki with active administrators, this user would have been blocked. That hasn't happened. The last block was in August 2009: http://www.haskell.org/haskellwiki/?title=Special%3ALogtype=block If there is not someone regularly watching the wiki at all times, it would probably be prudent to protect some of the higher profile pages once there are more admins able to edit them. -md Ashley has made me admin; I've spent the last 1.5 hours deleting all the vandalism and indef blocking the accounts. I have Recent Changes in my RSS reader, so hopefully in the future there will be no greater than 24 hours delay before vandalism is dealt with. A MW upgrade will also help (eg. currently checkuser* seems to be unavailable). * http://www.mediawiki.org/wiki/Extension:CheckUser -- gwern ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
