https://wiki.haskell.org/api.php?action=feedcontributions&user=Igloo&feedformat=atomHaskellWiki - User contributions [en]2024-03-28T15:31:55ZUser contributionsMediaWiki 1.35.5https://wiki.haskell.org/index.php?title=Library_submissions&diff=56017Library submissions2013-05-25T13:52:32Z<p>Igloo: </p>
<hr />
<div>This page describes the process for maintaining the <br />
'''Core libraries'''. The core libraries are a subset of the packages in the<br />
Haskell Platform, and define basic APIs that are expected to be<br />
available in any Haskell implementation. They are listed under "The Core Libraries" below.<br />
<br />
Non-core libraries are, of course, managed by their own authors/maintainers (named in their .cabal file), using whatever policies those maintainers see fit. [Note: arguably the policies below might usefully be applied to all libraries embodied in the Haskell Platform, but that is a question for the HP team.]<br />
<br />
= General principles =<br />
<br />
* Each core package has a named maintainer, or small group of maintainers, who have commit access to the package. <br />
<br />
* Third parties are encouraged to make proposals for changes, both to the library API and its implementation, by sending the proposal to the maintainer (CC'ing the libraries mailing list).<br />
<br />
* The maintainer is trusted to decide what changes to make to the package, and when. They are strongly encouraged to follow the guidance below, but the general principle is: the community offers opinions, but the maintainers decide.<br />
<br />
<br />
= Responsiveness =<br />
<br />
* Third parties submitting proposals to the maintainer of a library can expect a timely and thoughtful response. <br />
* The more effort the proposer invests (for example, by constructing a patch rather than making an off-the-cuff suggestion) the more consideration s/he can reasonably expect.<br />
* Proposals that have widespread support, and are accompanied by patches (preferably with tests and documentation), should normally be accepted by the maintainer. <br />
* It is up to the maintainer to decide what "widespread" means; in particular, it does not always mean "a majority of those who responded". The majority-responder story is vulnerable to selection bias; e.g. 7 people (out of a client base of hundreds) say "add this function" but the maintainer thinks it will make the interface incrementally more complicated without sufficient benefit.<br />
* Where there is significant work involved in implementing a proposal, it is reasonable for a maintainer to ask for a patch. The principle is that maintainers are not obliged to do the work of implementing a proposal, even if it does enjoy wide support. For more substantial changes, it makes sense to develop the implementation in dialogue with the maintainer.<br />
<br />
= Guidance for proposers =<br />
<br />
A "proposal" can be anything from a one-sentence suggestion to a fully-implemented, tested, and documented patch.<br />
However, the more substantial the proposal the more attention you can expect. The process is this:<br />
<br />
* Send your proposal by email to the maintainer, with a copy to the libraries@haskell.org mailing list (which you need to [http://www.haskell.org/mailman/listinfo/libraries subscribe] to before posting).<br />
<br />
* Set a deadline for discussion (no less than two weeks), and act as chair/moderator for the discussion. <br />
<br />
* At the end of the discussion period, summarise your understanding of the consensus (or lack thereof), including a link to the thread in the mailing list archives, and send the summary to the maintainer for decision. The deadline gives you a moment to summarise the debate and hand over to the maintainer. It isn't a deadline for the maintainer to decide; for example he or she may seek more discussion first. <br />
<br />
* If the decision is positive, [http://hackage.haskell.org/trac/ghc/newticket create a ticket] on the GHC trac. The description of the ticket can summarise the proposal and link to the mail thread. Further discussion and implementation patches can be attached to the ticket, and the ticket helps the maintainer to keep track of what is on the go. (Obviously if the maintainer prefers some other mechanism, follow his or her guidance.)<br />
<br />
* For non-trivial changes the maintainer may ask for a patch. You may create the patch up front, and make it part of your proposal; or you may want to have some discussion about the design first, and only then roll up your sleeves to do the implementation; and for bigger jobs you may want to wait until the maintainer agrees in principle with the change.<br />
<br />
Here are desirable properties for a proposal and its implementation. The more of these properties your proposal or patch has, the more likely it is that the maintainer will adopt your idea. After all, to adopt it the maintainter will have to do whatever tasks you didn't do.<br />
<br />
* '''Description'''. A good proposal says clearly ''what'' you propose, ''why'' it is a good idea, and what its consequences would be.<br />
* '''Patch'''. Use <tt>darcs record</tt> or <tt>git commit</tt> (depending on what sort of repo the library lives in) to create it. Save the patch to a file, using <tt>darcs send --output</tt> or <tt>git format-patch</tt>. Make your changes against a copy of the master branch of the relevant library, and make sure it compiles.<br />
* '''Portability'''. Good code is portable. In particular, try to ensure the code runs in Hugs and GHC, and on Windows and Linux.<br />
* '''Style'''. Good code follows the conventions in the library you are modifying.<br />
* '''Documentation'''. Good code includes valid [http://haskell.org/haddock Haddock] documentation.<br />
* '''Tests'''. Good patches have suitable tests for the library's testsuite.<br />
<br />
= Guidance for maintainers =<br />
<br />
The principle is that we '''trust the maintainer''' to behave sensibly. The guidelines below are just that: guidelines, not rules. Still, the core libraries are used by many, many people, so maintainers should make every effort not to mess them up by accident. <br />
<br />
* '''API changes should be discussed''' on the libraries mailing list prior to making the change, even if the maintainer is the proposer. The maintainer still has ultimate say in what changes are made, but the community should have the opportunity to comment on changes. However, unanimity (or even a majority) is not required.<br />
<br />
* '''Every API change should be described precisely in the commit log.''' The commit logs should be sent to a public mailing list, or otherwise made easily available (e.g. via github), so that the community can keep an eye on changes and comment.<br />
<br />
* '''Backwards compatibility''' is important to many users. API changes are expected to retain backwards compatibility wherever possible. However, from time to time we may decide to have major revisions which are explicitly not backwards compatible; in these cases we may try to make the previous version of the package available concurrently, as in the base-3/base-4 switchover.<br />
<br />
* You don't need to consult the community for '''purely internal changes'''; i.e. changes that do not affect the library's clients.<br />
<br />
* Changes that simply '''widen the API by adding new functions''' are a bit of a grey area. It's better to consult the community, because there may be useful feedback about (say) the order of arguments, or the name of the function, or whatnot. On the other hand few clients will actually break if you add a new function to the API. Use your judgment.<br />
<br />
Libraries maintained by the GHC team are subject to the GHC validation policy - patches will be tested for validation before committing ([http://hackage.haskell.org/trac/ghc/wiki/TestingPatches TestingPatches]). Those packages not maintained by the GHC team will probably have a GHC lagging mirror repository that is subject to validation.<br />
<br />
= The Core Libraries =<br />
<br />
The following packages constitute the core libraries:<br />
<br />
{| border="1"<br />
! Package !! Maintainer<br />
|-<br />
| [http://hackage.haskell.org/package/array array] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/base base] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/containers containers] || Johan Tibell and Milan Straka<br />
|-<br />
| [http://hackage.haskell.org/package/deepseq deepseq] || Simon Marlow<br />
|-<br />
| [http://hackage.haskell.org/package/directory directory] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/extensible-exceptions extensible-exceptions] || GHC HQ <br />
|-<br />
| [http://hackage.haskell.org/package/ghc-prim ghc-prim] || GHC HQ <br />
|-<br />
| [http://hackage.haskell.org/package/hpc hpc] || Andy Gill <br />
|-<br />
| [http://hackage.haskell.org/package/mtl mtl] || Edward Kmett<br />
|-<br />
| [http://hackage.haskell.org/package/parallel parallel] || Simon Marlow<br />
|-<br />
| [http://hackage.haskell.org/package/pretty pretty] || David Terei<br />
|-<br />
| [http://hackage.haskell.org/package/process process] || GHC HQ <br />
|-<br />
| [http://hackage.haskell.org/package/random random] || Ryan Newton<br />
|-<br />
| [http://hackage.haskell.org/package/template-haskell template-haskell] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/unix unix] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/Win32 Win32] || Bryan O'Sullivan<br />
|-<br />
| [http://hackage.haskell.org/package/xhtml xhtml] || Chris Dornan<br />
|}<br />
<br />
The maintainer "GHC HQ" means Simon Marlow, Simon Peyton Jones, and Ian Lynagh. Daniel Fischer has taken responsibility for numeric stuff. Email ghc-devs@haskell.org<br />
<br />
The following packages match the appropriate language standard, and as such cannot change independently. The code is maintained by the GHC team.<br />
<br />
{| border="1"<br />
|-<br />
| [http://hackage.haskell.org/package/haskell2010 haskell2010] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/haskell98 haskell98] || GHC HQ<br />
|}<br />
<br />
These packages are maintained only for backward compatibility, and are not expected to undergo API changes in the future. <br />
<br />
{| border="1"<br />
|-<br />
| [http://hackage.haskell.org/package/old-locale old-locale] || GHC HQ <br />
|-<br />
| [http://hackage.haskell.org/package/old-time old-time] || GHC HQ <br />
|}<br />
<br />
= See also =<br />
<br />
* [http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions GHC Working Conventions], including guidelines for submitting patches via darcs.<br />
* [http://haskell.org/haskellwiki/Category:Style Notes on programming style]<br />
<br />
[[Category:Community]]<br />
[[Category:Proposals| ]]</div>Igloohttps://wiki.haskell.org/index.php?title=DHD_UHac/Attendees&diff=44638DHD UHac/Attendees2012-02-23T16:26:13Z<p>Igloo: </p>
<hr />
<div>This is a list of attendees for [[DHD_UHac|DHD >>= UHac]].<br />
<br />
If you have [[DHD_UHac/Register|registered]], please consider adding yourself to the list. Your contact and travel information may help with coordination between participants.<br />
<br />
If you live around Utrecht or plan to commute from home each day, you may put "Local" for accommodation.<br />
<br />
{| class="wikitable"<br />
! IRC Nickname<br />
! Real Name (Affl)<br />
! Mobile #<br />
! Arrive<br />
! Depart<br />
! Accommodation<br />
|-<br />
| leather<br />
| Sean Leather (UU)<br />
| +31616158163<br />
|<br />
|<br />
| Local<br />
|-<br />
| norm2782<br />
| Jurriën Stutterheim (UU)<br />
| +31642392944<br />
|<br />
|<br />
| Local<br />
|-<br />
| ruud<br />
| Ruud Koot (UU)<br />
| +31623024223<br />
|<br />
|<br />
| Local<br />
|-<br />
| kosmikus<br />
| Andres Löh (Well-Typed LLP)<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| sol<br />
| Simon Hengel<br />
| +4917661064074<br />
|<br />
|<br />
|<br />
|-<br />
| dreixel<br />
| José Pedro Magalhães (UU)<br />
| +31650459029<br />
|<br />
|<br />
| Local<br />
|-<br />
| marczoid<br />
| Marc van Zee (UU)<br />
| +31633610518<br />
|<br />
|<br />
| Local<br />
|-<br />
| paba<br />
| Patrick Bahr (University of Copenhagen)<br />
|<br />
|<br />
|<br />
| Local<br />
|-<br />
| toothbrush<br />
| Paul van der Walt (UU)<br />
| +31614681351<br />
|<br />
|<br />
| Local<br />
|-<br />
| spockz<br />
| Alessandro Vermeulen (UU)<br />
| +31646165747<br />
|<br />
|<br />
| Local<br />
|-<br />
| wlad<br />
| Vlad Hanciuta<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| gcollins<br />
| Gregory Collins (Google)<br />
| +41 79 441 6832<br />
|<br />
|<br />
| Karel V Hotel<br />
|-<br />
| <br />
| Pascal Hof<br />
| <br />
|<br />
|<br />
| <br />
|-<br />
| jaspervdj<br />
| Jasper Van der Jeugt<br />
| +32 476 26 48 47<br />
|<br />
|<br />
| Yet undecided<br />
|-<br />
| cameleon<br />
| Erik Hesselink<br />
| +31 6 50 994 887<br />
|<br />
|<br />
| Local<br />
|-<br />
| sjoerd_visscher<br />
| Sjoerd Visscher<br />
| +31 6 1508 4368<br />
|<br />
|<br />
| Local<br />
|-<br />
| mklinik<br />
| Markus Klinik<br />
| +4917666101511<br />
|<br />
|<br />
|<br />
|-<br />
| <br />
| Jurriaan Hage<br />
| +31 611191976<br />
| <br />
| <br />
| Local<br />
|-<br />
| ncs<br />
| Nikos Savvidis (UU)<br />
| +31644321424<br />
|<br />
|<br />
| Local<br />
|-<br />
| <br />
| Henk-Jan van Tuyl<br />
| <br />
|<br />
|<br />
| Local (travelling from Rotterdam, DHD only)<br />
|-<br />
| sfvisser<br />
| Sebastiaan Visser<br />
| +31624828951<br />
|<br />
|<br />
| Local<br />
|-<br />
| dcoutts<br />
| Duncan Coutts (Well-Typed LLP)<br />
| <br />
|<br />
|<br />
|<br />
|-<br />
| igloo<br />
| Ian Lynagh (Well-Typed LLP)<br />
| <br />
|<br />
|<br />
|<br />
|-<br />
|}</div>Igloohttps://wiki.haskell.org/index.php?title=Library_submissions&diff=41019Library submissions2011-07-14T14:32:51Z<p>Igloo: fix typos</p>
<hr />
<div>This page describes the process for maintaining the <br />
'''Core libraries'''. The core libraries are a subset of the packages in the<br />
Haskell Platform, and define basic APIs that are expected to be<br />
available in any Haskell implementation. They are listed under "The Core Libraries" below.<br />
<br />
Non-core libraries are, of course, managed by their own authors/maintainers (named in their .cabal file), using whatever policies those maintainers see fit. [Note: arguably the policies below might usefully be applied to all libraries embodied in the Haskell Platform, but that is a question for the HP team.]<br />
<br />
= General principles =<br />
<br />
* Each core package has a named maintainer, or small group of maintainers, who have commit access to the package. <br />
<br />
* Third parties are encouraged to make proposals for changes, both to the library API and its implementation, by sending the proposal to the maintainer (CC'ing the libraries mailing list).<br />
<br />
* The maintainer is trusted to decide what changes to make to the package, and when. They are strongly encouraged to follow the guidance below, but the general principle is: the community offers opinions, but the maintainers decide.<br />
<br />
<br />
= Responsiveness =<br />
<br />
* Third parties submitting proposals to the maintainer of a library can expect a timely and thoughtful response. <br />
* The more effort the proposer invests (for example, by constructing a patch rather than making an off-the-cuff suggestion) the more consideration s/he can reasonably expect.<br />
* Proposals that have widespread support, and are accompanied by patches (preferably with tests and documentation), should normally be accepted by the maintainer. <br />
* It is up to the maintainer to decide what "widespread" means; in particular, it does not always mean "a majority of those who responded". The majority-responder story is vulnerable to selection bias; e.g. 7 people (out of a client base of hundreds) say "add this function" but the maintainer thinks it will make the interface incrementally more complicated without sufficient benefit.<br />
* Where there is significant work involved in implementing a proposal, it is reasonable for a maintainer to ask for a patch. The principle is that maintainers are not obliged to do the work of implementing a proposal, even if it does enjoy wide support. For more substantial changes, it makes sense to develop the implementation in dialogue with the maintainer.<br />
<br />
= Guidance for proposers =<br />
<br />
A "proposal" can be anything from a one-sentence suggestion to a fully-implemented, tested, and documented patch.<br />
However, the more substantial the proposal the more attention you can expect. The process is this:<br />
<br />
* Send your proposal by email to the maintainer, with a copy to the libraries@haskell.org mailing list (which you need to [http://www.haskell.org/mailman/listinfo/libraries subscribe] to before posting).<br />
<br />
* Set a deadline for discussion (no less than two weeks), and act as chair/moderator for the discussion. <br />
<br />
* At the end of the discussion period, summarise your understanding of the consensus (or lack thereof), including a link to the thread in the mailing list archives, and send the summary to the maintainer for decision. The deadline gives you a moment to summarise the debate and hand over to the maintainer. It isn't a deadline for the maintainer to decide; for example he or she may seek more discussion first. <br />
<br />
* If the decision is positive, [http://hackage.haskell.org/trac/ghc/newticket create a ticket] on the GHC trac. The description of the ticket can summarise the proposal and link to the mail thread. Further discussion and implementation patches can be attached to the ticket, and the ticket helps the maintainer to keep track of what is on the go. (Obviously if the maintainer prefers some other mechanism, follow his or her guidance.)<br />
<br />
* For non-trivial changes the maintainer may ask for a patch. You may create the patch up front, and make it part of your proposal; or you may want to have some discussion about the design first, and only then roll up your sleeves to do the implementation; and for bigger jobs you may want to wait until the maintainer agrees in principle with the change.<br />
<br />
Here are desirable properties for a proposal and its implementation. The more of these properties your proposal or patch has, the more likely it is that the maintainer will adopt your idea. After all, to adopt it the maintainter will have to do whatever tasks you didn't do.<br />
<br />
* '''Description'''. A good proposal says clearly ''what'' you propose, ''why'' it is a good idea, and what its consequences would be.<br />
* '''Patch'''. Use <tt>darcs record</tt> or <tt>git commit</tt> (depending on what sort of repo the library lives in) to create it. Save the patch to a file, using <tt>darcs send --output</tt> or <tt>git format-patch</tt>. Make your changes against a copy of the master branch of the relevant library, and make sure it compiles.<br />
* '''Portability'''. Good code is portable. In particular, try to ensure the code runs in Hugs and GHC, and on Windows and Linux.<br />
* '''Style'''. Good code follows the conventions in the library you are modifying.<br />
* '''Documentation'''. Good code includes valid [http://haskell.org/haddock Haddock] documentation.<br />
* '''Tests'''. Good patches have suitable tests for the library's testsuite.<br />
<br />
= Guidance for maintainers =<br />
<br />
The principle is that we '''trust the maintainer''' to behave sensibly. The guidelines below are just that: guidelines, not rules. Still, the core libraries are used by many, many people, so maintainers should make every effort not to mess them up by accident. <br />
<br />
* '''API changes should be discussed''' on the libraries mailing list prior to making the change, even if the maintainer is the proposer. The maintainer still has ultimate say in what changes are made, but the community should have the opportunity to comment on changes. However, unanimity (or even a majority) is not required.<br />
<br />
* '''Every API change should be described precisely in the commit log.''' The commit logs should be sent to a public mailing list, or otherwise made easily available (e.g. via github), so that the community can keep an eye on changes and comment.<br />
<br />
* '''Backwards compatibility''' is important to many users. API changes are expected to retain backwards compatibility wherever possible. However, from time to time we may decide to have major revisions which are explicitly not backwards compatible; in these cases we may try to make the previous version of the package available concurrently, as in the base-3/base-4 switchover.<br />
<br />
* You don't need to consult the community for '''purely internal changes'''; i.e. changes that do not affect the library's clients.<br />
<br />
* Changes that simply '''widen the API by adding new functions''' are a bit of a grey area. It's better to consult the community, because there may be useful feedback about (say) the order of arguments, or the name of the function, or whatnot. On the other hand few clients will actually break if you add a new function to the API. Use your judgment.<br />
<br />
Libraries maintained by the GHC team are subject to the GHC validation policy - patches will be tested for validation before committing. Those packages not maintained by the GHC team will probably have a GHC lagging mirror repository that is subject to validation.<br />
<br />
= The Core Libraries =<br />
<br />
The following packages constitute the core libraries:<br />
<br />
{| border="1"<br />
! Package !! Maintainer<br />
|-<br />
| [http://hackage.haskell.org/package/array array] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/base base] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/containers containers] || Johan Tibell and Milan Straka<br />
|-<br />
| [http://hackage.haskell.org/package/directory directory] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/mtl mtl] || Edward Kmett<br />
|-<br />
| [http://hackage.haskell.org/package/pretty pretty] || David Terei<br />
|-<br />
| [http://hackage.haskell.org/package/process process] || GHC HQ <br />
|-<br />
| [http://hackage.haskell.org/package/random random] || Ryan Newton<br />
|-<br />
| [http://hackage.haskell.org/package/unix unix] || GHC HQ<br />
|-<br />
|-<br />
| [http://hackage.haskell.org/package/template-haskell template-haskell] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/parallel parallel] || Simon Marlow<br />
|-<br />
| [http://hackage.haskell.org/package/hpc hpc] || Andy Gill <br />
|-<br />
| [http://hackage.haskell.org/package/ghc-prim ghc-prim] || GHC HQ <br />
|-<br />
| [http://hackage.haskell.org/package/extensible-exceptions extensible-exceptions] || GHC HQ <br />
|-<br />
| [http://hackage.haskell.org/package/deepseq deepseq] || Simon Marlow<br />
|-<br />
| [http://hackage.haskell.org/package/Win32 Win32] || Volunteer needed <br />
|-<br />
| [http://hackage.haskell.org/package/xhtml xhtml] || Volunteer needed <br />
|}<br />
<br />
* The maintainer "GHC HQ" means Simon Marlow, Simon Peyton Jones, and Ian Lynagh. Email cvs-ghc@haskell.org<br />
* "Volunteer needed" means that GHC HQ is the default maintainer, but that we'd like someone else to volunteer please!<br />
<br />
The following packages match the appropriate language standard, and as such cannot change independently. The code is maintained by the GHC team.<br />
<br />
{| border="1"<br />
|-<br />
| [http://hackage.haskell.org/package/haskell2010 haskell2010] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/haskell98 haskell98] || GHC HQ<br />
|}<br />
<br />
These packages are maintained only for backward compatibility, and are not expected to undergo API changes in the future. <br />
<br />
{| border="1"<br />
|-<br />
| [http://hackage.haskell.org/package/old-locale old-locale] || GHC HQ <br />
|-<br />
| [http://hackage.haskell.org/package/old-time old-time] || GHC HQ <br />
|}<br />
<br />
= See also =<br />
<br />
* [http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions GHC Working Conventions], including guidelines for submitting patches via darcs.<br />
* [http://haskell.org/haskellwiki/Category:Style Notes on programming style]<br />
<br />
[[Category:Community]]<br />
[[Category:Proposals| ]]</div>Igloohttps://wiki.haskell.org/index.php?title=Library_submissions&diff=40852Library submissions2011-07-07T19:39:20Z<p>Igloo: </p>
<hr />
<div>This page describes the process for maintaining the <br />
'''Core libraries'''. The core libraries are a subset of the packages in the<br />
Haskell Platform, and define basic APIs that are expected to be<br />
available in any Haskell implementation. They are listed under "The Core Libraries" below.<br />
<br />
Non-core libraries are, of course, managed by their own authors/maintainers (named in their .cabal file), using whatever policies those maintainers see fit. [Note: arguably the policies below might usefully be applied to all libraries embodied in the Haskell Platform, but that is a question for the HP team.]<br />
<br />
= General principles =<br />
<br />
* Each core package has a named maintainer, or small group of maintainers, who have commit access to the package. <br />
<br />
* Third parties are encouraged to make proposals for changes, both to the library API and its implementation, by sending the proposal to the maintainer (CC'ing the libraries mailing list).<br />
<br />
* The maintainer is trusted to decide what changes to make to the package, and when. They are strongly encouraged to follow the guidance below, but the general principle is: the community offers opinions, but the maintainers decide.<br />
<br />
<br />
= Responsiveness =<br />
<br />
* Third parties submitting proposals to the maintainer of a library can expect a timely and thoughtful response. <br />
* The more effort the proposer invests (for example, by constructing a patch rather than making an off-the-cuff suggestion) the more consideration s/he can reasonably expect.<br />
* Proposals that have widespread support, and are accompanied by patches (preferably with tests and documentation), should normally be accepted by the maintainer. <br />
* It is up to the maintainer to decide what "widespread" means; in particular, it does not always mean "a majority of those who responded". The majority-responder story is vulnerable to selection bias; e.g. 7 people (out of a client base of hundreds) say "add this function" but the maintainer thinks it will make the interface incrementally more complicated without sufficient benefit.<br />
* Where there is significant work involved in implementing a proposal, it is reasonable for a maintainer to ask for a patch. The principle is that maintainers are not obliged to do the work of implementing a proposal, even if it does enjoy wide support. For more substantial changes, it makes sense to develop the implementation in dialogue with the maintainer.<br />
<br />
= Guidance for proposers =<br />
<br />
A "proposal" can be anything from a one-sentence suggestion to a fully-implemented, tested, and documented patch.<br />
However, the more substantial the proposal the more attention you can expect. The process is this:<br />
<br />
* Send your proposal by email to the maintainer, with a copy to the libraries@haskell.org mailing list (which you need to [http://www.haskell.org/mailman/listinfo/libraries subscribe] to before posting).<br />
<br />
* Set a deadline for discussion (no less than two weeks), and act as chair/moderator for the discussion. <br />
<br />
* At the end of the discussion period, summarise your understanding of the consensus (or lack thereof), including a link to the thread in the mailing list archives, and send the summary to the maintainer for decision. The deadline gives you a moment to summarise the debate and hand over to the maintainer. It isn't a deadline for the maintainer to decide; for example he or she may seek more discussion first. <br />
<br />
* If the decision is positive, [http://hackage.haskell.org/trac/ghc/newticket create a ticket] on the GHC trac. The description of the ticket can summarise the proposal and link to the mail thread. Further discussion and implementation patches can be attached to the ticket, and the ticket helps the maintainer to keep track of what is on the go. (Obviously if the maintainer prefers some other mechanism, follow his or her guidance.)<br />
<br />
* For non-trivial changes the maintainer may ask for a patch. You may create the patch up front, and make it part of your proposal; or you may want to have some discussion about the design first, and only then roll up your sleeves to do the implementation; and for bigger jobs you may want to wait until the maintainer agrees in principle with the change.<br />
<br />
Here are desirable properties for a proposal and its implementation. The more of these properties your proposal or patch has, the more likely it is that the maintainer will adopt your idea. After all, to adopt it the maintainter will have to do whatever tasks you didn't do.<br />
<br />
* '''Description'''. A good proposal says clearly ''what'' you propose, ''why'' it is a good idea, and what its consequences would be.<br />
* '''Patch'''. Use <tt>darcs record</tt> or <tt>git commit</tt> (depending on what sort of repo the library lives in) to create it. Save the patch to a file, using <tt>darcs send --output</tt> or <tt>git format-patch</tt>. Make your changes against a copy of the master branch of the relevant library, and make sure it compiles.<br />
* '''Portability'''. Good code is portable. In particular, try to ensure the code runs in Hugs and GHC, and on Windows and Linux.<br />
* '''Style'''. Good code follows the conventions in the library you are modifying.<br />
* '''Documentation'''. Good code includes valid [http://haskell.org/haddock Haddock] documentation.<br />
* '''Tests'''. Good patches have suitable tests for the library's testsuite.<br />
<br />
= Guidance for maintainers =<br />
<br />
The principle is that we '''trust the maintainer''' to behave sensibly. The guidelines below are just that: guidelines, not rules. Still, the core libraries are used by many, many people, so maintainers should make every effort not to mess them up by accident. <br />
<br />
* '''API changes should be discussed''' on the libraries mailing list prior to making the change, even if the maintainer is the proposer. The maintainer still has ultimate say in what changes are made, but the community should have the opportunity to comment on changes. However, unaminity (or even a majority) is not required.<br />
<br />
* '''Every API change should be described precisely in the commit log.''' The commit logs should be sent to a public mailing list, or otherwise made easily available (e.g. via github), so that the community can keep an eye on changes and comment.<br />
<br />
* '''Backwards compatibility''' is important to many users. API changes are expected to retain backwards compatibility wherever possible. However, from time to time we may decide to have major revisions which are explicitly not backwards compatible; in these cases we may try to make the previous version of the package available concurrently, as in the base-3/base-4 switchover.<br />
<br />
* You don't need to consult the community for '''purely internal changes'''; i.e. changes that do not affect the library's clients.<br />
<br />
* Changes that simply '''widen the API by adding new functions''' are a bit of a grey area. It's better to consult the community, becuase there may be useful feedback about (say) the order of arguments, or the name of the function, or whatnot. On the other hand few clients will actually break if you add a new function to the API. Use your judgement.<br />
<br />
Libraries maintained by the GHC team are subject to the GHC validation policy - patches will be tested for validation before committing. Those packages not maintained by the GHC team will probably have a GHC lagging mirror repository that is subject to validation.<br />
<br />
= The Core Libraries =<br />
<br />
The following packages constitute the core libraries:<br />
<br />
{| border="1"<br />
! Package !! Maintainer<br />
|-<br />
| [http://hackage.haskell.org/package/array array] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/base base] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/containers containers] || Johan Tibell and Milan Straka<br />
|-<br />
| [http://hackage.haskell.org/package/directory directory] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/mtl mtl] || Edward Kmett<br />
|-<br />
| [http://hackage.haskell.org/package/pretty pretty] || David Terei<br />
|-<br />
| [http://hackage.haskell.org/package/process process] || GHC HQ <br />
|-<br />
| [http://hackage.haskell.org/package/random random] || Ryan Newton<br />
|-<br />
| [http://hackage.haskell.org/package/unix unix] || GHC HQ<br />
|-<br />
|-<br />
| [http://hackage.haskell.org/package/template-haskell template-haskell] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/parallel parallel] || Simon Marlow<br />
|-<br />
| [http://hackage.haskell.org/package/hpc hpc] || Andy Gill <br />
|-<br />
| [http://hackage.haskell.org/package/ghc-prim ghc-prim] || GHC HQ <br />
|-<br />
| [http://hackage.haskell.org/package/extensible-exceptions extensible-exceptions] || GHC HQ <br />
|-<br />
| [http://hackage.haskell.org/package/deepseq deepseq] || Simon Marlow<br />
|-<br />
| [http://hackage.haskell.org/package/Win32 Win32] || Volunteer needed <br />
|-<br />
| [http://hackage.haskell.org/package/xhtml xhtml] || Volunteer needed <br />
|}<br />
<br />
* The maintainer "GHC HQ" means Simon Marlow, Simon Peyton Jones, and Ian Lynagh. Email cvs-ghc@haskell.org<br />
* "Volunteer needed" means that GHC HQ is the default maintainer, but that we'd like someone else to volunteer please!<br />
<br />
The following packages match the appropriate language standard, and as such cannot change independently. The code is maintained by the GHC team.<br />
<br />
{| border="1"<br />
|-<br />
| [http://hackage.haskell.org/package/haskell2010 haskell2010] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/haskell98 haskell98] || GHC HQ<br />
|}<br />
<br />
These packages are maintained only for backward compatibility, and are not expected to undergo API changes in the future. <br />
<br />
{| border="1"<br />
|-<br />
| [http://hackage.haskell.org/package/old-locale old-locale] || GHC HQ <br />
|-<br />
| [http://hackage.haskell.org/package/old-time old-time] || GHC HQ <br />
|}<br />
<br />
= See also =<br />
<br />
* [http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions GHC Working Conventions], including guidelines for submitting patches via darcs.<br />
* [http://haskell.org/haskellwiki/Category:Style Notes on programming style]<br />
<br />
[[Category:Community]]<br />
[[Category:Proposals| ]]</div>Igloohttps://wiki.haskell.org/index.php?title=Library_submissions&diff=40851Library submissions2011-07-07T19:38:57Z<p>Igloo: </p>
<hr />
<div>This page describes the process for maintaining the <br />
'''Core libraries'''. The core libraries are a subset of the packages in the<br />
Haskell Platform, and define basic APIs that are expected to be<br />
available in any Haskell implementation. They are listed under "The Core Libraries" below.<br />
<br />
Non-core libraries are, of course, managed by their own authors/maintainers (named in their .cabal file), using whatever policies those maintainers see fit. [Note: arguably the policies below might usefully be applied to all libraries embodied in the Haskell Platform, but that is a question for the HP team.]<br />
<br />
= General principles =<br />
<br />
* Each core package has a named maintainer, or small group of maintainers, who have commit access to the package. <br />
<br />
* Third parties are encouraged to make proposals for changes, both to the library API and its implementation, by sending the proposal to the maintainer (CC'ing the libraries mailing list).<br />
<br />
* The maintainer is trusted to decide what changes to make to the package, and when. They are strongly encouraged to follow the guidance below, but the general principle is: the community offers opinions, but the maintainers decide.<br />
<br />
<br />
= Responsiveness =<br />
<br />
* Third parties submitting proposals to the maintainer of a library can expect a timely and thoughtful response. <br />
* The more effort the proposer invests (for example, by constructing a patch rather than making an off-the-cuff suggestion) the more consideration s/he can reasonably expect.<br />
* Proposals that have widespread support, and are accompanied by patches (preferably with tests and documentation), should normally be accepted by the maintainer. <br />
* It is up to the maintainer to decide what "widespread" means; in particular, it does not always mean "a majority of those who responded". The majority-responder story is vulnerable to selection bias; e.g. 7 people (out of a client base of hundreds) say "add this function" but the maintainer thinks it will make the interface incrementally more complicated without sufficient benefit.<br />
* Where there is significant work involved in implementing a proposal, it is reasonable for a maintainer to ask for a patch. The principle is that maintainers are not obliged to do the work of implementing a proposal, even if it does enjoy wide support. For more substantial changes, it makes sense to develop the implementation in dialogue with the maintainer.<br />
<br />
= Guidance for proposers =<br />
<br />
A "proposal" can be anything from a one-sentence suggestion to a fully-implemented, tested, and documented patch.<br />
However, the more substantial the proposal the more attention you can expect. The process is this:<br />
<br />
* Send your proposal by email to the maintainer, with a copy to the libraries@haskell.org mailing list (which you need to [http://www.haskell.org/mailman/listinfo/libraries subscribe] to before posting).<br />
<br />
* Set a deadline for discussion (no less than two weeks), and act as chair/moderator for the discussion. <br />
<br />
* At the end of the discussion period, summarise your understanding of the consensus (or lack thereof), including a link to the thread in the mailing list archives, and send the summary to the maintainer for decision. The deadline gives you a moment to summarise the debate and hand over to the maintainer. It isn't a deadline for the maintainer to decide; for example he or she may seek more discussion first. <br />
<br />
* If the decision is positive, [http://hackage.haskell.org/trac/ghc/newticket create a ticket] on the GHC trac. The description of the ticket can summarise the proposal and link to the mail thread. Further discussion and implementation patches can be attached to the ticket, and the ticket helps the maintainer to keep track of what is on the go. (Obviously if the maintainer prefers some other mechanism, follow his or her guidance.)<br />
<br />
* For non-trivial changes the maintainer may ask for a patch. You may create the patch up front, and make it part of your proposal; or you may want to have some discussion about the design first, and only then roll up your sleeves to do the implementation; and for bigger jobs you may want to wait until the maintainer agrees in principle with the change.<br />
<br />
Here are desirable properties for a proposal and its implementation. The more of these properties your proposal or patch has, the more likely it is that the maintainer will adopt your idea. After all, to adopt it the maintainter will have to do whatever tasks you didn't do.<br />
<br />
* '''Description'''. A good proposal says clearly ''what'' you propose, ''why'' it is a good idea, and what its consequences would be.<br />
* '''Patch'''. Use <tt>darcs record</tt> or <tt>git commit</tt> (depending on what sort of repo the library lives in) to create it. Save the patch to a file, using <tt>darcs send --output</tt> or <tt>git format-patch</tt>. Make your changes against a copy of the master branch of the relevant library, and make sure it compiles.<br />
* '''Portability'''. Good code is portable. In particular, try to ensure the code runs in Hugs and GHC, and on Windows and Linux.<br />
* '''Style'''. Good code follows the conventions in the library you are modifying.<br />
* '''Documentation'''. Good code includes valid [http://haskell.org/haddock Haddock] documentation.<br />
* '''Tests'''. Good patches have suitable tests for the library's testsuite.<br />
<br />
= Guidance for maintainers =<br />
<br />
The principle is that we '''trust the maintainer''' to behave sensibly. The guidelines below are just that: guidelines, not rules. Still, the core libraries are used by many, many people, so maintainers should make every effort not to mess them up by accident. <br />
<br />
* '''API changes should be discussed''' on the libraries mailing list prior to making the change, even if the maintainer is the proposer. The maintainer still has ultimate say in what changes are made, but the community should have the opportunity to comment on changes. However, unaminity (or even a majority) is not required.<br />
<br />
* '''Every API change should be described precisely in the commit log.''' The commit logs should be sent to a public mailing list, or otherwise made easily available (e.g. via github), so that the community can keep an eye on changes and comment.<br />
<br />
* '''Backwards compatibility''' is important to many users. API changes are expected to retain backwards compatibility wherever possible. However, from time to time we may decide to have major revisions which are explicitly not backwards compatible; in these cases we may try to make the previous version of the package available concurrently, as in the base-3/base-4 switchover.<br />
<br />
* You don't need to consult the community for '''purely internal changes'''; i.e. changes that do not affect the library's clients.<br />
<br />
* Changes that simply '''widen the API by adding new functions''' are a bit of a grey area. It's better to consult the community, becuase there may be useful feedback about (say) the order of arguments, or the name of the function, or whatnot. On the other hand few clients will actually break if you add a new function to the API. Use your judgement.<br />
<br />
Libraries maintained by the GHC team are subject to the GHC validation policy - patches will be tested for validation before committing. Those packages not maintained by the GHC team will probably have a GHC lagging mirror repository that is subject to validation.<br />
<br />
= The Core Libraries =<br />
<br />
The following packages constitute the core libraries:<br />
<br />
{| border="1"<br />
! Package !! Maintainer<br />
|-<br />
| [http://hackage.haskell.org/package/array array] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/base base] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/containers containers] || Johan Tibell and Milan Straka<br />
|-<br />
| [http://hackage.haskell.org/package/directory directory] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/mtl mtl] || Edward Kmett<br />
|-<br />
| [http://hackage.haskell.org/package/pretty pretty] || David Terei<br />
|-<br />
| [http://hackage.haskell.org/package/process process] || GHC HQ <br />
|-<br />
| [http://hackage.haskell.org/package/random random] || Ryan Newton<br />
|-<br />
| [http://hackage.haskell.org/package/unix unix] || GHC HQ<br />
|-<br />
|-<br />
| [http://hackage.haskell.org/package/template-haskell template-haskell] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/parallel parallel] || Simon Marlow<br />
|-<br />
| [http://hackage.haskell.org/package/hpc hpc] || Andy Gill <br />
|-<br />
| [http://hackage.haskell.org/package/ghc-prim ghc-prim] || GHC HQ <br />
|-<br />
| [http://hackage.haskell.org/package/extensible-exceptions extensible-exceptions] || GHC HQ <br />
|-<br />
| [http://hackage.haskell.org/package/deepseq deepseq] || Simon Marlow<br />
|-<br />
| [http://hackage.haskell.org/package/Win32 Win32] || Volunteer needed <br />
| [http://hackage.haskell.org/package/xhtml xhtml] || Volunteer needed <br />
|}<br />
<br />
* The maintainer "GHC HQ" means Simon Marlow, Simon Peyton Jones, and Ian Lynagh. Email cvs-ghc@haskell.org<br />
* "Volunteer needed" means that GHC HQ is the default maintainer, but that we'd like someone else to volunteer please!<br />
<br />
The following packages match the appropriate language standard, and as such cannot change independently. The code is maintained by the GHC team.<br />
<br />
{| border="1"<br />
|-<br />
| [http://hackage.haskell.org/package/haskell2010 haskell2010] || GHC HQ<br />
|-<br />
| [http://hackage.haskell.org/package/haskell98 haskell98] || GHC HQ<br />
|}<br />
<br />
These packages are maintained only for backward compatibility, and are not expected to undergo API changes in the future. <br />
<br />
{| border="1"<br />
|-<br />
| [http://hackage.haskell.org/package/old-locale old-locale] || GHC HQ <br />
|-<br />
| [http://hackage.haskell.org/package/old-time old-time] || GHC HQ <br />
|}<br />
<br />
= See also =<br />
<br />
* [http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions GHC Working Conventions], including guidelines for submitting patches via darcs.<br />
* [http://haskell.org/haskellwiki/Category:Style Notes on programming style]<br />
<br />
[[Category:Community]]<br />
[[Category:Proposals| ]]</div>Igloohttps://wiki.haskell.org/index.php?title=CamHac&diff=40174CamHac2011-05-28T14:37:40Z<p>Igloo: </p>
<hr />
<div>Haskell Hackaton in Cambridge, UK, '''August 12-14, 2011'''<br />
<br />
== About ==<br />
<br />
Come and spend a weekend in Cambridge hacking Haskell code in great surroundings with fantastic company! Haskell Hackathons are a tradition where everyone is welcome; we get together, work on projects with others or just do your own thing, the overall goal being to improve the Haskell ecosystem.<br />
<br />
CamHac will be held from 12-14 August 2011, at [http://www.homertonconference.com/ Homerton College] in Cambridge. As with previous Hackathons, all are welcome -- you do not have to be a Haskell guru. All you need is a basic knowledge of Haskell, a willingness to learn, and a project you're excited to help with (or a project of your own to work on).<br />
<br />
There will be lots of hacking, good food, and, of course, fun! <br />
<br />
* Organiser: [mailto:marlowsd@gmail.com Simon Marlow] (<tt>JaffaCake</tt> on IRC)<br />
* Mailing list: [http://www.haskell.org/mailman/listinfo/hackathon hackathon@haskell.org]<br />
* IRC channel: #ghc on FreeNode<br />
<br />
Many thanks to [http://research.microsoft.com/en-us/labs/cambridge/default.aspx Microsoft Research Cambridge] for agreeing to sponsor the event.<br />
<br />
== Registration ==<br />
<br />
'''Registration deadline''': Friday 15th July 2011<br />
<br />
Registration is free. To register, please email [mailto:msrcevnt@microsoft.com msrcevnt@microsoft.com] stating that you would like to register for the "Haskell Hackathon", with the following information<br />
<br />
Full name:<br />
Which days you are attending on:<br />
day 1: yes/no<br />
day 2: yes/no<br />
day 3: yes/no<br />
Dietary requirements:<br />
<br />
The venue is '''limited to 50 people''', and registration is first-come first-served, so register quickly to reserve your place! (but only register if you definitely intend to come, and please let us know if you find you cannot make it for any reason after you have registered, so we can re-allocate your place).<br />
<br />
Some people will probably want to travel on Friday morning and join us later on that day - that's absolutely fine.<br />
<br />
== Venue ==<br />
<br />
We're in the [http://www.homertonconference.com/Horobin.html Horobin Room] of [http://www.homertonconference.com/ Homerton Conference Centre]. It is about [http://www.google.co.uk/maps?f=d&source=s_d&saddr=United+Kingdom+(Cambridge,+Railway+Station+(Stop+B))&daddr=CB2+8PH&hl=en&geocode=FehrHAMdjhUCACHpLU_p7S-CNg%3BFc5LHAMdNhMCACmn-uB8eXrYRzFlrDhff7fJ9A&mra=iwd&dirflg=w&sll=52.190667,0.134583&sspn=0.021547,0.040598&ie=UTF8&z=16 15 minutes walk from the train station], and Cambridge town centre is about 30 minutes walk.<br />
<br />
'''Times''': we have the room booked all day for the three days, and we'll probably start around 10am and finish around 6pm. Exact time details to be confirmed later. <br />
<br />
There will be WiFi access.<br />
<br />
There will be a projector for giving talks/demos. We will probably reserve a part of the time for talks and demos.<br />
<br />
== Food ==<br />
<br />
Tea and coffee will be supplied. We will have to go out to find lunch, but there are various places to eat and buy food at the [http://www.cambridge-x.co.uk Cambridge Leisure Park] a few minutes walk towards Cambridge town centre. In the evening we will probably head towards the town where there are plenty of good restaurants.<br />
<br />
== Local arrangements ==<br />
<br />
=== Getting to Cambridge ===<br />
<br />
==== By Plane ====<br />
<br />
* [http://www.stanstedairport.com/ Stansted Airport]: Stansted is the nearest of the London-area airports to Cambridge. It is mostly served by flights to and from mainland Europe, Ireland, and elsewhere in the UK. <br />
<br />
* [http://www.heathrowairport.com/ Heathrow Airport]: Heathrow is the principal London-area airport and one of the busiest in Europe with a wide range of national, European, and international services. <br />
<br />
* [http://www.gatwickairport.com/ Gatwick Airport]: Gatwick is the second "London" airport with a wide range of national, European and international services. <br />
<br />
* Other airports: [http://www.london-luton.co.uk/ Luton Airport], [http://www.norwichairport.co.uk/ Norwich airport], and [http://www.southendairport.com/ Southend airport] are other regional airports in the East Anglia region. If you use these, car or taxi is the best option for travel to Cambridge. <br />
<br />
==== Trains from London ====<br />
<br />
London has two train lines into Cambridge, London Kings Cross and London Liverpool Street. There is a regular service on both lines and duration is under an hour on the direct trains. Go to [http://www.nationalrail.co.uk National Rail] to check train times<br />
<br />
=== Getting to the venue ===<br />
<br />
[http://www.google.co.uk/maps?f=d&source=s_d&saddr=United+Kingdom+(Cambridge,+Railway+Station+(Stop+B))&daddr=CB2+8PH&hl=en&geocode=FehrHAMdjhUCACHpLU_p7S-CNg%3BFc5LHAMdNhMCACmn-uB8eXrYRzFlrDhff7fJ9A&mra=iwd&dirflg=w&sll=52.190667,0.134583&sspn=0.021547,0.040598&ie=UTF8&z=16 Walk from the train station] (about 15 minutes)<br />
<br />
[http://www.homertonconference.com/How-to-find-us.html How to find the venue]<br />
<br />
'''Local Taxis''': Panther Taxis 01223 715715<br />
<br />
=== Accommodation ===<br />
<br />
[http://www.visitcambridge.org/VisitCambridge/WhereToStay.aspx VisitCambridge: Where to Stay in Cambridge]<br />
<br />
The nearest hotels to the venue seem to be:<br />
<br />
* [http://www2.travelodge.co.uk/ Travelodge] (Cambridge Central) is just a few minutes walk from the venue. It is currently charging £65.80 per night for 11-14 August.<br />
* [http://www.helenhotel.co.uk/index.htm Helen Hotel]<br />
* [http://www.bandbincambridgeshire.co.uk/ Bridge Guest House]<br />
* [http://www.cheapguesthouses.com/ Fairways Guest House]<br />
* [http://www.abbeyfieldguesthouse.com/ Abbeyfield Guest House]<br />
* [http://rockviewguesthouse.co.uk/default.aspx Rock View Guest House]<br />
* [http://alingtonhouse.com/default.aspx Alington House Guest House]<br />
<br />
If you contact any of the above and find they're booked up, please remove them from the list.<br />
<br />
Microsoft Research recommends the following hotels to visitors, these are closer to the city centre but are probably a lot more expensive than those above:<br />
<br />
* [http://www.hilton.co.uk/cambridgegardenhouse Double Tree by Hilton Garden House Cambridge]<br />
* [http://www.ichotelsgroup.com/h/d/cp/1/en/hotel/cbguk Crowne Plaza Cambridge]<br />
* [http://www.devere.co.uk/our-locations/university-arms.html De Vere University Arms]<br />
<br />
== Projects ==<br />
<br />
Use this space to list projects you are interested in working on, and add your name to projects you are interested in helping with.<br />
<br />
* General hacking away at Snap Framework (exact goals TBD), perhaps adding/improving documentation/tutorials at the same time. (Jurriën Stutterheim)<br />
* Darcs<br />
<br />
== Attendees ==<br />
<br />
# Simon Marlow<br />
# Jurriën Stutterheim<br />
# Neil Mitchell<br />
# Jasper Van der Jeugt<br />
# Max Bolingbroke<br />
# Ben Millwood<br />
# Roman Leshchinskiy<br />
# Gregory Collins<br />
# Martijn van Steenbergen<br />
# Sjoerd Visscher<br />
# Sebastiaan Visser<br />
# Tom Lokhorst<br />
# Erik Hesselink<br />
# Jeff Foster<br />
# Sebastian Korten<br />
# Alessandro Vermeulen<br />
# Vlad Hanciuta<br />
# Ganesh Sittampalam<br />
# Eric Kow<br />
# Alexander Njemz<br />
# Mikolaj Konarski<br />
# Ian Lynagh<br />
* Add your name here, once registered...</div>Igloohttps://wiki.haskell.org/index.php?title=CamHac&diff=40172CamHac2011-05-28T14:36:06Z<p>Igloo: </p>
<hr />
<div>Haskell Hackaton in Cambridge, UK, '''August 12-14, 2011'''<br />
<br />
== About ==<br />
<br />
Come and spend a weekend in Cambridge hacking Haskell code in great surroundings with fantastic company! Haskell Hackathons are a tradition where everyone is welcome; we get together, work on projects with others or just do your own thing, the overall goal being to improve the Haskell ecosystem.<br />
<br />
CamHac will be held from 12-14 August 2011, at [http://www.homertonconference.com/ Homerton College] in Cambridge. As with previous Hackathons, all are welcome -- you do not have to be a Haskell guru. All you need is a basic knowledge of Haskell, a willingness to learn, and a project you're excited to help with (or a project of your own to work on).<br />
<br />
There will be lots of hacking, good food, and, of course, fun! <br />
<br />
* Organiser: [mailto:marlowsd@gmail.com Simon Marlow] (<tt>JaffaCake</tt> on IRC)<br />
* Mailing list: [http://www.haskell.org/mailman/listinfo/hackathon hackathon@haskell.org]<br />
* IRC channel: #ghc on FreeNode<br />
<br />
Many thanks to [http://research.microsoft.com/en-us/labs/cambridge/default.aspx Microsoft Research Cambridge] for agreeing to sponsor the event.<br />
<br />
== Registration ==<br />
<br />
'''Registration deadline''': Friday 15th July 2011<br />
<br />
Registration is free. To register, please email [mailto:msrcevnt@microsoft.com msrcevnt@microsoft.com] stating that you would like to register for the "Haskell Hackathon", with the following information<br />
<br />
Full name:<br />
Which days you are attending on:<br />
day 1: yes/no<br />
day 2: yes/no<br />
day 3: yes/no<br />
Dietary requirements:<br />
<br />
The venue is '''limited to 50 people''', and registration is first-come first-served, so register quickly to reserve your place! (but only register if you definitely intend to come, and please let us know if you find you cannot make it for any reason after you have registered, so we can re-allocate your place).<br />
<br />
Some people will probably want to travel on Friday morning and join us later on that day - that's absolutely fine.<br />
<br />
== Venue ==<br />
<br />
We're in the [http://www.homertonconference.com/Horobin.html Horobin Room] of [http://www.homertonconference.com/ Homerton Conference Centre]. It is about [http://www.google.co.uk/maps?f=d&source=s_d&saddr=United+Kingdom+(Cambridge,+Railway+Station+(Stop+B))&daddr=CB2+8PH&hl=en&geocode=FehrHAMdjhUCACHpLU_p7S-CNg%3BFc5LHAMdNhMCACmn-uB8eXrYRzFlrDhff7fJ9A&mra=iwd&dirflg=w&sll=52.190667,0.134583&sspn=0.021547,0.040598&ie=UTF8&z=16 15 minutes walk from the train station], and Cambridge town centre is about 30 minutes walk.<br />
<br />
'''Times''': we have the room booked all day for the three days, and we'll probably start around 10am and finish around 6pm. Exact time details to be confirmed later. <br />
<br />
There will be WiFi access.<br />
<br />
There will be a projector for giving talks/demos. We will probably reserve a part of the time for talks and demos.<br />
<br />
== Food ==<br />
<br />
Tea and coffee will be supplied. We will have to go out to find lunch, but there are various places to eat and buy food at the [http://www.cambridge-x.co.uk Cambridge Leisure Park] a few minutes walk towards Cambridge town centre. In the evening we will probably head towards the town where there are plenty of good restaurants.<br />
<br />
== Local arrangements ==<br />
<br />
=== Getting to Cambridge ===<br />
<br />
==== By Plane ====<br />
<br />
* [http://www.stanstedairport.com/ Stansted Airport]: Stansted is the nearest of the London-area airports to Cambridge. It is mostly served by flights to and from mainland Europe, Ireland, and elsewhere in the UK. <br />
<br />
* [http://www.heathrowairport.com/ Heathrow Airport]: Heathrow is the principal London-area airport and one of the busiest in Europe with a wide range of national, European, and international services. <br />
<br />
* [http://www.gatwickairport.com/ Gatwick Airport]: Gatwick is the second "London" airport with a wide range of national, European and international services. <br />
<br />
* Other airports: [http://www.london-luton.co.uk/ Luton Airport], [http://www.norwichairport.co.uk/ Norwich airport], and [http://www.southendairport.com/ Southend airport] are other regional airports in the East Anglia region. If you use these, car or taxi is the best option for travel to Cambridge. <br />
<br />
==== Trains from London ====<br />
<br />
London has two train lines into Cambridge, London Kings Cross and London Liverpool Street. There is a regular service on both lines and duration is under an hour on the direct trains. Go to [http://www.nationalrail.co.uk National Rail] to check train times<br />
<br />
=== Getting to the venue ===<br />
<br />
[http://www.google.co.uk/maps?f=d&source=s_d&saddr=United+Kingdom+(Cambridge,+Railway+Station+(Stop+B))&daddr=CB2+8PH&hl=en&geocode=FehrHAMdjhUCACHpLU_p7S-CNg%3BFc5LHAMdNhMCACmn-uB8eXrYRzFlrDhff7fJ9A&mra=iwd&dirflg=w&sll=52.190667,0.134583&sspn=0.021547,0.040598&ie=UTF8&z=16 Walk from the train station] (about 15 minutes)<br />
<br />
[http://www.homertonconference.com/How-to-find-us.html How to find the venue]<br />
<br />
'''Local Taxis''': Panther Taxis 01223 715715<br />
<br />
=== Accommodation ===<br />
<br />
[http://www.visitcambridge.org/VisitCambridge/WhereToStay.aspx VisitCambridge: Where to Stay in Cambridge]<br />
<br />
The nearest hotels to the venue seem to be:<br />
<br />
* [http://www2.travelodge.co.uk/ Travelodge] (Cambridge Central) is just a few minutes walk from the venue. It is currently charging £65.80 per night for 11-14 August.<br />
* [http://www.helenhotel.co.uk/index.htm Helen Hotel]<br />
* [http://www.bandbincambridgeshire.co.uk/ Bridge Guest House]<br />
* [http://www.cheapguesthouses.com/ Fairways Guest House]<br />
* [http://www.abbeyfieldguesthouse.com/ Abbeyfield Guest House]<br />
* [http://rockviewguesthouse.co.uk/default.aspx Rock View Guest House]<br />
* [http://alingtonhouse.com/default.aspx Alington House Guest House]<br />
<br />
If you contact any of the above and find they're booked up, please remove them from the list.<br />
<br />
Microsoft Research recommends the following hotels to visitors, these are closer to the city centre but are probably a lot more expensive than those above:<br />
<br />
* [http://www.hilton.co.uk/cambridgegardenhouse Double Tree by Hilton Garden House Cambridge]<br />
* [http://www.ichotelsgroup.com/h/d/cp/1/en/hotel/cbguk Crowne Plaza Cambridge]<br />
* [http://www.devere.co.uk/our-locations/university-arms.html De Vere University Arms]<br />
<br />
== Projects ==<br />
<br />
Use this space to list projects you are interested in working on, and add your name to projects you are interested in helping with.<br />
<br />
* General hacking away at Snap Framework (exact goals TBD), perhaps adding/improving documentation/tutorials at the same time. (Jurriën Stutterheim)<br />
* Darcs<br />
<br />
== Attendees ==<br />
<br />
* Simon Marlow<br />
* Jurriën Stutterheim<br />
* Neil Mitchell<br />
* Jasper Van der Jeugt<br />
* Max Bolingbroke<br />
* Ben Millwood<br />
* Roman Leshchinskiy<br />
* Gregory Collins<br />
* Martijn van Steenbergen<br />
* Sjoerd Visscher<br />
* Sebastiaan Visser<br />
* Tom Lokhorst<br />
* Erik Hesselink<br />
* Jeff Foster<br />
* Sebastian Korten<br />
* Alessandro Vermeulen<br />
* Vlad Hanciuta<br />
* Ganesh Sittampalam<br />
* Eric Kow<br />
* Alexander Njemz<br />
* Mikolaj Konarski<br />
* Ian Lynagh<br />
* Add your name here, once registered...</div>Igloohttps://wiki.haskell.org/index.php?title=Library_submissions&diff=39699Library submissions2011-04-28T14:37:50Z<p>Igloo: </p>
<hr />
<div>As the Haskell community has grown, and emphasis on development has<br />
moved from language to libraries, the need for a more formalised process<br />
for contributing to libraries has emerged. This page documents our<br />
'best practices' for proposing changes to library interfaces<br />
(e.g. new modules or functions, removing functions) in packages that list ''libraries@haskell.org'' as maintainer.<br />
We have been using it since October 2006.<br />
<br />
In essence, we don't want proposals to go unnoticed, but changes to<br />
basic interfaces also need thorough consideration. <br />
<br />
== Creating a proposal ==<br />
<br />
In order to ensure we have something concrete to discuss, please follow<br />
the following guidelines:<br />
<br />
* ''Currency''. Make your changes against a copy of the HEAD branch of the [http://hackage.haskell.org/trac/ghc/wiki/DarcsRepositories relevant library], and make sure it compiles.<br />
* ''Portability''. Code should be portable. If it is not portable, reasons should be given. At the very least ensure the code runs in Hugs and GHC, and on Windows and Linux.<br />
* ''Style''. Follow the conventions in the library you are modifying.<br />
* ''Documentation''. It must include valid [http://haskell.org/haddock Haddock] documentation.<br />
* ''Tests''. Code should ideally also come with suitable tests for the testsuite. There's currently some disagreement about what this means. Discussion of where we may want to head is in the [[library tests]] page.<br />
<br />
== Submitting the proposal ==<br />
<br />
* ''Patch''. Create a [http://darcs.net darcs] or git patch (depending on what sort of repo the library lives in) of your change using <tt>darcs record</tt> or <tt>git commit -a</tt>, including a rationale for the change. Save the patch to a file, using <tt>darcs send --output</tt> or <tt>git format-patch</tt>.<br />
<br />
* ''Submission''. Start a new thread on the libraries@haskell.org mailing list (which you need to [http://www.haskell.org/mailman/listinfo/libraries subscribe] to before posting), with a subject beginning "Proposal:". Include a description of the change and the rationale, and attach the patch. You may wish to include a pointer to updated Haddock documentation, if relevant. You must also include a deadline for the discussion period; it must allow at least 2 weeks for discussion, but you may allow more - particularly if many people are likely to be away during the next 2 weeks. If discussion is still ongoing at the deadline, the discussion period can be extended.<br />
<br />
If someone has done all this, they are entitled to expect feedback;<br />
silence during the discussion period can be interpreted as consent.<br />
<br />
== At the end of the discussion period ==<br />
<br />
* Determine whether consensus for the change was reached. A deeply held disagreement at this point may require some form of governance (voting, dictatorship, etc). This should be a rare event.<br />
<br />
* If consensus was achieved, file a [http://hackage.haskell.org/trac/ghc/newticket ticket] on the GHC trac, attaching the (revised if necessary) patch. As well as the description and rationale, include a link to the discussion in the mailing list archives, as well as a summary of the conversation (the summary is needed for anyone wondering about the change later: it's not reasonable to point people at a 50-message thread (but please do include a link to the thread in the list archives too, so that people can review it if they wish)).<br />
<br />
Here is an example of how to [http://hackage.haskell.org/trac/ghc/ticket/966 summarise a successful submission].<br />
<br />
== See also ==<br />
<br />
* [http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions GHC Working Conventions], including guidelines for submitting patches via darcs.<br />
* [http://haskell.org/haskellwiki/Category:Style Notes on programming style]<br />
<br />
[[Category:Community]]<br />
[[Category:Proposals| ]]</div>Igloohttps://wiki.haskell.org/index.php?title=Library_submissions&diff=39646Library submissions2011-04-22T15:45:09Z<p>Igloo: /* Submitting the proposal */</p>
<hr />
<div>As the Haskell community has grown, and emphasis on development has<br />
moved from language to libraries, the need for a more formalised process<br />
for contributing to libraries has emerged. This page documents our<br />
'best practices' for proposing changes to library interfaces<br />
(e.g. new modules or functions, removing functions) in packages that list ''libraries@haskell.org'' as maintainer.<br />
We have been using it since October 2006.<br />
<br />
In essence, we don't want proposals to go unnoticed, but changes to<br />
basic interfaces also need thorough consideration. <br />
<br />
== Creating a proposal ==<br />
<br />
In order to ensure we have something concrete to discuss, please follow<br />
the following guidelines:<br />
<br />
* ''Currency''. Make your changes against a copy of the HEAD branch of the [http://hackage.haskell.org/trac/ghc/wiki/DarcsRepositories relevant library], and make sure it compiles.<br />
* ''Portability''. Code should be portable. If it is not portable, reasons should be given. At the very least ensure the code runs in Hugs and GHC, and on Windows and Linux.<br />
* ''Style''. Follow the conventions in the library you are modifying.<br />
* ''Documentation''. It must include valid [http://haskell.org/haddock Haddock] documentation.<br />
* ''Tests''. Code should ideally also come with suitable tests for the testsuite. There's currently some disagreement about what this means. Discussion of where we may want to head is in the [[library tests]] page.<br />
<br />
== Submitting the proposal ==<br />
<br />
* ''Patch''. Create a [http://darcs.net darcs] patch of your change using <tt>darcs record</tt>, including a rationale for the change. Save the patch to a file, using <tt>darcs send --output</tt>.<br />
<br />
* ''Submission''. Start a new thread on the libraries@haskell.org mailing list (which you need to [http://www.haskell.org/mailman/listinfo/libraries subscribe] to before posting), with a subject beginning "Proposal:". Include a description of the change and the rationale, and attach the patch. You may wish to include a pointer to updated Haddock documentation, if relevant. You must also include a deadline for the discussion period; it must allow at least 2 weeks for discussion, but you may allow more - particularly if many people are likely to be away during the next 2 weeks. If discussion is still ongoing at the deadline, the discussion period can be extended.<br />
<br />
If someone has done all this, they are entitled to expect feedback;<br />
silence during the discussion period can be interpreted as consent.<br />
<br />
== At the end of the discussion period ==<br />
<br />
* Determine whether consensus for the change was reached. A deeply held disagreement at this point may require some form of governance (voting, dictatorship, etc). This should be a rare event.<br />
<br />
* If consensus was achieved, file a [http://hackage.haskell.org/trac/ghc/newticket ticket] on the GHC trac, attaching the (revised if necessary) patch. As well as the description and rationale, include a link to the discussion in the mailing list archives, as well as a summary of the conversation (the summary is needed for anyone wondering about the change later: it's not reasonable to point people at a 50-message thread (but please do include a link to the thread in the list archives too, so that people can review it if they wish)).<br />
<br />
Here is an example of how to [http://hackage.haskell.org/trac/ghc/ticket/966 summarise a successful submission].<br />
<br />
== See also ==<br />
<br />
* [http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions GHC Working Conventions], including guidelines for submitting patches via darcs.<br />
* [http://haskell.org/haskellwiki/Category:Style Notes on programming style]<br />
<br />
[[Category:Community]]<br />
[[Category:Proposals| ]]</div>Igloohttps://wiki.haskell.org/index.php?title=GHC/As_a_library&diff=38853GHC/As a library2011-02-22T14:56:57Z<p>Igloo: </p>
<hr />
<div>''For instructions on the GHC API with GHC 6.8 or older please refer to [[GHC/As a library (up to 6.8)]]''<br />
<br />
__TOC__<br />
<br />
== Introduction ==<br />
<br />
GHC's functionality can be useful for more things than just compiling Haskell programs. Important use cases are programs that analyse (and perhaps transform) Haskell code. Others include loading Haskell code dynamically in a GHCi-like manner. For this reason, a lot of GHC's features can be accessed by programs which import the <tt>ghc</tt> package.<br />
<br />
The instructions on this page concern the API of GHC 6.10.1 and above. Please note that the GHC API is still in flux and may change quite significantly between major releases while we (the GHC team) provide new features or simplify certain aspects.<br />
<br />
<br />
== Getting Started ==<br />
<br />
To use the GHC API you need GHC 6.10.1 or above and import the <tt>ghc</tt> package.<br />
<pre><br />
ghc -package ghc my_program.hs<br />
</pre><br />
In most cases you probably also want to use the [http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-paths ghc-paths package].<br />
<br />
Most of the common functionality is provided by the <tt>GHC</tt> module, but occasionally you may have to import other modules. See the GHC's [http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/index.html haddock documentation] for a list of these modules. One good entry point into the docs is [http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html GHC].<br />
== A Simple Example ==<br />
<br />
The following little program essentially does what <tt>ghc --make</tt> does.<br />
<br />
<haskell><br />
import GHC<br />
import GHC.Paths ( libdir )<br />
import DynFlags ( defaultDynFlags )<br />
<br />
main = <br />
defaultErrorHandler defaultDynFlags $ do<br />
runGhc (Just libdir) $ do<br />
dflags <- getSessionDynFlags<br />
setSessionDynFlags dflags<br />
target <- guessTarget "test_main.hs" Nothing<br />
setTargets [target]<br />
load LoadAllTargets<br />
</haskell><br />
<br />
The outermost function, <tt>defaultErrorHandler</tt>, sets up proper exception handlers and prints an error message and exits with exit code 1 if it encounters one of these exceptions.<br />
<br />
Most of GHC's high-level API requires access to a current session. Therefore, these functions require to be called inside a monad that is an instance of the <tt>GhcMonad</tt> typeclass. Two default implementations of this typeclass are <tt>Ghc</tt> and <tt>GhcT</tt>. In the above example we used the <tt>Ghc</tt> monad since we don't need to track any extra state.<br />
<br />
The argument to <tt>runGhc</tt> is a bit tricky. GHC needs this to find its libraries, so the argument must refer to the directory that is printed by <tt>ghc --print-libdir</tt> for the ''same'' version of GHC that the program is being compiled with. Above we therefore use the <tt>ghc-paths</tt> package which provides this for us.<br />
<br />
== Another example ==<br />
<br />
Here we demonstrate calling [http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#v:parseModule parseModule], [http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#v:typecheckModule typecheckModule], [http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#v:desugarModule desugarModule], [http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#v:getNamesInScope getNamesInScope], and [http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#v:getModuleGraph getModuleGraph]. This works for haskell-platform, ghc-6.12.1. It also demonstrates how to enable some extensions.<br />
<br />
bugs: libdir is hardcoded. See ghc-paths above.<br />
<br />
<haskell><br />
--A.hs<br />
--invoke: ghci -package ghc A.hs<br />
<br />
import GHC<br />
import Outputable<br />
<br />
--import GHC.Paths ( libdir )<br />
import DynFlags ( defaultDynFlags )<br />
libdir = "/usr/local/lib/ghc-6.12.1"<br />
targetFile = "B.hs"<br />
<br />
main = do<br />
res <- example<br />
putStrLn $ showSDoc ( ppr res )<br />
<br />
example = <br />
defaultErrorHandler defaultDynFlags $ do<br />
runGhc (Just libdir) $ do<br />
dflags <- getSessionDynFlags<br />
let dflags' = foldl xopt_set dflags<br />
[Opt_Cpp, Opt_ImplicitPrelude, Opt_MagicHash]<br />
setSessionDynFlags dflags<br />
target <- guessTarget targetFile Nothing<br />
setTargets [target]<br />
load LoadAllTargets<br />
modSum <- getModSummary $ mkModuleName "B"<br />
p <- parseModule modSum<br />
t <- typecheckModule p<br />
d <- desugarModule t<br />
l <- loadModule d<br />
n <- getNamesInScope<br />
c <- return $ coreModule d<br />
<br />
g <- getModuleGraph<br />
mapM showModule g <br />
return $ (parsedSource d,"/n-----/n", typecheckedSource d)<br />
</haskell><br />
<br />
<haskell><br />
--B.hs<br />
module B where<br />
<br />
main = print "Hello, World!"<br />
<br />
</haskell><br />
<br />
== Links ==<br />
<br />
* [http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/index.html GHC API haddock]</div>Igloohttps://wiki.haskell.org/index.php?title=Library_submissions&diff=38450Library submissions2011-02-02T23:19:17Z<p>Igloo: </p>
<hr />
<div>As the Haskell community has grown, and emphasis on development has<br />
moved from language to libraries, the need for a more formalised process<br />
for contributing to libraries has emerged. This page documents our<br />
'best practices' for proposing changes to library interfaces<br />
(e.g. new modules or functions, removing functions) in packages that list ''libraries@haskell.org'' as maintainer.<br />
We have been using it since October 2006.<br />
<br />
In essence, we don't want proposals to go unnoticed, but changes to<br />
basic interfaces also need thorough consideration. <br />
<br />
== Creating a proposal ==<br />
<br />
In order to ensure we have something concrete to discuss, please follow<br />
the following guidelines:<br />
<br />
* ''Currency''. Make your changes against a copy of the HEAD branch of the [http://hackage.haskell.org/trac/ghc/wiki/DarcsRepositories relevant library], and make sure it compiles.<br />
* ''Portability''. Code should be portable. If it is not portable, reasons should be given. At the very least ensure the code runs in Hugs and GHC, and on Windows and Linux.<br />
* ''Style''. Follow the conventions in the library you are modifying.<br />
* ''Documentation''. It must include valid [http://haskell.org/haddock Haddock] documentation.<br />
* ''Tests''. Code should ideally also come with suitable tests for the testsuite. There's currently some disagreement about what this means. Discussion of where we may want to head is in the [[library tests]] page.<br />
<br />
== Submitting the proposal ==<br />
<br />
* ''Patch''. Create a [http://darcs.net darcs] patch of your change using <tt>darcs record</tt>, including a rationale for the change. Save the patch to a file, using <tt>darcs send --output</tt>.<br />
<br />
* ''Submission''. Start a new thread on the libraries@haskell.org mailing list (which you need to [http://www.haskell.org/mailman/listinfo/libraries subscribe] to before posting), with a subject beginning "Proposal:". Include a description of the change and the rationale, and attach the patch. You may wish to include a pointer to updated Haddock documentation, if relevant.<br />
<br />
If someone has done all this, they are entitled to expect feedback;<br />
silence during the discussion period can be interpreted as consent.<br />
<br />
== At the end of the discussion period ==<br />
<br />
* Determine whether consensus for the change was reached. A deeply held disagreement at this point may require some form of governance (voting, dictatorship, etc). This should be a rare event.<br />
<br />
* If consensus was achieved, file a [http://hackage.haskell.org/trac/ghc/newticket ticket] on the GHC trac, attaching the (revised if necessary) patch. As well as the description and rationale, include a link to the discussion in the mailing list archives, as well as a summary of the conversation (the summary is needed for anyone wondering about the change later: it's not reasonable to point people at a 50-message thread (but please do include a link to the thread in the list archives too, so that people can review it if they wish)).<br />
<br />
Here is an example of how to [http://hackage.haskell.org/trac/ghc/ticket/966 summarise a successful submission].<br />
<br />
== See also ==<br />
<br />
* [http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions GHC Working Conventions], including guidelines for submitting patches via darcs.<br />
* [http://haskell.org/haskellwiki/Category:Style Notes on programming style]<br />
<br />
[[Category:Community]]<br />
[[Category:Proposals| ]]</div>Igloohttps://wiki.haskell.org/index.php?title=Haskell.org_committee&diff=37886Haskell.org committee2010-12-13T12:20:00Z<p>Igloo: </p>
<hr />
<div>== Responsibilities ==<br />
<br />
The ''haskell.org committee'' represents the Open Source Haskell community. Its responsibilities include:<br />
<br />
* setting the policy on what [http://haskell.org/haskellwiki/Haskell.org_domain the haskell.org domain] name, and its subdomains, may be used for<br />
* setting the policy on what the servers owned by haskell.org may be used for<br />
* determining how haskell.org funds are spent<br />
<br />
== Current members ==<br />
<br />
* Don Stewart [chair]<br />
* Edward Z. Yang<br />
* Ganesh Sittampalam (term ends 2012)<br />
* Ian Lynagh (term ends 2011)<br />
* Johan Tibell (term ends 2012)<br />
* Malcolm Wallace (term ends 2011)<br />
* Vo Minh Thu<br />
<br />
e-mail: committee [AT] haskell.org<br />
<br />
== Operation ==<br />
<br />
The committee consists of 7 members. Members are expected to serve a 3 year term, and terms are staggered so that 2 or 3 members step down each year, at the end of October.<br />
<br />
The members will elect one of their number to be chair each year. The chair is responsible for making sure that things keep moving, and to ensure that a conclusion is reached on any issues raised.<br />
<br />
When a member steps down, either because they have reached the end of their term or because other circumstances require them to step down early, open self-nominations will be sought from the community via the haskell@ mailing list. Previous committee members, including those who have just stepped down, will also be eligible for nomination. The committee will then select a replacement from amongst those nominated.<br />
<br />
The committee replacement process is intentionally currently very light. As we get more experience, we may wish to change it, e.g. by having a larger subset of "the community" vote on nominations.<br />
<br />
If any member of the community wishes to raise any issue with the committee, they may contact it by e-mailing committee [AT] haskell.org.<br />
<br />
It is expected the committee will discuss any matters brought to it amongst themselves, and if they think appropriate, with the wider community, to try to reach consensus. Ultimately, the committee will make decisions by more than half of the membership voting for a particular outcome. These rules of operation may also be changed in the same way.<br />
<br />
Each year, the committee will post a statement of the haskell.org assets, and the transactions for that year. Some details may be omitted, e.g. for confidentiality of donors.<br />
<br />
<br />
[[Category:Community]]</div>Igloohttps://wiki.haskell.org/index.php?title=Template:Main/Quicklinks&diff=37579Template:Main/Quicklinks2010-11-30T17:08:50Z<p>Igloo: New version from test wiki</p>
<hr />
<div><b>Get Haskell</b><br />
<br />
* [http://hackage.haskell.org/platform/ The Haskell Platform]<br />
<br />
<b>Learn Haskell</b><br />
<br />
* [http://tryhaskell.org/ Try Haskell online]<br />
* [[Learning_Haskell|Online Tutorials]]<br />
<br />
<b>Explore Haskell</b><br />
<br />
* [[Applications_and_libraries|Documentation]]<br />
* [http://hackage.haskell.org/packages/archive/pkg-list.html Libraries]<br />
* [[Books_and_tutorials|Books]]</div>Igloohttps://wiki.haskell.org/index.php?title=Haskell&diff=37578Haskell2010-11-30T17:08:12Z<p>Igloo: New version from test wiki</p>
<hr />
<div>__NOTOC__<br />
__NOEDITSECTION__<br />
<div class="bg-image"><br />
<div class="title">The Haskell Programming Language</div><br />
<div class="intro"><br />
{{Main/Intro}}<br />
</div><br />
</div><br />
<br />
<div class="wrap"><br />
<div class="cols3 w1000" style="margin: 0 auto; text-align: left"><br />
<div class="c1"><div class="pad"><br />
{{Main/Learning}}<br />
</div></div><br />
<div class="c2"><div class="pad"><br />
{{Main/Libraries}}<br />
</div></div><br />
<div class="c3"><div class="pad"><br />
{{Main/Community}}<br />
</div></div><br />
</div><br />
</div><br />
<br />
<div class="visualClear"></div><br />
<br />
<div class="home-dynamic"><br />
<div class="wrap"><br />
<div style="text-align: center; text-shadow: white 0 1px; color: #666; font-size:smaller; margin-top:5px">News</div><br />
<div class="cols3 w1000"><br />
<div class="c1"><div class="pad"><br />
{{Main/Headlines}}<br />
</div></div><br />
<div class="c2"><div class="pad"><br />
{{Main/Events}}<br />
</div></div><br />
<div class="c3"><div class="pad"><br />
{{Main/News}}<br />
</div></div><br />
<div class="visualClear"></div><br />
</div><br />
<div class="visualClear"></div><br />
</div><br />
</div></div>Igloohttps://wiki.haskell.org/index.php?title=Haskell.org_domain&diff=37453Haskell.org domain2010-11-15T17:40:36Z<p>Igloo: </p>
<hr />
<div>[[Category:Community]]<br />
<br />
== Overview ==<br />
The names in the '''haskell.org domain''' point to a set of machines:<br />
<br />
=== [[haskell.org]] ===<br />
<br />
This machine responds to the names ''haskell.org'', ''www.haskell.org'', ''bugs.haskell.org'', ''haskell.cs.yale.edu''. It is hosted at Yale university.<br />
<br />
* web server and wiki, http://haskell.org/<br />
* [[mailing lists]], http://haskell.org/mailman/listinfo<br />
<br />
''MRTG'': [http://www.haskell.org/mrtg/localhost_00-c0-a8-7b-85-3c.html All network traffic].<br />
<br />
''Notes'': domain name to expire in December 2010. Plan underway to move to new-www.haskell.org (see below).<br />
<br />
=== lambda.haskell.org ===<br />
<br />
This machine responds to the names ''lambda.galois.com'' and ''new-www.haskell.org''. It is hosted in Germany by Hentzner.<br />
<br />
=== abbot ===<br />
<br />
This machine responds to the names ''darcs.haskell.org'', ''hackage.haskell.org'', ''cvs.haskell.org'', ''haskell.galois.com'', ''abbot.galois.com''. It is a dedicated host in Galois server room.<br />
<br />
* darcs repositories for GHC and core libraries, http://darcs.haskell.org/<br />
* HackageDB, http://hackage.haskell.org/<br />
* old CVS repositories, http://cvs.haskell.org/<br />
* various Trac instances, e.g. http://hackage.haskell.org/trac/ghc<br />
<br />
''MRTG'': [http://abbot.galois.com/mrtg/localhost_f4-ce-46-0f-0d-6e.html All network traffic], [http://abbot.galois.com/mrtg/external-bandwidth.html External network bandwidth], [http://abbot.galois.com/mrtg/freedisk.html Free disk space], [http://abbot.galois.com/mrtg/system-load.html System load], [http://abbot.galois.com/mrtg/memory.html Free memory], [http://abbot.galois.com/mrtg/swap.html Free swap], [http://abbot.galois.com/mrtg/daily.html All of the daily graphs].<!-- <br>''Analog'': [http://abbot.galois.com/analog/cvs_darcs/cvs.html cvs/darcs], [http://abbot.galois.com/analog/hackage/hackage.html hackage]. --><br />
<br />
For more details, see [[Abbot]].<br />
<br />
=== nun.haskell.org ===<br />
This machine also responds to the names [http://community.haskell.org/ ''community.haskell.org''], ''projects.haskell.org'', ''code.haskell.org'', ''trac.haskell.org'', ''rt.haskell.org'', ''planet.haskell.org''. See [http://www.haskell.org/pipermail/haskell/2007-June/019592.html this message].<br />
<br />
The Haskell community server is designed to support and encourage open Haskell-based projects and collaborations of all kinds, provided only that their intention is to contribute something to<br />
the community, and that all hosted project content is publicly available.<br />
Resources available include:<br />
<br />
* Publicly available read-only [http://darcs.org/ darcs] repositories, http://code.haskell.org/<br />
* Write access to the darcs repositories for project members<br />
* [http://trac.edgewall.org/ Trac] instances for integrated issue tracking, wiki, and project management. Trac instances are also integrated with the project's darcs repository. http://trac.haskell.org/<br />
* [http://www.gnu.org/software/mailman/ GNU Mailman] mailing lists<br />
* Public web-space for projects, http://projects.haskell.org/<br />
* Personal web-space for project members<br />
* Blog aggregation, http://planet.haskell.org/<br />
<br />
For information about how to host a project, see http://community.haskell.org/.<br />
<br />
''Notes:'' machine has been increasingly unreliable. Plan to move to a VM host on new-www.haskell.org<br />
<br />
''MRTG'': [http://community.haskell.org/mrtg/localhost_venet0.html All network traffic], [http://community.haskell.org/mrtg/freedisk.html Free disk space], [http://community.haskell.org/mrtg/system-load.html System load], [http://community.haskell.org/mrtg/memory.html Free memory], [http://community.haskell.org/mrtg/swap.html Free swap], [http://community.haskell.org/mrtg/daily.html All of the daily graphs].<br />
<br />
=== sparky.haskell.org ===<br />
<br />
sparky - a SPARC T2 donated by (formerly) Sun Microsystems. Kindly hosted by Chalmers but technically owned by Oxford University Computing Lab (?).<br />
<br />
== Relation between the services ==<br />
<br />
''I'm wondering what the relationship is (if any) between code.haskell.org and darcs.haskell.org.''<br />
<br />
:darcs.haskell.org hosts ghc, the core libs and many others. The server is maintained by Galois. Because it hosts the most central bits of the haskell platform, security is fairly tight and getting an account there is hard. There are very few community members with root privileges.<br />
<br />
:community.haskell.org was created precisely to provide hosting to the wider community. It is hosted commercially, paid for by haskell.org's Google Summer of Code funds. We have several community admins with root privileges.<br />
<br />
''Should my projects be hosted at darcs or code?''<br />
<br />
:code.haskell.org. It's easy to get an account there via the web submission system: http://community.haskell.org/admin/<br />
<br />
''Is one more blessed/preferred over the other for community projects?''<br />
<br />
:Yes, code.haskell.org is preferred.<br />
<br />
''If my project is currently on darcs, should I migrate to code?''<br />
<br />
:You can if you like, there is no need to do so however. Accounts on darcs.haskell.org are not going to be revoked as far as I know. The community server is an addition, not a replacement.<br />
<br />
''If I have an account on darcs, will it work on code, or do I need to get a new account on code?''<br />
<br />
:They are totally separate systems.<br />
<br />
== See also ==<br />
<br />
http://www.haskell.org/pipermail/haskell-cafe/2008-January/038759.html</div>Igloohttps://wiki.haskell.org/index.php?title=Haskell.org_domain&diff=37452Haskell.org domain2010-11-15T17:39:03Z<p>Igloo: </p>
<hr />
<div>[[Category:Community]]<br />
<br />
== Overview ==<br />
The names in the '''haskell.org domain''' point to a set of machines:<br />
<br />
=== [[haskell.org]] ===<br />
<br />
This machine responds to the names ''haskell.org'', ''www.haskell.org'', ''bugs.haskell.org'', ''haskell.cs.yale.edu''. It is hosted at Yale university.<br />
<br />
* web server and wiki, http://haskell.org/<br />
* [[mailing lists]], http://haskell.org/mailman/listinfo<br />
<br />
''MRTG'': [http://www.haskell.org/mrtg/localhost_00-c0-a8-7b-85-3c.html All network traffic].<br />
<br />
''Notes'': domain name to expire in December 2010. Plan underway to move to new-www.haskell.org (see below).<br />
<br />
=== lambda.haskell.org ===<br />
<br />
This machine responds to the names ''lambda.galois.com'' and ''new-www.haskell.org''. It is hosted in Germany by Hentzner.<br />
<br />
=== abbot ===<br />
<br />
This machine responds to the names ''darcs.haskell.org'', ''hackage.haskell.org'', ''cvs.haskell.org'', ''haskell.galois.com'', ''abbot.galois.com''. It is a dedicated host in Galois server room.<br />
<br />
* darcs repositories for GHC and core libraries, http://darcs.haskell.org/<br />
* HackageDB, http://hackage.haskell.org/<br />
* old CVS repositories, http://cvs.haskell.org/<br />
* various Trac instances, e.g. http://hackage.haskell.org/trac/ghc<br />
<br />
''MRTG'': [http://abbot.galois.com/mrtg/localhost_f4-ce-46-0f-0d-6e.html All network traffic], [http://abbot.galois.com/mrtg/external-bandwidth.html External network bandwidth], [http://abbot.galois.com/mrtg/freedisk.html Free disk space], [http://abbot.galois.com/mrtg/system-load.html System load], [http://abbot.galois.com/mrtg/memory.html Free memory], [http://abbot.galois.com/mrtg/swap.html Free swap], [http://abbot.galois.com/mrtg/daily.html All of the daily graphs].<!-- <br>''Analog'': [http://abbot.galois.com/analog/cvs_darcs/cvs.html cvs/darcs], [http://abbot.galois.com/analog/hackage/hackage.html hackage]. --><br />
<br />
For more details, see [[Abbot]].<br />
<br />
=== [http://community.haskell.org/ community.haskell.org] ===<br />
This machine also responds to the names ''projects.haskell.org'', ''code.haskell.org'', ''trac.haskell.org'', ''rt.haskell.org'', ''planet.haskell.org''. See [http://www.haskell.org/pipermail/haskell/2007-June/019592.html this message].<br />
<br />
The Haskell community server is designed to support and encourage open Haskell-based projects and collaborations of all kinds, provided only that their intention is to contribute something to<br />
the community, and that all hosted project content is publicly available.<br />
Resources available include:<br />
<br />
* Publicly available read-only [http://darcs.org/ darcs] repositories, http://code.haskell.org/<br />
* Write access to the darcs repositories for project members<br />
* [http://trac.edgewall.org/ Trac] instances for integrated issue tracking, wiki, and project management. Trac instances are also integrated with the project's darcs repository. http://trac.haskell.org/<br />
* [http://www.gnu.org/software/mailman/ GNU Mailman] mailing lists<br />
* Public web-space for projects, http://projects.haskell.org/<br />
* Personal web-space for project members<br />
* Blog aggregation, http://planet.haskell.org/<br />
<br />
For information about how to host a project, see http://community.haskell.org/.<br />
<br />
''Notes:'' machine has been increasingly unreliable. Plan to move to a VM host on new-www.haskell.org<br />
<br />
''MRTG'': [http://community.haskell.org/mrtg/localhost_venet0.html All network traffic], [http://community.haskell.org/mrtg/freedisk.html Free disk space], [http://community.haskell.org/mrtg/system-load.html System load], [http://community.haskell.org/mrtg/memory.html Free memory], [http://community.haskell.org/mrtg/swap.html Free swap], [http://community.haskell.org/mrtg/daily.html All of the daily graphs].<br />
<br />
=== sparky.haskell.org ===<br />
<br />
sparky - a SPARC T2 donated by (formerly) Sun Microsystems. Kindly hosted by Chalmers but technically owned by Oxford University Computing Lab (?).<br />
<br />
== Relation between the services ==<br />
<br />
''I'm wondering what the relationship is (if any) between code.haskell.org and darcs.haskell.org.''<br />
<br />
:darcs.haskell.org hosts ghc, the core libs and many others. The server is maintained by Galois. Because it hosts the most central bits of the haskell platform, security is fairly tight and getting an account there is hard. There are very few community members with root privileges.<br />
<br />
:community.haskell.org was created precisely to provide hosting to the wider community. It is hosted commercially, paid for by haskell.org's Google Summer of Code funds. We have several community admins with root privileges.<br />
<br />
''Should my projects be hosted at darcs or code?''<br />
<br />
:code.haskell.org. It's easy to get an account there via the web submission system: http://community.haskell.org/admin/<br />
<br />
''Is one more blessed/preferred over the other for community projects?''<br />
<br />
:Yes, code.haskell.org is preferred.<br />
<br />
''If my project is currently on darcs, should I migrate to code?''<br />
<br />
:You can if you like, there is no need to do so however. Accounts on darcs.haskell.org are not going to be revoked as far as I know. The community server is an addition, not a replacement.<br />
<br />
''If I have an account on darcs, will it work on code, or do I need to get a new account on code?''<br />
<br />
:They are totally separate systems.<br />
<br />
== See also ==<br />
<br />
http://www.haskell.org/pipermail/haskell-cafe/2008-January/038759.html</div>Igloohttps://wiki.haskell.org/index.php?title=Haskell.org_committee&diff=37445Haskell.org committee2010-11-12T13:16:17Z<p>Igloo: </p>
<hr />
<div>== Responsibilities ==<br />
<br />
The ''haskell.org committee'' represents the Open Source Haskell community. Its responsibilities include:<br />
<br />
* setting the policy on what the haskell.org domain name, and its subdomains, may be used for<br />
* setting the policy on what the servers owned by haskell.org may be used for<br />
* determining how haskell.org funds are spent<br />
<br />
== Current members ==<br />
<br />
* Don Stewart [chair]<br />
* Edward Z. Yang<br />
* Ganesh Sittampalam<br />
* Ian Lynagh<br />
* Johan Tibell<br />
* Malcolm Wallace<br />
* Vo Minh Thu<br />
<br />
e-mail: committee [AT] haskell.org<br />
<br />
== Operation ==<br />
<br />
The committee consists of 7 members. Members are expected to serve a 3 year term, and terms are staggered so that 2 or 3 members step down each year.<br />
<br />
The members will elect one of their number to be chair each year. The chair is responsible for making sure that things keep moving, and to ensure that a conclusion is reached on any issues raised.<br />
<br />
When a member steps down, either because they have reached the end of their term or because other circumstances require them to step down early, open self-nominations will be sought from the community via the haskell@ mailing list. Previous committee members, including those who have just stepped down, will also be eligible for nomination. The committee will then select a replacement from amongst those nominated.<br />
<br />
The committee replacement process is intentionally currently very light. As we get more experience, we may wish to change it, e.g. by having a larger subset of "the community" vote on nominations.<br />
<br />
If any member of the community wishes to raise any issue with the committee, they may contact it by e-mailing committee [AT] haskell.org.<br />
<br />
It is expected the committee will discuss any matters brought to it amongst themselves, and if they think appropriate, with the wider community, to try to reach consensus. Ultimately, the committee will make decisions by more than half of the membership voting for a particular outcome. These rules of operation may also be changed in the same way.<br />
<br />
Each year, the committee will post a statement of the haskell.org assets, and the transactions for that year. Some details may be omitted, e.g. for confidentiality of donors.<br />
<br />
<br />
[[Category:Community]]</div>Igloohttps://wiki.haskell.org/index.php?title=Haskell.org_committee&diff=37430Haskell.org committee2010-11-11T12:52:59Z<p>Igloo: describe the chair's role</p>
<hr />
<div>== Responsibilities ==<br />
<br />
The ''haskell.org committee'' represents the Open Source Haskell community. Its responsibilities include:<br />
<br />
* setting the policy on what the haskell.org domain name, and its subdomains, may be used for<br />
* setting the policy on what the servers owned by haskell.org may be used for<br />
* determining how haskell.org funds are spent<br />
<br />
== Current members ==<br />
<br />
The first haskell.org committee has not yet been selected.<br />
<br />
== Operation ==<br />
<br />
The committee consists of 7 members. Members are expected to serve a 3 year term, and terms are staggered so that 2 or 3 members step down each year.<br />
<br />
The members will elect one of their number to be chair each year. The chair is responsible for making sure that things keep moving, and to ensure that a conclusion is reached on any issues raised.<br />
<br />
When a member steps down, either because they have reached the end of their term or because other circumstances require them to step down early, open self-nominations will be sought from the community via the haskell@ mailing list. Previous committee members, including those who have just stepped down, will also be eligible for nomination. The committee will then select a replacement from amongst those nominated.<br />
<br />
The committee replacement process is intentionally currently very light. As we get more experience, we may wish to change it, e.g. by having a larger subset of "the community" vote on nominations.<br />
<br />
If any member of the community wishes to raise any issue with the committee, they may contact it by e-mailing [an address yet to be set up]<br />
<br />
It is expected the committee will discuss any matters brought to it amongst themselves, and if they think appropriate, with the wider community, to try to reach consensus. Ultimately, the committee will make decisions by more than half of the membership voting for a particular outcome. These rules of operation may also be changed in the same way.<br />
<br />
Each year, the committee will post a statement of the haskell.org assets, and the transactions for that year. Some details may be omitted, e.g. for confidentiality of donors.<br />
<br />
<br />
[[Category:Community]]</div>Igloohttps://wiki.haskell.org/index.php?title=CommunityMigration&diff=37424CommunityMigration2010-11-10T16:32:21Z<p>Igloo: </p>
<hr />
<div>== Migration From Etch ==<br />
<br />
=== Deliverables ===<br />
* c.h.o migrated to new server, all services functioning as before for all users<br />
* Regularly scheduled automated off-site backups of new server, so that we can redeploy if we suddenly lose the server (hardware failure, VPS provider belly up, etc.)<br />
* A set of migration scripts that can be re-used in case we need to migrate again in the future<br />
* A set of policies/procedures that will keep the migration scripts up-to-date<br />
<br />
=== Assets to be moved ===<br />
==== Services to migrate ====<br />
<br />
The following are in separately doable chunks:<br />
<br />
* Increase lun's memory allocation and move the disk image out of ~igloo<br />
<br />
* nagios<br />
<br />
* Admin home directories<br />
<br />
* Configure exim, mailman, apache, clamav<br />
<br />
* planet.haskell.org<br />
* planet (might need to migrate one or two users early for this)<br />
<br />
* projects.haskell.org MX (hmm, this'll divorce the lists from the web interface)<br />
* mailman (need to disable list creation script on nun first)<br />
<br />
* projects.haskell.org<br />
* code.haskell.org<br />
* community.haskell.org<br />
* trac.haskell.org<br />
* User accounts and home directories<br />
* RT on PostgreSQL<br />
* Trac<br />
* http<br />
* Exim<br />
* c.h.o admin scripts for users<br />
* account_request<br />
* project_request<br />
* createlist<br />
* createtrac<br />
* addtoproject<br />
* crontabfor<br />
* c.h.o admin scripts for admins<br />
* create_user.sh<br />
* create_project.sh<br />
<br />
==== User data to be transfered ====<br />
* User accounts and home directories<br />
* Project groups in /etc/group<br />
* Darcs repos from /srv/projects<br />
* Project data from /srv/code<br />
* Trac projects<br />
* Mailman lists<br />
* Planet Haskell<br />
* Physical mailboxes (igloo and malcolm)<br />
<br />
==== Domains to be transferred ====<br />
* community<br />
* code<br />
* rt<br />
* planet<br />
* trac<br />
* projects<br />
<br />
=== Migration plan ===<br />
<br />
Coordination will happen on the #haskell-infrastructure channel on FreeNode.<br />
<br />
==== Preparatory stage ====<br />
1. Formulate plan on how to communicate with users during the migration process; begin gathering required contact info if necessary<br />
1. Calculate the approximate size and rate of change of each type of data on the server<br />
1. Give preliminary notice to users and ask for feedback<br />
1. Configure domain name etch.haskell.org (will later become read-only copy and left active for a while as a backup)<br />
1. Change TTL on all domains to be short<br />
1. Provision the new server<br />
1. Install and perform basic configuration of all services<br />
1. Test all installed services<br />
1. Set up backup mirror(s)<br />
1. Set up backup mirror services/scripts. Install on new server and test.<br />
1. Write scripts to copy user accounts and rsync home directories, and to verify<br />
1. Write scripts to copy project groups in /etc/group, and to verify<br />
1. Write scripts to rsync darcs repos from /srv/projects, and to verify<br />
1. Write scripts to rsync project data from /srv/code, and to verify<br />
1. Write scripts to rsync trac projects, and to verify<br />
1. Write scripts to copy mailman lists and rsync archives, and to verify<br />
1. Write scripts to rsync Planet Haskell, and to verify<br />
1. Write a script to make all user data and projects read-only (except mailman archives), and to verify.<br />
1. Write a script to *undo* making things read-only, in case of emergency.<br />
1. Test all scripts thoroughly<br />
1. Fix dates for beginning initial copy and final migration, and give advance notice and instructions to users.<br />
1. Transfer RT database and verify (as a dry run, go through the entire migration process just for RT)<br />
1. Move the rt domain<br />
1. After TTL, verify that RT is working on the new server<br />
<br />
==== Initial copy ====<br />
1. Run script to copy user accounts. Verify.<br />
1. Run script to copy /etc/group entries for projects. Verify.<br />
1. Run scripts to rsync home directories, darcs repos, project data, trac projects, mailman archives, and Planet data<br />
1. Monitor progress; update schedule and notify users as needed<br />
1. When completed, verify.<br />
<br />
==== D-Day ====<br />
1. Notify users.<br />
1. Stop the Planet Haskell hourly cron job.<br />
1. Run script to make all user data and projects read-only. Verify.<br />
1. If any user accounts or projects were added since initial copy began, add them.<br />
1. Run scripts to rsync home directories, darcs repos, project data, and Trac projects. Verify.<br />
1. Stop mailman service on etch.<br />
1. Run the scripts to rsync mailman archives. Verify.<br />
1. Move the domain CNAME for community, trac, projects, and code.<br />
1. After TTL, verify remotely that the domains moved and that services are working.<br />
1. Notify users of current status.<br />
1. Tell Ian and Malcolm to check their mail.<br />
1. Move the domain MX records.<br />
1. Run the scripts to rsync Planet Haskell. Verify.<br />
1. Move the planet domain.<br />
1. Start the Planet Haskell hourly cron job.<br />
1. After TTL, verify remotely that '''all''' domains are moved and that '''all''' services are working.<br />
1. Notify users and community.<br />
<br />
==== Post-migration tasks ====<br />
1. Activate backup mirroring. Verify.<br />
1. Monitor net bandwidth and responsiveness of the new server.<br />
1. Monitor memory and cpu usage on the new server.<br />
1. Monitor and tune settings of PostgreSQL for resource usage on the new server<br />
1. Monitor and tune settings of Apache for resource usage on the new server<br />
1. After a day or two, raise TTL back to normal levels on all domains<br />
1. After a month or two, delete the Etch server</div>Igloohttps://wiki.haskell.org/index.php?title=CommunityMigration&diff=37422CommunityMigration2010-11-10T16:06:54Z<p>Igloo: </p>
<hr />
<div>== Migration From Etch ==<br />
<br />
=== Deliverables ===<br />
* c.h.o migrated to new server, all services functioning as before for all users<br />
* Regularly scheduled automated off-site backups of new server, so that we can redeploy if we suddenly lose the server (hardware failure, VPS provider belly up, etc.)<br />
* A set of migration scripts that can be re-used in case we need to migrate again in the future<br />
* A set of policies/procedures that will keep the migration scripts up-to-date<br />
<br />
=== Assets to be moved ===<br />
==== Services to migrate ====<br />
<br />
The following are in separately doable chunks:<br />
<br />
* Increase lun's memory allocation and move the disk image out of ~igloo<br />
<br />
* nagios<br />
<br />
* Admin home directories<br />
<br />
* Configure exim, mailman, apache, clamav<br />
<br />
* planet.haskell.org<br />
* planet (might need to migrate one or two users early for this)<br />
<br />
* projects.haskell.org MX<br />
* mailman (need to disable list creation script on nun first)<br />
<br />
* projects.haskell.org<br />
* code.haskell.org<br />
* community.haskell.org<br />
* trac.haskell.org<br />
* User accounts and home directories<br />
* RT on PostgreSQL<br />
* Trac<br />
* http<br />
* Exim<br />
* c.h.o admin scripts for users<br />
* account_request<br />
* project_request<br />
* createlist<br />
* createtrac<br />
* addtoproject<br />
* crontabfor<br />
* c.h.o admin scripts for admins<br />
* create_user.sh<br />
* create_project.sh<br />
<br />
==== User data to be transfered ====<br />
* User accounts and home directories<br />
* Project groups in /etc/group<br />
* Darcs repos from /srv/projects<br />
* Project data from /srv/code<br />
* Trac projects<br />
* Mailman lists<br />
* Planet Haskell<br />
* Physical mailboxes (igloo and malcolm)<br />
<br />
==== Domains to be transferred ====<br />
* community<br />
* code<br />
* rt<br />
* planet<br />
* trac<br />
* projects<br />
<br />
=== Migration plan ===<br />
<br />
Coordination will happen on the #haskell-infrastructure channel on FreeNode.<br />
<br />
==== Preparatory stage ====<br />
1. Formulate plan on how to communicate with users during the migration process; begin gathering required contact info if necessary<br />
1. Calculate the approximate size and rate of change of each type of data on the server<br />
1. Give preliminary notice to users and ask for feedback<br />
1. Configure domain name etch.haskell.org (will later become read-only copy and left active for a while as a backup)<br />
1. Change TTL on all domains to be short<br />
1. Provision the new server<br />
1. Install and perform basic configuration of all services<br />
1. Test all installed services<br />
1. Set up backup mirror(s)<br />
1. Set up backup mirror services/scripts. Install on new server and test.<br />
1. Write scripts to copy user accounts and rsync home directories, and to verify<br />
1. Write scripts to copy project groups in /etc/group, and to verify<br />
1. Write scripts to rsync darcs repos from /srv/projects, and to verify<br />
1. Write scripts to rsync project data from /srv/code, and to verify<br />
1. Write scripts to rsync trac projects, and to verify<br />
1. Write scripts to copy mailman lists and rsync archives, and to verify<br />
1. Write scripts to rsync Planet Haskell, and to verify<br />
1. Write a script to make all user data and projects read-only (except mailman archives), and to verify.<br />
1. Write a script to *undo* making things read-only, in case of emergency.<br />
1. Test all scripts thoroughly<br />
1. Fix dates for beginning initial copy and final migration, and give advance notice and instructions to users.<br />
1. Transfer RT database and verify (as a dry run, go through the entire migration process just for RT)<br />
1. Move the rt domain<br />
1. After TTL, verify that RT is working on the new server<br />
<br />
==== Initial copy ====<br />
1. Run script to copy user accounts. Verify.<br />
1. Run script to copy /etc/group entries for projects. Verify.<br />
1. Run scripts to rsync home directories, darcs repos, project data, trac projects, mailman archives, and Planet data<br />
1. Monitor progress; update schedule and notify users as needed<br />
1. When completed, verify.<br />
<br />
==== D-Day ====<br />
1. Notify users.<br />
1. Stop the Planet Haskell hourly cron job.<br />
1. Run script to make all user data and projects read-only. Verify.<br />
1. If any user accounts or projects were added since initial copy began, add them.<br />
1. Run scripts to rsync home directories, darcs repos, project data, and Trac projects. Verify.<br />
1. Stop mailman service on etch.<br />
1. Run the scripts to rsync mailman archives. Verify.<br />
1. Move the domain CNAME for community, trac, projects, and code.<br />
1. After TTL, verify remotely that the domains moved and that services are working.<br />
1. Notify users of current status.<br />
1. Tell Ian and Malcolm to check their mail.<br />
1. Move the domain MX records.<br />
1. Run the scripts to rsync Planet Haskell. Verify.<br />
1. Move the planet domain.<br />
1. Start the Planet Haskell hourly cron job.<br />
1. After TTL, verify remotely that '''all''' domains are moved and that '''all''' services are working.<br />
1. Notify users and community.<br />
<br />
==== Post-migration tasks ====<br />
1. Activate backup mirroring. Verify.<br />
1. Monitor net bandwidth and responsiveness of the new server.<br />
1. Monitor memory and cpu usage on the new server.<br />
1. Monitor and tune settings of PostgreSQL for resource usage on the new server<br />
1. Monitor and tune settings of Apache for resource usage on the new server<br />
1. After a day or two, raise TTL back to normal levels on all domains<br />
1. After a month or two, delete the Etch server</div>Igloohttps://wiki.haskell.org/index.php?title=CommunityMigration&diff=37421CommunityMigration2010-11-10T16:05:52Z<p>Igloo: </p>
<hr />
<div>== Migration From Etch ==<br />
<br />
=== Deliverables ===<br />
* c.h.o migrated to new server, all services functioning as before for all users<br />
* Regularly scheduled automated off-site backups of new server, so that we can redeploy if we suddenly lose the server (hardware failure, VPS provider belly up, etc.)<br />
* A set of migration scripts that can be re-used in case we need to migrate again in the future<br />
* A set of policies/procedures that will keep the migration scripts up-to-date<br />
<br />
=== Assets to be moved ===<br />
==== Services to migrate ====<br />
<br />
The following are in separately doable chunks:<br />
<br />
* nagios<br />
<br />
* Admin home directories<br />
<br />
* Configure exim, mailman, apache, clamav<br />
<br />
* planet.haskell.org<br />
* planet (might need to migrate one or two users early for this)<br />
<br />
* projects.haskell.org MX<br />
* mailman (need to disable list creation script on nun first)<br />
<br />
* projects.haskell.org<br />
* code.haskell.org<br />
* community.haskell.org<br />
* trac.haskell.org<br />
* User accounts and home directories<br />
* RT on PostgreSQL<br />
* Trac<br />
* http<br />
* Exim<br />
* c.h.o admin scripts for users<br />
* account_request<br />
* project_request<br />
* createlist<br />
* createtrac<br />
* addtoproject<br />
* crontabfor<br />
* c.h.o admin scripts for admins<br />
* create_user.sh<br />
* create_project.sh<br />
<br />
==== User data to be transfered ====<br />
* User accounts and home directories<br />
* Project groups in /etc/group<br />
* Darcs repos from /srv/projects<br />
* Project data from /srv/code<br />
* Trac projects<br />
* Mailman lists<br />
* Planet Haskell<br />
* Physical mailboxes (igloo and malcolm)<br />
<br />
==== Domains to be transferred ====<br />
* community<br />
* code<br />
* rt<br />
* planet<br />
* trac<br />
* projects<br />
<br />
=== Migration plan ===<br />
<br />
Coordination will happen on the #haskell-infrastructure channel on FreeNode.<br />
<br />
==== Preparatory stage ====<br />
1. Formulate plan on how to communicate with users during the migration process; begin gathering required contact info if necessary<br />
1. Calculate the approximate size and rate of change of each type of data on the server<br />
1. Give preliminary notice to users and ask for feedback<br />
1. Configure domain name etch.haskell.org (will later become read-only copy and left active for a while as a backup)<br />
1. Change TTL on all domains to be short<br />
1. Provision the new server<br />
1. Install and perform basic configuration of all services<br />
1. Test all installed services<br />
1. Set up backup mirror(s)<br />
1. Set up backup mirror services/scripts. Install on new server and test.<br />
1. Write scripts to copy user accounts and rsync home directories, and to verify<br />
1. Write scripts to copy project groups in /etc/group, and to verify<br />
1. Write scripts to rsync darcs repos from /srv/projects, and to verify<br />
1. Write scripts to rsync project data from /srv/code, and to verify<br />
1. Write scripts to rsync trac projects, and to verify<br />
1. Write scripts to copy mailman lists and rsync archives, and to verify<br />
1. Write scripts to rsync Planet Haskell, and to verify<br />
1. Write a script to make all user data and projects read-only (except mailman archives), and to verify.<br />
1. Write a script to *undo* making things read-only, in case of emergency.<br />
1. Test all scripts thoroughly<br />
1. Fix dates for beginning initial copy and final migration, and give advance notice and instructions to users.<br />
1. Transfer RT database and verify (as a dry run, go through the entire migration process just for RT)<br />
1. Move the rt domain<br />
1. After TTL, verify that RT is working on the new server<br />
<br />
==== Initial copy ====<br />
1. Run script to copy user accounts. Verify.<br />
1. Run script to copy /etc/group entries for projects. Verify.<br />
1. Run scripts to rsync home directories, darcs repos, project data, trac projects, mailman archives, and Planet data<br />
1. Monitor progress; update schedule and notify users as needed<br />
1. When completed, verify.<br />
<br />
==== D-Day ====<br />
1. Notify users.<br />
1. Stop the Planet Haskell hourly cron job.<br />
1. Run script to make all user data and projects read-only. Verify.<br />
1. If any user accounts or projects were added since initial copy began, add them.<br />
1. Run scripts to rsync home directories, darcs repos, project data, and Trac projects. Verify.<br />
1. Stop mailman service on etch.<br />
1. Run the scripts to rsync mailman archives. Verify.<br />
1. Move the domain CNAME for community, trac, projects, and code.<br />
1. After TTL, verify remotely that the domains moved and that services are working.<br />
1. Notify users of current status.<br />
1. Tell Ian and Malcolm to check their mail.<br />
1. Move the domain MX records.<br />
1. Run the scripts to rsync Planet Haskell. Verify.<br />
1. Move the planet domain.<br />
1. Start the Planet Haskell hourly cron job.<br />
1. After TTL, verify remotely that '''all''' domains are moved and that '''all''' services are working.<br />
1. Notify users and community.<br />
<br />
==== Post-migration tasks ====<br />
1. Activate backup mirroring. Verify.<br />
1. Monitor net bandwidth and responsiveness of the new server.<br />
1. Monitor memory and cpu usage on the new server.<br />
1. Monitor and tune settings of PostgreSQL for resource usage on the new server<br />
1. Monitor and tune settings of Apache for resource usage on the new server<br />
1. After a day or two, raise TTL back to normal levels on all domains<br />
1. After a month or two, delete the Etch server</div>Igloohttps://wiki.haskell.org/index.php?title=CommunityMigration&diff=37420CommunityMigration2010-11-10T15:51:33Z<p>Igloo: </p>
<hr />
<div>== Migration From Etch ==<br />
<br />
=== Deliverables ===<br />
* c.h.o migrated to new server, all services functioning as before for all users<br />
* Regularly scheduled automated off-site backups of new server, so that we can redeploy if we suddenly lose the server (hardware failure, VPS provider belly up, etc.)<br />
* A set of migration scripts that can be re-used in case we need to migrate again in the future<br />
* A set of policies/procedures that will keep the migration scripts up-to-date<br />
<br />
=== Assets to be moved ===<br />
==== Services to migrate ====<br />
* RT on PostgreSQL<br />
* Trac<br />
* http<br />
* Exim<br />
* ClamAV<br />
* mrtg<br />
* darcs<br />
* ghc<br />
* mailman<br />
* nagios<br />
* planet<br />
* c.h.o admin scripts for users<br />
* account_request<br />
* project_request<br />
* createlist<br />
* createtrac<br />
* addtoproject<br />
* crontabfor<br />
* c.h.o admin scripts for admins<br />
* create_user.sh<br />
* create_project.sh<br />
<br />
==== User data to be transfered ====<br />
* User accounts and home directories<br />
* Project groups in /etc/group<br />
* Darcs repos from /srv/projects<br />
* Project data from /srv/code<br />
* Trac projects<br />
* Mailman lists<br />
* Planet Haskell<br />
* Physical mailboxes (igloo and malcolm)<br />
<br />
==== Domains to be transferred ====<br />
* community<br />
* code<br />
* rt<br />
* planet<br />
* trac<br />
* projects<br />
<br />
=== Migration plan ===<br />
<br />
Coordination will happen on the #haskell-infrastructure channel on FreeNode.<br />
<br />
==== Preparatory stage ====<br />
1. Formulate plan on how to communicate with users during the migration process; begin gathering required contact info if necessary<br />
1. Calculate the approximate size and rate of change of each type of data on the server<br />
1. Give preliminary notice to users and ask for feedback<br />
1. Configure domain name etch.haskell.org (will later become read-only copy and left active for a while as a backup)<br />
1. Change TTL on all domains to be short<br />
1. Provision the new server<br />
1. Install and perform basic configuration of all services<br />
1. Test all installed services<br />
1. Set up backup mirror(s)<br />
1. Set up backup mirror services/scripts. Install on new server and test.<br />
1. Write scripts to copy user accounts and rsync home directories, and to verify<br />
1. Write scripts to copy project groups in /etc/group, and to verify<br />
1. Write scripts to rsync darcs repos from /srv/projects, and to verify<br />
1. Write scripts to rsync project data from /srv/code, and to verify<br />
1. Write scripts to rsync trac projects, and to verify<br />
1. Write scripts to copy mailman lists and rsync archives, and to verify<br />
1. Write scripts to rsync Planet Haskell, and to verify<br />
1. Write a script to make all user data and projects read-only (except mailman archives), and to verify.<br />
1. Write a script to *undo* making things read-only, in case of emergency.<br />
1. Test all scripts thoroughly<br />
1. Fix dates for beginning initial copy and final migration, and give advance notice and instructions to users.<br />
1. Transfer RT database and verify (as a dry run, go through the entire migration process just for RT)<br />
1. Move the rt domain<br />
1. After TTL, verify that RT is working on the new server<br />
<br />
==== Initial copy ====<br />
1. Run script to copy user accounts. Verify.<br />
1. Run script to copy /etc/group entries for projects. Verify.<br />
1. Run scripts to rsync home directories, darcs repos, project data, trac projects, mailman archives, and Planet data<br />
1. Monitor progress; update schedule and notify users as needed<br />
1. When completed, verify.<br />
<br />
==== D-Day ====<br />
1. Notify users.<br />
1. Stop the Planet Haskell hourly cron job.<br />
1. Run script to make all user data and projects read-only. Verify.<br />
1. If any user accounts or projects were added since initial copy began, add them.<br />
1. Run scripts to rsync home directories, darcs repos, project data, and Trac projects. Verify.<br />
1. Stop mailman service on etch.<br />
1. Run the scripts to rsync mailman archives. Verify.<br />
1. Move the domain CNAME for community, trac, projects, and code.<br />
1. After TTL, verify remotely that the domains moved and that services are working.<br />
1. Notify users of current status.<br />
1. Tell Ian and Malcolm to check their mail.<br />
1. Move the domain MX records.<br />
1. Run the scripts to rsync Planet Haskell. Verify.<br />
1. Move the planet domain.<br />
1. Start the Planet Haskell hourly cron job.<br />
1. After TTL, verify remotely that '''all''' domains are moved and that '''all''' services are working.<br />
1. Notify users and community.<br />
<br />
==== Post-migration tasks ====<br />
1. Activate backup mirroring. Verify.<br />
1. Monitor net bandwidth and responsiveness of the new server.<br />
1. Monitor memory and cpu usage on the new server.<br />
1. Monitor and tune settings of PostgreSQL for resource usage on the new server<br />
1. Monitor and tune settings of Apache for resource usage on the new server<br />
1. After a day or two, raise TTL back to normal levels on all domains<br />
1. After a month or two, delete the Etch server</div>Igloohttps://wiki.haskell.org/index.php?title=CommunityMigration&diff=37419CommunityMigration2010-11-10T15:50:15Z<p>Igloo: </p>
<hr />
<div>== Migration From Etch ==<br />
<br />
=== Deliverables ===<br />
* c.h.o migrated to new server, all services functioning as before for all users<br />
* Regularly scheduled automated off-site backups of new server, so that we can redeploy if we suddenly lose the server (hardware failure, VPS provider belly up, etc.)<br />
* A set of migration scripts that can be re-used in case we need to migrate again in the future<br />
* A set of policies/procedures that will keep the migration scripts up-to-date<br />
<br />
=== Assets to be moved ===<br />
==== Services to migrate ====<br />
* RT on PostgreSQL<br />
* Trac<br />
* http<br />
* Exim<br />
* ClamAV<br />
* mrtg<br />
* darcs<br />
* ghc<br />
* mailman<br />
* nagios<br />
* planet<br />
* c.h.o admin scripts for users<br />
* account_request<br />
* project_request<br />
* createlist<br />
* createtrac<br />
* addtoproject<br />
* crontabfor<br />
* c.h.o admin scripts for admins<br />
* create_user.sh<br />
* create_project.sh<br />
<br />
==== User data to be transfered ====<br />
* User accounts and home directories<br />
* Project groups in /etc/group<br />
* Darcs repos from /srv/projects<br />
* Project data from /srv/code<br />
* Trac projects<br />
* Mailman lists<br />
* Planet Haskell<br />
* Physical mailboxes (igloo and malcolm)<br />
<br />
==== Domains to be transferred ====<br />
* community<br />
* code<br />
* rt<br />
* planet<br />
* trac<br />
* projects<br />
<br />
=== Migration plan ===<br />
==== Preparatory stage ====<br />
1. Formulate plan on how to communicate with users during the migration process; begin gathering required contact info if necessary<br />
1. Calculate the approximate size and rate of change of each type of data on the server<br />
1. Give preliminary notice to users and ask for feedback<br />
1. Configure domain name etch.haskell.org (will later become read-only copy and left active for a while as a backup)<br />
1. Set up an IRC channel for admins to coordinate during the migration process<br />
1. Change TTL on all domains to be short<br />
1. Provision the new server<br />
1. Install and perform basic configuration of all services<br />
1. Test all installed services<br />
1. Set up backup mirror(s)<br />
1. Set up backup mirror services/scripts. Install on new server and test.<br />
1. Write scripts to copy user accounts and rsync home directories, and to verify<br />
1. Write scripts to copy project groups in /etc/group, and to verify<br />
1. Write scripts to rsync darcs repos from /srv/projects, and to verify<br />
1. Write scripts to rsync project data from /srv/code, and to verify<br />
1. Write scripts to rsync trac projects, and to verify<br />
1. Write scripts to copy mailman lists and rsync archives, and to verify<br />
1. Write scripts to rsync Planet Haskell, and to verify<br />
1. Write a script to make all user data and projects read-only (except mailman archives), and to verify.<br />
1. Write a script to *undo* making things read-only, in case of emergency.<br />
1. Test all scripts thoroughly<br />
1. Fix dates for beginning initial copy and final migration, and give advance notice and instructions to users.<br />
1. Transfer RT database and verify (as a dry run, go through the entire migration process just for RT)<br />
1. Move the rt domain<br />
1. After TTL, verify that RT is working on the new server<br />
<br />
==== Initial copy ====<br />
1. Run script to copy user accounts. Verify.<br />
1. Run script to copy /etc/group entries for projects. Verify.<br />
1. Run scripts to rsync home directories, darcs repos, project data, trac projects, mailman archives, and Planet data<br />
1. Monitor progress; update schedule and notify users as needed<br />
1. When completed, verify.<br />
<br />
==== D-Day ====<br />
1. Notify users.<br />
1. Stop the Planet Haskell hourly cron job.<br />
1. Run script to make all user data and projects read-only. Verify.<br />
1. If any user accounts or projects were added since initial copy began, add them.<br />
1. Run scripts to rsync home directories, darcs repos, project data, and Trac projects. Verify.<br />
1. Stop mailman service on etch.<br />
1. Run the scripts to rsync mailman archives. Verify.<br />
1. Move the domain CNAME for community, trac, projects, and code.<br />
1. After TTL, verify remotely that the domains moved and that services are working.<br />
1. Notify users of current status.<br />
1. Tell Ian and Malcolm to check their mail.<br />
1. Move the domain MX records.<br />
1. Run the scripts to rsync Planet Haskell. Verify.<br />
1. Move the planet domain.<br />
1. Start the Planet Haskell hourly cron job.<br />
1. After TTL, verify remotely that '''all''' domains are moved and that '''all''' services are working.<br />
1. Notify users and community.<br />
<br />
==== Post-migration tasks ====<br />
1. Activate backup mirroring. Verify.<br />
1. Monitor net bandwidth and responsiveness of the new server.<br />
1. Monitor memory and cpu usage on the new server.<br />
1. Monitor and tune settings of PostgreSQL for resource usage on the new server<br />
1. Monitor and tune settings of Apache for resource usage on the new server<br />
1. After a day or two, raise TTL back to normal levels on all domains<br />
1. After a month or two, delete the Etch server</div>Igloohttps://wiki.haskell.org/index.php?title=Upgrading_packages/Updating_to_GHC_7&diff=37353Upgrading packages/Updating to GHC 72010-10-29T17:23:37Z<p>Igloo: </p>
<hr />
<div>A list of common problems upgrading packages to GHC 7.<br />
<br />
If you maintain packages, this is for you.<br />
<br />
== -XMonoLocalBinds ==<br />
<br />
If you use -XGADTs or -XTypeFamilies you get -XMonoLocalBinds, which says that local let/where bindings are not auto-generalised. There's a blog post that explains the change, and what do to about it:<br />
<br />
* http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7<br />
<br />
== base 3 goes away ==<br />
<br />
There is no base 3 now, after being deprecated for several years, so dependencies on base 3 won't compile with GHC 7.<br />
<br />
== -fglasgow-exts is deprecated ==<br />
<br />
-fglasgow-exts is deprecated, and no longer enables GADTs or TypeFamilies. Use individual language flags (or better yet, pragmas) instead.<br />
<br />
== Quasiquotation data constructor modified ==<br />
<br />
The QuasiQuoter constructor now takes four arguments instead of 2. (quoteType and quoteDec were added). One solution: use record syntax to set only the quoters you provide. This allows code to remain backwards compatible.<br />
<br />
== Quasiquotation: [$foo|...|] -> [foo|...|] ==<br />
<br />
Quasiquoter invocation no longer requires/allows a leading dollar sign.<br />
<br />
== Required library versions ==<br />
<br />
A list of libraries and their earliest (known) GHC 7 ready version:<br />
<br />
* network >= 2.2.1.8<br />
* mtl >= 1.1.1.0<br />
* quickcheck >= 2.3.0.2<br />
* stringsearch >= 0.3.2</div>Igloohttps://wiki.haskell.org/index.php?title=Upgrading_packages/Updating_to_GHC_7&diff=37352Upgrading packages/Updating to GHC 72010-10-29T17:18:00Z<p>Igloo: </p>
<hr />
<div>A list of common problems upgrading packages to GHC 7.<br />
<br />
If you maintain packages, this is for you.<br />
<br />
== -XMonoLocalBinds ==<br />
<br />
If you use -XGADTs or -XTypeFamilies you get -XMonoLocalBinds, which says that local let/where bindings are not auto-generalised. There's a blog post that explains the change, and what do to about it:<br />
<br />
* http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7<br />
<br />
== base 3 goes away ==<br />
<br />
There is no base 3 now, after being deprecated for several years, so dependencies on base 3 won't compile with GHC 7.<br />
<br />
== -fglasgow-exts is deprecated ==<br />
<br />
-fglasgow-exts is deprecated, and enables fewer extensions than in previous<br />
releases. Use individual language flags (or better yet, pragmas) instead.<br />
<br />
== Quasiquotation data constructor modified ==<br />
<br />
The QuasiQuoter constructor now takes four arguments instead of 2. (quoteType and quoteDec were added). One solution: use record syntax to set only the quoters you provide. This allows code to remain backwards compatible.<br />
<br />
== Quasiquotation: [$foo|...|] -> [foo|...|] ==<br />
<br />
Quasiquoter invocation no longer requires/allows a leading dollar sign.<br />
<br />
== Required library versions ==<br />
<br />
A list of libraries and their earliest (known) GHC 7 ready version:<br />
<br />
* network >= 2.2.1.8<br />
* mtl >= 1.1.1.0<br />
* quickcheck >= 2.3.0.2<br />
* stringsearch >= 0.3.2</div>Igloohttps://wiki.haskell.org/index.php?title=Upgrading_packages/Updating_to_GHC_7&diff=37351Upgrading packages/Updating to GHC 72010-10-29T17:16:36Z<p>Igloo: </p>
<hr />
<div>A list of common problems upgrading packages to GHC 7.<br />
<br />
If you maintain packages, this is for you.<br />
<br />
== -XMonoLocalBinds ==<br />
<br />
If you use -XGADTs or -XTypeFamilies you get -XMonoLocalBinds, which says that local let/where bindings are not auto-generalised. There's a blog post that explains the change, and what do to about it:<br />
<br />
* http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7<br />
<br />
== base 3 goes away ==<br />
<br />
There is no base 3 now, after being deprecated for several years, so dependencies on base 3 won't compile with GHC 7.<br />
<br />
== -fglasgow-exts is deprecated ==<br />
<br />
-fglasgow-exts is deprecated, and enables fewer extensions than in previous<br />
releases. Use individual language flags (or better yet, pragmas) instead.<br />
<br />
== Quasiquotation data constructor modified ==<br />
<br />
The QuasiQuoter constructor now takes four arguments instead of 2. (quoteType and quoteDec were added). One solution: use record syntax to set only the quoters you provide. This allows code to remain backwards compatible.<br />
<br />
== Quasiquotation: [$foo|...|] -> [foo|...|] ==<br />
<br />
Quasiquoter invocation no longer requires/allows a leading dollar sign.<br />
<br />
== The binary library shipped with the compiler is renamed ghc-binary ==<br />
<br />
If your package expects to see binary, the correct thing is to build and install an external version. However, you will need a version newer than 0.5.0.2, which was the current version in hackage when this was written.<br />
<br />
== Required library versions ==<br />
<br />
A list of libraries and their earliest (known) GHC 7 ready version:<br />
<br />
* network >= 2.2.1.8<br />
* mtl >= 1.1.1.0<br />
* quickcheck >= 2.3.0.2<br />
* stringsearch >= 0.3.2</div>Igloohttps://wiki.haskell.org/index.php?title=Haskell.org_committee&diff=36726Haskell.org committee2010-09-09T12:48:16Z<p>Igloo: </p>
<hr />
<div>== Responsibilities ==<br />
<br />
The ''haskell.org committee'' represents the Open Source Haskell community. Its responsibilities include:<br />
<br />
* setting the policy on what the haskell.org domain name, and its subdomains, may be used for<br />
* setting the policy on what the servers owned by haskell.org may be used for<br />
* determining how haskell.org funds are spent<br />
<br />
== Current members ==<br />
<br />
The first haskell.org committee has not yet been selected.<br />
<br />
== Operation ==<br />
<br />
The committee consists of 7 members, with the members electing one of their number to be chair each year. Members are expected to serve a 3 year term, and terms are staggered so that 2 or 3 members step down each year.<br />
<br />
When a member steps down, either because they have reached the end of their term or because other circumstances require them to step down early, open self-nominations will be sought from the community via the haskell@ mailing list. Previous committee members, including those who have just stepped down, will also be eligible for nomination. The committee will then select a replacement from amongst those nominated.<br />
<br />
The committee replacement process is intentionally currently very light. As we get more experience, we may wish to change it, e.g. by having a larger subset of "the community" vote on nominations.<br />
<br />
If any member of the community wishes to raise any issue with the committee, they may contact it by e-mailing [an address yet to be set up]<br />
<br />
It is expected the committee will discuss any matters brought to it amongst themselves, and if they thing appropriate, with the wider community, to try to reach consensus. Ultimately, the committee will make decisions by more than half of the membership voting for a particular outcome. These rules of operation may also be changed in the same way.<br />
<br />
Each year, the committee will post a statement of the haskell.org assets, and the transactions for that year. Some details may be omitted, e.g. for confidentiality of donors.</div>Igloohttps://wiki.haskell.org/index.php?title=Ghent_Functional_Programming_Group/BelHac/Register&diff=36651Ghent Functional Programming Group/BelHac/Register2010-09-05T19:59:22Z<p>Igloo: </p>
<hr />
<div>Important: Please wait for a confirmation email before booking any flights/hotels.<br />
<br />
Registration is via email to Jasper Van der Jeugt at<br />
<br />
jaspervdj+belhac@gmail.com<br />
<br />
with the subject<br />
<br />
BelHac registration <br />
<br />
and body containing the following information:<br />
<br />
Name:<br />
#haskell nick: (if applicable)<br />
Email:<br />
Food restrictions:<br />
Days attending: <br />
<br />
Here is an example:<br />
<br />
Name: Jasper Van der Jeugt<br />
Nick: jaspervdj<br />
Email: jaspervdj@gmail.com<br />
Food restrictions: Raw flesh only<br />
Days attending: Friday, saturday and sunday<br />
<br />
If you want, you can also add you name here:<br />
<br />
{| class="wikitable"<br />
! Nickname<br />
! Real Name<br />
! Affiliation<br />
! Mobile #<br />
! Email<br />
! Arriving - Departing<br />
! Accomodation<br />
|-<br />
| jaspervdj<br />
| Jasper Van der Jeugt<br />
| Ghent University<br />
| +32 476 26 48 47<br />
| jaspervdj@gmail.com<br />
| <br />
| Has a small place in Ghent<br />
|-<br />
| Itkovian<br />
| Andy Georges<br />
| Ghent University/FWO<br />
| <br />
| itkovian@gmail.com<br />
|<br />
| Lives in Ostend, arrives by train on daily basis<br />
|-<br />
| Javache<br />
| Pieter De Baets<br />
| Ghent University<br />
| <br />
| pieter.debaets@gmail.com<br />
|<br />
|<br />
|-<br />
| boegel<br />
| Kenneth Hoste<br />
| Ghent University<br />
| <br />
| kenneth.hoste@ugent.be<br />
|<br />
| commute to/from Ghent daily<br />
|-<br />
| BCoppens<br />
| Bart Coppens<br />
| Ghent University<br />
| <br />
| bart.coppens@elis.ugent.be<br />
|<br />
|<br />
|-<br />
| jejansse<br />
| Jeroen Janssen<br />
| VUB<br />
|<br />
| jejansse@gmail.com<br />
|<br />
| Lives in Ghent.<br />
|-<br />
| Feuerbach<br />
| Roman Cheplyaka<br />
| <br />
| +380662285780<br />
| roma@ro-che.info<br />
| unknown yet<br />
| unknown yet<br />
|-<br />
| solidsnack<br />
| Jason Dusek<br />
| Heroku<br />
| +1 415 894 2162<br />
| jason.dusek@gmail.com<br />
| 5th-7th<br />
| Probably Monasterium.<br />
|-<br />
| kosmikus<br />
| Andres L&ouml;h<br />
| Well-Typed LLP<br />
|<br />
| mail@andres-loeh.de<br />
| 5th-7th<br />
|<br />
|-<br />
| Igloo<br />
| Ian Lynagh<br />
| Well-Typed LLP<br />
|<br />
| igloo@earth.li<br />
| 5th-7th<br />
|}</div>Igloohttps://wiki.haskell.org/index.php?title=Library_submissions&diff=36644Library submissions2010-09-03T22:56:33Z<p>Igloo: </p>
<hr />
<div>As the Haskell community has grown, and emphasis on development has<br />
moved from language to libraries, the need for a more formalised process<br />
for contributing to libraries has emerged. This page documents our<br />
'best practices' for proposing changes to library interfaces<br />
(e.g. new modules or functions, removing functions) in packages that list ''libraries@haskell.org'' as maintainer.<br />
We have been using it since October 2006.<br />
<br />
In essence, we don't want proposals to go unnoticed, but changes to<br />
basic interfaces also need thorough consideration. <br />
<br />
== Creating a proposal ==<br />
<br />
In order to ensure we have something concrete to discuss, please follow<br />
the following guidelines:<br />
<br />
* ''Currency''. Make your changes against a copy of the HEAD branch of the [http://hackage.haskell.org/trac/ghc/wiki/DarcsRepositories relevant library], and make sure it compiles.<br />
* ''Portability''. Code should be portable. If it is not portable, reasons should be given. At the very least ensure the code runs in Hugs and GHC, and on Windows and Linux.<br />
* ''Style''. Follow the conventions in the library you are modifying.<br />
* ''Documentation''. It must include valid [http://haskell.org/haddock Haddock] documentation.<br />
* ''Tests''. Code should ideally also come with suitable tests for the testsuite. There's currently some disagreement about what this means. Discussion of where we may want to head is in the [[library tests]] page.<br />
<br />
== Submitting the proposal ==<br />
<br />
* ''Patch''. Create a [http://darcs.net darcs] patch of your change using <tt>darcs record</tt>, including a rationale for the change. Save the patch to a file, using <tt>darcs send --output</tt>.<br />
<br />
* ''Tracking''. [http://hackage.haskell.org/trac/ghc/newticket?type=proposal&component=libraries/base&milestone=Not+GHC Add a Trac ticket] of type ''proposal'' for the appropriate library component, with a timescale for consideration (to focus the community's attention for a limited period), adding the patch file as an attachment.<br />
<br />
* ''Submission''. Send an email containing the Trac ticket number and description to libraries@haskell.org, which you need to [http://www.haskell.org/mailman/listinfo/libraries subscribe] before posting. (In the future this should happen when you record the ticket, but we haven't set it up yet.) You may wish to include a pointer to updated Haddock documentation, if relevant.<br />
<br />
If someone has done all this, they are entitled to expect feedback;<br />
silence during the discussion period can be interpreted as consent.<br />
<br />
Here are the [http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&group=component&type=proposal&order=priority proposals currently under consideration].<br />
<br />
== At the end of the discussion period ==<br />
<br />
* Add to the ticket a summary of the relevant parts of the discussion. (The summary is needed for anyone wondering about the change later: it's not reasonable to point people at a 50-message thread (but please do include a link to the thread in the list archives too, so that people can review it if they wish)).<br />
* If consensus was achieved, revise the patch as necessary, including the Trac ticket number, and commit it (or set the ticket state to "patch" so that someone will commit it for you).<br />
* Close the ticket (usually as ''fixed'' or ''wontfix'').<br />
<br />
A deeply held disagreement at this point may require some form of governance (voting, dictatorship, etc). This should be a rare event.<br />
<br />
Here are the [http://hackage.haskell.org/trac/ghc/query?status=closed&group=component&type=proposal&order=priority archived past proposals].<br />
<br />
Here is an example of how to [http://hackage.haskell.org/trac/ghc/ticket/966 summarise a successful submission].<br />
<br />
== See also ==<br />
<br />
* [http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions GHC Working Conventions], including guidelines for submitting patches via darcs.<br />
* [http://haskell.org/haskellwiki/Category:Style Notes on programming style]<br />
<br />
[[Category:Community]]<br />
[[Category:Proposals| ]]</div>Igloohttps://wiki.haskell.org/index.php?title=Haskell&diff=35420Haskell2010-07-11T16:33:58Z<p>Igloo: revert spam</p>
<hr />
<div>__NOTOC__<br />
__NOEDITSECTION__<br />
{| border=0 cellspacing=5 cellpadding=10<br />
| valign=top style="text-align:left" bgcolor=#F0F0F0 |<br />
<br />
{{Main/About}}<br />
<br />
{{Main/Learning}}<br />
<br />
{{Main/Libraries}}<br />
<br />
{{Main/Community}}<br />
<br />
|valign=top width=75% style="text-align:left; line-height:120%"|<br />
<br />
{{Main/Intro}}<br />
<br />
{| border=0 cellspacing=0 cellpadding=15<br />
|-<br />
|valign=top width=65% style="text-align:left"|<br />
{{Main/Headlines}}<br />
<br />
{{Main/Events}}<br />
<br />
{{Main/News}}<br />
<br />
|-<br />
|}<br />
|}</div>Igloohttps://wiki.haskell.org/index.php?title=Library_submissions&diff=35044Library submissions2010-06-23T13:39:21Z<p>Igloo: </p>
<hr />
<div>As the Haskell community has grown, and emphasis on development has<br />
moved from language to libraries, the need for a more formalised process<br />
for contributing to libraries has emerged. This page documents our<br />
'best practices' for proposing changes to library interfaces<br />
(e.g. new modules or functions, removing functions) in packages that list ''libraries@haskell.org'' as maintainer.<br />
We have been using it since October 2006.<br />
<br />
In essence, we don't want proposals to go unnoticed, but changes to<br />
basic interfaces also need thorough consideration. <br />
<br />
== Creating a proposal ==<br />
<br />
In order to ensure we have something concrete to discuss, please follow<br />
the following guidelines:<br />
<br />
* ''Currency''. Make your changes against a copy of the HEAD branch of the [http://hackage.haskell.org/trac/ghc/wiki/DarcsRepositories relevant library], and make sure it compiles.<br />
* ''Portability''. Code should be portable. If it is not portable, reasons should be given. At the very least ensure the code runs in Hugs and GHC, and on Windows and Linux.<br />
* ''Style''. Follow the conventions in the library you are modifying.<br />
* ''Documentation''. It must include valid [http://haskell.org/haddock Haddock] documentation.<br />
* ''Tests''. Code should ideally also come with suitable tests for the testsuite. There's currently some disagreement about what this means. Discussion of where we may want to head is in the [[library tests]] page.<br />
<br />
== Submitting the proposal ==<br />
<br />
* ''Patch''. Create a [http://darcs.net darcs] patch of your change using <tt>darcs record</tt>, including a rationale for the change. Save the patch to a file, using <tt>darcs send --output</tt>.<br />
<br />
* ''Tracking''. [http://hackage.haskell.org/trac/ghc/newticket?type=proposal&component=libraries/base&milestone=Not+GHC Add a Trac ticket] of type ''proposal'' for the appropriate library component, with a timescale for consideration (to focus the community's attention for a limited period), adding the patch file as an attachment.<br />
<br />
* ''Submission''. Send an email containing the Trac ticket number and description to libraries@haskell.org, which you need to [http://www.haskell.org/mailman/listinfo/libraries subscribe] before posting. (In the future this should happen when you record the ticket, but we haven't set it up yet.) You may wish to include a pointer to updated Haddock documentation, if relevant.<br />
<br />
If someone has done all this, they are entitled to expect feedback;<br />
silence during the discussion period can be interpreted as consent.<br />
<br />
Here are the [http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&group=component&type=proposal&order=priority proposals currently under consideration].<br />
<br />
== At the end of the discussion period ==<br />
<br />
* Add to the ticket a summary of the relevant parts of the discussion. (The summary is needed for anyone wondering about the change later: it's not reasonable to point people at a 50-message thread (but please do include a link to the thread in the list archives too, so that people can review it if they wish)).<br />
* If consensus was achieved, revise the patch as necessary, including the Trac ticket number, and commit it (or get someone to commit it for you).<br />
* Close the ticket (usually as ''fixed'' or ''wontfix'').<br />
<br />
A deeply held disagreement at this point may require some form of government (voting, dictatorship, etc). This should be a rare event.<br />
<br />
Here are the [http://hackage.haskell.org/trac/ghc/query?status=closed&group=component&type=proposal&order=priority archived past proposals].<br />
<br />
Here is an example of how to [http://hackage.haskell.org/trac/ghc/ticket/966 summarise a successful submission].<br />
<br />
== See also ==<br />
<br />
* [http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions GHC Working Conventions], including guidelines for submitting patches via darcs.<br />
* [http://haskell.org/haskellwiki/Category:Style Notes on programming style]<br />
<br />
[[Category:Community]]<br />
[[Category:Proposals| ]]</div>Igloohttps://wiki.haskell.org/index.php?title=Haskell.org_domain&diff=34433Haskell.org domain2010-04-06T19:21:18Z<p>Igloo: </p>
<hr />
<div>[[Category:Community]]<br />
<br />
== Overview ==<br />
The names in the '''haskell.org domain''' point to three machines:<br />
<br />
=== [[haskell.org]] ===<br />
This machine responds to the names ''haskell.org'', ''www.haskell.org'', ''bugs.haskell.org'', ''haskell.cs.yale.edu''. It's at Yale university.<br />
<br />
* web server and wiki, http://haskell.org/<br />
* [[mailing lists]], http://haskell.org/mailman/listinfo<br />
<br />
''MRTG'': [http://www.haskell.org/mrtg/localhost_00-c0-a8-7b-85-3c.html All network traffic].<br />
<br />
=== abbot ===<br />
This machine responds to the names ''darcs.haskell.org'', ''hackage.haskell.org'', ''cvs.haskell.org'', ''haskell.galois.com'', ''abbot.galois.com''. It's run by Galois.<br />
<br />
* darcs repositories for GHC and core libraries, http://darcs.haskell.org/<br />
* HackageDB, http://hackage.haskell.org/<br />
* old CVS repositories, http://cvs.haskell.org/<br />
* various Trac instances, e.g. http://hackage.haskell.org/trac/ghc<br />
<br />
''MRTG'': [http://abbot.galois.com/mrtg/localhost_f4-ce-46-0f-0d-6e.html All network traffic], [http://abbot.galois.com/mrtg/external-bandwidth.html External network bandwidth], [http://abbot.galois.com/mrtg/freedisk.html Free disk space], [http://abbot.galois.com/mrtg/system-load.html System load], [http://abbot.galois.com/mrtg/memory.html Free memory], [http://abbot.galois.com/mrtg/swap.html Free swap], [http://abbot.galois.com/mrtg/daily.html All of the daily graphs].<!-- <br>''Analog'': [http://abbot.galois.com/analog/cvs_darcs/cvs.html cvs/darcs], [http://abbot.galois.com/analog/hackage/hackage.html hackage]. --><br />
<br />
For more details, see [[Abbot]].<br />
<br />
=== nun ===<br />
This machine responds to the names ''community.haskell.org'', ''projects.haskell.org'', ''code.haskell.org'', ''trac.haskell.org'', ''rt.haskell.org'', ''planet.haskell.org'', ''nun.haskell.org''. See [http://www.haskell.org/pipermail/haskell/2007-June/019592.html this message].<br />
<br />
* darcs repositories for anyone's Haskell projects, http://code.haskell.org/<br />
* web-space for projects, http://projects.haskell.org/<br />
* admin for the above, http://community.haskell.org/<br />
* blog aggregation, http://planet.haskell.org/<br />
<br />
''MRTG'': [http://community.haskell.org/mrtg/localhost_venet0.html All network traffic], [http://community.haskell.org/mrtg/freedisk.html Free disk space], [http://community.haskell.org/mrtg/system-load.html System load], [http://community.haskell.org/mrtg/memory.html Free memory], [http://community.haskell.org/mrtg/swap.html Free swap], [http://community.haskell.org/mrtg/daily.html All of the daily graphs].<br />
<br />
== Relation between the services ==<br />
<br />
''I'm wondering what the relationship is (if any) between code.haskell.org and darcs.haskell.org.''<br />
<br />
:darcs.haskell.org hosts ghc, the core libs and many others. The server is maintained by Galois. Because it hosts the most central bits of the haskell platform, security is fairly tight and getting an account there is hard. There are very few community members with root privileges.<br />
<br />
:community.haskell.org was created precisely to provide hosting to the wider community. It is hosted commercially, paid for by haskell.org's Google Summer of Code funds. We have several community admins with root privileges.<br />
<br />
''Should my projects be hosted at darcs or code?''<br />
<br />
:code.haskell.org. It's easy to get an account there via the web submission system: http://community.haskell.org/admin/<br />
<br />
''Is one more blessed/preferred over the other for community projects?''<br />
<br />
:Yes, code.haskell.org is preferred.<br />
<br />
''If my project is currently on darcs, should I migrate to code?''<br />
<br />
:You can if you like, there is no need to do so however. Accounts on darcs.haskell.org are not going to be revoked as far as I know. The community server is an addition, not a replacement.<br />
<br />
''If I have an account on darcs, will it work on code, or do I need to get a new account on code?''<br />
<br />
:They are totally separate systems.<br />
<br />
== See also ==<br />
<br />
http://www.haskell.org/pipermail/haskell-cafe/2008-January/038759.html</div>Igloohttps://wiki.haskell.org/index.php?title=Haskell.org_domain&diff=34432Haskell.org domain2010-04-06T19:18:44Z<p>Igloo: </p>
<hr />
<div>[[Category:Community]]<br />
<br />
== Overview ==<br />
The names in the '''haskell.org domain''' point to three machines:<br />
<br />
=== [[haskell.org]] ===<br />
This machine responds to the names ''haskell.org'', ''www.haskell.org'', ''bugs.haskell.org'', ''haskell.cs.yale.edu''. It's at Yale university.<br />
<br />
* web server and wiki, http://haskell.org/<br />
* [[mailing lists]], http://haskell.org/mailman/listinfo<br />
<br />
''MRTG'': [http://www.haskell.org/mrtg/localhost_00-c0-a8-7b-85-3c.html All network traffic].<br />
<br />
=== abbot ===<br />
This machine responds to the names ''darcs.haskell.org'', ''hackage.haskell.org'', ''cvs.haskell.org'', ''haskell.galois.com'', ''abbot.galois.com''. It's run by Galois.<br />
<br />
* darcs repositories for GHC and core libraries, http://darcs.haskell.org/<br />
* HackageDB, http://hackage.haskell.org/<br />
* old CVS repositories, http://cvs.haskell.org/<br />
* various Trac instances, e.g. http://hackage.haskell.org/trac/ghc<br />
<br />
''MRTG'': [http://abbot.galois.com/mrtg/localhost_f4-ce-46-0f-0d-6e.html All network traffic], [http://abbot.galois.com/mrtg/external-bandwidth.html External network bandwidth], [http://abbot.galois.com/mrtg/freedisk.html Free disk space], [http://abbot.galois.com/mrtg/system-load.html System load], [http://abbot.galois.com/mrtg/memory.html Free memory], [http://abbot.galois.com/mrtg/swap.html Free swap], [http://abbot.galois.com/mrtg/daily.html All of the daily graphs].<br>''Analog'': [http://abbot.galois.com/analog/cvs_darcs/cvs.html cvs/darcs], [http://abbot.galois.com/analog/hackage/hackage.html hackage].<br />
<br />
For more details, see [[Abbot]].<br />
<br />
=== nun ===<br />
This machine responds to the names ''community.haskell.org'', ''projects.haskell.org'', ''code.haskell.org'', ''trac.haskell.org'', ''rt.haskell.org'', ''planet.haskell.org'', ''nun.haskell.org''. See [http://www.haskell.org/pipermail/haskell/2007-June/019592.html this message].<br />
<br />
* darcs repositories for anyone's Haskell projects, http://code.haskell.org/<br />
* web-space for projects, http://projects.haskell.org/<br />
* admin for the above, http://community.haskell.org/<br />
* blog aggregation, http://planet.haskell.org/<br />
<br />
''MRTG'': [http://community.haskell.org/mrtg/localhost_venet0.html All network traffic], [http://community.haskell.org/mrtg/freedisk.html Free disk space], [http://community.haskell.org/mrtg/system-load.html System load], [http://community.haskell.org/mrtg/memory.html Free memory], [http://community.haskell.org/mrtg/swap.html Free swap], [http://community.haskell.org/mrtg/daily.html All of the daily graphs].<br />
<br />
== Relation between the services ==<br />
<br />
''I'm wondering what the relationship is (if any) between code.haskell.org and darcs.haskell.org.''<br />
<br />
:darcs.haskell.org hosts ghc, the core libs and many others. The server is maintained by Galois. Because it hosts the most central bits of the haskell platform, security is fairly tight and getting an account there is hard. There are very few community members with root privileges.<br />
<br />
:community.haskell.org was created precisely to provide hosting to the wider community. It is hosted commercially, paid for by haskell.org's Google Summer of Code funds. We have several community admins with root privileges.<br />
<br />
''Should my projects be hosted at darcs or code?''<br />
<br />
:code.haskell.org. It's easy to get an account there via the web submission system: http://community.haskell.org/admin/<br />
<br />
''Is one more blessed/preferred over the other for community projects?''<br />
<br />
:Yes, code.haskell.org is preferred.<br />
<br />
''If my project is currently on darcs, should I migrate to code?''<br />
<br />
:You can if you like, there is no need to do so however. Accounts on darcs.haskell.org are not going to be revoked as far as I know. The community server is an addition, not a replacement.<br />
<br />
''If I have an account on darcs, will it work on code, or do I need to get a new account on code?''<br />
<br />
:They are totally separate systems.<br />
<br />
== See also ==<br />
<br />
http://www.haskell.org/pipermail/haskell-cafe/2008-January/038759.html</div>Igloohttps://wiki.haskell.org/index.php?title=Haskell.org_domain&diff=34431Haskell.org domain2010-04-06T19:17:58Z<p>Igloo: </p>
<hr />
<div>[[Category:Community]]<br />
<br />
== Overview ==<br />
The names in the '''haskell.org domain''' point to three machines:<br />
<br />
=== [[haskell.org]] ===<br />
This machine responds to the names ''haskell.org'', ''www.haskell.org'', ''bugs.haskell.org'', ''haskell.cs.yale.edu''. It's at Yale university.<br />
<br />
* web server and wiki, http://haskell.org/<br />
* [[mailing lists]], http://haskell.org/mailman/listinfo<br />
<br />
''MRTG'': [http://www.haskell.org/mrtg/localhost_00-c0-a8-7b-85-3c.html All network traffic].<br />
<br />
=== abbot ===<br />
This machine responds to the names ''darcs.haskell.org'', ''hackage.haskell.org'', ''cvs.haskell.org'', ''haskell.galois.com'', ''abbot.galois.com''. It's run by Galois.<br />
<br />
* darcs repositories for GHC and core libraries, http://darcs.haskell.org/<br />
* HackageDB, http://hackage.haskell.org/<br />
* old CVS repositories, http://cvs.haskell.org/<br />
* various Trac instances, e.g. http://hackage.haskell.org/trac/ghc<br />
<br />
''MRTG'': [http://abbot.galois.com/mrtg/localhost_00-11-2f-2e-4f-7c.html All network traffic], [http://abbot.galois.com/mrtg/external-bandwidth.html External network bandwidth], [http://abbot.galois.com/mrtg/freedisk.html Free disk space], [http://abbot.galois.com/mrtg/system-load.html System load], [http://abbot.galois.com/mrtg/memory.html Free memory], [http://abbot.galois.com/mrtg/swap.html Free swap], [http://abbot.galois.com/mrtg/daily.html All of the daily graphs].<br>''Analog'': [http://abbot.galois.com/analog/cvs_darcs/cvs.html cvs/darcs], [http://abbot.galois.com/analog/hackage/hackage.html hackage].<br />
<br />
For more details, see [[Abbot]].<br />
<br />
=== nun ===<br />
This machine responds to the names ''community.haskell.org'', ''projects.haskell.org'', ''code.haskell.org'', ''trac.haskell.org'', ''rt.haskell.org'', ''planet.haskell.org'', ''nun.haskell.org''. See [http://www.haskell.org/pipermail/haskell/2007-June/019592.html this message].<br />
<br />
* darcs repositories for anyone's Haskell projects, http://code.haskell.org/<br />
* web-space for projects, http://projects.haskell.org/<br />
* admin for the above, http://community.haskell.org/<br />
* blog aggregation, http://planet.haskell.org/<br />
<br />
''MRTG'': [http://community.haskell.org/mrtg/localhost_venet0.html All network traffic], [http://community.haskell.org/mrtg/freedisk.html Free disk space], [http://community.haskell.org/mrtg/system-load.html System load], [http://community.haskell.org/mrtg/memory.html Free memory], [http://community.haskell.org/mrtg/swap.html Free swap], [http://community.haskell.org/mrtg/daily.html All of the daily graphs].<br />
<br />
== Relation between the services ==<br />
<br />
''I'm wondering what the relationship is (if any) between code.haskell.org and darcs.haskell.org.''<br />
<br />
:darcs.haskell.org hosts ghc, the core libs and many others. The server is maintained by Galois. Because it hosts the most central bits of the haskell platform, security is fairly tight and getting an account there is hard. There are very few community members with root privileges.<br />
<br />
:community.haskell.org was created precisely to provide hosting to the wider community. It is hosted commercially, paid for by haskell.org's Google Summer of Code funds. We have several community admins with root privileges.<br />
<br />
''Should my projects be hosted at darcs or code?''<br />
<br />
:code.haskell.org. It's easy to get an account there via the web submission system: http://community.haskell.org/admin/<br />
<br />
''Is one more blessed/preferred over the other for community projects?''<br />
<br />
:Yes, code.haskell.org is preferred.<br />
<br />
''If my project is currently on darcs, should I migrate to code?''<br />
<br />
:You can if you like, there is no need to do so however. Accounts on darcs.haskell.org are not going to be revoked as far as I know. The community server is an addition, not a replacement.<br />
<br />
''If I have an account on darcs, will it work on code, or do I need to get a new account on code?''<br />
<br />
:They are totally separate systems.<br />
<br />
== See also ==<br />
<br />
http://www.haskell.org/pipermail/haskell-cafe/2008-January/038759.html</div>Igloohttps://wiki.haskell.org/index.php?title=Haskell.org_domain&diff=34430Haskell.org domain2010-04-06T19:15:36Z<p>Igloo: </p>
<hr />
<div>[[Category:Community]]<br />
<br />
== Overview ==<br />
The names in the '''haskell.org domain''' point to three machines:<br />
<br />
=== [[haskell.org]] ===<br />
This machine responds to the names ''haskell.org'', ''www.haskell.org'', ''bugs.haskell.org'', ''haskell.cs.yale.edu''. It's at Yale university.<br />
<br />
* web server and wiki, http://haskell.org/<br />
* [[mailing lists]], http://haskell.org/mailman/listinfo<br />
<br />
''MRTG'': [http://www.haskell.org/mrtg/localhost_00-c0-a8-7b-85-3c.html All network traffic].<br />
<br />
=== abbot ===<br />
This machine responds to the names ''darcs.haskell.org'', ''hackage.haskell.org'', ''cvs.haskell.org'', ''haskell.galois.com'', ''abbot.galois.com''. It's run by Galois.<br />
<br />
* darcs repositories for GHC and core libraries, http://darcs.haskell.org/<br />
* HackageDB, http://hackage.haskell.org/<br />
* old CVS repositories, http://cvs.haskell.org/<br />
* various Trac instances, e.g. http://hackage.haskell.org/trac/ghc<br />
<br />
''MRTG'': [http://darcs.haskell.org/mrtg/localhost_00-11-2f-2e-4f-7c.html All network traffic], [http://darcs.haskell.org/mrtg/external-bandwidth.html External network bandwidth], [http://darcs.haskell.org/mrtg/freedisk.html Free disk space], [http://darcs.haskell.org/mrtg/system-load.html System load], [http://darcs.haskell.org/mrtg/memory.html Free memory], [http://darcs.haskell.org/mrtg/swap.html Free swap], [http://darcs.haskell.org/mrtg/daily.html All of the daily graphs].<br>''Analog'': [http://darcs.haskell.org/analog/cvs_darcs/cvs.html cvs/darcs], [http://darcs.haskell.org/analog/hackage/hackage.html hackage].<br />
<br />
For more details, see [[Abbot]].<br />
<br />
=== nun ===<br />
This machine responds to the names ''community.haskell.org'', ''projects.haskell.org'', ''code.haskell.org'', ''trac.haskell.org'', ''rt.haskell.org'', ''planet.haskell.org'', ''nun.haskell.org''. See [http://www.haskell.org/pipermail/haskell/2007-June/019592.html this message].<br />
<br />
* darcs repositories for anyone's Haskell projects, http://code.haskell.org/<br />
* web-space for projects, http://projects.haskell.org/<br />
* admin for the above, http://community.haskell.org/<br />
* blog aggregation, http://planet.haskell.org/<br />
<br />
''MRTG'': [http://community.haskell.org/mrtg/localhost_venet0.html All network traffic], [http://community.haskell.org/mrtg/freedisk.html Free disk space], [http://community.haskell.org/mrtg/system-load.html System load], [http://community.haskell.org/mrtg/memory.html Free memory], [http://community.haskell.org/mrtg/swap.html Free swap], [http://community.haskell.org/mrtg/daily.html All of the daily graphs].<br />
<br />
== Relation between the services ==<br />
<br />
''I'm wondering what the relationship is (if any) between code.haskell.org and darcs.haskell.org.''<br />
<br />
:darcs.haskell.org hosts ghc, the core libs and many others. The server is maintained by Galois. Because it hosts the most central bits of the haskell platform, security is fairly tight and getting an account there is hard. There are very few community members with root privileges.<br />
<br />
:community.haskell.org was created precisely to provide hosting to the wider community. It is hosted commercially, paid for by haskell.org's Google Summer of Code funds. We have several community admins with root privileges.<br />
<br />
''Should my projects be hosted at darcs or code?''<br />
<br />
:code.haskell.org. It's easy to get an account there via the web submission system: http://community.haskell.org/admin/<br />
<br />
''Is one more blessed/preferred over the other for community projects?''<br />
<br />
:Yes, code.haskell.org is preferred.<br />
<br />
''If my project is currently on darcs, should I migrate to code?''<br />
<br />
:You can if you like, there is no need to do so however. Accounts on darcs.haskell.org are not going to be revoked as far as I know. The community server is an addition, not a replacement.<br />
<br />
''If I have an account on darcs, will it work on code, or do I need to get a new account on code?''<br />
<br />
:They are totally separate systems.<br />
<br />
== See also ==<br />
<br />
http://www.haskell.org/pipermail/haskell-cafe/2008-January/038759.html</div>Igloohttps://wiki.haskell.org/index.php?title=Template:Main/Libraries&diff=34122Template:Main/Libraries2010-03-17T15:03:27Z<p>Igloo: </p>
<hr />
<div>'''Libraries'''<br />
<br />
{| border="0" cellspacing="0" cellpadding="2" style="text-align:left"<br />
|-<br />
| [[Applications and libraries#Haskell_library_collections|Standard libraries]]<br />
|-<br />
| [http://hackage.haskell.org/packages/hackage.html Hackage library database]<br />
|-<br />
| [[Applications and libraries]]<br />
|-<br />
| [http://haskell.org/hoogle/ Hoogle] and [http://holumbus.fh-wedel.de/hayoo/ Hayoo] API search<br />
|-<br />
|}</div>Igloohttps://wiki.haskell.org/index.php?title=Applications_and_libraries&diff=34121Applications and libraries2010-03-17T14:41:47Z<p>Igloo: </p>
<hr />
<div>__NOTOC__<br />
[[Category:Libraries]] [[Category:Tools]]<br />
Applications, libraries and tools written in Haskell. <br />
<br />
'''For the latest set of ready to use libraries and tools, visit [http://hackage.haskell.org/packages/archive/pkg-list.html hackage.haskell.org]<br />
<br />
== Haskell library collections ==<br />
<br />
In increasing order of size:<br />
<br />
* The [http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html Haskell 98 Prelude] is implicitly imported by default, and includes the most commonly used functions.<br />
* The Haskell 98 [[Language and library specification]] define basic, portable functionality. However, it uses the old, deprecated namespace, and the way some functionality (such as exception handling) is defined is now believed to have been a mistake.<br />
** Changes to these libraries are handled by the [http://hackage.haskell.org/trac/haskell-prime/ Haskell'] process.<br />
* The [http://www.haskell.org/ghc/docs/latest/html/libraries/index.html The GHC boot libraries], which come with GHC, are generally an improved and expanded version of the Haskell 98 libraries, in the hierarchical namespace.<br />
** Changes to these libraries are handled by the package maintainer if one exists, or the [[Library submissions]] process if not.<br />
** [http://haskell.org/hoogle Hoogle] - the Haskell API Search Engine - indexes the above libraries<br />
* The [http://hackage.haskell.org/packages/archive/pkg-list.html Hackage database] aims to be a comprehensive a collection of released Haskell packages.<br />
<br />
See also [[Hackage]] and [[Cabal/How to install a Cabal package | how to install a Cabal package]].<br />
<br />
== Hackage ==<br />
<br />
'''New libraries are packaged and distributed from [http://hackage.haskell.org Hackage]'''<br />
<br />
Start on Hackage if looking for a library not in the standard.<br />
<br />
* Developers: you can [http://hackage.haskell.org/packages/upload.html upload your cabalised packages] to hackage (if you don't have a login, just ask).<br />
<br />
* [http://hackage.haskell.org/packages/archive/recent.html New packages uploaded to Hackage].<br />
<br />
== Haskell applications and libraries ==<br />
<br />
Applications, libraries and tools for Haskell or written in Haskell have been classified below, but you should check [http://hackage.haskell.org Hackage] for the latest list.<br />
<br />
* [[/Music and sound/|Audio, music and sound]]<br />
* [[/Bioinformatics/]]<br />
* [[/Concurrency and parallelism/]]<br />
* [[/Compilers and interpreters/]]<br />
* [[/Compiler tools|Compiler construction, lexing, parsing, pretty printing]]<br />
* [[/Cryptography|Cryptography and hashing]]<br />
* [[/Data structures | Data Structures and IO Libraries]]<br />
* [[/Database interfaces/]]<br />
* [[/Editors|Editors written in Haskell]] and [[Editors|editors for Haskell]].<br />
* [[/Extended Haskell/]]<br />
* [[/Games/]]<br />
* [[/Genetic programming/]]<br />
* [[/GUI libraries|Graphical User Interface (GUI) Libraries]]<br />
* [[/Graphics/]]<br />
* [[/Hardware verification/]]<br />
* [[/Linguistics|Linguistics and natural language processing]]<br />
* [[/Mathematics/|Mathematics and physics]]<br />
* [[/Network/]]<br />
* [[/Operating system/|Operating systems and systems programming]] (also emulators)<br />
* [[/Program development/]]<br />
* [[/Robots/]]<br />
* [[/Theorem provers/]]<br />
* [[/Interfacing other languages|Tools for interfacing with other languages]]<br />
* [[/Web programming|Web, HTML, XML]]<br />
<br />
Other places to look include:<br />
* The [[Library]] hierarchy page on this wiki<br />
* The Haskell [http://haskell.org/communities/ community reports]<br />
* The [http://www.haskell.org/mailman/listinfo/libraries mailing list] for discussion of issues related to libraries.]<br />
<br />
You can also [http://www.reddit.com/r/haskell_proposals/top/?t=month propose and vote on new libraries] that you'd like, and look at our past [http://hackage.haskell.org/trac/summer-of-code/ Summer of Code proposals].<br />
<br />
== Guidelines for developers ==<br />
<br />
[[Image:Cabal-With-Text-small.png|frame|Built with Cabal]]<br />
<br />
Developer guides:<br />
<br />
* [[How to write a Haskell program|How to write a new Haskell library]]<br />
* [[Library submissions|How to propose changes to the standard libraries]]<br />
* [http://pupeno.com/2006/12/12/the-lambda-revolution-v/ Creating a .deb from a Haskell Cabal package]<br />
* [http://cgi.cse.unsw.edu.au/~dons/blog/2006/12/11 Creating a Haskell library by example]<br />
* Guide to making standard [[Library submissions|library submissions]]<br />
* If you notice the library documentation is lacking, or could be improved, [http://haskell.org/haskellwiki/Improving_library_documentation please report it here]<br />
* [http://www.google.com/codesearch Google Code Search] can help identify common idioms, improving your API.<br />
* [[Future projects]], more projects people would like.<br />
* Project activity for some of the larger Haskell projects is graphed [http://www.cse.unsw.edu.au/~dons/images/commits/community/ here].<br />
* [[Cabal]], The Common Architecture for Building Applications and Libraries, is a framework for packaging, building, and installing any tool developed in the Haskell language.<br />
* [[Hack-Nix]], a set of tools based on the [http://nixos.org Nix] package manager to manage multiple setups to build a project<br />
<br />
Proposals for the module name space layout that can be used to guide the construction of new libraries. <br />
<br />
* [[Hierarchical module names|Almost current guide]]<br />
* [http://www.cs.york.ac.uk/fp/libraries/layout.html Proposal 1]<br />
* [http://www.cs.york.ac.uk/fp/libraries/layoutSM.html Proposal 2]<br />
<br />
== Libraries for other languages ==<br />
<br />
If you are thinking about designing a new library for Haskell, you ought to look what has been done in other languages. Here are standard library definitions for <br />
<br />
* [http://www.cs.ru.nl/~clean/Download/Download_Libraries/body_download_libraries.html Clean]<br />
* [http://www.standardml.org/Basis Standard ML]<br />
* [http://caml.inria.fr/pub/docs/manual-ocaml/manual034.html Objective Caml]<br />
* [http://srfi.schemers.org/ Scheme]</div>Igloohttps://wiki.haskell.org/index.php?title=ZuriHac&diff=30919ZuriHac2009-10-18T23:37:40Z<p>Igloo: </p>
<hr />
<div>'''March 2010'''<br />
<br />
Zurich, Switzerland<br />
<br />
== About ==<br />
<br />
The Haskell Hackathon is an international, grassroots collaborative coding festival with a simple focus: build and improve Haskell libraries, tools, and infrastructure.<br />
<br />
ZuriHac will be held in March at the Google office in Zurich. It is open to all -- you do not have to be a Haskell guru to attend. All you need is a basic knowledge of Haskell, a willingness to learn, and a project you're excited to help with (or a project of your own to work on).<br />
<br />
There will be lots of hacking, some talks, good food, and, of course, fun! <br />
<br />
== When ==<br />
<br />
Right now we're looking at four possible dates (Friday-Sunday):<br />
<br />
* March 5-7,<br />
* March 12-14,<br />
* March 19-21, or<br />
* March 26-28.<br />
<br />
If you add your name under [[#Possible Attendees]] below please note the dates that absolutely don't work for you.<br />
<br />
== Where ==<br />
<br />
We will be in the TechTalk area of the [http://maps.google.com/maps?q=Brandschenkestrasse+110,+8002+Z%C3%BCrich,+Switzerland+(Google)&ie=UTF8&t=h&hq=&hnear=Brandschenkestrasse+110,+8002+Zurich,+Switzerland&z=16&iwloc=A Google office].<br />
<br />
== Equipment ==<br />
<br />
You should bring a laptop with wireless (802.11). The room has whiteboards and a projector for any discussions or should anyone wish to give a talk. <br />
<br />
== Travel ==<br />
<br />
Online timetables for travel within Zurich can be found at [http://www.zvv.ch/en/ ZVV]. For trains within Switzerland and to neighboring countries go to [http://www.sbb.ch/en/index.htm SBB].<br />
<br />
=== Getting to Zurich ===<br />
<br />
There are direct flight to Zurich airport (code: ZRH) from most major European cities. Switzerland also has excellent and reasonably priced train connections with the rest of Europe.<br />
<br />
=== Getting to the Google Office ===<br />
<br />
The train and tram stop closest to the Google office is [http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=Bahnhof+Enge+station&sll=47.36554,8.524864&sspn=0.012484,0.018497&ie=UTF8&hq=&hnear=Z%C3%BCrich+Enge&ll=47.364903,8.527515&spn=0.012485,0.018497&t=h&z=16&iwloc=A Bahnhof Enge]. You can take tram 5, 6, 7, 13, or S-Bahn S2 to get there. It takes about seven minutes by tram from the main train station (Zurich HB) to Bahnhof Enge and another five minutes to walk to the office.<br />
<br />
==== From the Airport ====<br />
<br />
Take S-Bahn S2 directly to Bahnhof Enge and walk from there. Alternatively, take any S-Bahn that goes to the main train station (Zurich HB) and take tram 6, 7, or 13 to Bahnhof Enge.<br />
<br />
== Possible Attendees ==<br />
<br />
Note: This section is just to gauge the level of interest in having a hackathon. If there are any dates that absolutely don't work for you then please add them after your name.<br />
<br />
* Johan Tibell (tibbe)<br />
* Christophe Poucet (poucet)<br />
* Duncan Coutts (dcoutts)<br />
* Ganesh Sittampalam (Heffalump)<br />
* Iustin Pop<br />
* Tom Harper (sioraiocht)<br />
* Simon Meier<br />
* Marc A. Ziegert (coeus)<br />
* Joachim Breitner (nomeata)<br />
* Reinier Lamers (tux_rocker)<br />
* Chris Eidhof (chr1s)<br />
* Ian Lynagh (Igloo)<br />
<br />
== Organizers ==<br />
<br />
* Johan Tibell (irc: tibbe, e-mail: johan.tibell+zurihac@gmail.com)<br />
* Christophe Poucet (irc: poucet, e-mail: christophe.poucet+zurihac@gmail.com)<br />
<br />
[[Category:Community]]<br />
[[Category:Events]]<br />
[[Category:Hackathon]]</div>Igloohttps://wiki.haskell.org/index.php?title=Consultants&diff=30170Consultants2009-09-22T11:38:18Z<p>Igloo: </p>
<hr />
<div>; Well-Typed LLP http://www.well-typed.com/<br />
: The Haskell Consultants<br />
: Duncan Coutts and Ian Lynagh<br />
: [mailto:info@well-typed.com info@well-typed.com]<br />
<br />
; OM Consulting Limited ''[mailto:omconsult@gmail.com omconsult@gmail.com]'' :Intelligent solutions.<br />
<br />
; Chris Forno [http://jekor.com/ http://jekor.com/]<br />
: San Fransisco<br />
<br />
; Simon Michael http://joyful.com<br />
: Los Angeles<br />
<br />
; Tupil http://tupil.com<br />
: Chris Eidhof & Eelco Lempsink<br />
: Utrecht, The Netherlands<br />
<br />
; LambdaPix http://lambdapix.com<br />
: Conal Elliott<br />
: Blog: http://conal.net/blog<br />
: San Andreas, CA, USA<br />
<br />
; Brett Letner http://www.linkedin.com/in/brettletner<br />
: Lawrence, KS, USA<br />
<br />
; AppSolutions LLC http://www.appsolutions.com/<br />
: Anton van Straaten http://www.appsolutions.com/anton/<br />
: New York, Boston, Philadelphia, Washington DC<br />
<br />
[[Category:Community]]</div>Igloohttps://wiki.haskell.org/index.php?title=Hac7/Attendees&diff=29194Hac7/Attendees2009-07-22T15:54:09Z<p>Igloo: </p>
<hr />
<div>This is the attendee list for [[Hac7]]. Please refer to the [[Hac7|main page]] for more information.<br />
<br />
= Attendees =<br />
<br />
Once you've [[Hac7/Register|registered]], please add your name to the following table:<br />
<br />
{| class="wikitable"<br />
! Nickname<br />
! Real Name<br />
! Affiliation<br />
! Mobile #<br />
! Arriving<br />
! Departing<br />
! Accommodation<br />
|-<br />
| <br />
| Matthew Brecknell<br />
| <br />
|<br />
| 29 August<br />
| 29 August (attending Generics Workshop 30th)<br />
|<br />
|-<br />
| <br />
| Andrew Smith<br />
| <br />
|<br />
| 29 August<br />
| 30 August<br />
|<br />
|-<br />
| <br />
| Dougal Stanton<br />
| <br />
|<br />
| 29 August<br />
| 30 August<br />
|<br />
|-<br />
| byorgey<br />
| Brent Yorgey<br />
| University of Pennsylvania<br />
| +12025318646<br />
| 29 August (probably)<br />
| >= 30 August<br />
| Heriot-Watt University<br />
|-<br />
| JaffaCake<br />
| Simon Marlow<br />
| MSR<br />
|<br />
| 29 August (afternoon)<br />
| >= 30 August<br />
|<br />
|-<br />
| Heffalump<br />
| Ganesh Sittampalam<br />
| Credit Suisse<br />
| +447968253467<br />
| 29 August<br />
| 6 September<br />
| Ramada Mount Royal<br />
|-<br />
| Kowey<br />
| Eric Kow<br />
| University of Brighton<br />
| +447518728483<br />
| 29 August<br />
| 30 August<br />
| [http://www.edinburghfirst.com/accommodation/selfcateredaccommodation.asp University of Edinburgh - Baird House]<br />
|-<br />
| benl23<br />
| Ben Lippmeier<br />
| Australian National University<br />
| +61421381880<br />
| 29 August (afternoon)<br />
| 6 September<br />
| Heriot-Watt University<br />
|-<br />
| Igloo<br />
| Ian Lynagh<br />
| Well-Typed LLP<br />
| <br />
| Days before the Hackathon<br />
| Days after the Hackathon<br />
| Northumberland Hotel<br />
|}<br />
<br />
= Additional Comments =<br />
<br />
Please use this section to leave comments for other attendees, e.g. for organizing accommodation.</div>Igloohttps://wiki.haskell.org/index.php?title=GHC&diff=28152GHC2009-05-09T13:36:46Z<p>Igloo: </p>
<hr />
<div>The '''Glasgow Haskell Compiler''' is a state-of-the-art, open source, compiler and interactive environment for the functional language Haskell.<br />
<br />
* [http://www.haskell.org/ghc/ The GHC Home Page]<br />
<br />
== Documentation ==<br />
<br />
The documentation below relates to ''using'' GHC. For documentation about GHC's internals and building GHC, head over to the [http://hackage.haskell.org/trac/ghc GHC Developer Wiki].<br />
<br />
These documents relate to the ''latest released'' version of GHC.<br />
For ''earlier released'' versions click the relevant version on the<br />
[http://www.haskell.org/ghc/download.html downloads page]. <br />
For the the ''current HEAD snapshot'' look at <br />
[http://www.haskell.org/ghc/download.html#snapshots development snapshots].<br />
<br />
<br />
; [http://www.haskell.org/ghc/docs/latest/html/users_guide/index.html The User's Guide]: The User's Guide has all you need to know about using GHC: command line options, language extensions, GHCi, etc.<br />
: Download: | [http://www.haskell.org/ghc/docs/latest/users_guide.html.tar.bz2 HTML.tar.bz2] | [http://www.haskell.org/ghc/docs/latest/users_guide.pdf PDF] | [http://www.haskell.org/ghc/docs/latest/users_guide.ps PS] |<br />
<br />
; [http://www.haskell.org/ghc/docs/latest/html/libraries/index.html Standard Libraries]: Documentation for the libraries that come with GHC.<br />
: Download: | [http://www.haskell.org/ghc/docs/latest/libraries.html.tar.bz2 HTML.tar.bz2]<br />
<br />
; [http://www.haskell.org/ghc/docs/latest/html/Cabal/index.html Cabal]: An infrastructure for building and distributing Haskell software.<br />
: Download: | [http://www.haskell.org/ghc/docs/latest/Cabal.html.tar.bz2 HTML.tar.bz2] | [http://www.haskell.org/ghc/docs/latest/Cabal.pdf PDF] | [http://www.haskell.org/ghc/docs/latest/Cabal.ps PS] |<br />
<br />
== Collaborative documentation ==<br />
<br />
GHC is a big system. We try to document the core functionality (above), but<br />
you can help by writing documentation yourself. This section collects<br />
documentation written in a collaborative way, by users and developers together.<br />
Please help by adding new sections, and by clarifying and improving existing ones.<br />
<br />
* Using GHC<br />
** [[How_to_write_a_Haskell_program|How to write a Haskell program]]<br />
** [[/FAQ|GHC FAQ]]<br />
** [[Upgrading_packages|Guidelines for upgrading your GHC]]<br />
** [[/GHCi|Using GHCi]]<br />
** [[/GHCi debugger| The GHCi debugger]]<br />
** [[Cabal|Using Cabal]] (including with DLLs)<br />
** The [[Performance|Haskell Performance Resource]], for advice on improving the performance of your code<br />
** [[Mutually recursive modules]]<br />
<br />
* Platform related matters<br />
** [[GHC under WINE|Running GHC under Wine]]<br />
** [http://haskell.forkio.com/dotnet Using GHC with .NET]<br />
** [http://haskell.forkio.com/gmpwindows Dynamically linking GMP on Windows]<br />
** [[Windows]]<br />
<br />
* GHC extensions<br />
** [[/Type system|Type system extensions in GHC]]<br />
** [[/As a library|Using GHC as a library]]<br />
** [[/Concurrency|Concurrent programming in GHC]]<br />
** [[Template Haskell]] is a (GHC) extension to Haskell that adds compile-time metaprogramming facilities.<br />
** [[Quasiquotation]] allows the ability for user-definable parsers to provide new concrete syntax for any datatype.<br />
** [http://www.cse.unsw.edu.au/~dons/hs-plugins Dynamically loaded Haskell modules]: Don Stewart's <tt>hs-plugins</tt> library<br />
** [[/Using the FFI|Using the Foreign Function Interface]]<br />
** [[/GUI programming|GUI programming in GHC]]<br />
** [[/Using rules|Using RULES in GHC]]<br />
** [[GHC/Data Parallel Haskell|Data Parallel Haskell: using nested data parallelism in GHC]]<br />
<br />
* [[Correctness of short cut fusion]]<br />
<br />
== Development of GHC ==<br />
<br />
See the [http://hackage.haskell.org/trac/ghc GHC Developer Wiki]. The latest snapshot of the documentation for the next version can be found [http://haskell.org/ghc/dist/current/docs/ here].<br />
<br />
[[Category:Implementations]]<br />
[[Category:GHC]]</div>Igloohttps://wiki.haskell.org/index.php?title=GHC&diff=27303GHC2009-04-01T19:27:24Z<p>Igloo: </p>
<hr />
<div>The '''Glasgow Haskell Compiler''' is a state-of-the-art, open source, compiler and interactive environment for the functional language Haskell.<br />
<br />
* [http://www.haskell.org/ghc/ The GHC Home Page]<br />
<br />
== Documentation ==<br />
<br />
The documentation below relates to ''using'' GHC. For documentation about GHC's internals and building GHC, head over to the [http://hackage.haskell.org/trac/ghc GHC Developer Wiki].<br />
<br />
These documents relate to the ''latest released'' version of GHC.<br />
For ''earlier released'' versions click the relevant version on the<br />
[http://www.haskell.org/ghc/download.html downloads page]. <br />
For the the ''current HEAD snapshot'' look at <br />
[http://www.haskell.org/ghc/download.html#snapshots development snapshots].<br />
<br />
<br />
; [http://www.haskell.org/ghc/docs/latest/html/users_guide/index.html The User's Guide]: The User's Guide has all you need to know about using GHC: command line options, language extensions, GHCi, etc.<br />
: Download: | [http://www.haskell.org/ghc/docs/latest/users_guide.html.tar.bz2 HTML.tar.bz2] |<br />
<br />
; [http://www.haskell.org/ghc/docs/latest/html/libraries/index.html Standard Libraries]: Documentation for the libraries that come with GHC.<br />
: Download: | [http://www.haskell.org/ghc/docs/latest/libraries.html.tar.bz2 HTML.tar.bz2] |<br />
<br />
; [http://www.haskell.org/ghc/docs/latest/html/Cabal/index.html Cabal]: An infrastructure for building and distributing Haskell software.<br />
: Download: | [http://www.haskell.org/ghc/docs/latest/Cabal.html.tar.bz2 HTML.tar.bz2] |<br />
<br />
== Collaborative documentation ==<br />
<br />
GHC is a big system. We try to document the core functionality (above), but<br />
you can help by writing documentation yourself. This section collects<br />
documentation written in a collaborative way, by users and developers together.<br />
Please help by adding new sections, and by clarifying and improving existing ones.<br />
<br />
* Using GHC<br />
** [[How_to_write_a_Haskell_program|How to write a Haskell program]]<br />
** [[/FAQ|GHC FAQ]]<br />
** [[Upgrading_packages|Guidelines for upgrading your GHC]]<br />
** [[/GHCi|Using GHCi]]<br />
** [[/GHCi debugger| The GHCi debugger]]<br />
** [[Cabal|Using Cabal]] (including with DLLs)<br />
** The [[Performance|Haskell Performance Resource]], for advice on improving the performance of your code<br />
** [[Mutually recursive modules]]<br />
<br />
* Platform related matters<br />
** [[GHC under WINE|Running GHC under Wine]]<br />
** [http://haskell.forkio.com/dotnet Using GHC with .NET]<br />
** [http://haskell.forkio.com/gmpwindows Dynamically linking GMP on Windows]<br />
** [[Windows]]<br />
<br />
* GHC extensions<br />
** [[/Type system|Type system extensions in GHC]]<br />
** [[/As a library|Using GHC as a library]]<br />
** [[/Concurrency|Concurrent programming in GHC]]<br />
** [[Template Haskell]] is a (GHC) extension to Haskell that adds compile-time metaprogramming facilities.<br />
** [[Quasiquotation]] allows the ability for user-definable parsers to provide new concrete syntax for any datatype.<br />
** [http://www.cse.unsw.edu.au/~dons/hs-plugins Dynamically loaded Haskell modules]: Don Stewart's <tt>hs-plugins</tt> library<br />
** [[/Using the FFI|Using the Foreign Function Interface]]<br />
** [[/GUI programming|GUI programming in GHC]]<br />
** [[/Using rules|Using RULES in GHC]]<br />
** [[GHC/Data Parallel Haskell|Data Parallel Haskell: using nested data parallelism in GHC]]<br />
<br />
* [[Correctness of short cut fusion]]<br />
<br />
== Development of GHC ==<br />
<br />
See the [http://hackage.haskell.org/trac/ghc GHC Developer Wiki]. The latest snapshot of the documentation for the next version can be found [http://haskell.org/ghc/dist/current/docs/ here].<br />
<br />
[[Category:Implementations]]<br />
[[Category:GHC]]</div>Igloohttps://wiki.haskell.org/index.php?title=GHC&diff=27302GHC2009-04-01T19:26:59Z<p>Igloo: </p>
<hr />
<div>The '''Glasgow Haskell Compiler''' is a state-of-the-art, open source, compiler and interactive environment for the functional language Haskell.<br />
<br />
* [http://www.haskell.org/ghc/ The GHC Home Page]<br />
<br />
== Documentation ==<br />
<br />
The documentation below relates to ''using'' GHC. For documentation about GHC's internals and building GHC, head over to the [http://hackage.haskell.org/trac/ghc GHC Developer Wiki].<br />
<br />
These documents relate to the ''latest released'' version of GHC.<br />
For ''earlier released'' versions click the relevant version on the<br />
[http://www.haskell.org/ghc/download.html downloads page]. <br />
For the the ''current HEAD snapshot'' look at <br />
[http://www.haskell.org/ghc/download.html#snapshots development snapshots].<br />
<br />
<br />
; [http://www.haskell.org/ghc/docs/latest/html/users_guide/index.html The User's Guide]: The User's Guide has all you need to know about using GHC: command line options, language extensions, GHCi, etc.<br />
: Download: | [http://www.haskell.org/ghc/docs/latest/users_guide.html.tar.gz HTML.tar.bz2] |<br />
<br />
; [http://www.haskell.org/ghc/docs/latest/html/libraries/index.html Standard Libraries]: Documentation for the libraries that come with GHC.<br />
: Download: | [http://www.haskell.org/ghc/docs/latest/libraries.html.tar.gz HTML.tar.bz2] |<br />
<br />
; [http://www.haskell.org/ghc/docs/latest/html/Cabal/index.html Cabal]: An infrastructure for building and distributing Haskell software.<br />
: Download: | [http://www.haskell.org/ghc/docs/latest/Cabal.html.tar.gz HTML.tar.bz2] |<br />
<br />
== Collaborative documentation ==<br />
<br />
GHC is a big system. We try to document the core functionality (above), but<br />
you can help by writing documentation yourself. This section collects<br />
documentation written in a collaborative way, by users and developers together.<br />
Please help by adding new sections, and by clarifying and improving existing ones.<br />
<br />
* Using GHC<br />
** [[How_to_write_a_Haskell_program|How to write a Haskell program]]<br />
** [[/FAQ|GHC FAQ]]<br />
** [[Upgrading_packages|Guidelines for upgrading your GHC]]<br />
** [[/GHCi|Using GHCi]]<br />
** [[/GHCi debugger| The GHCi debugger]]<br />
** [[Cabal|Using Cabal]] (including with DLLs)<br />
** The [[Performance|Haskell Performance Resource]], for advice on improving the performance of your code<br />
** [[Mutually recursive modules]]<br />
<br />
* Platform related matters<br />
** [[GHC under WINE|Running GHC under Wine]]<br />
** [http://haskell.forkio.com/dotnet Using GHC with .NET]<br />
** [http://haskell.forkio.com/gmpwindows Dynamically linking GMP on Windows]<br />
** [[Windows]]<br />
<br />
* GHC extensions<br />
** [[/Type system|Type system extensions in GHC]]<br />
** [[/As a library|Using GHC as a library]]<br />
** [[/Concurrency|Concurrent programming in GHC]]<br />
** [[Template Haskell]] is a (GHC) extension to Haskell that adds compile-time metaprogramming facilities.<br />
** [[Quasiquotation]] allows the ability for user-definable parsers to provide new concrete syntax for any datatype.<br />
** [http://www.cse.unsw.edu.au/~dons/hs-plugins Dynamically loaded Haskell modules]: Don Stewart's <tt>hs-plugins</tt> library<br />
** [[/Using the FFI|Using the Foreign Function Interface]]<br />
** [[/GUI programming|GUI programming in GHC]]<br />
** [[/Using rules|Using RULES in GHC]]<br />
** [[GHC/Data Parallel Haskell|Data Parallel Haskell: using nested data parallelism in GHC]]<br />
<br />
* [[Correctness of short cut fusion]]<br />
<br />
== Development of GHC ==<br />
<br />
See the [http://hackage.haskell.org/trac/ghc GHC Developer Wiki]. The latest snapshot of the documentation for the next version can be found [http://haskell.org/ghc/dist/current/docs/ here].<br />
<br />
[[Category:Implementations]]<br />
[[Category:GHC]]</div>Igloohttps://wiki.haskell.org/index.php?title=GHC&diff=26560GHC2009-02-21T23:04:30Z<p>Igloo: Remove links to non-existant docs</p>
<hr />
<div>The '''Glasgow Haskell Compiler''' is a state-of-the-art, open source, compiler and interactive environment for the functional language Haskell.<br />
<br />
* [http://www.haskell.org/ghc/ The GHC Home Page]<br />
<br />
== Documentation ==<br />
<br />
The documentation below relates to ''using'' GHC. For documentation about GHC's internals and building GHC, head over to the [http://hackage.haskell.org/trac/ghc GHC Developer Wiki].<br />
<br />
These documents relate to the ''latest released'' version of GHC.<br />
For ''earlier released'' versions click the relevant version on the<br />
[http://www.haskell.org/ghc/download.html downloads page]. <br />
For the the ''current HEAD snapshot'' look at <br />
[http://www.haskell.org/ghc/download.html#snapshots development snapshots].<br />
<br />
<br />
; [http://www.haskell.org/ghc/docs/latest/html/users_guide/index.html The User's Guide]: The User's Guide has all you need to know about using GHC: command line options, language extensions, GHCi, etc.<br />
: Download: | [http://www.haskell.org/ghc/docs/latest/users_guide.html.tar.gz HTML.tar.gz] |<br />
<br />
; [http://www.haskell.org/ghc/docs/latest/html/libraries/index.html Standard Libraries]: Documentation for the libraries that come with GHC.<br />
: Download: | [http://www.haskell.org/ghc/docs/latest/libraries.html.tar.gz HTML.tar.gz] |<br />
<br />
; [http://www.haskell.org/ghc/docs/latest/html/Cabal/index.html Cabal]: An infrastructure for building and distributing Haskell software.<br />
: Download: | [http://www.haskell.org/ghc/docs/latest/Cabal.html.tar.gz HTML.tar.gz] |<br />
<br />
== Collaborative documentation ==<br />
<br />
GHC is a big system. We try to document the core functionality (above), but<br />
you can help by writing documentation yourself. This section collects<br />
documentation written in a collaborative way, by users and developers together.<br />
Please help by adding new sections, and by clarifying and improving existing ones.<br />
<br />
* Using GHC<br />
** [[How_to_write_a_Haskell_program|How to write a Haskell program]]<br />
** [[/FAQ|GHC FAQ]]<br />
** [[Upgrading_packages|Guidelines for upgrading your GHC]]<br />
** [[/GHCi|Using GHCi]]<br />
** [[/GHCi debugger| The GHCi debugger]]<br />
** [[Cabal|Using Cabal]] (including with DLLs)<br />
** The [[Performance|Haskell Performance Resource]], for advice on improving the performance of your code<br />
** [[Mutually recursive modules]]<br />
<br />
* Platform related matters<br />
** [[GHC under WINE|Running GHC under Wine]]<br />
** [http://haskell.forkio.com/dotnet Using GHC with .NET]<br />
** [http://haskell.forkio.com/gmpwindows Dynamically linking GMP on Windows]<br />
<br />
* GHC extensions<br />
** [[/Type system|Type system extensions in GHC]]<br />
** [[/As a library|Using GHC as a library]]<br />
** [[/Concurrency|Concurrent programming in GHC]]<br />
** [[Template Haskell]] is a (GHC) extension to Haskell that adds compile-time metaprogramming facilities.<br />
** [[Quasiquotation]] allows the ability for user-definable parsers to provide new concrete syntax for any datatype.<br />
** [http://www.cse.unsw.edu.au/~dons/hs-plugins Dynamically loaded Haskell modules]: Don Stewart's <tt>hs-plugins</tt> library<br />
** [[/Using the FFI|Using the Foreign Function Interface]]<br />
** [[/GUI programming|GUI programming in GHC]]<br />
** [[/Using rules|Using RULES in GHC]]<br />
** [[GHC/Data Parallel Haskell|Data Parallel Haskell: using nested data parallelism in GHC]]<br />
<br />
* [[Correctness of short cut fusion]]<br />
<br />
== Development of GHC ==<br />
<br />
See the [http://hackage.haskell.org/trac/ghc GHC Developer Wiki]. The latest snapshot of the documentation for the next version can be found [http://haskell.org/ghc/dist/current/docs/ here].<br />
<br />
[[Category:Implementations]]<br />
[[Category:GHC]]</div>Igloohttps://wiki.haskell.org/index.php?title=Hac5/Attendees&diff=26535Hac5/Attendees2009-02-19T18:20:12Z<p>Igloo: </p>
<hr />
<div>This is the attendee list for [[Hac5]]. Please refer to the [[Hac5|main page]] for more information.<br />
<br />
= Attendees =<br />
<br />
Once you've [[Hac5/Register|registered]], please add your name to the following table:<br />
<br />
{| class="wikitable"<br />
! Nickname<br />
! Real Name<br />
! Affiliation<br />
! Mobile #<br />
! Arriving<br />
! Departing<br />
! Accomodation<br />
|-<br />
| eelco<br />
| Eelco Lempsink<br />
| UU + Tupil<br />
| +31629486398<br />
| -<br />
| -<br />
| Lives in Utrecht.<br />
|-<br />
| kosmikus<br />
| Andres Löh<br />
| UU<br />
|<br />
| -<br />
| -<br />
| Lives close to Utrecht.<br />
|-<br />
| dreixel<br />
| José Pedro Magalhães<br />
| UU<br />
| +31 650459029<br />
| -<br />
| -<br />
| Lives in Utrecht.<br />
|-<br />
| Heffalump<br />
| Ganesh Sittampalam<br />
| Credit Suisse<br />
| +447968253467<br />
| 17th morning (overnight ferry arrives Hook of Holland at 0630)<br />
| 19th late afternoon (overnight ferry leaves Hook of Holland at 2200)<br />
| Don't know yet.<br />
|-<br />
| kowey<br />
| Eric Kow<br />
| University of Brighton<br />
|<br />
| Don't know yet.<br />
| Don't know yet.<br />
| Don't know yet.<br />
|-<br />
|<br />
| Martijn van Steenbergen<br />
| UU<br />
|<br />
|<br />
|<br />
| Lives close to Utrecht.<br />
|-<br />
| Igloo<br />
| Ian Lynagh<br />
| Well-Typed LLP<br />
|<br />
| 17th morning (overnight ferry)<br />
| 19th late afternoon (overnight ferry)<br />
| Strowis hostel<br />
|-<br />
| thorkilnaur<br />
| Thorkil Naur<br />
| thorkilnaur.com<br />
| +45 24 82 85 98<br />
| Probably April 16<br />
| Probably April 20<br />
| Don't know<br />
|-<br />
| tux_rocker<br />
| Reinier Lamers<br />
|<br />
| <br />
| -<br />
| -<br />
| Lives in Utrecht<br />
|-<br />
| Jutaro<br />
| Jürgen Nicklisch-Franken<br />
| ICS AG<br />
|<br />
| ?<br />
| ?<br />
| ?<br />
|-<br />
| kolmodin<br />
| Lennart Kolmodin<br />
| <br />
| +46736223606<br />
| Don't know yet.<br />
| Don't know yet.<br />
| Don't know yet.<br />
|-<br />
| chr1s<br />
| Chris Eidhof<br />
| UU + Tupil<br />
| +31628887656<br />
| -<br />
| -<br />
| Lives in Utrecht.<br />
|-<br />
| sebas<br />
| Sebastiaan Visser<br />
| UU<br />
| +31624828951<br />
| -<br />
| -<br />
| Lives in Utrecht.<br />
|-<br />
| dcoutts<br />
| Duncan Coutts<br />
| Well-Typed LLP<br />
|<br />
| 16th<br />
| 20th<br />
| Don't know yet.<br />
|}<br />
<br />
= Additional Comments =<br />
<br />
Please use this section to leave comments for other attendees, e.g. for organizing accommodation.</div>Igloohttps://wiki.haskell.org/index.php?title=Hac5/Attendees&diff=26434Hac5/Attendees2009-02-12T16:26:05Z<p>Igloo: </p>
<hr />
<div>This is the attendee list for [[Hac5]]. Please refer to the [[Hac5|main page]] for more information.<br />
<br />
= Attendees =<br />
<br />
Once you've [[Hac5/Register|registered]], please add your name to the following table:<br />
<br />
{| class="wikitable"<br />
! Nick<br />
! Name<br />
! Affiliation<br />
! Mobile #<br />
! Arriving<br />
! Departing<br />
! Accomodation<br />
|-<br />
| eelco<br />
| Eelco Lempsink<br />
| UU + Tupil<br />
| +31629486398<br />
| -<br />
| -<br />
| Lives in Utrecht.<br />
|-<br />
| kosmikus<br />
| Andres Löh<br />
| UU<br />
|<br />
| -<br />
| -<br />
| Lives close to Utrecht.<br />
|-<br />
| dreixel<br />
| José Pedro Magalhães<br />
| UU<br />
| +31 650459029<br />
| -<br />
| -<br />
| Lives in Utrecht.<br />
|-<br />
| Heffalump<br />
| Ganesh Sittampalam<br />
| Credit Suisse<br />
| +447968253467<br />
| Don't know yet.<br />
| Don't know yet.<br />
| Don't know yet.<br />
|-<br />
| kowey<br />
| Eric Kow<br />
| University of Brighton<br />
|<br />
| Don't know yet.<br />
| Don't know yet.<br />
| Don't know yet.<br />
|-<br />
|<br />
| Martijn van Steenbergen<br />
| UU<br />
|<br />
|<br />
|<br />
| Lives close to Utrecht.<br />
|-<br />
| Igloo<br />
| Ian Lynagh<br />
| Well-Typed LLP<br />
|<br />
| Don't know yet.<br />
| Don't know yet.<br />
| Don't know yet.<br />
|}<br />
<br />
= Additional Comments =<br />
<br />
Please use this section to leave comments for other attendees, e.g. for organizing accommodation.</div>Igloohttps://wiki.haskell.org/index.php?title=AngloHaskell/2008&diff=22047AngloHaskell/20082008-07-30T20:26:30Z<p>Igloo: </p>
<hr />
<div>Anglo Haskell has previously happened at Microsoft Research, Cambridge in both [[AngloHaskell/2006|2006]] and [[AngloHaskell/2007|2007]] much fun was had! For 2008, we think it should happen again, but this time at Imperial College, London. Who's up for it (add names further down)?<br />
<br />
This year it's being (un)organised by Matthew Sackman (matthew-_), Tristan Allwood (ToRA) and Ganesh Sittampalam (Heffalump) who all regularly sit on #haskell and #anglohaskell (with nicks in (parenthesis)). Philippa Cowderoy is also prodding the organisers at regular intervals to do some organising...<br />
<br />
== Date and Venue ==<br />
<br />
We have a suitable sized room booked out at the Department of Computing, Imperial College, London on Friday the 8th and Saturday the 9th of August.<br />
<br />
The room that we have booked is quite nicely reconfigurable, so we can do break away groups and such or even multiple tracks if there is demand for this.<br />
<br />
Some reasonable instructions for getting to Imperial are [http://www3.imperial.ac.uk/computing/about/mapandtravel/ available].<br />
<br />
Details for getting to the Department of Computing and the event room (Huxley 344) are now [http://www.zonetora.co.uk/NonBlog/angloHaskellRoute/ available]. There will likely be some lambdas dotted around Huxley & the walkway to point you in the right direction on the day.<br />
<br />
Mobile contact details for the event organisers will be made available closer to the date (no later than Weds 6th).<br />
<br />
=== WiFi ===<br />
<br />
WiFi will be available at Imperial throughout the weekend. There is a simple mac-registration system which you can do through your laptops and all should work without a hitch.<br />
<br />
=== Lodging ===<br />
<br />
It's likely that there'll be people in need of crashspace and so forth. If you need to, please you this area and #anglohaskell to organise where to stay overnight.<br />
<br />
Imperial does offer [http://www3.imperial.ac.uk/accommodation/visitingacademics/flats lodging] in its halls but they're very expensive. There are some useful contacts if you want to [http://www3.imperial.ac.uk/accommodation/usefulcontacts phone and barter]. Or, possibly just crashing with friends on floors with sleeping bags and so forth might be simpler and certainly cheaper. Also don't forget that Imperial is about 10 mins walk from South Kensington tube station so public transportation is available if you want to rush home.<br />
<br />
Note that parking is both expensive and highly competitive in the surrounding area so it would probably be easier to not drive in. Parking for bicycles is available on campus, provided you have your own bike locks.<br />
<br />
== Attendees ==<br />
<br />
Per last year, all attendees should '''bring or make a nametag''' that identifies you by your real name and/or IRC name. If anyone wants to drag a roll of stickers and a pen along that'll help!<br />
<br />
Attendees should consider signing up for [[#Friday_night_dinner|dinner on Friday]] too.<br />
<br />
=== Definite ===<br />
<br />
Please add yourself to a list here if you know you can attend.<br />
<br />
* Simon Marlow<br />
* Matthew Sackman<br />
* Tristan Allwood<br />
* Ganesh Sittampalam<br />
* Pieter Laeremans<br />
* Philippa Cowderoy<br />
* Tom Harper<br />
* Neil Mitchell<br />
* Neil Brown<br />
* Edwin Brady (Friday only)<br />
* Simon PJ (Friday only)<br />
* Alistair Bayley (probably Friday only)<br />
* Eric Kow (commuting from Brighton, i.e. no overnights)<br />
* Ian Lynagh<br />
<br />
=== Possible ===<br />
<br />
* Lauri Pesonen<br />
* Roly Perera<br />
* Alex McLean<br />
* Chaddaï Fouché<br />
* Jamie Brandon<br />
* Duncan Coutts<br />
* James Rowe<br />
* David Himmelstrup<br />
* Simon Parry<br />
* Chris Done<br />
<br />
Please add yourself to a list here if you think you can attend.<br />
<br />
== Programme ==<br />
<br />
Planning will be taking place on IRC as per last year: #anglohaskell on irc.freenode.net<br />
<br />
If you're having trouble following things on IRC, the discussion page on the wiki might be a good place to leave comments and questions.<br />
<br />
Last year we had talks in the day on a Friday, followed by pubbage in the evening and assorted activities on the Saturday. Again, no one has suggested there's anything wrong with this plan, so we're going ahead.<br />
<br />
=== Friday night dinner ===<br />
<br />
For dinner on Friday, there are many good pubs around Imperial and some really decent pubs across London many of which sell decent PubGastro food. If you want to rush off to meet friends, family etc then that's obviously fine, but if you'd like to stay around for a geeky evening meal then that might be fun.<br />
<br />
We're proposing to go up to [http://www.giraffe.net/locations_restaurant.php?id=99 Giraffe at High Street Kensington] which is about a 10-15 minute walk from Imperial. It has a [http://www.giraffe.net/files/giraffe_highst_menu.pdf menu] which should give some idea - basically if you just have a main and a drink then you can get by for less than £15 which is pretty damn good for that part of London. I (Matthew) have been to this particular Giraffe at least a dozen times over the last 5 years and I do think it's probably the best value for money in the surrounding area.<br />
<br />
'''If you'd like to join us for this meal then could you add your name below please.''' I'd like to book with them in advance ('''by the end of July''') as they will be busy on a Friday evening.<br />
<br />
* Matthew Sackman<br />
* Tristan Allwood<br />
* Philippa Cowderoy<br />
* Tom Harper<br />
* Ganesh Sittampalam<br />
* Edwin Brady<br />
* Neil Mitchell + 1<br />
<br />
=== Saturday ===<br />
<br />
We have the room at Imperial booked here as well and are planning on using it for talks. Later on, if people want a quiet place to Group Hack with access to whiteboards and so forth then it could be used for that. Let's see how many people want to give talks, but other suggestions for Saturday could be noted here too.<br />
<br />
=== Other Thoughts ===<br />
<br />
For potential group hacking on Saturday, we need something to hack on. On what shall we hack?<br />
<br />
:''I have a suggestion, although it's not quite hacking. Could we sit down together and run darcs through the profiler? The outcome I desire from this is (a) a Haskell wiki page showing you how to profile a largeish program and make sense of the output [and act on it] and (b) more insight into darcs performance and (c) more Haskellers working on darcs'' -- [[User:EricKow|kowey]] 16:20, 30 July 2008 (UTC)<br />
<br />
=== Talks ===<br />
<br />
It wouldn't be AngloHaskell without some talks, so volunteers please! Previously we have had a largely more practical set of talks than you might find at Fun in the Afternoon or an academic event. This was a good thing, and some of the best talks were from people who were far from considering themselves as experts, so feel free to tell us about your experiences.<br />
<br />
The room booked at Imperial has multiple projectors and connections for laptops and so forth. It even has whiteboards.<br />
<br />
* Simon Marlow has promised to keynote on Parallel GC<br />
* Matthew Sackman could talk on automatic type level static analysis of embedded Domain Specific Languages.<br />
* Tristan Allwood - Making zippers for structured editors<br />
* Philippa Cowderoy - Fusion-powered EDSLs<br />
* Neil Mitchell - Hoogle 4, fast type searching (I gave an AngloHaskell 2007 talk, so would be happy to defer to someone else)<br />
* Ganesh Sittampalam - Squiggle: using associated types to embed SQL<br />
* Tom Harper - Stream fusion on Haskell Unicode strings<br />
* Neil Brown - Explicit concurrency with the CHP library<br />
<br />
Please please keep offering talks. If you have constraints like "Friday only" or "can only talk for 30 mins" then please indicate these and try and grab slots in the timetable below as necessary. I've just added a timetable for Saturday too so we can spill over there as we are now in the wonderful position of having more talks than we can fit on Friday (without reducing talks to 30 mins).<br />
<br />
=== Timetable ===<br />
<br />
A programme, talks need to be confirmed and can change around. I've assumed a rough 35mins + 10min questions/overrun/discussion per talk - shout if this is a problem.<br />
<br />
==== Friday ====<br />
{| class="wikitable"<br />
|-<br />
! Time !! Event<br />
|-<br />
| 10am || Matthew and Tristan around to open up<br />
|-<br />
| 10:30 am || Tea, coffee, water and biscuits<br />
|-<br />
| 11am || Welcome, Start!<br />
|-<br />
| 11:15am || Keynote (Simon Marlow)<br />
|-<br />
| 12am || Talk 2 (Tom Harper)<br />
|-<br />
| 12:45pm || Lunch - [[#Friday_Lunch|see below]]<br />
|-<br />
| 2pm || Talk 3 (Tristan Allwood)<br />
|-<br />
| 2:45pm || Talk 4 (Philippa Cowderoy)<br />
|-<br />
| 3:30pm || Tea, coffee, water and biscuits<br />
|-<br />
| 4pm || Talk 5 (Neil Brown)<br />
|-<br />
| 4:45pm || Functional grit - small talks that may grow into functional pearls. Open session, [[#Functional_Grit|see below]].<br />
|-<br />
| 7pm at resturant || Food! - [[#Friday_night_dinner|see above]]<br />
|-<br />
| Beer o'Clock || When everyone's finished eating, we'll head for a nearby pub<br />
|}<br />
===== Friday Lunch =====<br />
<br />
We will be able to provide some food (as-well as tea/coffee/water) for the Friday Lunch spot. Provisionally it will be:<br />
<br />
* Sandwiches<br />
** Mozerella & Sundried Tomato<br />
** Egg Mayo<br />
** Tuna & Pepper<br />
** Chicken & Sweetcorn<br />
* Vegetable wraps<br />
* Tuna Coquettes<br />
* Veg Quiche<br />
* Random fruit<br />
* Cake<br />
<br />
===== Functional Grit =====<br />
<br />
This is an informal and quick forum to discuss ideas and work - anyone can give a quick (30 seconds to 10 minutes) talk! Feel free to turn up with 2 slides (pdf, usb stick!) and give a quick talk on what you're up to or thinking about. We will organise this further on the day - no need to pre register for this.<br />
<br />
==== Saturday ====<br />
{| class="wikitable"<br />
|-<br />
! Time !! Event<br />
|-<br />
| 10am onwards, as people stagger out of bed || Brunch at Marble Arch Wetherspoons ([[#Brunch|see below]])<br />
|-<br />
| 12.15pm || Mosey across Hyde Park back to Imperial<br />
|-<br />
| 1pm || Talk 1 (Matthew Sackman)<br />
|-<br />
| 1:45pm || Talk 2 (Neil Mitchell)<br />
|-<br />
| 2:30pm || Break<br />
|-<br />
| 3pm || Talk 3 (Ganesh Sittampalam)<br />
|-<br />
| 3:45pm || Talk 4 TBC<br />
|-<br />
| 4:30pm onwards || Hacking? Pubbage? Dinner?<br />
|-<br />
| Tired o'Clock || Depart!<br />
|}<br />
<br />
===== Brunch =====<br />
<br />
We're hoping to do this at the [http://www.jdwetherspoon.co.uk/pubs/pub-details.php?PubNumber=1613 Marble Arch Wetherspoons] which is a 30 min walk away from Imperial (though across Hyde Park, so should be a nice walk!). They open at 8am and have a selection of food. We apologise for resorting to a Wetherspoon's, but they really are the only suitable place which will be open early enough and will be serving breakfast.<br />
<br />
[[Category:Events]]</div>Igloohttps://wiki.haskell.org/index.php?title=GHC&diff=21619GHC2008-07-05T15:33:22Z<p>Igloo: </p>
<hr />
<div>The '''Glasgow Haskell Compiler''' is a state-of-the-art, open source, compiler and interactive environment for the functional language Haskell.<br />
<br />
* [http://www.haskell.org/ghc/ The GHC Home Page]<br />
<br />
== Documentation ==<br />
<br />
The documentation below relates to ''using'' GHC. For documentation about GHC's internals and building GHC, head over to the [http://hackage.haskell.org/trac/ghc GHC Developer Wiki].<br />
<br />
These documents relate to the ''latest released'' version of GHC.<br />
For ''earlier released'' versions click the relevant version on the<br />
[http://www.haskell.org/ghc/download.html downloads page]. <br />
For the the ''current HEAD snapshot'' look at <br />
[http://www.haskell.org/ghc/download.html#snapshots development snapshots].<br />
<br />
<br />
; [http://www.haskell.org/ghc/docs/latest/html/users_guide/index.html The User's Guide]: The User's Guide has all you need to know about using GHC: command line options, language extensions, GHCi, etc.<br />
: Download: | [http://www.haskell.org/ghc/docs/latest/users_guide.html.tar.gz HTML.tar.gz] | [http://www.haskell.org/ghc/docs/latest/users_guide.pdf PDF] | [http://www.haskell.org/ghc/docs/latest/users_guide.ps.gz A4 Postscript (gzipped)] |<br />
<br />
; [http://www.haskell.org/ghc/docs/latest/html/libraries/index.html Standard Libraries]: Documentation for the libraries that come with GHC.<br />
: Download: | [http://www.haskell.org/ghc/docs/latest/libraries.html.tar.gz HTML.tar.gz] | [http://www.haskell.org/ghc/docs/latest/libraries.html-haddock2.tgz GHC 6.8 haddock 2 HTML.tar.gz] |<br />
<br />
; [http://www.haskell.org/ghc/docs/latest/html/Cabal/index.html Cabal]: An infrastructure for building and distributing Haskell software.<br />
: Download: | [http://www.haskell.org/ghc/docs/latest/Cabal.html.tar.gz HTML.tar.gz] | [http://www.haskell.org/ghc/docs/latest/Cabal.pdf PDF] | [http://www.haskell.org/ghc/docs/latest/Cabal.ps.gz A4 Postscript (gzipped)] |<br />
<br />
== Collaborative documentation ==<br />
<br />
GHC is a big system. We try to document the core functionality (above), but<br />
you can help by writing documentation yourself. This section collects<br />
documentation written in a collaborative way, by users and developers together.<br />
Please help by adding new sections, and by clarifying and improving existing ones.<br />
<br />
* Using GHC<br />
** [[How_to_write_a_Haskell_program|How to write a Haskell program]]<br />
** [[/FAQ|GHC FAQ]]<br />
** [[/GHCi|Using GHCi]]<br />
** [[/GHCi debugger| The GHCi debugger]]<br />
** [[Cabal|Using Cabal]] (including with DLLs)<br />
** The [[Performance|Haskell Performance Resource]], for advice on improving the performance of your code<br />
** [[GHC under WINE|Running GHC under Wine]]<br />
<br />
* GHC extensions<br />
** [[/Type system|Type system extensions in GHC]]<br />
** [[/As a library|Using GHC as a library]]<br />
** [[/Concurrency|Concurrent programming in GHC]]<br />
** [[Template Haskell]] is a (GHC) extension to Haskell that adds compile-time metaprogramming facilities.<br />
** [[Quasiquotation]] allows the ability for user-definable parsers to provide new concrete syntax for any datatype.<br />
** [http://www.cse.unsw.edu.au/~dons/hs-plugins Dynamically loaded Haskell modules]: Don Stewart's <tt>hs-plugins</tt> library<br />
** [[/Using the FFI|Using the Foreign Function Interface]]<br />
** [[/GUI programming|GUI programming in GHC]]<br />
** [[/Using rules|Using RULES in GHC]]<br />
** [[GHC/Data Parallel Haskell|Data Parallel Haskell: using nested data parallelism in GHC]]<br />
<br />
* [[Correctness of short cut fusion]]<br />
<br />
== Development of GHC ==<br />
<br />
See the [http://hackage.haskell.org/trac/ghc GHC Developer Wiki]. The latest snapshot of the documentation for the next version can be found [http://haskell.org/ghc/dist/current/docs/ here].<br />
<br />
[[Category:Implementations]]<br />
[[Category:GHC]]</div>Igloohttps://wiki.haskell.org/index.php?title=Library_submissions&diff=21222Library submissions2008-06-08T10:24:43Z<p>Igloo: Weaken what we say about tests</p>
<hr />
<div>As the Haskell community has grown, and emphasis on development has<br />
moved from language to libraries, the need for a more formalised process<br />
for contributing to libraries has emerged. This page documents our<br />
'best practices' for proposing changes to library interfaces<br />
(e.g. new modules or functions, removing functions) in packages that list ''libraries@haskell.org'' as maintainer.<br />
We have been using it since October 2006.<br />
<br />
In essence, we don't want proposals to go unnoticed, but changes to<br />
basic interfaces also need thorough consideration. <br />
<br />
== Creating a proposal ==<br />
<br />
In order to ensure we have something concrete to discuss, please follow<br />
the following guidelines:<br />
<br />
* ''Currency''. Make your changes against a copy of the HEAD branch of the [http://hackage.haskell.org/trac/ghc/wiki/DarcsRepositories relevant library], and make sure it compiles.<br />
* ''Portability''. Code should be portable. If it is not portable, reasons should be given. At the very least ensure the code runs in Hugs and GHC, and on Windows and Linux.<br />
* ''Style''. Follow the conventions in the library you are modifying.<br />
* ''Documentation''. It must include valid [http://haskell.org/haddock Haddock] documentation.<br />
* ''Tests''. Code should ideally also come with suitable tests for the testsuite. There's currently some disagreement about what this means. Discussion of where we may want to head is in the [[Library_tests | library tests]] page.<br />
<br />
== Submitting the proposal ==<br />
<br />
* ''Patch''. Create a [http://darcs.net darcs] patch of your change using <tt>darcs record</tt>, including a rationale for the change. Save the patch to a file, using <tt>darcs send --output</tt>.<br />
<br />
* ''Tracking''. [http://hackage.haskell.org/trac/ghc/newticket?type=proposal&component=libraries/base&milestone=Not+GHC Add a Trac ticket] of type ''proposal'' for the appropriate library component, with a timescale for consideration (to focus the community's attention for a limited period), adding the patch file as an attachment.<br />
<br />
* ''Submission''. Send an email containing the Trac ticket number and description to libraries@haskell.org. (In the future this should happen when you record the ticket, but we haven't set it up yet.)<br />
<br />
If someone has done all this, they are entitled to expect feedback;<br />
silence during the discussion period can be interpreted as consent.<br />
<br />
Here are the [http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&group=component&type=proposal&order=priority proposals currently under consideration].<br />
<br />
== At the end of the discussion period ==<br />
<br />
* Add to the ticket a summary of the relevant parts of the discussion. (The summary is needed for anyone wondering about the change later: it's not reasonable to point people at a 50-message thread.)<br />
* If consensus was achieved, revise the patch as necessary, including the Trac ticket number, and commit it (or get someone to commit it for you).<br />
* Close the ticket (usually as ''fixed'' or ''wontfix'').<br />
<br />
A deeply held disagreement at this point may require some form of government (voting, dictatorship, etc). This should be a rare event.<br />
<br />
Here are the [http://hackage.haskell.org/trac/ghc/query?status=closed&group=component&type=proposal&order=priority archived past proposals].<br />
<br />
Here is an example of how to [http://hackage.haskell.org/trac/ghc/ticket/966 summarise a successful submission].<br />
<br />
== See also ==<br />
<br />
* [http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions GHC Working Conventions], including guidelines for submitting patches via darcs.<br />
* [http://haskell.org/haskellwiki/Category:Style Notes on programming style]<br />
<br />
[[Category:Community]]<br />
[[Category:Proposals| ]]</div>Igloohttps://wiki.haskell.org/index.php?title=Consultants&diff=20346Consultants2008-03-30T22:15:50Z<p>Igloo: </p>
<hr />
<div>; Well-Typed LLP http://www.well-typed.com/<br />
: The Haskell Consultants<br />
: Björn Bringert, Duncan Coutts and Ian Lynagh<br />
: [mailto:info@well-typed.com info@well-typed.com]<br />
<br />
; OM Consulting Limited ''[mailto:omconsult@gmail.com omconsult@gmail.com]'' :Intelligent solutions.<br />
<br />
; Chris Forno [http://jekor.com/ http://jekor.com/]<br />
: Los Angeles<br />
<br />
[[Category:Community]]</div>Igloo