https://wiki.haskell.org/api.php?action=feedcontributions&user=Ivanm&feedformat=atomHaskellWiki - User contributions [en]2024-03-28T13:30:11ZUser contributionsMediaWiki 1.35.5https://wiki.haskell.org/index.php?title=Polyparse&diff=57353Polyparse2013-12-27T22:04:17Z<p>Ivanm: /* Download */ Update hackage location to point to most recent</p>
<hr />
<div>[[Category:Libraries]] [[Category:Compiler tools]]<br />
== Download ==<br />
Get polyparse from [http://hackage.haskell.org/package/polyparse hackage].<br />
<br />
== Useful information ==<br />
'''polyparse''' is a collection of alternative parser combinator libraries.<br />
Please edit this page to add any useful information you can think of.<br />
<br />
The polyparse home page: http://code.haskell.org/~malcolm/polyparse/docs</div>Ivanmhttps://wiki.haskell.org/index.php?title=AusHac2011&diff=39462AusHac20112011-04-16T06:29:57Z<p>Ivanm: Add graph project</p>
<hr />
<div>AusHac 2011 will be held at UNSW from the '''8th to the 10th of July''' 2011, at the [http://maps.google.com/maps?cid=9827534508363927277&hl=en&ie=UTF8&hq=&hnear=&ll=-33.918168,151.231077&spn=0.010773,0.022702&t=h&z=16&iwloc=A Computer Science and Engineering building] at UNSW (Bilding K17), in room 113.<br />
<br />
Last year's AusHac was a huge success, and we'd love to make this years even bigger and better, but for that, we need you!<br />
<br />
If you are interested on coming, please fill in our [http://axman6.wufoo.com/forms/aushac-2011-sign-up/ sign up] form so we have an idea of numbers. Signup is required to gain access to the university network. If you're not sure you can come, fill it in anyway and leave a comment down the bottom. '''We'd rather be ready for too many people than not enough!'''<br />
<br />
== Project ideas ==<br />
<br />
=== Graph Stuff ===<br />
<br />
'''What:''' Not quite sure yet; possibly a [http://thejit.org/ JavaScript InfoVis Toolkit] backend for [http://projects.haskell.org/graphviz/ graphviz].<br />
<br />
'''Who:''' Ivan<br />
<br />
== Accommodation ==<br />
<br />
=== Hostels ===<br />
If you're looking for somewhere cheap to stay near UNSW then there are a [http://www.hostelworld.com/hostels/Sydney/Coogee few back-packers in Coogee].<br />
It's about a 10 minute bus ride from Coogee Beach to UNSW. Shared rooms are AUD$30 - 40.<br />
<br />
For something a bit further out, you could also try one of the [http://www.yha.com.au/hostels/search/region.cfm?regionid=62 Sydney YHA hostels]. The Glebe one is walking distance to Darling Harbour, though it takes about 50 min to get to UNSW via light rail then bus. Private rooms with shared facilities are about AUD$80. Shared rooms are AUD$30 - 40.<br />
<br />
If you want to say across the road from Central station, and don't mind hanging out with English gap-year kids, then you try [http://www.wakeup.com.au/ WakeUp].<br />
<br />
If you like to party then [http://www.evasbackpackers.com.au/ Evas Backpackers] is a short stumble home from Kings Cross. <br />
<br />
I'd avoid [http://www.sydneycentralonwentworth.com.au/ SydneyCentralOnWentworth]. It has a pretty website but the rooms are small and dingy (benl23 stayed there in 2009)<br />
<br />
Note that hostels tend to be busiest on Friday and Saturday nights, so it's good to book early.<br />
<br />
=== Colleges ===<br />
For something more up-market you could try one of [http://www.housing.unsw.edu.au/housing/short_term/short_term.php?p=overview the UNSW residential Colleges]. This site also has more links to hotels and hostels.<br />
<br />
=== Hotels ===<br />
If you have AUD$120 - 150 per night and aren't organised then [http://www.lastminute.com.au/hotels.html LastMinute] is a good place to find a hotel. You get the best prices if you book 2-3 days in advance. Alternatively, try [http://www.wotif.com/ wotif].<br />
<br />
== Related Links ==<br />
<br />
* [[AusHac2010]]<br />
* [[OzHaskell]]<br />
<br />
[[Category:Events]]<br />
[[Category:Hackathon]]</div>Ivanmhttps://wiki.haskell.org/index.php?title=AusHac2011&diff=39461AusHac20112011-04-16T06:26:38Z<p>Ivanm: Add wotif link</p>
<hr />
<div>AusHac 2011 will be held at UNSW from the '''8th to the 10th of July''' 2011, at the [http://maps.google.com/maps?cid=9827534508363927277&hl=en&ie=UTF8&hq=&hnear=&ll=-33.918168,151.231077&spn=0.010773,0.022702&t=h&z=16&iwloc=A Computer Science and Engineering building] at UNSW (Bilding K17), in room 113.<br />
<br />
Last year's AusHac was a huge success, and we'd love to make this years even bigger and better, but for that, we need you!<br />
<br />
If you are interested on coming, please fill in our [http://axman6.wufoo.com/forms/aushac-2011-sign-up/ sign up] form so we have an idea of numbers. Signup is required to gain access to the university network. If you're not sure you can come, fill it in anyway and leave a comment down the bottom. '''We'd rather be ready for too many people than not enough!'''<br />
<br />
== Project ideas ==<br />
<br />
== Accommodation ==<br />
<br />
=== Hostels ===<br />
If you're looking for somewhere cheap to stay near UNSW then there are a [http://www.hostelworld.com/hostels/Sydney/Coogee few back-packers in Coogee].<br />
It's about a 10 minute bus ride from Coogee Beach to UNSW. Shared rooms are AUD$30 - 40.<br />
<br />
For something a bit further out, you could also try one of the [http://www.yha.com.au/hostels/search/region.cfm?regionid=62 Sydney YHA hostels]. The Glebe one is walking distance to Darling Harbour, though it takes about 50 min to get to UNSW via light rail then bus. Private rooms with shared facilities are about AUD$80. Shared rooms are AUD$30 - 40.<br />
<br />
If you want to say across the road from Central station, and don't mind hanging out with English gap-year kids, then you try [http://www.wakeup.com.au/ WakeUp].<br />
<br />
If you like to party then [http://www.evasbackpackers.com.au/ Evas Backpackers] is a short stumble home from Kings Cross. <br />
<br />
I'd avoid [http://www.sydneycentralonwentworth.com.au/ SydneyCentralOnWentworth]. It has a pretty website but the rooms are small and dingy (benl23 stayed there in 2009)<br />
<br />
Note that hostels tend to be busiest on Friday and Saturday nights, so it's good to book early.<br />
<br />
=== Colleges ===<br />
For something more up-market you could try one of [http://www.housing.unsw.edu.au/housing/short_term/short_term.php?p=overview the UNSW residential Colleges]. This site also has more links to hotels and hostels.<br />
<br />
=== Hotels ===<br />
If you have AUD$120 - 150 per night and aren't organised then [http://www.lastminute.com.au/hotels.html LastMinute] is a good place to find a hotel. You get the best prices if you book 2-3 days in advance. Alternatively, try [http://www.wotif.com/ wotif].<br />
<br />
== Related Links ==<br />
<br />
* [[AusHac2010]]<br />
* [[OzHaskell]]<br />
<br />
[[Category:Events]]<br />
[[Category:Hackathon]]</div>Ivanmhttps://wiki.haskell.org/index.php?title=Libraries/WhenToRewriteOrRename&diff=35606Libraries/WhenToRewriteOrRename2010-07-13T12:26:46Z<p>Ivanm: FGL is not Haskell98-compatible</p>
<hr />
<div>There have been a few cases of major API changes / rewrites to famous old<br />
packages causing problems, including:<br />
<br />
* QuickCheck 1 vs 2<br />
* parsec 2 vs 3<br />
* OpenGL<br />
* Haxml 1.13,1.19<br />
<br />
a similar opportunity is present with 'fgl', where the new maintainers<br />
are seeking to improve the code.<br />
<br />
Below I try to summarise the pros and cons of calling the new<br />
rewrite/api 'fgl', in the hope we can identify a path that minimizes<br />
disruption to users.<br />
<br />
------------------------------------------------------------------------<br />
<br />
A group of developers is planning to write a new graph library for<br />
Haskell.<br />
<br />
* They maintain an existing package called 'fgl'.<br />
* 'fgl' has a long history: http://web.engr.oregonstate.edu/~erwig/fgl/<br />
* The new library will have different authors and a different API.<br />
* They would like to call the new library 'fgl'.<br />
<br />
It is a controversial step to write a new library and give it the same<br />
name as an existing, famous library. Let's look at the arguments.<br />
<br />
Quoting Duncan Coutts on #haskell (with some formatting added): the critical issues are:<br />
<br />
1. Is the new API in the spirit of the old?<br />
<br />
2. Do you have the support of a) the previous maintainer and b) current users<br />
<br />
3. Will the new implementation actually be better?<br />
<br />
4. Will the transition be managed well?<br />
<br />
= Reasons to use the old name =<br />
<br />
* Considering the four points raised by Duncan, we believe that the first and third points are/will be met; we have plans to manage the transition and the point of the "technology preview" releases is to ensure 2. b). We have not, however, directly contacted Martin as yet.<br />
<br />
* The new code will be better, and should be preferred. Using the name 'fgl' will ensure adoption.<br />
<br />
* Rewrites are effective if the name is preserved. E.g. QuickCheck 2.<br />
<br />
* It is the maintainer's right to modify APIs as they see fit.<br />
<br />
* Keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade.<br />
<br />
* Relatively few packages use fgl. So damage is limited.<br />
<br />
* It makes development by new users simpler by not fracturing the package-space (the "Which version of QuickCheck should I use?" problem). <br />
<br />
* It decreases the maintainer workload as the same person or team will often be responsible for both packages.<br />
<br />
* A lot of respected members of the Haskell community (e.g. Cale) do not like many aspects of the current API (and thus refuse to use it) and we're taking their points of view into account.<br />
<br />
* The new version of the library is keeping the "spirit" of old fgl alive, but modernising the interface and providing new functionality (e.g. the ability to restrict the label types or use a custom Node type).<br />
<br />
* There will be a full transition guide between the old and new versions (something that was lacking for packages like QuickCheck from what I could tell).<br />
<br />
* Major version numbers exist for a reason: to denote breakage. We really need to educate developers to avoid having too lax or open-ended package dependencies.<br />
<br />
= Reasons not to use the name =<br />
<br />
* Code that depends on 'fgl' will break. There are 23 direct and 25 indirect dependencies on fgl. http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/fgl-5.4.2.2#direct<br />
<br />
** Rebuttal: <br />
<br />
*** Have contacted all maintainers of packages on Hackage which have packages without an upper bound on the version of fgl used; most have already gotten back to me saying they will release a bug-fix version to resolve this.<br />
<br />
*** With the [[Package_versioning_policy]], people should always have upper bounds on their dependencies anyway.<br />
<br />
*** Until new fgl is stabilised, Hackage can set the default version of fgl to be < 6 (same as what happened with base-3 to base-4 transition, etc., thus any packages that do not have an upper bound will not be affected by cabal-install, etc.<br />
<br />
* Doesn't matter if the old fgl is still around. If the new code is better, it will be adopted on its own merits (see e.g. bytestrings vs packedstring, vector vs uvector) Let the market decide if it is better, rather than forcing us.<br />
<br />
** This is true. However, every now and then someone tries to work out what this mystical packedstring library is and tries to use it (old invalid deps, etc.).<br />
<br />
* The package has been stable for ~10 years -- why change a stable API? It is already "perfect"<br />
<br />
** As mentioned above: many people do not think that the current API is perfect.<br />
<br />
* The new package really isn't the same package in any sense.<br />
<br />
** Sure it is: we might be changing the API, but it's the same basic concepts, etc. See current status [http://code.haskell.org/FGL/fgl/Data/Graph/Inductive/Graph.hs here]<br />
<br />
* Rewrites by new teams damage the brand of famous packages (e.g. parsec 3)<br />
<br />
* No additional breakages are introduced.<br />
<br />
** Not sure what your point is here.<br />
<br />
* If you weren't maintainer of 'fgl' this rewrite wouldn't even be possible to call 'fgl' -- there's a conflict of interest.<br />
<br />
** Of course not, but I volunteered to become the maintainer of fgl precisely to modernise the interface (which as far as I know is why Martin Erwig gave fgl up for adoption: he didn't have time to make changes that people were asking him for).<br />
<br />
* Maintaining Haskell98 compatability. Keep it simple. (See regex-posix's mistakes here)<br />
<br />
** Not sure what you mean by this point; what are regix-posix's mistakes? Whilst in general I can see Haskell98 (or Haskell2010) compatability being a good thing to keep (in case someone uses another compiler, etc.) if there's a good argument to be made for why a certain extension would be useful then why shouldn't we use it? Whilst I mightn't have been working on a major Haskell library back then, it was pointed out to me a while back that you shouldn't constrain yourself by enforcing Haskell98 compatability for no reason.<br />
<br />
** Non-point: FGL is already incompatible with Haskell98 (MPTCs, etc.).<br />
<br />
* Distros that support the Haskell Platform will have to keep an old version of fgl around for a long time anyway.<br />
<br />
** I don't intend to have the new fgl be actually used by people for a while yet anyway, as I intend to get the ecosystem built up around it (fgl-algorithms, etc.) first.<br />
<br />
** I think that keeping base-3 compatibility in xmonad just to ensure that people using the Long Term Release of Ubuntu has in a sense held it back, as it was more of a pain to transition to base-4 later on than it would have been to do it earlier (using extensible-exceptions if nothing else).<br />
<br />
* The original author might not approve of the use of the name.<br />
<br />
** If this is true, then why did he publicly state in mailing lists that he wanted someone to take over?<br />
<br />
* having tutorials not work for later revisions is more confusing than having various packages doing the same thing.<br />
<br />
** The current tutorials do not fully work with the current version anyway, and we will be writing tutorials (already had one offer to help out with this).<br />
<br />
* separate names (both for the package name and module name-space) is that its easier to have both packages installed at the same time<br />
<br />
** A valid argument, especially when seeing the fall-out between mtl and transformers.<br />
<br />
*** However, that means we'd have to think of new module names as well as a new package name, and I can't think of anything better/more appropriate than "Data.Graph.Inductive".<br />
<br />
= Possible Compromises =<br />
<br />
* Until we're ready to release, either don't release fgl on Hackage or call it fgl-experimental or something.<br />
<br />
* The name "Functional Graph Library" is rather vague anyway, whereas something like "inductive-graphs" makes more sense in terms of the actual data structures, etc. involved. As such we could give the new version of the library something like that if down the track we could officially deprecate the fgl library (like how packedstring has been deprecated).<br />
<br />
* We could officially split up the fgl package namespace even further: rather than having fgl + fgl-algorithms, etc. we could have something like fgl-classes, fgl-algorithms, etc. As such the base name is kept whilst there is no ambiguity on which version is being used.</div>Ivanmhttps://wiki.haskell.org/index.php?title=Libraries/WhenToRewriteOrRename&diff=34947Libraries/WhenToRewriteOrRename2010-06-09T22:16:43Z<p>Ivanm: Add four critical issues by Duncan Coutts</p>
<hr />
<div>There have been a few cases of major API changes / rewrites to famous old<br />
packages causing problems, including:<br />
<br />
* QuickCheck 1 vs 2<br />
* parsec 2 vs 3<br />
* OpenGL<br />
* Haxml 1.13,1.19<br />
<br />
a similar opportunity is present with 'fgl', where the new maintainers<br />
are seeking to improve the code.<br />
<br />
Below I try to summarise the pros and cons of calling the new<br />
rewrite/api 'fgl', in the hope we can identify a path that minimizes<br />
disruption to users.<br />
<br />
------------------------------------------------------------------------<br />
<br />
A group of developers is planning to write a new graph library for<br />
Haskell.<br />
<br />
* They maintain an existing package called 'fgl'.<br />
* 'fgl' has a long history: http://web.engr.oregonstate.edu/~erwig/fgl/<br />
* The new library will have different authors and a different API.<br />
* They would like to call the new library 'fgl'.<br />
<br />
It is a controversial step to write a new library and give it the same<br />
name as an existing, famous library. Let's look at the arguments.<br />
<br />
Quoting Duncan Coutts on #haskell (with some formatting added): the critical issues are:<br />
<br />
1. Is the new API in the spirit of the old?<br />
<br />
2. Do you have the support of a) the previous maintainer and b) current users<br />
<br />
3. Will the new implementation actually be better?<br />
<br />
4. Will the transition be managed well?<br />
<br />
= Reasons to use the old name =<br />
<br />
* Considering the four points raised by Duncan, we believe that the first and third points are/will be met; we have plans to manage the transition and the point of the "technology preview" releases is to ensure 2. b). We have not, however, directly contacted Martin as yet.<br />
<br />
* The new code will be better, and should be preferred. Using the name 'fgl' will ensure adoption.<br />
<br />
* Rewrites are effective if the name is preserved. E.g. QuickCheck 2.<br />
<br />
* It is the maintainer's right to modify APIs as they see fit.<br />
<br />
* Keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade.<br />
<br />
* Relatively few packages use fgl. So damage is limited.<br />
<br />
* It makes development by new users simpler by not fracturing the package-space (the "Which version of QuickCheck should I use?" problem). <br />
<br />
* It decreases the maintainer workload as the same person or team will often be responsible for both packages.<br />
<br />
* A lot of respected members of the Haskell community (e.g. Cale) do not like many aspects of the current API (and thus refuse to use it) and we're taking their points of view into account.<br />
<br />
* The new version of the library is keeping the "spirit" of old fgl alive, but modernising the interface and providing new functionality (e.g. the ability to restrict the label types or use a custom Node type).<br />
<br />
* There will be a full transition guide between the old and new versions (something that was lacking for packages like QuickCheck from what I could tell).<br />
<br />
* Major version numbers exist for a reason: to denote breakage. We really need to educate developers to avoid having too lax or open-ended package dependencies.<br />
<br />
= Reasons not to use the name =<br />
<br />
* Code that depends on 'fgl' will break. There are 23 direct and 25 indirect dependencies on fgl. http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/fgl-5.4.2.2#direct<br />
<br />
** Rebuttal: <br />
<br />
*** Have contacted all maintainers of packages on Hackage which have packages without an upper bound on the version of fgl used; most have already gotten back to me saying they will release a bug-fix version to resolve this.<br />
<br />
*** With the [[Package_versioning_policy]], people should always have upper bounds on their dependencies anyway.<br />
<br />
*** Until new fgl is stabilised, Hackage can set the default version of fgl to be < 6 (same as what happened with base-3 to base-4 transition, etc., thus any packages that do not have an upper bound will not be affected by cabal-install, etc.<br />
<br />
* Doesn't matter if the old fgl is still around. If the new code is better, it will be adopted on its own merits (see e.g. bytestrings vs packedstring, vector vs uvector) Let the market decide if it is better, rather than forcing us.<br />
<br />
** This is true. However, every now and then someone tries to work out what this mystical packedstring library is and tries to use it (old invalid deps, etc.).<br />
<br />
* The package has been stable for ~10 years -- why change a stable API? It is already "perfect"<br />
<br />
** As mentioned above: many people do not think that the current API is perfect.<br />
<br />
* The new package really isn't the same package in any sense.<br />
<br />
** Sure it is: we might be changing the API, but it's the same basic concepts, etc. See current status [http://code.haskell.org/FGL/fgl/Data/Graph/Inductive/Graph.hs here]<br />
<br />
* Rewrites by new teams damage the brand of famous packages (e.g. parsec 3)<br />
<br />
* No additional breakages are introduced.<br />
<br />
** Not sure what your point is here.<br />
<br />
* If you weren't maintainer of 'fgl' this rewrite wouldn't even be possible to call 'fgl' -- there's a conflict of interest.<br />
<br />
** Of course not, but I volunteered to become the maintainer of fgl precisely to modernise the interface (which as far as I know is why Martin Erwig gave fgl up for adoption: he didn't have time to make changes that people were asking him for).<br />
<br />
* Maintaining Haskell98 compatability. Keep it simple. (See regex-posix's mistakes here)<br />
<br />
** Not sure what you mean by this point; what are regix-posix's mistakes? Whilst in general I can see Haskell98 (or Haskell2010) compatability being a good thing to keep (in case someone uses another compiler, etc.) if there's a good argument to be made for why a certain extension would be useful then why shouldn't we use it? Whilst I mightn't have been working on a major Haskell library back then, it was pointed out to me a while back that you shouldn't constrain yourself by enforcing Haskell98 compatability for no reason.<br />
<br />
* Distros that support the Haskell Platform will have to keep an old version of fgl around for a long time anyway.<br />
<br />
** I don't intend to have the new fgl be actually used by people for a while yet anyway, as I intend to get the ecosystem built up around it (fgl-algorithms, etc.) first.<br />
<br />
** I think that keeping base-3 compatibility in xmonad just to ensure that people using the Long Term Release of Ubuntu has in a sense held it back, as it was more of a pain to transition to base-4 later on than it would have been to do it earlier (using extensible-exceptions if nothing else).<br />
<br />
* The original author might not approve of the use of the name.<br />
<br />
** If this is true, then why did he publicly state in mailing lists that he wanted someone to take over?<br />
<br />
* having tutorials not work for later revisions is more confusing than having various packages doing the same thing.<br />
<br />
** The current tutorials do not fully work with the current version anyway, and we will be writing tutorials (already had one offer to help out with this).<br />
<br />
* separate names (both for the package name and module name-space) is that its easier to have both packages installed at the same time<br />
<br />
** A valid argument, especially when seeing the fall-out between mtl and transformers.<br />
<br />
*** However, that means we'd have to think of new module names as well as a new package name, and I can't think of anything better/more appropriate than "Data.Graph.Inductive".<br />
<br />
= Possible Compromises =<br />
<br />
* Until we're ready to release, either don't release fgl on Hackage or call it fgl-experimental or something.<br />
<br />
* The name "Functional Graph Library" is rather vague anyway, whereas something like "inductive-graphs" makes more sense in terms of the actual data structures, etc. involved. As such we could give the new version of the library something like that if down the track we could officially deprecate the fgl library (like how packedstring has been deprecated).<br />
<br />
* We could officially split up the fgl package namespace even further: rather than having fgl + fgl-algorithms, etc. we could have something like fgl-classes, fgl-algorithms, etc. As such the base name is kept whilst there is no ambiguity on which version is being used.</div>Ivanmhttps://wiki.haskell.org/index.php?title=Libraries/WhenToRewriteOrRename&diff=34939Libraries/WhenToRewriteOrRename2010-06-09T11:34:32Z<p>Ivanm: /* Reasons not to use the name */ Comment on module namespacing between versions</p>
<hr />
<div>There have been a few cases of major API changes / rewrites to famous old<br />
packages causing problems, including:<br />
<br />
* QuickCheck 1 vs 2<br />
* parsec 2 vs 3<br />
* OpenGL<br />
* Haxml 1.13,1.19<br />
<br />
a similar opportunity is present with 'fgl', where the new maintainers<br />
are seeking to improve the code.<br />
<br />
Below I try to summarise the pros and cons of calling the new<br />
rewrite/api 'fgl', in the hope we can identify a path that minimizes<br />
disruption to users.<br />
<br />
------------------------------------------------------------------------<br />
<br />
A group of developers is planning to write a new graph library for<br />
Haskell.<br />
<br />
* They maintain an existing package called 'fgl'.<br />
* 'fgl' has a long history: http://web.engr.oregonstate.edu/~erwig/fgl/<br />
* The new library will have different authors and a different API.<br />
* They would like to call the new library 'fgl'.<br />
<br />
It is a controversial step to write a new library and give it the same<br />
name as an existing, famous library. Let's look at the arguments.<br />
<br />
= Reasons to use the old name =<br />
<br />
* The new code will be better, and should be preferred. Using the name 'fgl' will ensure adoption.<br />
<br />
* Rewrites are effective if the name is preserved. E.g. QuickCheck 2.<br />
<br />
* It is the maintainer's right to modify APIs as they see fit.<br />
<br />
* Keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade.<br />
<br />
* Relatively few packages use fgl. So damage is limited.<br />
<br />
* It makes development by new users simpler by not fracturing the package-space (the "Which version of QuickCheck should I use?" problem). <br />
<br />
* It decreases the maintainer workload as the same person or team will often be responsible for both packages.<br />
<br />
* A lot of respected members of the Haskell community (e.g. Cale) do not like many aspects of the current API (and thus refuse to use it) and we're taking their points of view into account.<br />
<br />
* The new version of the library is keeping the "spirit" of old fgl alive, but modernising the interface and providing new functionality (e.g. the ability to restrict the label types or use a custom Node type).<br />
<br />
* There will be a full transition guide between the old and new versions (something that was lacking for packages like QuickCheck from what I could tell).<br />
<br />
* Major version numbers exist for a reason: to denote breakage. We really need to educate developers to avoid having too lax or open-ended package dependencies.<br />
<br />
= Reasons not to use the name =<br />
<br />
* Code that depends on 'fgl' will break. There are 23 direct and 25 indirect dependencies on fgl. http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/fgl-5.4.2.2#direct<br />
<br />
** Rebuttal: <br />
<br />
*** Have contacted all maintainers of packages on Hackage which have packages without an upper bound on the version of fgl used; most have already gotten back to me saying they will release a bug-fix version to resolve this.<br />
<br />
*** With the [[Package_versioning_policy]], people should always have upper bounds on their dependencies anyway.<br />
<br />
*** Until new fgl is stabilised, Hackage can set the default version of fgl to be < 6 (same as what happened with base-3 to base-4 transition, etc., thus any packages that do not have an upper bound will not be affected by cabal-install, etc.<br />
<br />
* Doesn't matter if the old fgl is still around. If the new code is better, it will be adopted on its own merits (see e.g. bytestrings vs packedstring, vector vs uvector) Let the market decide if it is better, rather than forcing us.<br />
<br />
** This is true. However, every now and then someone tries to work out what this mystical packedstring library is and tries to use it (old invalid deps, etc.).<br />
<br />
* The package has been stable for ~10 years -- why change a stable API? It is already "perfect"<br />
<br />
** As mentioned above: many people do not think that the current API is perfect.<br />
<br />
* The new package really isn't the same package in any sense.<br />
<br />
** Sure it is: we might be changing the API, but it's the same basic concepts, etc. See current status [http://code.haskell.org/FGL/fgl/Data/Graph/Inductive/Graph.hs here]<br />
<br />
* Rewrites by new teams damage the brand of famous packages (e.g. parsec 3)<br />
<br />
* No additional breakages are introduced.<br />
<br />
** Not sure what your point is here.<br />
<br />
* If you weren't maintainer of 'fgl' this rewrite wouldn't even be possible to call 'fgl' -- there's a conflict of interest.<br />
<br />
** Of course not, but I volunteered to become the maintainer of fgl precisely to modernise the interface (which as far as I know is why Martin Erwig gave fgl up for adoption: he didn't have time to make changes that people were asking him for).<br />
<br />
* Maintaining Haskell98 compatability. Keep it simple. (See regex-posix's mistakes here)<br />
<br />
** Not sure what you mean by this point; what are regix-posix's mistakes? Whilst in general I can see Haskell98 (or Haskell2010) compatability being a good thing to keep (in case someone uses another compiler, etc.) if there's a good argument to be made for why a certain extension would be useful then why shouldn't we use it? Whilst I mightn't have been working on a major Haskell library back then, it was pointed out to me a while back that you shouldn't constrain yourself by enforcing Haskell98 compatability for no reason.<br />
<br />
* Distros that support the Haskell Platform will have to keep an old version of fgl around for a long time anyway.<br />
<br />
** I don't intend to have the new fgl be actually used by people for a while yet anyway, as I intend to get the ecosystem built up around it (fgl-algorithms, etc.) first.<br />
<br />
** I think that keeping base-3 compatibility in xmonad just to ensure that people using the Long Term Release of Ubuntu has in a sense held it back, as it was more of a pain to transition to base-4 later on than it would have been to do it earlier (using extensible-exceptions if nothing else).<br />
<br />
* The original author might not approve of the use of the name.<br />
<br />
** If this is true, then why did he publicly state in mailing lists that he wanted someone to take over?<br />
<br />
* having tutorials not work for later revisions is more confusing than having various packages doing the same thing.<br />
<br />
** The current tutorials do not fully work with the current version anyway, and we will be writing tutorials (already had one offer to help out with this).<br />
<br />
* separate names (both for the package name and module name-space) is that its easier to have both packages installed at the same time<br />
<br />
** A valid argument, especially when seeing the fall-out between mtl and transformers.<br />
<br />
*** However, that means we'd have to think of new module names as well as a new package name, and I can't think of anything better/more appropriate than "Data.Graph.Inductive".<br />
<br />
= Possible Compromises =<br />
<br />
* Until we're ready to release, either don't release fgl on Hackage or call it fgl-experimental or something.<br />
<br />
* The name "Functional Graph Library" is rather vague anyway, whereas something like "inductive-graphs" makes more sense in terms of the actual data structures, etc. involved. As such we could give the new version of the library something like that if down the track we could officially deprecate the fgl library (like how packedstring has been deprecated).<br />
<br />
* We could officially split up the fgl package namespace even further: rather than having fgl + fgl-algorithms, etc. we could have something like fgl-classes, fgl-algorithms, etc. As such the base name is kept whilst there is no ambiguity on which version is being used.</div>Ivanmhttps://wiki.haskell.org/index.php?title=Libraries/WhenToRewriteOrRename&diff=34933Libraries/WhenToRewriteOrRename2010-06-09T10:37:41Z<p>Ivanm: Another case where I had accidentally added an extra * to one of the existing points</p>
<hr />
<div>There have been a few cases of major API changes / rewrites to famous old<br />
packages causing problems, including:<br />
<br />
* QuickCheck 1 vs 2<br />
* parsec 2 vs 3<br />
* OpenGL<br />
* Haxml 1.13,1.19<br />
<br />
a similar opportunity is present with 'fgl', where the new maintainers<br />
are seeking to improve the code.<br />
<br />
Below I try to summarise the pros and cons of calling the new<br />
rewrite/api 'fgl', in the hope we can identify a path that minimizes<br />
disruption to users.<br />
<br />
------------------------------------------------------------------------<br />
<br />
A group of developers is planning to write a new graph library for<br />
Haskell.<br />
<br />
* They maintain an existing package called 'fgl'.<br />
* 'fgl' has a long history: http://web.engr.oregonstate.edu/~erwig/fgl/<br />
* The new library will have different authors and a different API.<br />
* They would like to call the new library 'fgl'.<br />
<br />
It is a controversial step to write a new library and give it the same<br />
name as an existing, famous library. Let's look at the arguments.<br />
<br />
= Reasons to use the old name =<br />
<br />
* The new code will be better, and should be preferred. Using the name 'fgl' will ensure adoption.<br />
<br />
* Rewrites are effective if the name is preserved. E.g. QuickCheck 2.<br />
<br />
* It is the maintainer's right to modify APIs as they see fit.<br />
<br />
* Keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade.<br />
<br />
* Relatively few packages use fgl. So damage is limited.<br />
<br />
* It makes development by new users simpler by not fracturing the package-space (the "Which version of QuickCheck should I use?" problem). <br />
<br />
* It decreases the maintainer workload as the same person or team will often be responsible for both packages.<br />
<br />
* A lot of respected members of the Haskell community (e.g. Cale) do not like many aspects of the current API (and thus refuse to use it) and we're taking their points of view into account.<br />
<br />
* The new version of the library is keeping the "spirit" of old fgl alive, but modernising the interface and providing new functionality (e.g. the ability to restrict the label types or use a custom Node type).<br />
<br />
* There will be a full transition guide between the old and new versions (something that was lacking for packages like QuickCheck from what I could tell).<br />
<br />
* Major version numbers exist for a reason: to denote breakage. We really need to educate developers to avoid having too lax or open-ended package dependencies.<br />
<br />
= Reasons not to use the name =<br />
<br />
* Code that depends on 'fgl' will break. There are 23 direct and 25 indirect dependencies on fgl. http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/fgl-5.4.2.2#direct<br />
<br />
** Rebuttal: <br />
<br />
*** Have contacted all maintainers of packages on Hackage which have packages without an upper bound on the version of fgl used; most have already gotten back to me saying they will release a bug-fix version to resolve this.<br />
<br />
*** With the [[Package_versioning_policy]], people should always have upper bounds on their dependencies anyway.<br />
<br />
*** Until new fgl is stabilised, Hackage can set the default version of fgl to be < 6 (same as what happened with base-3 to base-4 transition, etc., thus any packages that do not have an upper bound will not be affected by cabal-install, etc.<br />
<br />
* Doesn't matter if the old fgl is still around. If the new code is better, it will be adopted on its own merits (see e.g. bytestrings vs packedstring, vector vs uvector) Let the market decide if it is better, rather than forcing us.<br />
<br />
** This is true. However, every now and then someone tries to work out what this mystical packedstring library is and tries to use it (old invalid deps, etc.).<br />
<br />
* The package has been stable for ~10 years -- why change a stable API? It is already "perfect"<br />
<br />
** As mentioned above: many people do not think that the current API is perfect.<br />
<br />
* The new package really isn't the same package in any sense.<br />
<br />
** Sure it is: we might be changing the API, but it's the same basic concepts, etc. See current status [http://code.haskell.org/FGL/fgl/Data/Graph/Inductive/Graph.hs here]<br />
<br />
* Rewrites by new teams damage the brand of famous packages (e.g. parsec 3)<br />
<br />
* No additional breakages are introduced.<br />
<br />
** Not sure what your point is here.<br />
<br />
* If you weren't maintainer of 'fgl' this rewrite wouldn't even be possible to call 'fgl' -- there's a conflict of interest.<br />
<br />
** Of course not, but I volunteered to become the maintainer of fgl precisely to modernise the interface (which as far as I know is why Martin Erwig gave fgl up for adoption: he didn't have time to make changes that people were asking him for).<br />
<br />
* Maintaining Haskell98 compatability. Keep it simple. (See regex-posix's mistakes here)<br />
<br />
** Not sure what you mean by this point; what are regix-posix's mistakes? Whilst in general I can see Haskell98 (or Haskell2010) compatability being a good thing to keep (in case someone uses another compiler, etc.) if there's a good argument to be made for why a certain extension would be useful then why shouldn't we use it? Whilst I mightn't have been working on a major Haskell library back then, it was pointed out to me a while back that you shouldn't constrain yourself by enforcing Haskell98 compatability for no reason.<br />
<br />
* Distros that support the Haskell Platform will have to keep an old version of fgl around for a long time anyway.<br />
<br />
** I don't intend to have the new fgl be actually used by people for a while yet anyway, as I intend to get the ecosystem built up around it (fgl-algorithms, etc.) first.<br />
<br />
** I think that keeping base-3 compatibility in xmonad just to ensure that people using the Long Term Release of Ubuntu has in a sense held it back, as it was more of a pain to transition to base-4 later on than it would have been to do it earlier (using extensible-exceptions if nothing else).<br />
<br />
* The original author might not approve of the use of the name.<br />
<br />
** If this is true, then why did he publicly state in mailing lists that he wanted someone to take over?<br />
<br />
* having tutorials not work for later revisions is more confusing than having various packages doing the same thing.<br />
<br />
** The current tutorials do not fully work with the current version anyway, and we will be writing tutorials (already had one offer to help out with this).<br />
<br />
* separate names (both for the package name and module name-space) is that its easier to have both packages installed at the same time<br />
<br />
** A valid argument, especially when seeing the fall-out between mtl and transformers.<br />
<br />
= Possible Compromises =<br />
<br />
* Until we're ready to release, either don't release fgl on Hackage or call it fgl-experimental or something.<br />
<br />
* The name "Functional Graph Library" is rather vague anyway, whereas something like "inductive-graphs" makes more sense in terms of the actual data structures, etc. involved. As such we could give the new version of the library something like that if down the track we could officially deprecate the fgl library (like how packedstring has been deprecated).<br />
<br />
* We could officially split up the fgl package namespace even further: rather than having fgl + fgl-algorithms, etc. we could have something like fgl-classes, fgl-algorithms, etc. As such the base name is kept whilst there is no ambiguity on which version is being used.</div>Ivanmhttps://wiki.haskell.org/index.php?title=Libraries/WhenToRewriteOrRename&diff=34932Libraries/WhenToRewriteOrRename2010-06-09T10:35:02Z<p>Ivanm: Pro-keep argument about major versions</p>
<hr />
<div>There have been a few cases of major API changes / rewrites to famous old<br />
packages causing problems, including:<br />
<br />
* QuickCheck 1 vs 2<br />
* parsec 2 vs 3<br />
* OpenGL<br />
* Haxml 1.13,1.19<br />
<br />
a similar opportunity is present with 'fgl', where the new maintainers<br />
are seeking to improve the code.<br />
<br />
Below I try to summarise the pros and cons of calling the new<br />
rewrite/api 'fgl', in the hope we can identify a path that minimizes<br />
disruption to users.<br />
<br />
------------------------------------------------------------------------<br />
<br />
A group of developers is planning to write a new graph library for<br />
Haskell.<br />
<br />
* They maintain an existing package called 'fgl'.<br />
* 'fgl' has a long history: http://web.engr.oregonstate.edu/~erwig/fgl/<br />
* The new library will have different authors and a different API.<br />
* They would like to call the new library 'fgl'.<br />
<br />
It is a controversial step to write a new library and give it the same<br />
name as an existing, famous library. Let's look at the arguments.<br />
<br />
= Reasons to use the old name =<br />
<br />
* The new code will be better, and should be preferred. Using the name 'fgl' will ensure adoption.<br />
<br />
* Rewrites are effective if the name is preserved. E.g. QuickCheck 2.<br />
<br />
* It is the maintainer's right to modify APIs as they see fit.<br />
<br />
* Keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade.<br />
<br />
* Relatively few packages use fgl. So damage is limited.<br />
<br />
* It makes development by new users simpler by not fracturing the package-space (the "Which version of QuickCheck should I use?" problem). <br />
<br />
* It decreases the maintainer workload as the same person or team will often be responsible for both packages.<br />
<br />
* A lot of respected members of the Haskell community (e.g. Cale) do not like many aspects of the current API (and thus refuse to use it) and we're taking their points of view into account.<br />
<br />
* The new version of the library is keeping the "spirit" of old fgl alive, but modernising the interface and providing new functionality (e.g. the ability to restrict the label types or use a custom Node type).<br />
<br />
* There will be a full transition guide between the old and new versions (something that was lacking for packages like QuickCheck from what I could tell).<br />
<br />
* Major version numbers exist for a reason: to denote breakage. We really need to educate developers to avoid having too lax or open-ended package dependencies.<br />
<br />
= Reasons not to use the name =<br />
<br />
* Code that depends on 'fgl' will break. There are 23 direct and 25 indirect dependencies on fgl. http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/fgl-5.4.2.2#direct<br />
<br />
** Rebuttal: <br />
<br />
*** Have contacted all maintainers of packages on Hackage which have packages without an upper bound on the version of fgl used; most have already gotten back to me saying they will release a bug-fix version to resolve this.<br />
<br />
*** With the [[Package_versioning_policy]], people should always have upper bounds on their dependencies anyway.<br />
<br />
*** Until new fgl is stabilised, Hackage can set the default version of fgl to be < 6 (same as what happened with base-3 to base-4 transition, etc., thus any packages that do not have an upper bound will not be affected by cabal-install, etc.<br />
<br />
* Doesn't matter if the old fgl is still around. If the new code is better, it will be adopted on its own merits (see e.g. bytestrings vs packedstring, vector vs uvector) Let the market decide if it is better, rather than forcing us.<br />
<br />
** This is true. However, every now and then someone tries to work out what this mystical packedstring library is and tries to use it (old invalid deps, etc.).<br />
<br />
* The package has been stable for ~10 years -- why change a stable API? It is already "perfect"<br />
<br />
** As mentioned above: many people do not think that the current API is perfect.<br />
<br />
* The new package really isn't the same package in any sense.<br />
<br />
** Sure it is: we might be changing the API, but it's the same basic concepts, etc. See current status [http://code.haskell.org/FGL/fgl/Data/Graph/Inductive/Graph.hs here]<br />
<br />
* Rewrites by new teams damage the brand of famous packages (e.g. parsec 3)<br />
<br />
* No additional breakages are introduced.<br />
<br />
** Not sure what your point is here.<br />
<br />
* If you weren't maintainer of 'fgl' this rewrite wouldn't even be possible to call 'fgl' -- there's a conflict of interest.<br />
<br />
** Of course not, but I volunteered to become the maintainer of fgl precisely to modernise the interface (which as far as I know is why Martin Erwig gave fgl up for adoption: he didn't have time to make changes that people were asking him for).<br />
<br />
* Maintaining Haskell98 compatability. Keep it simple. (See regex-posix's mistakes here)<br />
<br />
** Not sure what you mean by this point; what are regix-posix's mistakes? Whilst in general I can see Haskell98 (or Haskell2010) compatability being a good thing to keep (in case someone uses another compiler, etc.) if there's a good argument to be made for why a certain extension would be useful then why shouldn't we use it? Whilst I mightn't have been working on a major Haskell library back then, it was pointed out to me a while back that you shouldn't constrain yourself by enforcing Haskell98 compatability for no reason.<br />
<br />
* Distros that support the Haskell Platform will have to keep an old version of fgl around for a long time anyway.<br />
<br />
** I don't intend to have the new fgl be actually used by people for a while yet anyway, as I intend to get the ecosystem built up around it (fgl-algorithms, etc.) first.<br />
<br />
** I think that keeping base-3 compatibility in xmonad just to ensure that people using the Long Term Release of Ubuntu has in a sense held it back, as it was more of a pain to transition to base-4 later on than it would have been to do it earlier (using extensible-exceptions if nothing else).<br />
<br />
* The original author might not approve of the use of the name.<br />
<br />
** If this is true, then why did he publicly state in mailing lists that he wanted someone to take over?<br />
<br />
* having tutorials not work for later revisions is more confusing than having various packages doing the same thing.<br />
<br />
** The current tutorials do not fully work with the current version anyway, and we will be writing tutorials (already had one offer to help out with this).<br />
<br />
** separate names (both for the package name and module name-space) is that its easier to have both packages installed at the same time<br />
<br />
** A valid argument, especially when seeing the fall-out between mtl and transformers.<br />
<br />
= Possible Compromises =<br />
<br />
* Until we're ready to release, either don't release fgl on Hackage or call it fgl-experimental or something.<br />
<br />
* The name "Functional Graph Library" is rather vague anyway, whereas something like "inductive-graphs" makes more sense in terms of the actual data structures, etc. involved. As such we could give the new version of the library something like that if down the track we could officially deprecate the fgl library (like how packedstring has been deprecated).<br />
<br />
* We could officially split up the fgl package namespace even further: rather than having fgl + fgl-algorithms, etc. we could have something like fgl-classes, fgl-algorithms, etc. As such the base name is kept whilst there is no ambiguity on which version is being used.</div>Ivanmhttps://wiki.haskell.org/index.php?title=Libraries/WhenToRewriteOrRename&diff=34931Libraries/WhenToRewriteOrRename2010-06-09T10:33:34Z<p>Ivanm: Clean up some formatting problems with bullet points</p>
<hr />
<div>There have been a few cases of major API changes / rewrites to famous old<br />
packages causing problems, including:<br />
<br />
* QuickCheck 1 vs 2<br />
* parsec 2 vs 3<br />
* OpenGL<br />
* Haxml 1.13,1.19<br />
<br />
a similar opportunity is present with 'fgl', where the new maintainers<br />
are seeking to improve the code.<br />
<br />
Below I try to summarise the pros and cons of calling the new<br />
rewrite/api 'fgl', in the hope we can identify a path that minimizes<br />
disruption to users.<br />
<br />
------------------------------------------------------------------------<br />
<br />
A group of developers is planning to write a new graph library for<br />
Haskell.<br />
<br />
* They maintain an existing package called 'fgl'.<br />
* 'fgl' has a long history: http://web.engr.oregonstate.edu/~erwig/fgl/<br />
* The new library will have different authors and a different API.<br />
* They would like to call the new library 'fgl'.<br />
<br />
It is a controversial step to write a new library and give it the same<br />
name as an existing, famous library. Let's look at the arguments.<br />
<br />
= Reasons to use the old name =<br />
<br />
* The new code will be better, and should be preferred. Using the name 'fgl' will ensure adoption.<br />
<br />
* Rewrites are effective if the name is preserved. E.g. QuickCheck 2.<br />
<br />
* It is the maintainer's right to modify APIs as they see fit.<br />
<br />
* Keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade.<br />
<br />
* Relatively few packages use fgl. So damage is limited.<br />
<br />
* It makes development by new users simpler by not fracturing the package-space (the "Which version of QuickCheck should I use?" problem). <br />
<br />
* It decreases the maintainer workload as the same person or team will often be responsible for both packages.<br />
<br />
* A lot of respected members of the Haskell community (e.g. Cale) do not like many aspects of the current API (and thus refuse to use it) and we're taking their points of view into account.<br />
<br />
* The new version of the library is keeping the "spirit" of old fgl alive, but modernising the interface and providing new functionality (e.g. the ability to restrict the label types or use a custom Node type).<br />
<br />
* There will be a full transition guide between the old and new versions (something that was lacking for packages like QuickCheck from what I could tell).<br />
<br />
= Reasons not to use the name =<br />
<br />
* Code that depends on 'fgl' will break. There are 23 direct and 25 indirect dependencies on fgl. http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/fgl-5.4.2.2#direct<br />
<br />
** Rebuttal: <br />
<br />
*** Have contacted all maintainers of packages on Hackage which have packages without an upper bound on the version of fgl used; most have already gotten back to me saying they will release a bug-fix version to resolve this.<br />
<br />
*** With the [[Package_versioning_policy]], people should always have upper bounds on their dependencies anyway.<br />
<br />
*** Until new fgl is stabilised, Hackage can set the default version of fgl to be < 6 (same as what happened with base-3 to base-4 transition, etc., thus any packages that do not have an upper bound will not be affected by cabal-install, etc.<br />
<br />
* Doesn't matter if the old fgl is still around. If the new code is better, it will be adopted on its own merits (see e.g. bytestrings vs packedstring, vector vs uvector) Let the market decide if it is better, rather than forcing us.<br />
<br />
** This is true. However, every now and then someone tries to work out what this mystical packedstring library is and tries to use it (old invalid deps, etc.).<br />
<br />
* The package has been stable for ~10 years -- why change a stable API? It is already "perfect"<br />
<br />
** As mentioned above: many people do not think that the current API is perfect.<br />
<br />
* The new package really isn't the same package in any sense.<br />
<br />
** Sure it is: we might be changing the API, but it's the same basic concepts, etc. See current status [http://code.haskell.org/FGL/fgl/Data/Graph/Inductive/Graph.hs here]<br />
<br />
* Rewrites by new teams damage the brand of famous packages (e.g. parsec 3)<br />
<br />
* No additional breakages are introduced.<br />
<br />
** Not sure what your point is here.<br />
<br />
* If you weren't maintainer of 'fgl' this rewrite wouldn't even be possible to call 'fgl' -- there's a conflict of interest.<br />
<br />
** Of course not, but I volunteered to become the maintainer of fgl precisely to modernise the interface (which as far as I know is why Martin Erwig gave fgl up for adoption: he didn't have time to make changes that people were asking him for).<br />
<br />
* Maintaining Haskell98 compatability. Keep it simple. (See regex-posix's mistakes here)<br />
<br />
** Not sure what you mean by this point; what are regix-posix's mistakes? Whilst in general I can see Haskell98 (or Haskell2010) compatability being a good thing to keep (in case someone uses another compiler, etc.) if there's a good argument to be made for why a certain extension would be useful then why shouldn't we use it? Whilst I mightn't have been working on a major Haskell library back then, it was pointed out to me a while back that you shouldn't constrain yourself by enforcing Haskell98 compatability for no reason.<br />
<br />
* Distros that support the Haskell Platform will have to keep an old version of fgl around for a long time anyway.<br />
<br />
** I don't intend to have the new fgl be actually used by people for a while yet anyway, as I intend to get the ecosystem built up around it (fgl-algorithms, etc.) first.<br />
<br />
** I think that keeping base-3 compatibility in xmonad just to ensure that people using the Long Term Release of Ubuntu has in a sense held it back, as it was more of a pain to transition to base-4 later on than it would have been to do it earlier (using extensible-exceptions if nothing else).<br />
<br />
* The original author might not approve of the use of the name.<br />
<br />
** If this is true, then why did he publicly state in mailing lists that he wanted someone to take over?<br />
<br />
* having tutorials not work for later revisions is more confusing than having various packages doing the same thing.<br />
<br />
** The current tutorials do not fully work with the current version anyway, and we will be writing tutorials (already had one offer to help out with this).<br />
<br />
** separate names (both for the package name and module name-space) is that its easier to have both packages installed at the same time<br />
<br />
** A valid argument, especially when seeing the fall-out between mtl and transformers.<br />
<br />
= Possible Compromises =<br />
<br />
* Until we're ready to release, either don't release fgl on Hackage or call it fgl-experimental or something.<br />
<br />
* The name "Functional Graph Library" is rather vague anyway, whereas something like "inductive-graphs" makes more sense in terms of the actual data structures, etc. involved. As such we could give the new version of the library something like that if down the track we could officially deprecate the fgl library (like how packedstring has been deprecated).<br />
<br />
* We could officially split up the fgl package namespace even further: rather than having fgl + fgl-algorithms, etc. we could have something like fgl-classes, fgl-algorithms, etc. As such the base name is kept whilst there is no ambiguity on which version is being used.</div>Ivanmhttps://wiki.haskell.org/index.php?title=Libraries/WhenToRewriteOrRename&diff=34927Libraries/WhenToRewriteOrRename2010-06-09T00:28:26Z<p>Ivanm: Accidentally added another * to one of the main points.</p>
<hr />
<div>There have been a few cases of major API changes / rewrites to famous old<br />
packages causing problems, including:<br />
<br />
* QuickCheck 1 vs 2<br />
* parsec 2 vs 3<br />
* OpenGL<br />
* Haxml 1.13,1.19<br />
<br />
a similar opportunity is present with 'fgl', where the new maintainers<br />
are seeking to improve the code.<br />
<br />
Below I try to summarise the pros and cons of calling the new<br />
rewrite/api 'fgl', in the hope we can identify a path that minimizes<br />
disruption to users.<br />
<br />
------------------------------------------------------------------------<br />
<br />
A group of developers is planning to write a new graph library for<br />
Haskell.<br />
<br />
* They maintain an existing package called 'fgl'.<br />
* 'fgl' has a long history: http://web.engr.oregonstate.edu/~erwig/fgl/<br />
* The new library will have different authors and a different API.<br />
* They would like to call the new library 'fgl'.<br />
<br />
It is a controversial step to write a new library and give it the same<br />
name as an existing, famous library. Let's look at the arguments.<br />
<br />
= Reasons to use the old name =<br />
<br />
* The new code will be better, and should be preferred. Using the name 'fgl' will ensure adoption.<br />
<br />
* Rewrites are effective if the name is preserved. E.g. QuickCheck 2.<br />
<br />
* It is the maintainer's right to modify APIs as they see fit.<br />
<br />
* Keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade.<br />
<br />
* Relatively few packages use fgl. So damage is limited.<br />
<br />
* It makes development by new users simpler by not fracturing the<br />
package-space (the "Which version of QuickCheck should I use?"<br />
problem). <br />
<br />
* It decreases the maintainer workload as the same person or team will<br />
often be responsible for both packages.<br />
<br />
* A lot of respected members of the Haskell community (e.g. Cale) do not like many aspects of the current API (and thus refuse to use it) and we're taking their points of view into account.<br />
<br />
* The new version of the library is keeping the "spirit" of old fgl alive, but modernising the interface and providing new functionality (e.g. the ability to restrict the label types or use a custom Node type).<br />
<br />
* There will be a full transition guide between the old and new versions (something that was lacking for packages like QuickCheck from what I could tell).<br />
<br />
= Reasons not to use the name =<br />
<br />
* Code that depends on 'fgl' will break. There are 23 direct and 25 indirect dependencies on fgl. http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/fgl-5.4.2.2#direct<br />
<br />
** Rebuttal: <br />
<br />
*** Have contacted all maintainers of packages on Hackage which have packages without an upper bound on the version of fgl used; most have already gotten back to me saying they will release a bug-fix version to resolve this.<br />
<br />
*** With the [[Package_versioning_policy]], people should always have upper bounds on their dependencies anyway.<br />
<br />
*** Until new fgl is stabilised, Hackage can set the default version of fgl to be < 6 (same as what happened with base-3 to base-4 transition, etc., thus any packages that do not have an upper bound will not be affected by cabal-install, etc.<br />
<br />
* Doesn't matter if the old fgl is still around. If the new code is<br />
better, it will be adopted on its own merits (see e.g.<br />
bytestrings vs packedstring, vector vs uvector)<br />
Let the market decide if it is better, rather than forcing us.<br />
<br />
** This is true. However, every now and then someone tries to work out what this mystical packedstring library is and tries to use it (old invalid deps, etc.).<br />
<br />
* The package has been stable for ~10 years -- why change a stable API? It is already "perfect"<br />
<br />
** As mentioned above: many people do not think that the current API is perfect.<br />
<br />
* The new package really isn't the same package in any sense.<br />
<br />
** Sure it is: we might be changing the API, but it's the same basic concepts, etc. See current status [http://code.haskell.org/FGL/fgl/Data/Graph/Inductive/Graph.hs here]<br />
<br />
* Rewrites by new teams damage the brand of famous packages (e.g. parsec 3)<br />
<br />
* No additional breakages are introduced.<br />
<br />
** Not sure what your point is here.<br />
<br />
* If you weren't maintainer of 'fgl' this rewrite wouldn't even be possible to call 'fgl' -- there's a conflict of interest.<br />
<br />
** Of course not, but I volunteered to become the maintainer of fgl precisely to modernise the interface (which as far as I know is why Martin Erwig gave fgl up for adoption: he didn't have time to make changes that people were asking him for).<br />
<br />
* Maintaining Haskell98 compatability. Keep it simple. (See regex-posix's mistakes here)<br />
<br />
** Not sure what you mean by this point; what are regix-posix's mistakes? Whilst in general I can see Haskell98 (or Haskell2010) compatability being a good thing to keep (in case someone uses another compiler, etc.) if there's a good argument to be made for why a certain extension would be useful then why shouldn't we use it? Whilst I mightn't have been working on a major Haskell library back then, it was pointed out to me a while back that you shouldn't constrain yourself by enforcing Haskell98 compatability for no reason.<br />
<br />
* Distros that support the Haskell Platform will have to keep an old version of fgl around for a long time anyway.<br />
<br />
** I don't intend to have the new fgl be actually used by people for a while yet anyway, as I intend to get the ecosystem built up around it (fgl-algorithms, etc.) first.<br />
<br />
** I think that keeping base-3 compatibility in xmonad just to ensure that people using the Long Term Release of Ubuntu has in a sense held it back, as it was more of a pain to transition to base-4 later on than it would have been to do it earlier (using extensible-exceptions if nothing else).<br />
<br />
* The original author might not approve of the use of the name.<br />
<br />
** If this is true, then why did he publicly state in mailing lists that he wanted someone to take over?<br />
<br />
* having tutorials not work for later revisions is more confusing than having various packages doing the same thing.<br />
<br />
** The current tutorials do not fully work with the current version anyway, and we will be writing tutorials (already had one offer to help out with this).<br />
<br />
** separate names (both for the package name and module name-space) is that its easier to have both packages installed at the same time<br />
<br />
** A valid argument, especially when seeing the fall-out between mtl and transformers.<br />
<br />
= Possible Compromises =<br />
<br />
* Until we're ready to release, either don't release fgl on Hackage or call it fgl-experimental or something.<br />
<br />
* The name "Functional Graph Library" is rather vague anyway, whereas something like "inductive-graphs" makes more sense in terms of the actual data structures, etc. involved. As such we could give the new version of the library something like that if down the track we could officially deprecate the fgl library (like how packedstring has been deprecated).<br />
<br />
* We could officially split up the fgl package namespace even further: rather than having fgl + fgl-algorithms, etc. we could have something like fgl-classes, fgl-algorithms, etc. As such the base name is kept whilst there is no ambiguity on which version is being used.</div>Ivanmhttps://wiki.haskell.org/index.php?title=Libraries/WhenToRewriteOrRename&diff=34925Libraries/WhenToRewriteOrRename2010-06-08T21:52:05Z<p>Ivanm: My thoughts and views on the fgl rewrite naming dispute.</p>
<hr />
<div>There have been a few cases of major API changes / rewrites to famous old<br />
packages causing problems, including:<br />
<br />
* QuickCheck 1 vs 2<br />
* parsec 2 vs 3<br />
* OpenGL<br />
* Haxml 1.13,1.19<br />
<br />
a similar opportunity is present with 'fgl', where the new maintainers<br />
are seeking to improve the code.<br />
<br />
Below I try to summarise the pros and cons of calling the new<br />
rewrite/api 'fgl', in the hope we can identify a path that minimizes<br />
disruption to users.<br />
<br />
------------------------------------------------------------------------<br />
<br />
A group of developers is planning to write a new graph library for<br />
Haskell.<br />
<br />
* They maintain an existing package called 'fgl'.<br />
* 'fgl' has a long history: http://web.engr.oregonstate.edu/~erwig/fgl/<br />
* The new library will have different authors and a different API.<br />
* They would like to call the new library 'fgl'.<br />
<br />
It is a controversial step to write a new library and give it the same<br />
name as an existing, famous library. Let's look at the arguments.<br />
<br />
= Reasons to use the old name =<br />
<br />
* The new code will be better, and should be preferred. Using the name 'fgl' will ensure adoption.<br />
<br />
* Rewrites are effective if the name is preserved. E.g. QuickCheck 2.<br />
<br />
* It is the maintainer's right to modify APIs as they see fit.<br />
<br />
* Keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade.<br />
<br />
* Relatively few packages use fgl. So damage is limited.<br />
<br />
* It makes development by new users simpler by not fracturing the<br />
package-space (the "Which version of QuickCheck should I use?"<br />
problem). <br />
<br />
* It decreases the maintainer workload as the same person or team will<br />
often be responsible for both packages.<br />
<br />
* A lot of respected members of the Haskell community (e.g. Cale) do not like many aspects of the current API (and thus refuse to use it) and we're taking their points of view into account.<br />
<br />
* The new version of the library is keeping the "spirit" of old fgl alive, but modernising the interface and providing new functionality (e.g. the ability to restrict the label types or use a custom Node type).<br />
<br />
* There will be a full transition guide between the old and new versions (something that was lacking for packages like QuickCheck from what I could tell).<br />
<br />
= Reasons not to use the name =<br />
<br />
* Code that depends on 'fgl' will break. There are 23 direct and 25 indirect dependencies on fgl. http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/fgl-5.4.2.2#direct<br />
<br />
** Rebuttal: <br />
<br />
*** Have contacted all maintainers of packages on Hackage which have packages without an upper bound on the version of fgl used; most have already gotten back to me saying they will release a bug-fix version to resolve this.<br />
<br />
*** With the [[Package_versioning_policy]], people should always have upper bounds on their dependencies anyway.<br />
<br />
*** Until new fgl is stabilised, Hackage can set the default version of fgl to be < 6 (same as what happened with base-3 to base-4 transition, etc., thus any packages that do not have an upper bound will not be affected by cabal-install, etc.<br />
<br />
* Doesn't matter if the old fgl is still around. If the new code is<br />
better, it will be adopted on its own merits (see e.g.<br />
bytestrings vs packedstring, vector vs uvector)<br />
Let the market decide if it is better, rather than forcing us.<br />
<br />
** This is true. However, every now and then someone tries to work out what this mystical packedstring library is and tries to use it (old invalid deps, etc.).<br />
<br />
** The package has been stable for ~10 years -- why change a stable API? It is already "perfect"<br />
<br />
** As mentioned above: many people do not think that the current API is perfect.<br />
<br />
* The new package really isn't the same package in any sense.<br />
<br />
** Sure it is: we might be changing the API, but it's the same basic concepts, etc. See current status [http://code.haskell.org/FGL/fgl/Data/Graph/Inductive/Graph.hs here]<br />
<br />
* Rewrites by new teams damage the brand of famous packages (e.g. parsec 3)<br />
<br />
* No additional breakages are introduced.<br />
<br />
** Not sure what your point is here.<br />
<br />
* If you weren't maintainer of 'fgl' this rewrite wouldn't even be possible to call 'fgl' -- there's a conflict of interest.<br />
<br />
** Of course not, but I volunteered to become the maintainer of fgl precisely to modernise the interface (which as far as I know is why Martin Erwig gave fgl up for adoption: he didn't have time to make changes that people were asking him for).<br />
<br />
* Maintaining Haskell98 compatability. Keep it simple. (See regex-posix's mistakes here)<br />
<br />
** Not sure what you mean by this point; what are regix-posix's mistakes? Whilst in general I can see Haskell98 (or Haskell2010) compatability being a good thing to keep (in case someone uses another compiler, etc.) if there's a good argument to be made for why a certain extension would be useful then why shouldn't we use it? Whilst I mightn't have been working on a major Haskell library back then, it was pointed out to me a while back that you shouldn't constrain yourself by enforcing Haskell98 compatability for no reason.<br />
<br />
* Distros that support the Haskell Platform will have to keep an old version of fgl around for a long time anyway.<br />
<br />
** I don't intend to have the new fgl be actually used by people for a while yet anyway, as I intend to get the ecosystem built up around it (fgl-algorithms, etc.) first.<br />
<br />
** I think that keeping base-3 compatibility in xmonad just to ensure that people using the Long Term Release of Ubuntu has in a sense held it back, as it was more of a pain to transition to base-4 later on than it would have been to do it earlier (using extensible-exceptions if nothing else).<br />
<br />
* The original author might not approve of the use of the name.<br />
<br />
** If this is true, then why did he publicly state in mailing lists that he wanted someone to take over?<br />
<br />
* having tutorials not work for later revisions is more confusing than having various packages doing the same thing.<br />
<br />
** The current tutorials do not fully work with the current version anyway, and we will be writing tutorials (already had one offer to help out with this).<br />
<br />
** separate names (both for the package name and module name-space) is that its easier to have both packages installed at the same time<br />
<br />
** A valid argument, especially when seeing the fall-out between mtl and transformers.<br />
<br />
= Possible Compromises =<br />
<br />
* Until we're ready to release, either don't release fgl on Hackage or call it fgl-experimental or something.<br />
<br />
* The name "Functional Graph Library" is rather vague anyway, whereas something like "inductive-graphs" makes more sense in terms of the actual data structures, etc. involved. As such we could give the new version of the library something like that if down the track we could officially deprecate the fgl library (like how packedstring has been deprecated).<br />
<br />
* We could officially split up the fgl package namespace even further: rather than having fgl + fgl-algorithms, etc. we could have something like fgl-classes, fgl-algorithms, etc. As such the base name is kept whilst there is no ambiguity on which version is being used.</div>Ivanmhttps://wiki.haskell.org/index.php?title=AusHac2010&diff=34503AusHac20102010-04-10T06:59:22Z<p>Ivanm: Add haskell-updater as a project</p>
<hr />
<div>If you've found this page, you use Haskell, ''and'' live in Australia (or at the very least able and willing to travel here), then you're in the right place! '''AusHac2010 will be held at UNSW, from the 16th to the 18th of July.'''<br />
<br />
If you're interested in coming, '''please [http://axman6.wufoo.com/forms/aushac-2010-sign-up/ sign up]''', and put your name down on the list below, along with your IRC nickname if you're on #haskell. Also, if you've got something to discuss, feel free to add it to the bottom of the page in the Discussion section (just to keep the rest of the page clean and helpful).<br />
<br />
If you need further information, feel free to email Alex at axman6@gmail.com or Ivan at Ivan.Miljenovic@gmail.com .<br />
<br />
== What we've got so far ==<br />
<br />
===Why===<br />
<br />
Because we miss out on all the fun they have up north, and we've got something to offer. It's also a great chance to meet all these people you talk to on IRC, or read their blogs, and just have a good time, while getting some (potentially) useful work done!<br />
<br />
===When===<br />
<br />
As mentioned above, the date has now been set for the 16th - 18th of July.<br />
<br />
===Where===<br />
<br />
We will be holding the hackathon in the [http://maps.google.com/maps?cid=9827534508363927277&hl=en&ie=UTF8&hq=&hnear=&ll=-33.918168,151.231077&spn=0.010773,0.022702&t=h&z=16&iwloc=A Computer Science and Engineering building at UNSW] (Bilding K17), in room 113.<br />
<br />
Ben Lippmeier has booked the room from 1:00 pm on Friday until late on Sunday night, and is looking into seeing if those using the room before us could finish earlier, or on another day.<br />
<br />
===Who===<br />
<br />
'''We now have a [http://axman6.wufoo.com/forms/aushac-2010-sign-up/ sign up page]'''. Please add your name and email there (your details will be kept secret) and then add your details below (so other people can see who's coming). Sorry to all those who have put their name down below, We might keep the table around, so that everyone can see who is going to be there.<br />
<br />
<br />
{| class="wikitable"<br />
! Nickname<br />
! Real Name<br />
! Affiliation<br />
! Mobile #<br />
! Arriving<br />
! Departing<br />
! Accomodation<br />
! Comments<br />
|-<br />
| Axman6<br />
| [[User:Axman6|Alex Mason]]<br />
| Undergrad @ ANU<br />
| <br />
| Friday sometime<br />
| Sunday night<br />
|<br />
| Organiser<br />
|-<br />
| ivanm<br />
| [[user:ivanm|Ivan Miljenovic]]<br />
| PhD student @ ANU<br />
| 0416 195 883<br />
| Friday sometime<br />
| Sunday night<br />
| Somewhere cheap<br />
| Organiser<br />
|}<br />
<br />
<br />
== Discussion ==<br />
<br />
=== Possible Projects ===<br />
<br />
====Generic graph class====<br />
'''What:''' I (Ivan) last year floated the idea of replacing the current default array-based Graph data type with an extensible set of classes with default instances. There's various interest about this around and I've done some work on it, but if there's anyone else coming it'd be better to bounce ideas together about how to define such classes.<br />
<br />
'''Who:''' Ivan M<br />
<br />
====Gloss-based plots====<br />
'''What:''' Either an alternative graphing back end to Criterion that only relies on OpenGL (through the use of Gloss), or a library for plotting. At the moment Gloss looks like it may only be suitable for bar type graphs, but we'll see. (We may look into writing some other library that's better suited than Gloss, as Gloss is aimed at students learning haskell, and wanting to just get something drawn)<br />
<br />
'''Who:''' Ivan M, Alex M<br />
<br />
====GHC LLVM backend====<br />
'''What:''' The recent work dome by David Terei on an LLVM backend for GHC has shown some fantastic results, and getting it to a point where it could become the default GHC backend is something a lot of people would really like to see.<br />
<br />
'''Who:''' Alex M, Manuel, Erik<br />
<br />
====Accelerate====<br />
'''What:''' [http://hackage.haskell.org/package/accelerate Accelerate] is a Haskell EDSL for regular array computations. The aim is to make it generate so blindingly fast code that the C folks start to cry. An LLVM backend is in very early stages of development and a CUDA GPU backend is good enough to run some first small Accelerate programs.<br />
<br />
'''Who:''' Manuel, Alex M<br />
<br />
====Repa====<br />
'''What:''' "Regular, shape-polymorphic, parallel arrays in Haskell", a library for array computations using regular arrays, which aims to produce very efficient code which can be easily and automatically parallelised, producing very high performance computations on multicore systems. ([http://www.cse.unsw.edu.au/~chak/papers/repa.pdf PDF])<br />
<br />
'''Who:''' Alex M<br />
<br />
====Hubris====<br />
'''What:''' [http://github.com/mwotton/hubris Hubris] is a bridge between Ruby and Haskell. There are two main options - working on Hubris itself (adding instances for more data types, making it easier to install, chasing the 64-bit linking bug...) or actually building something cool with it. Open to either. (Oh, one other idea - using Hubris to export QuickCheck to Ruby directly. RushCheck looks a bit moribund these days...)<br />
<br />
'''Who:''' Mark<br />
<br />
====Leksah====<br />
'''What:''' [http://leksah.org/ Leksah] is a Haskell IDE written in Haskell. Goal for 1.0 is mainly to fix issues in 0.8 rather than add new features, but it would also be nice to make some more progress on replacing GtkSourceView with Yi. Support for running QuickCheck and HUnit may be something we could slip into 1.0.<br />
<br />
'''Who:''' Hamish, Jens<br />
<br />
====MPI bindings====<br />
'''What:''' The Message Passing Interface [http://en.wikipedia.org/wiki/Message_Passing_Interface MPI] is a popular library/standard used in distributed high performance computing systems . An [http://www.foldr.org/~michaelw/hmpi/ old Haskell binding] exists, but has suffered severe bit rot. It would be nice to get this working again, and then try to build some nicer abstractions on top (such as mapReduce).<br />
<br />
'''Who:''' Bernie<br />
<br />
==== Notification library ====<br />
'''What:''' write a library for use with libnotify, growl, etc. (note that there is already fdo-notify and GrowlNotify, so this project isn't very original; however, a wrapper library might be nice).<br />
<br />
'''Who:''' Ivan<br />
<br />
==== Library re-builder ====<br />
'''What:''' extend [http://hackage.haskell.org/package/haskell-updater haskell-updater] to use with cabal-install, Arch, etc.<br />
<br />
'''Who:''' Ivan (willing to help out if anyone else is interested; is not planning on doing the conversions himself)<br />
<br />
== Accommodation ==<br />
<br />
=== Hostels ===<br />
If you're looking for somewhere cheap to stay near UNSW then there are a [http://www.hostelworld.com/hostels/Sydney/Coogee few back-packers in Coogee].<br />
It's about a 10 minute bus ride from Coogee Beach to UNSW. Shared rooms are AUD$30 - 40.<br />
<br />
For something a bit further out, you could also try one of the [http://www.yha.com.au/hostels/search/region.cfm?regionid=62 Sydney YHA hostels]. The Glebe one is walking distance to Darling Harbour, though it takes about 50 min to get to UNSW via light rail then bus. Private rooms with shared facilities are about AUD$80. Shared rooms are AUD$30 - 40.<br />
<br />
If you want to say across the road from Central station, and don't mind hanging out with English gap-year kids, then you try [http://www.wakeup.com.au/ WakeUp].<br />
<br />
If you like to party then [http://www.evasbackpackers.com.au/ Evas Backpackers] is a short stumble home from Kings Cross. <br />
<br />
I'd avoid [http://www.sydneycentralonwentworth.com.au/ SydneyCentralOnWentworth]. It has a pretty website but the rooms are small and dingy (benl23 stayed there in 2009)<br />
<br />
Note that hostels tend to be busiest on Friday and Saturday nights, so it's good to book early.<br />
<br />
=== Colleges ===<br />
For something more up-market you could try one of [http://www.housing.unsw.edu.au/housing/short_term/short_term.php?p=overview the UNSW residential Colleges]. This site also has more links to hotels and hostels.<br />
<br />
=== Hotels ===<br />
If you have AUD$120 - 150 per night and aren't organised then [http://www.lastminute.com.au/hotels.html LastMinute] is a good place to find a hotel. You get the best prices if you book 2-3 days in advance.<br />
<br />
<br />
== Related Links ==<br />
<br />
* [[OzHaskell]]<br />
<br />
[[Category:Events]]<br />
<br />
[[Category:Hackathon]]<br />
<br />
== Historic information ==<br />
<br />
The old "who's interested" table:<br />
<br />
<table border="1px"><br />
<tr><br />
<td>Name</td><br />
<td>IRC Nickname</td><br />
<td>Email</td><br />
<td>Availability</td><br />
<td>Preferred date</td><br />
<td>Comment</td><br />
</tr><br />
<br />
<tr><br />
<td>[[User:Axman6|Alex Mason]]</td><br />
<td>Axman6</td><br />
<td></td><br />
<td>Probably any weekend during the ANU holidays</td><br />
<td>-</td><br />
<td>Organiser</td><br />
</tr><br />
<br />
<tr><br />
<td>Liam O'Connor-Davis</td><br />
<td>kamatsu</td><br />
<td></td><br />
<td>All the UNSW midyear break.</td><br />
<td>-</td><br />
</tr><br />
<br />
<tr><br />
<td>[[:User:ivanm|Ivan Miljenovic]]</td><br />
<td>ivanm</td><br />
<td></td><br />
<td>*shrug* lazy PhD student, so whenever</td><br />
<td>&nbsp;&nbsp; <=== </td><br />
<td>Organiser</td><br />
</tr><br />
<br />
<tr><br />
<td>Tony Morris</td><br />
<td>dibblego</td><br />
<td></td><br />
<td>Nothing specific</td><br />
<td>-</td><br />
<td>Tentative, depending on health</td><br />
</tr><br />
<br />
<tr><br />
<td>Manuel Chakravarty</td><br />
<td>TacticalGrace</td><br />
<td></td><br />
<td>I'm away 4-11 July; will probably not be able to attend all of it regardless of date</td><br />
<td>Probably weekend of the 18th July</td><br />
<td>Will help getting a room at UNSW</td><br />
</tr><br />
<br />
<tr><br />
<td>Mark Wotton</td><br />
<td>blackdog</td><br />
<td></td><br />
<td>flexible, but weekend</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>David Terei</td><br />
<td>dterei</td><br />
<td></td><br />
<td>I'm away from April - start of August. Probably can't attend given proposed dates</td><br />
<td>Any weekend after August 19th</td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>Hamish Mackenzie</td><br />
<td>hamishmack</td><br />
<td></td><br />
<td>Any weekend</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<tr><br />
<td>Ben Lippmeier</td><br />
<td>benl23</td><br />
<td></td><br />
<td>flexible</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<tr><br />
<td>Stephen Blackheath</td><br />
<td>blackh</td><br />
<td></td><br />
<td>Any time</td><br />
<td></td><br />
<td>Please fix date soon if poss</td><br />
</tr><br />
<br />
<tr><br />
<td>Erik de Castro Lopo</td><br />
<td>m3ga</td><br />
<td></td><br />
<td>Weekends</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>Ben Sinclair</td><br />
<td>bens</td><br />
<td>-</td><br />
<td>Any weekend</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>Michael Mounteney</td><br />
<td>mounty?</td><br />
<td></td><br />
<td>Weekends</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>Bernie Pope</td><br />
<td>bjpop</td><br />
<td></td><br />
<td>Weekends</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>Stephen Gream</td><br />
<td>Fallen_Demon</td><br />
<td></td><br />
<td>Weekends</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>Jens Petersen</td><br />
<td>juhp</td><br />
<td></td><br />
<td>Weekends</td><br />
<td>earlier better</td><br />
<td></td><br />
</tr><br />
<tr><br />
<td>Matt Roberts</td><br />
<td>altmattr</td><br />
<td></td><br />
<td></td><br />
<td></td><br />
<td></td><br />
</tr><br />
</table></div>Ivanmhttps://wiki.haskell.org/index.php?title=AusHac2010&diff=34325AusHac20102010-03-26T22:10:28Z<p>Ivanm: Add Notification project</p>
<hr />
<div>If you've found this page, you use Haskell, ''and'' live in Australia (or at the very least able and willing to travel here), then you're in the right place! '''AusHac2010 will be held at UNSW, from the 16th to the 18th of July.'''<br />
<br />
If you're interested in coming, '''please [http://axman6.wufoo.com/forms/aushac-2010-sign-up/ sign up]''', and put your name down on the list below, along with your IRC nickname if you're on #haskell. Also, if you've got something to discuss, feel free to add it to the bottom of the page in the Discussion section (just to keep the rest of the page clean and helpful).<br />
<br />
If you need further information, feel free to email Alex at axman6@gmail.com or Ivan at Ivan.Miljenovic@gmail.com .<br />
<br />
== What we've got so far ==<br />
<br />
===Why===<br />
<br />
Because we miss out on all the fun they have up north, and we've got something to offer. It's also a great chance to meet all these people you talk to on IRC, or read their blogs, and just have a good time, while getting some (potentially) useful work done!<br />
<br />
===When===<br />
<br />
As mentioned above, the date has now been set for the 16th - 18th of July.<br />
<br />
===Where===<br />
<br />
We will be holding the hackathon in the [http://maps.google.com/maps?cid=9827534508363927277&hl=en&ie=UTF8&hq=&hnear=&ll=-33.918168,151.231077&spn=0.010773,0.022702&t=h&z=16&iwloc=A Computer Science and Engineering building at UNSW] (Bilding K17), in room 113.<br />
<br />
Ben Lippmeier has booked the room from 1:00 pm on Friday until late on Sunday night, and is looking into seeing if those using the room before us could finish earlier, or on another day.<br />
<br />
===Who===<br />
<br />
'''We now have a [http://axman6.wufoo.com/forms/aushac-2010-sign-up/ sign up page]'''. Please add your name and email there (your details will be kept secret) and then add your details below (so other people can see who's coming). Sorry to all those who have put their name down below, We might keep the table around, so that everyone can see who is going to be there.<br />
<br />
<br />
{| class="wikitable"<br />
! Nickname<br />
! Real Name<br />
! Affiliation<br />
! Mobile #<br />
! Arriving<br />
! Departing<br />
! Accomodation<br />
! Comments<br />
|-<br />
| Axman6<br />
| [[User:Axman6|Alex Mason]]<br />
| Undergrad @ ANU<br />
| <br />
| Friday sometime<br />
| Sunday night<br />
|<br />
| Organiser<br />
|-<br />
| ivanm<br />
| [[user:ivanm|Ivan Miljenovic]]<br />
| PhD student @ ANU<br />
| 0416 195 883<br />
| Friday sometime<br />
| Sunday night<br />
| Somewhere cheap<br />
| Organiser<br />
|}<br />
<br />
<br />
== Discussion ==<br />
<br />
=== Possible Projects ===<br />
<br />
====Generic graph class====<br />
'''What:''' I (Ivan) last year floated the idea of replacing the current default array-based Graph data type with an extensible set of classes with default instances. There's various interest about this around and I've done some work on it, but if there's anyone else coming it'd be better to bounce ideas together about how to define such classes.<br />
<br />
'''Who:''' Ivan M<br />
<br />
====Gloss-based plots====<br />
'''What:''' Either an alternative graphing back end to Criterion that only relies on OpenGL (through the use of Gloss), or a library for plotting. At the moment Gloss looks like it may only be suitable for bar type graphs, but we'll see. (We may look into writing some other library that's better suited than Gloss, as Gloss is aimed at students learning haskell, and wanting to just get something drawn)<br />
<br />
'''Who:''' Ivan M, Alex M<br />
<br />
====GHC LLVM backend====<br />
'''What:''' The recent work dome by David Terei on an LLVM backend for GHC has shown some fantastic results, and getting it to a point where it could become the default GHC backend is something a lot of people would really like to see.<br />
<br />
'''Who:''' Alex M, Manuel, Erik<br />
<br />
====Accelerate====<br />
'''What:''' [http://hackage.haskell.org/package/accelerate Accelerate] is a Haskell EDSL for regular array computations. The aim is to make it generate so blindingly fast code that the C folks start to cry. An LLVM backend is in very early stages of development and a CUDA GPU backend is good enough to run some first small Accelerate programs.<br />
<br />
'''Who:''' Manuel, Alex M<br />
<br />
====Hubris====<br />
'''What:''' [http://github.com/mwotton/hubris Hubris] is a bridge between Ruby and Haskell. There are two main options - working on Hubris itself (adding instances for more data types, making it easier to install, chasing the 64-bit linking bug...) or actually building something cool with it. Open to either. (Oh, one other idea - using Hubris to export QuickCheck to Ruby directly. RushCheck looks a bit moribund these days...)<br />
<br />
'''Who:''' Mark<br />
<br />
====Leksah====<br />
'''What:''' [http://leksah.org/ Leksah] is a Haskell IDE written in Haskell. Goal for 1.0 is mainly to fix issues in 0.8 rather than add new features, but it would also be nice to make some more progress on replacing GtkSourceView with Yi. Support for running QuickCheck and HUnit may be something we could slip into 1.0.<br />
<br />
'''Who:''' Hamish, Jens<br />
<br />
====MPI bindings====<br />
'''What:''' The Message Passing Interface [http://en.wikipedia.org/wiki/Message_Passing_Interface MPI] is a popular library/standard used in distributed high performance computing systems . An [http://www.foldr.org/~michaelw/hmpi/ old Haskell binding] exists, but has suffered severe bit rot. It would be nice to get this working again, and then try to build some nicer abstractions on top (such as mapReduce).<br />
<br />
'''Who:''' Bernie<br />
<br />
==== Notification library ====<br />
'''What:''' write a library for use with libnotify, growl, etc. (note that there is already fdo-notify and GrowlNotify, so this project isn't very original; however, a wrapper library might be nice).<br />
<br />
'''Who:''' Ivan<br />
<br />
== Accommodation ==<br />
<br />
=== Hostels ===<br />
If you're looking for somewhere cheap to stay near UNSW then there are a [http://www.hostelworld.com/hostels/Sydney/Coogee few back-packers in Coogee].<br />
It's about a 10 minute bus ride from Coogee Beach to UNSW. Shared rooms are AUD$30 - 40.<br />
<br />
For something a bit further out, you could also try one of the [http://www.yha.com.au/hostels/search/region.cfm?regionid=62 Sydney YHA hostels]. The Glebe one is walking distance to Darling Harbour, though it takes about 50 min to get to UNSW via light rail then bus. Private rooms with shared facilities are about AUD$80. Shared rooms are AUD$30 - 40.<br />
<br />
If you want to say across the road from Central station, and don't mind hanging out with English gap-year kids, then you try [http://www.wakeup.com.au/ WakeUp].<br />
<br />
If you like to party then [http://www.evasbackpackers.com.au/ Evas Backpackers] is a short stumble home from Kings Cross. <br />
<br />
I'd avoid [http://www.sydneycentralonwentworth.com.au/ SydneyCentralOnWentworth]. It has a pretty website but the rooms are small and dingy (benl23 stayed there in 2009)<br />
<br />
Note that hostels tend to be busiest on Friday and Saturday nights, so it's good to book early.<br />
<br />
=== Colleges ===<br />
For something more up-market you could try one of [http://www.housing.unsw.edu.au/housing/short_term/short_term.php?p=overview the UNSW residential Colleges]. This site also has more links to hotels and hostels.<br />
<br />
=== Hotels ===<br />
If you have AUD$120 - 150 per night and aren't organised then [http://www.lastminute.com.au/hotels.html LastMinute] is a good place to find a hotel. You get the best prices if you book 2-3 days in advance.<br />
<br />
<br />
== Related Links ==<br />
<br />
* [[OzHaskell]]<br />
<br />
[[Category:Events]]<br />
<br />
[[Category:Hackathon]]<br />
<br />
== Historic information ==<br />
<br />
The old "who's interested" table:<br />
<br />
<table border="1px"><br />
<tr><br />
<td>Name</td><br />
<td>IRC Nickname</td><br />
<td>Email</td><br />
<td>Availability</td><br />
<td>Preferred date</td><br />
<td>Comment</td><br />
</tr><br />
<br />
<tr><br />
<td>[[User:Axman6|Alex Mason]]</td><br />
<td>Axman6</td><br />
<td></td><br />
<td>Probably any weekend during the ANU holidays</td><br />
<td>-</td><br />
<td>Organiser</td><br />
</tr><br />
<br />
<tr><br />
<td>Liam O'Connor-Davis</td><br />
<td>kamatsu</td><br />
<td></td><br />
<td>All the UNSW midyear break.</td><br />
<td>-</td><br />
</tr><br />
<br />
<tr><br />
<td>[[:User:ivanm|Ivan Miljenovic]]</td><br />
<td>ivanm</td><br />
<td></td><br />
<td>*shrug* lazy PhD student, so whenever</td><br />
<td>&nbsp;&nbsp; <=== </td><br />
<td>Organiser</td><br />
</tr><br />
<br />
<tr><br />
<td>Tony Morris</td><br />
<td>dibblego</td><br />
<td></td><br />
<td>Nothing specific</td><br />
<td>-</td><br />
<td>Tentative, depending on health</td><br />
</tr><br />
<br />
<tr><br />
<td>Manuel Chakravarty</td><br />
<td>TacticalGrace</td><br />
<td></td><br />
<td>I'm away 4-11 July; will probably not be able to attend all of it regardless of date</td><br />
<td>Probably weekend of the 18th July</td><br />
<td>Will help getting a room at UNSW</td><br />
</tr><br />
<br />
<tr><br />
<td>Mark Wotton</td><br />
<td>blackdog</td><br />
<td></td><br />
<td>flexible, but weekend</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>David Terei</td><br />
<td>dterei</td><br />
<td></td><br />
<td>I'm away from April - start of August. Probably can't attend given proposed dates</td><br />
<td>Any weekend after August 19th</td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>Hamish Mackenzie</td><br />
<td>hamishmack</td><br />
<td></td><br />
<td>Any weekend</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<tr><br />
<td>Ben Lippmeier</td><br />
<td>benl23</td><br />
<td></td><br />
<td>flexible</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<tr><br />
<td>Stephen Blackheath</td><br />
<td>blackh</td><br />
<td></td><br />
<td>Any time</td><br />
<td></td><br />
<td>Please fix date soon if poss</td><br />
</tr><br />
<br />
<tr><br />
<td>Erik de Castro Lopo</td><br />
<td>m3ga</td><br />
<td></td><br />
<td>Weekends</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>Ben Sinclair</td><br />
<td>bens</td><br />
<td>-</td><br />
<td>Any weekend</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>Michael Mounteney</td><br />
<td>mounty?</td><br />
<td></td><br />
<td>Weekends</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>Bernie Pope</td><br />
<td>bjpop</td><br />
<td></td><br />
<td>Weekends</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>Stephen Gream</td><br />
<td>Fallen_Demon</td><br />
<td></td><br />
<td>Weekends</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>Jens Petersen</td><br />
<td>juhp</td><br />
<td></td><br />
<td>Weekends</td><br />
<td>earlier better</td><br />
<td></td><br />
</tr><br />
<tr><br />
<td>Matt Roberts</td><br />
<td>altmattr</td><br />
<td></td><br />
<td></td><br />
<td></td><br />
<td></td><br />
</tr><br />
</table></div>Ivanmhttps://wiki.haskell.org/index.php?title=AusHac2010&diff=34258AusHac20102010-03-23T08:52:08Z<p>Ivanm: New "registration" table to replace the "who's interested" table</p>
<hr />
<div>If you've found this page, you use Haskell, ''and'' live in Australia (or at the very least able and willing to travel here), then you're in the right place! '''AusHac2010 will be held at UNSW, from the 16th to the 18th of July.'''<br />
<br />
If you're interested in coming, '''please [http://axman6.wufoo.com/forms/aushac-2010-sign-up/ sign up]''', and put your name down on the list below, along with your IRC nickname if you're on #haskell. Also, if you've got something to discuss, feel free to add it to the bottom of the page in the Discussion section (just to keep the rest of the page clean and helpful).<br />
<br />
If you need further information, feel free to email Alex at axman6@gmail.com or Ivan at Ivan.Miljenovic@gmail.com .<br />
<br />
== What we've got so far ==<br />
<br />
===Why===<br />
<br />
Because we miss out on all the fun they have up north, and we've got something to offer. It's also a great chance to meet all these people you talk to on IRC, or read their blogs, and just have a good time, while getting some (potentially) useful work done!<br />
<br />
===When===<br />
<br />
As mentioned above, the date has now been set for the 16th - 18th of July.<br />
<br />
===Where===<br />
<br />
We will be holding the hackathon in the [http://maps.google.com/maps?cid=9827534508363927277&hl=en&ie=UTF8&hq=&hnear=&ll=-33.918168,151.231077&spn=0.010773,0.022702&t=h&z=16&iwloc=A Computer Science and Engineering building at UNSW] (Bilding K17), in room 113.<br />
<br />
Ben Lippmeier has booked the room from 1:00 pm on Friday until late on Sunday night, and is looking into seeing if those using the room before us could finish earlier, or on another day.<br />
<br />
===Who===<br />
<br />
'''We now have a [http://axman6.wufoo.com/forms/aushac-2010-sign-up/ sign up page]'''. Please add your name and email there (your details will be kept secret) and then add your details below (so other people can see who's coming). Sorry to all those who have put their name down below, We might keep the table around, so that everyone can see who is going to be there.<br />
<br />
<br />
{| class="wikitable"<br />
! Nickname<br />
! Real Name<br />
! Affiliation<br />
! Mobile #<br />
! Arriving<br />
! Departing<br />
! Accomodation<br />
! Comments<br />
|-<br />
| Axman6<br />
| [[User:Axman6|Alex Mason]]<br />
| Undergrad @ ANU<br />
| <br />
| Friday sometime<br />
| Sunday night<br />
|<br />
| Organiser<br />
|-<br />
| ivanm<br />
| [[user:ivanm|Ivan Miljenovic]]<br />
| PhD student @ ANU<br />
| 0416 195 883<br />
| Friday sometime<br />
| Sunday night<br />
| Somewhere cheap<br />
| Organiser<br />
|}<br />
<br />
<br />
== Discussion ==<br />
<br />
=== Possible Projects ===<br />
<br />
====Generic graph class====<br />
'''What:''' I (Ivan) last year floated the idea of replacing the current default array-based Graph data type with an extensible set of classes with default instances. There's various interest about this around and I've done some work on it, but if there's anyone else coming it'd be better to bounce ideas together about how to define such classes.<br />
<br />
'''Who:''' Ivan M<br />
<br />
====Gloss-based plots====<br />
'''What:''' Either an alternative graphing back end to Criterion that only relies on OpenGL (through the use of Gloss), or a library for plotting. At the moment Gloss looks like it may only be suitable for bar type graphs, but we'll see. (We may look into writing some other library that's better suited than Gloss, as Gloss is aimed at students learning haskell, and wanting to just get something drawn)<br />
<br />
'''Who:''' Ivan M, Alex M<br />
<br />
====GHC LLVM backend====<br />
'''What:''' The recent work dome by David Terei on an LLVM backend for GHC has shown some fantastic results, and getting it to a point where it could become the default GHC backend is something a lot of people would really like to see.<br />
<br />
'''Who:''' Alex M, Manuel, Erik<br />
<br />
====Accelerate====<br />
'''What:''' [http://hackage.haskell.org/package/accelerate Accelerate] is a Haskell EDSL for regular array computations. The aim is to make it generate so blindingly fast code that the C folks start to cry. An LLVM backend is in very early stages of development and a CUDA GPU backend is good enough to run some first small Accelerate programs.<br />
<br />
'''Who:''' Manuel, Alex M<br />
<br />
====Hubris====<br />
'''What:''' [http://github.com/mwotton/hubris Hubris] is a bridge between Ruby and Haskell. There are two main options - working on Hubris itself (adding instances for more data types, making it easier to install, chasing the 64-bit linking bug...) or actually building something cool with it. Open to either. (Oh, one other idea - using Hubris to export QuickCheck to Ruby directly. RushCheck looks a bit moribund these days...)<br />
<br />
'''Who:''' Mark<br />
<br />
====Leksah====<br />
'''What:''' [http://leksah.org/ Leksah] is a Haskell IDE written in Haskell. Goal for 1.0 is mainly to fix issues in 0.8 rather than add new features, but it would also be nice to make some more progress on replacing GtkSourceView with Yi. Support for running QuickCheck and HUnit may be something we could slip into 1.0.<br />
<br />
'''Who:''' Hamish, Jens<br />
<br />
====MPI bindings====<br />
'''What:''' The Message Passing Interface [http://en.wikipedia.org/wiki/Message_Passing_Interface MPI] is a popular library/standard used in distributed high performance computing systems . An [http://www.foldr.org/~michaelw/hmpi/ old Haskell binding] exists, but has suffered severe bit rot. It would be nice to get this working again, and then try to build some nicer abstractions on top (such as mapReduce).<br />
<br />
'''Who:''' Bernie<br />
<br />
== Accommodation ==<br />
<br />
=== Hostels ===<br />
If you're looking for somewhere cheap to stay near UNSW then there are a [http://www.hostelworld.com/hostels/Sydney/Coogee few back-packers in Coogee].<br />
It's about a 10 minute bus ride from Coogee Beach to UNSW. Shared rooms are AUD$30 - 40.<br />
<br />
For something a bit further out, you could also try one of the [http://www.yha.com.au/hostels/search/region.cfm?regionid=62 Sydney YHA hostels]. The Glebe one is walking distance to Darling Harbour, though it takes about 50 min to get to UNSW via light rail then bus. Private rooms with shared facilities are about AUD$80. Shared rooms are AUD$30 - 40.<br />
<br />
If you want to say across the road from Central station, and don't mind hanging out with English gap-year kids, then you try [http://www.wakeup.com.au/ WakeUp].<br />
<br />
If you like to party then [http://www.evasbackpackers.com.au/ Evas Backpackers] is a short stumble home from Kings Cross. <br />
<br />
I'd avoid [http://www.sydneycentralonwentworth.com.au/ SydneyCentralOnWentworth]. It has a pretty website but the rooms are small and dingy (benl23 stayed there in 2009)<br />
<br />
Note that hostels tend to be busiest on Friday and Saturday nights, so it's good to book early.<br />
<br />
=== Colleges ===<br />
For something more up-market you could try one of [http://www.housing.unsw.edu.au/housing/short_term/short_term.php?p=overview the UNSW residential Colleges]. This site also has more links to hotels and hostels.<br />
<br />
=== Hotels ===<br />
If you have AUD$120 - 150 per night and aren't organised then [http://www.lastminute.com.au/hotels.html LastMinute] is a good place to find a hotel. You get the best prices if you book 2-3 days in advance.<br />
<br />
<br />
== Related Links ==<br />
<br />
* [[OzHaskell]]<br />
<br />
[[Category:Events]]<br />
<br />
[[Category:Hackathon]]<br />
<br />
== Historic information ==<br />
<br />
The old "who's interested" table:<br />
<br />
<table border="1px"><br />
<tr><br />
<td>Name</td><br />
<td>IRC Nickname</td><br />
<td>Email</td><br />
<td>Availability</td><br />
<td>Preferred date</td><br />
<td>Comment</td><br />
</tr><br />
<br />
<tr><br />
<td>[[User:Axman6|Alex Mason]]</td><br />
<td>Axman6</td><br />
<td></td><br />
<td>Probably any weekend during the ANU holidays</td><br />
<td>-</td><br />
<td>Organiser</td><br />
</tr><br />
<br />
<tr><br />
<td>Liam O'Connor-Davis</td><br />
<td>kamatsu</td><br />
<td></td><br />
<td>All the UNSW midyear break.</td><br />
<td>-</td><br />
</tr><br />
<br />
<tr><br />
<td>[[:User:ivanm|Ivan Miljenovic]]</td><br />
<td>ivanm</td><br />
<td></td><br />
<td>*shrug* lazy PhD student, so whenever</td><br />
<td>&nbsp;&nbsp; <=== </td><br />
<td>Organiser</td><br />
</tr><br />
<br />
<tr><br />
<td>Tony Morris</td><br />
<td>dibblego</td><br />
<td></td><br />
<td>Nothing specific</td><br />
<td>-</td><br />
<td>Tentative, depending on health</td><br />
</tr><br />
<br />
<tr><br />
<td>Manuel Chakravarty</td><br />
<td>TacticalGrace</td><br />
<td></td><br />
<td>I'm away 4-11 July; will probably not be able to attend all of it regardless of date</td><br />
<td>Probably weekend of the 18th July</td><br />
<td>Will help getting a room at UNSW</td><br />
</tr><br />
<br />
<tr><br />
<td>Mark Wotton</td><br />
<td>blackdog</td><br />
<td></td><br />
<td>flexible, but weekend</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>David Terei</td><br />
<td>dterei</td><br />
<td></td><br />
<td>I'm away from April - start of August. Probably can't attend given proposed dates</td><br />
<td>Any weekend after August 19th</td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>Hamish Mackenzie</td><br />
<td>hamishmack</td><br />
<td></td><br />
<td>Any weekend</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<tr><br />
<td>Ben Lippmeier</td><br />
<td>benl23</td><br />
<td></td><br />
<td>flexible</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<tr><br />
<td>Stephen Blackheath</td><br />
<td>blackh</td><br />
<td></td><br />
<td>Any time</td><br />
<td></td><br />
<td>Please fix date soon if poss</td><br />
</tr><br />
<br />
<tr><br />
<td>Erik de Castro Lopo</td><br />
<td>m3ga</td><br />
<td></td><br />
<td>Weekends</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>Ben Sinclair</td><br />
<td>bens</td><br />
<td>-</td><br />
<td>Any weekend</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>Michael Mounteney</td><br />
<td>mounty?</td><br />
<td></td><br />
<td>Weekends</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>Bernie Pope</td><br />
<td>bjpop</td><br />
<td></td><br />
<td>Weekends</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>Stephen Gream</td><br />
<td>Fallen_Demon</td><br />
<td></td><br />
<td>Weekends</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>Jens Petersen</td><br />
<td>juhp</td><br />
<td></td><br />
<td>Weekends</td><br />
<td>earlier better</td><br />
<td></td><br />
</tr><br />
<tr><br />
<td>Matt Roberts</td><br />
<td>altmattr</td><br />
<td></td><br />
<td></td><br />
<td></td><br />
<td></td><br />
</tr><br />
</table></div>Ivanmhttps://wiki.haskell.org/index.php?title=AusHac2010&diff=34167AusHac20102010-03-19T00:44:03Z<p>Ivanm: Add accommodation link</p>
<hr />
<div>If you've found this page, you use Haskell, ''and'' live in Australia (or at the very least able and willing to travel here), then you're in the right place! We're looking into organising a Haskell [[Hackathon]] some time during the middle of 2010, and this where it shall be organised.<br />
<br />
If you're interested in coming, '''please''' put your name down on the list below, along with your IRC nickname if you're on #haskell, and possibly your email (We'll use this to let you know of any progress we've made, but it's not mandatory). Also, if you've got something to discuss, feel free to add it to the bottom of the page in the Discussion section (just to keep the rest of the page clean and helpful).<br />
<br />
== What we've got so far ==<br />
<br />
===Why===<br />
<br />
Because we miss out on all the fun they have up north, and we've got something to offer. It's also a great chance to meet all these people you talk to on IRC, or read their blogs, and just have a good time, while getting some (potentially) useful work done!<br />
<br />
===When===<br />
<br />
A few dates have been discussed, mainly taking into account when the university holidays are for various universities:<br />
<br />
* ANU: 7 June -> 18 July<br />
* UNSW: 29 June -> 18 July<br />
<br />
So so far we need a weekend between the 28th of June and the 18th of July.<br />
<br />
We're looking at organising it over a weekend, and I (Axman6) would quite like to have it start on a Friday, ending on Sunday. This does not at all mean that those who can’t make the Friday will miss out, the more people we have, the better. But I think that having more time will mean that we can get more done (which is the point right?).<br />
<br />
===Where===<br />
<br />
Manuel Chakravarty and Ben Lippmeier have said there should be no problem finding a room at UNSW, with the only possible problem being Internet access for everyone, but hopefully something can be arranged by that time.<br />
<br />
===Who===<br />
<br />
If you're interested in coming, please show your interest by adding your details to the list below (if you don't have an account, please email me (Axman6) your details and I'll add you).<br />
<br />
<table border="1px"><br />
<tr><br />
<td>Name</td><br />
<td>IRC Nickname</td><br />
<td>Email</td><br />
<td>Availability</td><br />
<td>Preferred date</td><br />
<td>Comment</td><br />
</tr><br />
<br />
<tr><br />
<td>Alex Mason</td><br />
<td>Axman6</td><br />
<td>axman6@gmail.com</td><br />
<td>Probably any weekend during the ANU holidays</td><br />
<td>-</td><br />
<td>Organiser... sort of</td><br />
</tr><br />
<br />
<br />
<tr><br />
<td>[[:User:ivanm|Ivan Miljenovic]]</td><br />
<td>ivanm</td><br />
<td>Ivan <dot> Miljenovic <at> gmail <dot> com</td><br />
<td>*shrug* lazy PhD student, so whenever</td><br />
<td>&nbsp;&nbsp; <=== </td><br />
<td>ditto</td><br />
</tr><br />
<br />
<tr><br />
<td>Tony Morris</td><br />
<td>dibblego</td><br />
<td>code@tmorris.net</td><br />
<td>Nothing specific</td><br />
<td>-</td><br />
<td>Tentative, depending on health</td><br />
</tr><br />
<br />
<tr><br />
<td>Manuel Chakravarty</td><br />
<td>TacticalGrace</td><br />
<td>chak@justtesting.org</td><br />
<td>I'm away 4-11 July; will probably not be able to attend all of it regardless of date</td><br />
<td>Probably weekend of the 18th July</td><br />
<td>Will help getting a room at UNSW</td><br />
</tr><br />
<br />
<tr><br />
<td>Mark Wotton</td><br />
<td>blackdog</td><br />
<td>mwotton@gmail.com</td><br />
<td>flexible, but weekend</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>David Terei</td><br />
<td>dterei</td><br />
<td>dave.terei@gmail.com</td><br />
<td>I'm away from April - start of August. Probably can't attend given proposed dates</td><br />
<td>Any weekend after August 19th</td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>Hamish Mackenzie</td><br />
<td>hamishmack</td><br />
<td>hamish.k.mackenzie@googlemail.com</td><br />
<td>Any weekend</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<tr><br />
<td>Ben Lippmeier</td><br />
<td>benl23</td><br />
<td>benl@ouroborus.net</td><br />
<td>flexible</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<tr><br />
<td>Stephen Blackheath</td><br />
<td>blackh</td><br />
<td>naughty.biscuit.stephen@blacksapphire.com</td><br />
<td>Any time</td><br />
<td></td><br />
<td>Please fix date soon if poss</td><br />
</tr><br />
<br />
<tr><br />
<td>Erik de Castro Lopo</td><br />
<td>m3ga</td><br />
<td>erikd@mega-nerd.com</td><br />
<td>Weekends</td><br />
<td></td><br />
<td></td><br />
</tr><br />
</table><br />
<br />
== Discussion ==<br />
<br />
=== Possible Projects ===<br />
<br />
====Generic graph class====<br />
'''What:''' I (Ivan) last year floated the idea of replacing the current default array-based Graph data type with an extensible set of classes with default instances. There's various interest about this around and I've done some work on it, but if there's anyone else coming it'd be better to bounce ideas together about how to define such classes.<br />
<br />
'''Who:''' Ivan M<br />
<br />
====Gloss-based plots====<br />
'''What:''' Either an alternative graphing back end to Criterion that only relies on OpenGL (through the use of Gloss), or a library for plotting. At the moment Gloss looks like it may only be suitable for bar type graphs, but we'll see. (We may look into writing some other library that's better suited than Gloss, as Gloss is aimed at students learning haskell, and wanting to just get something drawn)<br />
<br />
'''Who:''' Ivan M, Alex M<br />
<br />
====GHC LLVM backend====<br />
'''What:''' The recent work dome by David Terei on an LLVM backend for GHC has shown some fantastic results, and getting it to a point where it could become the default GHC backend is something a lot of people would really like to see.<br />
<br />
'''Who:''' Alex M, Manuel, Erik<br />
<br />
====Accelerate====<br />
'''What:''' [http://hackage.haskell.org/package/accelerate Accelerate] is a Haskell EDSL for regular array computations. The aim is to make it generate so blindingly fast code that the C folks start to cry. An LLVM backend is in very early stages of development and a CUDA GPU backend is good enough to run some first small Accelerate programs.<br />
<br />
'''Who:''' Manuel, Alex M<br />
<br />
====Hubris====<br />
'''What:''' [http://github.com/mwotton/hubris Hubris] is a bridge between Ruby and Haskell. There are two main options - working on Hubris itself (adding instances for more data types, making it easier to install, chasing the 64-bit linking bug...) or actually building something cool with it. Open to either. (Oh, one other idea - using Hubris to export QuickCheck to Ruby directly. RushCheck looks a bit moribund these days...)<br />
<br />
'''Who:''' Mark<br />
<br />
====Leksah====<br />
'''What:''' [http://leksah.org/ Leksah] is a Haskell IDE written in Haskell. Goal for 1.0 is mainly to fix issues in 0.8 rather than add new features, but it would also be nice to make some more progress on replacing GtkSourceView with Yi. Support for running QuickCheck and HUnit may be something we could slip into 1.0.<br />
<br />
'''Who:''' Hamish<br />
<br />
=== Dates ===<br />
If you want to propose a date, add it to the list below.<br />
<br />
It has been proposed that we have the date set at the weekend of the 16th-18th of July. (I [Axman6] would prefer it to be a week earlier, because the 19th is the first day of uni at ANU and UNSW). <br />
<br />
<table border="1"><br />
<tr><br />
<td>Date</td><br />
<td>Who can make it</td><br />
<td>Who can't</td><br />
<td>Comments</td><br />
</tr><br />
<br />
<tr><br />
<td>July 9th-11th</td><br />
<td>Alex Mason<br />Ivan Miljenovic</td><br />
<td>Manuel Chakravarty</td><br />
<td>-</td><br />
</tr><br />
<br />
<tr><br />
<td>July 16th-18th</td><br />
<td>Alex Mason<br />Ivan Miljenovic</td><br />
<td>-</td><br />
<td>This ends the day before ANU and UNSW terms begin</td><br />
</tr><br />
</table><br />
<br />
== Related Links ==<br />
<br />
* [[OzHaskell]]<br />
* [http://www.housing.unsw.edu.au/housing/short_term/short_term.php?p=overview Accommodation near UNSW]</div>Ivanmhttps://wiki.haskell.org/index.php?title=AusHac2010&diff=34164AusHac20102010-03-19T00:02:58Z<p>Ivanm: When I can make it</p>
<hr />
<div>If you've found this page, you use Haskell, ''and'' live in Australia (or at the very least able and willing to travel here), then you're in the right place! We're looking into organising a Haskell [[Hackathon]] some time during the middle of 2010, and this where it shall be organised.<br />
<br />
If you're interested in coming, '''please''' put your name down on the list below, along with your IRC nickname if you're on #haskell, and possibly your email (We'll use this to let you know of any progress we've made, but it's not mandatory). Also, if you've got something to discuss, feel free to add it to the bottom of the page in the Discussion section (just to keep the rest of the page clean and helpful).<br />
<br />
== What we've got so far ==<br />
<br />
===Why===<br />
<br />
Because we miss out on all the fun they have up north, and we've got something to offer. It's also a great chance to meet all these people you talk to on IRC, or read their blogs, and just have a good time, while getting some (potentially) useful work done!<br />
<br />
===When===<br />
<br />
A few dates have been discussed, mainly taking into account when the university holidays are for various universities:<br />
<br />
* ANU: 7 June -> 18 July<br />
* UNSW: 29 June -> 18 July<br />
<br />
So so far we need a weekend between the 28th of June and the 18th of July.<br />
<br />
We're looking at organising it over a weekend, and I (Axman6) would quite like to have it start on a Friday, ending on Sunday. This does not at all mean that those who can’t make the Friday will miss out, the more people we have, the better. But I think that having more time will mean that we can get more done (which is the point right?).<br />
<br />
===Where===<br />
<br />
Manuel Chakravarty and Ben Lippmeier have said there should be no problem finding a room at UNSW, with the only possible problem being Internet access for everyone, but hopefully something can be arranged by that time.<br />
<br />
===Who===<br />
<br />
If you're interested in coming, please show your interest by adding your details to the list below (if you don't have an account, please email me (Axman6) your details and I'll add you).<br />
<br />
<table border="1px"><br />
<tr><br />
<td>Name</td><br />
<td>IRC Nickname</td><br />
<td>Email</td><br />
<td>Availability</td><br />
<td>Preferred date</td><br />
<td>Comment</td><br />
</tr><br />
<br />
<tr><br />
<td>Alex Mason</td><br />
<td>Axman6</td><br />
<td>axman6@gmail.com</td><br />
<td>Probably any weekend during the ANU holidays</td><br />
<td>-</td><br />
<td>Organiser... sort of</td><br />
</tr><br />
<br />
<br />
<tr><br />
<td>[[:User:ivanm|Ivan Miljenovic]]</td><br />
<td>ivanm</td><br />
<td>Ivan <dot> Miljenovic <at> gmail <dot> com</td><br />
<td>*shrug* lazy PhD student, so whenever</td><br />
<td>&nbsp;&nbsp; <=== </td><br />
<td>ditto</td><br />
</tr><br />
<br />
<tr><br />
<td>Tony Morris</td><br />
<td>dibblego</td><br />
<td>code@tmorris.net</td><br />
<td>Nothing specific</td><br />
<td>-</td><br />
<td>Tentative, depending on health</td><br />
</tr><br />
<br />
<tr><br />
<td>Manuel Chakravarty</td><br />
<td>TacticalGrace</td><br />
<td>chak@justtesting.org</td><br />
<td>I'm away 4-11 July; will probably not be able to attend all of it regardless of date</td><br />
<td>Probably weekend of the 18th July</td><br />
<td>Will help getting a room at UNSW</td><br />
</tr><br />
<br />
<tr><br />
<td>Mark Wotton</td><br />
<td>blackdog</td><br />
<td>mwotton@gmail.com</td><br />
<td>flexible, but weekend</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>David Terei</td><br />
<td>dterei</td><br />
<td>dave.terei@gmail.com</td><br />
<td>I'm away from April - start of August. Probably can't attend given proposed dates</td><br />
<td>Any weekend after August 19th</td><br />
<td></td><br />
</tr><br />
<br />
<tr><br />
<td>Hamish Mackenzie</td><br />
<td>hamishmack</td><br />
<td>hamish.k.mackenzie@googlemail.com</td><br />
<td>Any weekend</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<tr><br />
<td>Ben Lippmeier</td><br />
<td>benl23</td><br />
<td>benl@ouroborus.net</td><br />
<td>flexible</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<tr><br />
<td>Stephen Blackheath</td><br />
<td>blackh</td><br />
<td>naughty.biscuit.stephen@blacksapphire.com</td><br />
<td>Any time</td><br />
<td></td><br />
<td>Please fix date soon if poss</td><br />
</tr><br />
<br />
<tr><br />
<td>Erik de Castro Lopo</td><br />
<td>m3ga</td><br />
<td>erikd@mega-nerd.com</td><br />
<td>Weekends</td><br />
<td></td><br />
<td></td><br />
</tr><br />
</table><br />
<br />
== Discussion ==<br />
<br />
=== Possible Projects ===<br />
<br />
====Generic graph class====<br />
'''What:''' I (Ivan) last year floated the idea of replacing the current default array-based Graph data type with an extensible set of classes with default instances. There's various interest about this around and I've done some work on it, but if there's anyone else coming it'd be better to bounce ideas together about how to define such classes.<br />
<br />
'''Who:''' Ivan M<br />
<br />
====Gloss-based plots====<br />
'''What:''' Either an alternative graphing back end to Criterion that only relies on OpenGL (through the use of Gloss), or a library for plotting. At the moment Gloss looks like it may only be suitable for bar type graphs, but we'll see. (We may look into writing some other library that's better suited than Gloss, as Gloss is aimed at students learning haskell, and wanting to just get something drawn)<br />
<br />
'''Who:''' Ivan M, Alex M<br />
<br />
====GHC LLVM backend====<br />
'''What:''' The recent work dome by David Terei on an LLVM backend for GHC has shown some fantastic results, and getting it to a point where it could become the default GHC backend is something a lot of people would really like to see.<br />
<br />
'''Who:''' Alex M, Manuel, Erik<br />
<br />
====Accelerate====<br />
'''What:''' [http://hackage.haskell.org/package/accelerate Accelerate] is a Haskell EDSL for regular array computations. The aim is to make it generate so blindingly fast code that the C folks start to cry. An LLVM backend is in very early stages of development and a CUDA GPU backend is good enough to run some first small Accelerate programs.<br />
<br />
'''Who:''' Manuel, Alex M<br />
<br />
====Hubris====<br />
'''What:''' [http://github.com/mwotton/hubris Hubris] is a bridge between Ruby and Haskell. There are two main options - working on Hubris itself (adding instances for more data types, making it easier to install, chasing the 64-bit linking bug...) or actually building something cool with it. Open to either. (Oh, one other idea - using Hubris to export QuickCheck to Ruby directly. RushCheck looks a bit moribund these days...)<br />
<br />
'''Who:''' Mark<br />
<br />
====Leksah====<br />
'''What:''' [http://leksah.org/ Leksah] is a Haskell IDE written in Haskell. Goal for 1.0 is mainly to fix issues in 0.8 rather than add new features, but it would also be nice to make some more progress on replacing GtkSourceView with Yi. Support for running QuickCheck and HUnit may be something we could slip into 1.0.<br />
<br />
'''Who:''' Hamish<br />
<br />
=== Dates ===<br />
If you want to propose a date, add it to the list below.<br />
<br />
It has been proposed that we have the date set at the weekend of the 16th-18th of July. (I [Axman6] would prefer it to be a week earlier, because the 19th is the first day of uni at ANU and UNSW). <br />
<br />
<table border="1"><br />
<tr><br />
<td>Date</td><br />
<td>Who can make it</td><br />
<td>Comments</td><br />
</tr><br />
<br />
<tr><br />
<td>July 9th-11th</td><br />
<td>Alex Mason<br />Ivan Miljenovic</td><br />
<td>-</td><br />
</tr><br />
<br />
<tr><br />
<td>July 16th-18th</td><br />
<td>Alex Mason<br />Ivan Miljenovic</td><br />
<td>This ends the day before ANU and UNSW terms begin</td><br />
</tr><br />
</table><br />
<br />
== Related Links ==<br />
<br />
* [[OzHaskell]]</div>Ivanmhttps://wiki.haskell.org/index.php?title=Hackathon&diff=34131Hackathon2010-03-18T02:36:32Z<p>Ivanm: Add link to AusHack2010</p>
<hr />
<div>[[Image:Hac-axe-icon.png|Hac icon]]<br />
<br />
'''Hac: The Haskell Hackathon'''<br />
<br />
The Haskell developer community holds regular hackathons, to get<br />
together, collaborate, and work on key tools and infrastructure.<br />
<br />
* [[AusHac2010|Proposed Australian Hackathon, July 2010]]<br />
* [[ZuriHac|Zurich, Mar 2010]]<br />
* [[HacPDX|Portland, OR, Sep 2009]]<br />
* [[Hac7|Edinburgh, Aug 2009]]<br />
* [[Hac φ|Philadelphia, July 2009]]<br />
* [[Hac5|Utrecht, Apr 2009]]<br />
* [[Hac 2008|Göteborg, Apr 2008]]<br />
* [[Hac 2007 II|Freiburg, Oct 2007]]<br />
* [[Hac 2007|Oxford, Jan 2007]]<br />
* [http://hackage.haskell.org/trac/ghc/wiki/Hackathon Portland, Sep 2006]<br />
<br />
[[Category:Events]]<br />
[[Category:Hackathon]]</div>Ivanmhttps://wiki.haskell.org/index.php?title=User:Ivanm&diff=34119User:Ivanm2010-03-17T11:54:44Z<p>Ivanm: s/various/following/</p>
<hr />
<div>Wow, you mean someone is actually interested in me? :o<br />
<br />
== What I do ==<br />
<br />
I'm currently doing a PhD at [https://www.anu.edu.au/ ANU] under the supervision of [http://cs.anu.edu.au/~bdm/ Professor Brendan McKay].<br />
<br />
== Code I write ==<br />
<br />
I'm responsible for the following Haskell software packages:<br />
<br />
* [http://hackage.haskell.org/package/graphviz graphviz] "Bindings" to the [http://graphviz.org Graphviz] suite of graph visualisation tools.<br />
<br />
* [http://hackage.haskell.org/package/Graphalyze Graphalyz] Library for using graphs to analyse the relationships inherent in discrete data (used by SourceGraph).<br />
<br />
* [http://hackage.haskell.org/package/SourceGraph SourceGraph] Use graph theory to analyse your Haskell code. Related papers:<br />
** My [http://ivanmiljenovic.files.wordpress.com/2008/11/honoursthesis.pdf Mathematics Honours thesis]<br />
** The [http://ivanmiljenovic.files.wordpress.com/2010/03/sourcegraph_pepm10_reprint.pdf paper] I presented at [http://www.program-transformation.org/PEPM10/ PEPM'10].<br />
*** The [http://ivanmiljenovic.files.wordpress.com/2010/03/sourcegraph_pepm10_slides.pdf slides] I used.<br />
<br />
* [[Gentoo#haskell-updater]] (along with the rest of the Gentoo-Haskell team, though I started it and am the main developer: the others are too scared of me to make changes! :p).<br />
<br />
=== Un-released code ===<br />
<br />
For my sins, ever since I started my honours in mathematics, I've been writing more and more graph-related code. Here's a sample of what I'm doing:<br />
<br />
* [http://www.haskell.org/pipermail/haskell-cafe/2009-June/063402.html Generic Graph Classes]; a rough-and-ready first draft is available upon request.<br />
<br />
* A Partial Latin Square generator (a complete re-write of the project with which I learnt Haskell that was originally based upon [[Sudoku#Sudoku_incrementally.2C_.C3.A0_la_Bird]]; this is waiting on the following project.<br />
<br />
* An implementation of [http://cs.anu.edu.au/~bdm/nauty/ nauty] in Haskell (yes, I know about [http://hackage.haskell.org/package/hgal hgal], but it's slow and unmaintained). Work on this is halted until the generic graph classes are sorted out (and when I can pry some time out from hacking on graphviz, etc.).<br />
<br />
=== Not quite code, but still... ===<br />
<br />
* I'm an unofficial developer in the [[Gentoo]]-Haskell team (which means I write a lot of ebuilds for it, but haven't bothered to make it official). My work on haskell-updater grew out of my frustration at having to manually rebuild packages.<br />
<br />
== Links ==<br />
<br />
* My [http://ivanmiljenovic.wordpress.com blog]</div>Ivanmhttps://wiki.haskell.org/index.php?title=User:Ivanm&diff=34118User:Ivanm2010-03-17T11:52:30Z<p>Ivanm: Actually provide some info about me</p>
<hr />
<div>Wow, you mean someone is actually interested in me? :o<br />
<br />
== What I do ==<br />
<br />
I'm currently doing a PhD at [https://www.anu.edu.au/ ANU] under the supervision of [http://cs.anu.edu.au/~bdm/ Professor Brendan McKay].<br />
<br />
== Code I write ==<br />
<br />
I'm responsible for the various Haskell software packages:<br />
<br />
* [http://hackage.haskell.org/package/graphviz graphviz] "Bindings" to the [http://graphviz.org Graphviz] suite of graph visualisation tools.<br />
<br />
* [http://hackage.haskell.org/package/Graphalyze Graphalyz] Library for using graphs to analyse the relationships inherent in discrete data (used by SourceGraph).<br />
<br />
* [http://hackage.haskell.org/package/SourceGraph SourceGraph] Use graph theory to analyse your Haskell code. Related papers:<br />
** My [http://ivanmiljenovic.files.wordpress.com/2008/11/honoursthesis.pdf Mathematics Honours thesis]<br />
** The [http://ivanmiljenovic.files.wordpress.com/2010/03/sourcegraph_pepm10_reprint.pdf paper] I presented at [http://www.program-transformation.org/PEPM10/ PEPM'10].<br />
*** The [http://ivanmiljenovic.files.wordpress.com/2010/03/sourcegraph_pepm10_slides.pdf slides] I used.<br />
<br />
* [[Gentoo#haskell-updater]] (along with the rest of the Gentoo-Haskell team, though I started it and am the main developer: the others are too scared of me to make changes! :p).<br />
<br />
=== Un-released code ===<br />
<br />
For my sins, ever since I started my honours in mathematics, I've been writing more and more graph-related code. Here's a sample of what I'm doing:<br />
<br />
* [http://www.haskell.org/pipermail/haskell-cafe/2009-June/063402.html Generic Graph Classes]; a rough-and-ready first draft is available upon request.<br />
<br />
* A Partial Latin Square generator (a complete re-write of the project with which I learnt Haskell that was originally based upon [[Sudoku#Sudoku_incrementally.2C_.C3.A0_la_Bird]]; this is waiting on the following project.<br />
<br />
* An implementation of [http://cs.anu.edu.au/~bdm/nauty/ nauty] in Haskell (yes, I know about [http://hackage.haskell.org/package/hgal hgal], but it's slow and unmaintained). Work on this is halted until the generic graph classes are sorted out (and when I can pry some time out from hacking on graphviz, etc.).<br />
<br />
=== Not quite code, but still... ===<br />
<br />
* I'm an unofficial developer in the [[Gentoo]]-Haskell team (which means I write a lot of ebuilds for it, but haven't bothered to make it official). My work on haskell-updater grew out of my frustration at having to manually rebuild packages.<br />
<br />
== Links ==<br />
<br />
* My [http://ivanmiljenovic.wordpress.com blog]</div>Ivanmhttps://wiki.haskell.org/index.php?title=AusHac2010&diff=34116AusHac20102010-03-17T11:29:02Z<p>Ivanm: Description of generic graph class project</p>
<hr />
<div>If you've found this page, you use Haskell, ''and'' live in Australia (or at the very least able and willing to travel here), then you're in the right place! We're looking into organising a Haskell [[Hackathon]] some time during the middle of 2010, and this where it shall be organised.<br />
<br />
If you're interested in coming, '''please''' put your name down on the list below, along with your IRC nickname if you're on #haskell, and possibly your email (We'll use this to let you know of any progress we've made, but it's not mandatory). Also, if you've got something to discuss, feel free to add it to the bottom of the page in the Discussion section (just to keep the rest of the page clean and helpful).<br />
<br />
== What we've got so far ==<br />
<br />
===Why===<br />
<br />
Because we miss out on all the fun they have up north, and we've got something to offer. It's also a great chance to meet all these people you talk to on IRC, or read their blogs, and just have a good time, while getting some (potentially) useful work done!<br />
<br />
===When===<br />
<br />
A few dates have been discussed, mainly taking into account when the university holidays are for various universities:<br />
<br />
* ANU: 7 June -> 18 July<br />
* UNSW: 29 June -> 18 July<br />
<br />
So so far we need a weekend between the 28th of June and the 18th of July.<br />
<br />
We're looking at organising it over a weekend, and I (Axman6) would quite like to have it start on a Friday, ending on Sunday. This does not at all mean that those who can’t make the Friday will miss out, the more people we have, the better. But I think that having more time will mean that we can get more done (which is the point right?).<br />
<br />
===Where===<br />
<br />
Manuel Chakravarty and Ben Lippmeier have said there should be no problem finding a room at UNSW, with the only possible problem being Internet access for everyone, but hopefully something can be arranged by that time.<br />
<br />
===Who===<br />
<br />
If you're interested in coming, please show your interest by adding your details to the list below (if you don't have an account, please email me (Axman6) your details and I'll add you).<br />
<br />
<table border="1px"><br />
<tr><br />
<td>Name</td><br />
<td>IRC Nickname</td><br />
<td>Email</td><br />
<td>Availability</td><br />
<td>Preferred date</td><br />
<td>Comment</td><br />
</tr><br />
<br />
<tr><br />
<td>Alex Mason</td><br />
<td>Axman6</td><br />
<td>axman6@gmail.com</td><br />
<td>Probably any weekend during the ANU holidays</td><br />
<td>-</td><br />
<td>Organiser... sort of</td><br />
</tr><br />
<br />
<br />
<tr><br />
<td>[[:User:ivanm|Ivan Miljenovic]]</td><br />
<td>ivanm</td><br />
<td>Ivan <dot> Miljenovic <at> gmail <dot> com</td><br />
<td>*shrug* lazy PhD student, so whenever</td><br />
<td>&nbsp;&nbsp; <=== </td><br />
<td>ditto</td><br />
</tr><br />
<br />
</table><br />
<br />
== Discussion ==<br />
<br />
=== Possible Projects ===<br />
<br />
====Generic graph class====<br />
'''What:''' I (Ivan) last year floated the idea of replacing the current default array-based Graph data type with an extensible set of classes with default instances. There's various interest about this around and I've done some work on it, but if there's anyone else coming it'd be better to bounce ideas together about how to define such classes.<br />
<br />
'''Who:''' Ivan M<br />
<br />
====Gloss-based plots====<br />
'''What:''' Either an alternative graphing back end to Criterion that only relies on OpenGL (through the use of Gloss), or a library for plotting. At the moment Gloss looks like it may only be suitable for bar type graphs, but we'll see. (We may look into writing some other library that's better suited than Gloss, as Gloss is aimed at students learning haskell, and wanting to just get something drawn)<br />
<br />
'''Who:''' Ivan M, Alex M<br />
<br />
====GHC LLVM backend====<br />
'''What:''' The recent work dome by David Terei on an LLVM backend for GHC has shown some fantastic results, and getting it to a point where it could become the default GHC backend is something a lot of people would really like to see.<br />
<br />
'''Who:''' Alex M<br />
<br />
=== Dates ===<br />
<br />
<br />
== Related Links ==<br />
<br />
* [[OzHaskell]]</div>Ivanmhttps://wiki.haskell.org/index.php?title=OzHaskell&diff=34111OzHaskell2010-03-17T11:13:51Z<p>Ivanm: I'm (Ivan) now in Canberra</p>
<hr />
<div>'''There is AngloHaskell and now AmeroHaskell. Doesn't that call for OzHaskell?'''<br />
<br />
Who would be interested to have a Haskell event in Australia, possibly in Sydney? This is just a wild idea without any concrete date or format yet. Jot down any suggestions on this page.<br />
<br />
Interested Haskellers:<br />
<br />
* [[:User:Chak|Manuel Chakravarty]] (Sydney)<br />
* [[:User:TonyMorris|Tony Morris]] (Brisbane)<br />
* [[:User:Brecknell|Matthew Brecknell]] (Brisbane, will travel, prefer late Jan)<br />
* [[:User:Mark_Wassell|Mark Wassell]] - Prefer Jan/Feb option.<br />
* [[:User:Rl|Roman Leshchinskiy]]<br />
* [[:User:cbrad|Brad Clow]] (Brisbane)<br />
* [[:User:nornagon|Jeremy Apthorp]]<br />
* [[:User:AndrewA|Andrew Appleyard]] (Sydney)<br />
* [[:User:bjpop|Bernie Pope]] (Melbourne)<br />
* [[:User:benl23|Ben Lippmeier]]<br />
* [[:User:RohanDrape|Rohan Drape]] (Melbourne)<br />
* [[:User:ivanm|Ivan Miljenovic]] (Canberra)<br />
* [[:User:EricWilligers|Eric Willigers]]<br />
* [[:User:TonySloane|Tony Sloane]] (Sydney)<br />
* [[:User:Bens|Ben Sinclair]] (Sydney)<br />
* [[:User:andrep|Andre Pang]]<br />
* [[:User:AndrewBromage|Andrew Bromage]] (Melbourne)<br />
* [[:User:Droberts|Dale Roberts]] (Sydney)<br />
* [[:User:GeoffWilson|Geoff Wilson]] (Melbourne)<br />
* [[:User:Saulzar|Oliver Batchelor]] (Brisbane)<br />
* [[:User:Nick|Nick Seow]] (Sydney)<br />
* [[:User:sseefried|Sean Seefried]] (Sydney)<br />
* [[:User:green_tea|Alexis Hazell]] (Melbourne)<br />
* [[:User:PhilipDerrin|Philip Derrin]] (Sydney)<br />
* [[:User:Jeeva|Jeeva]] (Sydney)<br />
* [[:User:michaelneale|Michael Neale]] (Brisbane)<br />
* [[:User:rus|Ruslan Abdulkhalikov]] (Sydney)<br />
* [[:User:doverton|David Overton]] (London, soon to be Melbourne)<br />
* [[:User:mleeming|Michael Leeming]] (Sydney)<br />
* [[:User:horsfall|Ben Horsfall]] (Melbourne)<br />
* [[:User:trh|Toby Hutton]] (Melbourne)<br />
* [[:User:OJ|OJ Reeves]] (Brisbane)<br />
(Add your name!)<br />
<br />
== Possible dates ==<br />
<br />
How about one of the following between Easter and ANZAC day:<br />
<br />
* Friday 4/ Saturday 5 April<br />
* Friday 11/ Saturday 12 April<br />
* Friday 18/ Saturday 19 April<br />
<br />
== Format ==<br />
<br />
How about the following?<br />
<br />
* One day meeting with informal talks and demos (preferably on a Friday)<br />
* There could be a second, even less formal day, for those who want to hang out some more and maybe some hacking<br />
* Run it at the University of New South Wales, Sydney<br />
<br />
(Add your thoughts to the above.)<br />
<br />
== Talks and demos ==<br />
<br />
Do you have anything you'd like to talk about or a system you'd like to demo? '''This is just a tentative list - you commit to nothing.'''<br />
<br />
=== Talk proposals ===<br />
<br />
* Manuel Chakravarty: ''Type-level Programming with Type Families''<br />
::GHC recently gained support for data families and type synonym families (which are a generalisation of our earlier proposal for associated types). In this talk, I'd give an overview over this new language feature, illustrate what it is good for, and discuss why I believe it fits Haskell better than functional dependencies.<br />
* Bernie Pope: ''The GHCi debugger''<br />
:: A new breakpoint debugger has been added to GHCi. In this talk, I'd demonstrate how to use the debugger, and also go into some detail about how it works. I might even discuss the relative advantages and disadvantages of this debugger over tools such as Hat.<br />
<br />
=== Demo proposals ===<br />
<br />
* rohan drape: ''supercollider for haskellers''<br />
:: an introduction to, and demonstration of, the [http://slavepianos.org/rd/f/207949/ hsc3] haskell bindings to the [http://supercollider.svn.sourceforge.net/viewvc/*checkout*/supercollider/trunk/build/Help/Help.html supercollider3] real-time audio synthesiser; or making experimental music in experimental haskell.<br />
<br />
[[Category:Events]]</div>Ivanmhttps://wiki.haskell.org/index.php?title=AusHac2010&diff=34110AusHac20102010-03-17T11:12:38Z<p>Ivanm: Adding myself to the list with some projects</p>
<hr />
<div>= AusHac2010 =<br />
<br />
If you've found this page, you use Haskell, ''and'' live in Australia (or at the very least able and willing to travel here), then you're in the right place! We're looking into organising a Haskell [[Hackathon]] some time during the middle of 2010, and this where it shall be organised.<br />
<br />
If you're interested in coming, '''please''' put your name down on the list below, along with your IRC nickname if you're on #haskell, and possibly your email (We'll use this to let you know of any progress we've made, but it's not mandatory). Also, if you've got something to discuss, feel free to add it to the bottom of the page in the Discussion section (just to keep the rest of the page clean and helpful).<br />
<br />
== What we've got so far ==<br />
<br />
'''Why:''' Because we miss out on all the fun they have up north, and we've got something to offer. It's also a great chance to meet all these people you talk to on IRC, or read their blogs, and just have a good time, while getting some (potentially) useful work done!<br />
<br />
'''When:''' A few dates have been discussed, mainly taking into account when the university holidays are for various universities:<br />
<br />
* ANU: 7 June -> 18 July<br />
* UNSW: 29 June -> 18 July<br />
<br />
So so far we need a weekend between the 28th of June and the 18th of July.<br />
<br />
We're looking at organising it over a weekend, and I (Axman6) would quite like to have it start on a Friday, ending on Sunday. This does not at all mean that those who can’t make the Friday will miss out, the more people we have, the better. But I think that having more time will mean that we can get more done (which is the point right?).<br />
<br />
'''Where:''' Manuel Chakravarty and Ben Lippmeier have said there should be no problem finding a room at UNSW, with the only possible problem being Internet access for everyone, but hopefully something can be arranged by that time.<br />
<br />
'''Who:''' If you're interested in coming, please show your interest by adding your details to the list below (if you don't have an account, please email me (Axman6) your details and I'll add you).<br />
<br />
<table border="1px"><br />
<tr><br />
<td>Name</td><br />
<td>IRC Nickname</td><br />
<td>Email</td><br />
<td>Availability</td><br />
<td>Preferred date</td><br />
<td>Comment</td><br />
</tr><br />
<br />
<tr><br />
<td>Alex Mason</td><br />
<td>Axman6</td><br />
<td>axman6@gmail.com</td><br />
<td>Probably any weekend during the ANU holidays</td><br />
<td>-</td><br />
<td>Organiser... sort of</td><br />
</tr><br />
<br />
<br />
<tr><br />
<td>[[:User:ivanm|Ivan Miljenovic]]</td><br />
<td>ivanm</td><br />
<td>Ivan <dot> Miljenovic <at> gmail <dot> com</td><br />
<td>*shrug* lazy PhD student, so whenever</td><br />
<td>&nbsp;&nbsp; <=== </td><br />
<td>ditto</td><br />
</tr><br />
<br />
</table><br />
<br />
= Discussion =<br />
<br />
== Possible Projects ==<br />
<br />
* '''Generic graph class:''' Ivan<br />
<br />
* '''Gloss-based plots:''' Ivan, Alex<br />
<br />
== Related Links ==<br />
<br />
* [[OzHaskell]]</div>Ivanmhttps://wiki.haskell.org/index.php?title=AusHac2010&diff=34109AusHac20102010-03-17T11:06:07Z<p>Ivanm: Grammar, wording, links, etc.</p>
<hr />
<div>= AusHac2010 =<br />
<br />
If you've found this page, you use Haskell, ''and'' live in Australia (or at the very least able and willing to travel here), then you're in the right place! We're looking into organising a Haskell [[Hackathon]] some time during the middle of 2010, and this where it shall be organised.<br />
<br />
If you're interested in coming, '''please''' put your name down on the list below, along with your IRC nickname if you're on #haskell, and possibly your email (We'll use this to let you know of any progress we've made, but it's not mandatory). Also, if you've got something to discuss, feel free to add it to the bottom of the page in the Discussion section (just to keep the rest of the page clean and helpful).<br />
<br />
== What we've got so far ==<br />
<br />
'''Why:''' Because we miss out on all the fun they have up north, and we've got something to offer. It's also a great chance to meet all these people you talk to on IRC, or read their blogs, and just have a good time, while getting some (potentially) useful work done!<br />
<br />
'''When:''' A few dates have been discussed, mainly taking into account when the university holidays are for various universities:<br />
<br />
* ANU: 7 June -> 18 July<br />
* UNSW: 29 June -> 18 July<br />
<br />
So so far we need a weekend between the 28th of June and the 18th of July.<br />
<br />
We're looking at organising it over a weekend, and I (Axman6) would quite like to have it start on a Friday, ending on Sunday. This does not at all mean that those who can’t make the Friday will miss out, the more people we have, the better. But I think that having more time will mean that we can get more done (which is the point right?).<br />
<br />
'''Where:''' Manuel Chakravarty and Ben Lippmeier have said there should be no problem finding a room at UNSW, with the only possible problem being Internet access for everyone, but hopefully something can be arranged by that time.<br />
<br />
'''Who:''' If you're interested in coming, please show your interest by adding your details to the list below (if you don't have an account, please email me (Axman6) your details and I'll add you).<br />
<br />
<table border="1px"><br />
<tr><br />
<td>Name</td><br />
<td>IRC Nickname</td><br />
<td>Email</td><br />
<td>Availability</td><br />
<td>Preferred date</td><br />
<td>Comment</td><br />
</tr><br />
<br />
<tr><br />
<td>Alex Mason</td><br />
<td>Axman6</td><br />
<td>axman6@gmail.com</td><br />
<td>Probably any weekend during the ANU holidays</td><br />
<td>-</td><br />
<td>Organiser... sort of</td><br />
</tr><br />
</table><br />
<br />
= Discussion =</div>Ivanmhttps://wiki.haskell.org/index.php?title=Gentoo&diff=28721Gentoo2009-06-21T12:06:57Z<p>Ivanm: Add information on haskell-updater</p>
<hr />
<div>==Packages==<br />
[http://gentoo.org/ Gentoo Linux] has fairly good support for Haskell.<br />
<br />
There are packages for [[GHC]] and more than 60 other Haskell libraries and tools. There are also packages for other Haskell implementations like [[Hugs|Hugs98]] and [[Helium]].<br />
<br />
You can check the currently available versions of packages:<br />
<br />
* [http://packages.gentoo.org/category/dev-haskell libraries and tools]<br />
* [http://packages.gentoo.org/package/dev-lang/ghc ghc]<br />
* [http://packages.gentoo.org/package/dev-lang/hugs98 hugs98]<br />
* [http://packages.gentoo.org/package/dev-util/darcs darcs]<br />
* [http://packages.gentoo.org/package/x11-wm/xmonad xmonad]<br />
<br />
There is support for most packages on several architectures: ''x86'', ''amd64'', ''sparc'' and ''ppc''.<br />
There is support for some packages on ''ppc64'', ''alpha'', ''ia64'' and ''hppa''.<br />
<br />
==Gentoo Haskell Overlay==<br />
If you want the most up to date (but also most untested) packages you can use the Gentoo Haskell Overlay. "Overlays" are package trees for Portage. They contain additional ebuilds for Gentoo. They are maintained by Gentoo developers, but are distributed separately from the main Portage tree. Haskell has [http://code.haskell.org/gentoo/gentoo-haskell/ its own] dedicated overlay containing lots of haskell projects. See the [http://www.gentoo.org/proj/en/overlays/userguide.xml Gentoo Overlays: Users' Guide] for how to use overlays. However, don't forget that like with all overlays, you use the ebuilds there at your own risk. '''Do not report errors in overlay ebuilds to the Gentoo Bugzilla!'''<br />
<br />
==Support and bugs==<br />
* Bugs found in ebuilds within the official tree should be reported in the [http://bugs.gentoo.org Gentoo bugzilla]. Bugs found in the overlay should be reported in the IRC channel.<br />
* There is a #gentoo-haskell [[IRC channel]] on freenode.net for people interested in developing and testing haskell-related ebuilds.<br />
<br />
Filing bugs can also be used to ask for new packages or new versions of existing packages. We would like to encourage users to suggest any packages they feel are useful but are currently not included in portage. Though note that we generally only package released versions of software where there are tarballs available and where there is an expectation that the software will be maintained. We also greatly prefer packages that are distributed via [http://hackage.haskell.org/ Hackage] as it allows us to use automated tools.<br />
<br />
==haskell-updater==<br />
<br />
Work is currently progressing on ''haskell-updater'', the replacement for ghc-updater currently installed with dev-lang/ghc. There are four main advantages:<br />
<br />
* Now supports pkgcore and paludis, not just portage. This can easily be extended if anyone decides to create Yet Another Gentoo Package Manager.<br />
* Will also rebuild Haskell libraries that have had their dependencies changed (ala revdep-rebuild/reconcilio/etc.). That is, it will rebuild packages corresponding to the libraries listed by "ghc-pkg check".<br />
* It will be shipped separately to GHC, which means we can update it (ghc-updater has been frozen due to not wanting to cause problems with versions already installed, etc.).<br />
* It's written in our favourite language (Haskell, of course) rather than a weird conglomeration of bash and Python. This means it's faster (presumably), more flexible, and we're more likely to maintain it since it's in a language we prefer and are more used to.<br />
<br />
The darcs repository is available at [http://code.haskell.org/gentoo/haskell-updater/ here]. For more information, ping ivanm on the #gentoo-haskell [[IRC channel]].<br />
<br />
[[Category:OS]]</div>Ivanmhttps://wiki.haskell.org/index.php?title=Xmonad/Using_xmonad_in_XFCE&diff=20775Xmonad/Using xmonad in XFCE2008-05-03T14:00:56Z<p>Ivanm: Actually give some content</p>
<hr />
<div>{{xmonad}}<br />
[[Category:XMonad]]<br />
<br />
=Introduction=<br />
<br />
This is an updated and hopefully less confusing version of my original blog post located here: [http://ivanmiljenovic.wordpress.com/2008/01/20/xmonad/ X<sup>2</sup>Monad]<br />
<br />
''Why use Xfce with XMonad?''<br />
<br />
Whilst XMonad is a truly excellent Window Manager, alone it doesn't offer the full convenience of an entire Desktop Environment, such as the provided menus, all-in-one configuration settings, consistent dialogs, etc. Out of the three main DEs available in Unix-like Operating Systems - Gnome, KDE and Xfce - the latter is often touted as the most "nimble" of the lot. In my own opinion, it is simpler to use than KDE but with more configuration options (and a saner environment) than Gnome.<br />
<br />
= Configuring XMonad to work with Xfce =<br />
<br />
This guide assumes that you're using at least version 4.4 of Xfce, and have both XMonad and XMonad-Contrib 0.7 installed. First we need to configure Xfce to play nicely, before adding in XMonad.<br />
<br />
==Xfce Settings==<br />
<br />
We're going to utilise Xfce's Session Manager to make sure that xfwm4 (Xfce's default WM) is no longer started. Preferably, it'd be nice if we could have XMonad started this way as well (or even set in a configuration option like with Gnome or KDE), but the former isn't possible until XMonad supports the required Session Management Protocol and the latter isn't possible in Xfce at all.<br />
<br />
===Backing up your settings===<br />
<br />
If you're already using Xfce, you may wish to first backup your ~/.config directory. Whilst Xfce isn't the only application/library/etc. to utilise the ~/.config directory to store it's settings, it does so in a few different sub-directories (i.e. in some cases specific applications have their own settings directory), it's easier to backup the whole thing.<br />
<br />
Note that as far as I know, it isn't possible to have for the same user both a standard Xfce login and an XMonad Xfce login. Whilst you can have different sessions to determine whether you use XMonad or not, there are some settings - such as the panel layout - that aren't saved on a per-session basis.<br />
<br />
===Start a new session===<br />
<br />
For backup purposes in case something goes wrong with your XMonad settings, it is recommended to create a new Xfce session. To do so, open the "Sessions and Startup" option dialog either from the "Settings" section of the Xfce menu, or in Xfce's Settings Manager (xfce-setting-show). Enable the the session chooser and automatic saving of sessions, then logout and log back in again. When the session chooser appears, choose to create a new session.<br />
<br />
A word of warning: I found that the session chooser kept crashing Xfce on a freshly installed Xfce-4.4.2. If this happens to you, delete the ~/.config/xfce-session directory.<br />
<br />
===Setting up Xfce===<br />
<br />
Open up the Xfce settings manager. There, you can customise Xfce to your hearts content. Note that the following settings dialogs won't be applicable once we start XMonad:<br />
* Window Manager<br />
* Window Manager Tweaks<br />
* Workspaces and Margins<br />
The last option isn't required, as Xfce will happily use XMonad's workspaces.<br />
<br />
These options are recommended:<br />
* Under "Desktop", let Xfce manage the desktop, but under Behaviour set the Desktop Icons to "None". This way, Xfce will control your wallpaper, etc., allowing you to have random lists, different wallpapers for different screens for multi-head setups, etc.<br />
* The Keyboard settings can be used to set keyboard shortcuts for those multimedia keys (e.g. XF86AudioMute) found on many keyboards, since these types of keys are currently difficult to create shortcuts for in XMonad. Simply setup the various keyevents to these keybindinds for use with xmodmap in ~/.Xmodmap and Xfce will read these on start.<br />
* Mouse: if you don't have or want to use a mouse, there's a limited type of mouse emulation available where you can use the Numpad arrow keys to move the cursor.<br />
* For "Preferred Applications", set whichever terminal emulator you plan to use. I find that Xfce's own Terminal application to work quite nicely with XMonad and to resize rather well.<br />
<br />
If you so wish, you can now disable the session chooser, though I suggest you leave it enabled until you've successfully managed to login to your Xfce/XMonad environment several times.<br />
<br />
===Xfce's Panels===<br />
<br />
If you so wish you can now customize the panels and the plugins on them. This can be safely left to later, however. With XMonad, I typically only have one panel rather than the default two. In terms of panel plugins, I've removed the Task List, but kept the pager: with the EWMH settings in XMonad, Xfce's pager acts as a mini-preview of your various layouts!<br />
<br />
===Ensure XMonad gets started===<br />
<br />
Because XMonad doesn't support the session protocol and Xfce is missing an option to specify which Window Manager to use, we must ensure that XMonad is started each time we log in. '''WARNING!!! Make sure you don't log out and back in again after setting this and before you reach the stage where we kill xfwm4, or else you will have two different Window Managers fighting each other!!!''' Run Xfce's Autostarted Applications manager (either under the Settings section in the Xfce menu or run <code>xfce4-autostart-editor</code>). There, add a new autostarted application with the command being simply <code>xmonad</code> (this of course assumes XMonad is in your path... otherwise, specify the full path to the binary) with whatever name you want. Ensure that the new autostarted application entry you just created is ticked.<br />
<br />
To repeat the warning: '''After creating this, don't exit Xfce until you've finished configuring XMonad and have killed xfwm4!!!'''<br />
<br />
==XMonad Hacking==<br />
<br />
It's now time to customise XMonad. You have a wide variety of Layouts, Hooks, etc. to experiment with. Here are some basic changes that you ''should'' make:<br />
<br />
* Replace the old gaps setup with ManageDocks (especially since Gaps are deprecated in the current darcs version of XMonad and won't be present from 0.8 onwards). This also involves changing the keybinding to hide/show panels.<br />
* Use the EWMH hooks so that Xfce can obtain Workspace information from XMonad and vice versa. This lets the Pager plugin to the panel act as a mini workspace-previewer, and let you choose which workspace to view by clicking on the pager. Note that by using this, the pager will also automatically add/remove workspaces based upon how many workspaces XMonad has.<br />
* Use ''mod4'' (aka the "Windows" key) as the modifier key. Many applications - including Xfce - use the Alt key for keybindings themselve (e.g. Xfce uses Alt-F2 to show its run dialog).<br />
* With keybindings, ''xfce4-session-logout'' to exit for the Mod-Shift-q keybinding, rather than just exiting XMonad (which will leave Xfce still running).<br />
* Use Xfce's Terminal as the terminal program.<br />
<br />
Here is a minimal ~/.xmonad/xmonad.hs that demonstrates how to do this. Note that it is expected that you copy and edit the sample configuration file to get the remaining keybindings present, or else use something like the EZConfig extension in the Contrib library to selectively add/edit/remove keybindings from the default list. As it stands, this configuration file ''isn't'' sufficient, as it doesn't list all the keybindings and in fact won't compile due to the "..." present in the keybinding list.<br />
<br />
<haskell><br />
import XMonad<br />
import qualified Data.Map as M<br />
import XMonad.Hooks.ManageDocks<br />
import XMonad.Hooks.EwmhDesktops<br />
<br />
myTerminal = "Terminal"<br />
<br />
myKeys conf@(XConfig {XMonad.modMask = modMask}) = M.fromList $<br />
[<br />
...<br />
, ((modMask, xK_b), sendMessage ToggleStruts)<br />
...<br />
, ((modMask .|. shiftMask, xK_q), spawn "xfce4-session-logout")<br />
...<br />
]<br />
<br />
main = xmonad defaultConfig<br />
{ manageHook = manageDocks <+> manageHook defaultConfig<br />
, logHook = ewmhDesktopsLogHook<br />
, layoutHook = ewmhDesktopsLayout $ avoidStruts $ layoutHook defaultConfig<br />
, modMask = mod4Mask<br />
, keys = myKeys<br />
}<br />
</haskell><br />
<br />
If you so wish, you can also use ''xfrun4'' or ''xfce4-appfinder'' as the program launchers for the Mod-p and Mod-Shift-p keybindings instead of the default dmenu and gmrun.<br />
<br />
You may wish to run ghci or something on your ~/.xmonad/xmonad.hs configuration file to make sure it's correct before moving on to the next section.<br />
<br />
=Get XMonad Going!=<br />
<br />
It's now time to ditch Xfce's default Window Manager xfwm4 and replace it with something better (i.e. XMonad). To do so, it's probably easiest to run xfrun4 with Xfce's default key combination Alt-F2 and enter the following:<br />
<code><br />
killall xfwm4 && xmonad<br />
</code><br />
<br />
If all went well, you'll now find yourself in XMonad!<br />
<br />
=That's all folks!=<br />
<br />
Congratulations, you have now successfully configured XMonad and Xfce so that XMonad acts as Xfce's Window Manager! Sample screenshots to come.</div>Ivanmhttps://wiki.haskell.org/index.php?title=Xmonad/Using_xmonad_in_XFCE&diff=20772Xmonad/Using xmonad in XFCE2008-05-03T11:01:15Z<p>Ivanm: </p>
<hr />
<div>{{xmonad}}<br />
[[Category:XMonad]]<br />
<br />
=Introduction=<br />
<br />
This is an updated and hopefully less confusing version of my original blog post located here: [http://ivanmiljenovic.wordpress.com/2008/01/20/xmonad/ X<math>^2</math>Monad]<br />
<br />
''Why use Xfce with XMonad?''<br />
<br />
Whilst XMonad is a truly excellent Window Manager, alone it doesn't offer the full convenience of an entire Desktop Environment, such as the provided menus, all-in-one configuration settings, consistent dialogs, etc. Out of the three main DEs available in Unix-like Operating Systems - Gnome, KDE and Xfce - the latter is often touted as the most "nimble" of the lot. In my own opinion, it is simpler to use than KDE but with more configuration options (and a saner environment) than Gnome.<br />
<br />
= Configuring XMonad to work with Xfce =<br />
<br />
This guide assumes that you're using at least version 4.4 of Xfce, and have both XMonad and XMonad-Contrib 0.7 installed. First we need to configure Xfce to play nicely, before adding in XMonad.<br />
<br />
==Xfce Settings==<br />
<br />
We're going to utilise Xfce's Session Manager to make sure that xfwm4 (Xfce's default WM) is no longer started. Preferably, it'd be nice if we could have XMonad started this way as well (or even set in a configuration option like with Gnome or KDE), but the former isn't possible until XMonad supports the required Session Management Protocol and the latter isn't possible in Xfce at all.<br />
<br />
===Backing up your settings===<br />
<br />
If you're already using Xfce, you may wish to first backup your ~/.config directory. Whilst Xfce isn't the only application/library/etc. to utilise the ~/.config directory to store it's settings, it does so in a few different sub-directories (i.e. in some cases specific applications have their own settings directory), it's easier to backup the whole thing.<br />
<br />
Note that as far as I know, it isn't possible to have for the same user both a standard Xfce login and an XMonad Xfce login. Whilst you can have different sessions to determine whether you use XMonad or not, there are some settings - such as the panel layout - that aren't saved on a per-session basis.<br />
<br />
===Start a new session===<br />
<br />
For backup purposes in case something goes wrong with your XMonad settings, it is recommended to create a new Xfce session. To do so, open the "Sessions and Startup" option dialog either from the "Settings" section of the Xfce menu, or in Xfce's Settings Manager (xfce-setting-show). Enable the the session chooser and automatic saving of sessions, then logout and log back in again. When the session chooser appears, choose to create a new session.<br />
<br />
A word of warning: I found that the session chooser kept crashing Xfce on a freshly installed Xfce-4.4.2. If this happens to you, delete the ~/.config/xfce-session directory.<br />
<br />
===Setting up Xfce===<br />
<br />
Open up the Xfce settings manager. There, you can customise Xfce to your hearts content. Note that the following settings dialogs won't be applicable once we start XMonad:<br />
* Window Manager<br />
* Window Manager Tweaks<br />
* Workspaces and Margins<br />
The last option isn't required, as Xfce will happily use XMonad's workspaces.<br />
<br />
These options are recommended:<br />
* Under "Desktop", let Xfce manage the desktop, but under Behaviour set the Desktop Icons to "None". This way, Xfce will control your wallpaper, etc., allowing you to have random lists, different wallpapers for different screens for multi-head setups, etc.<br />
* The Keyboard settings can be used to set keyboard shortcuts for those multimedia keys (e.g. XF86AudioMute) found on many keyboards, since these types of keys are currently difficult to create shortcuts for in XMonad. Simply setup the various keyevents to these keybindinds for use with xmodmap in ~/.Xmodmap and Xfce will read these on start.<br />
* Mouse: if you don't have or want to use a mouse, there's a limited type of mouse emulation available where you can use the Numpad arrow keys to move the cursor.<br />
* For "Preferred Applications", set whichever terminal emulator you plan to use. I find that Xfce's own Terminal application to work quite nicely with XMonad and to resize rather well.<br />
<br />
If you so wish, you can now disable the session chooser, though I suggest you leave it enabled until you've successfully managed to login to your Xfce/XMonad environment several times.<br />
<br />
===Xfce's Panels===<br />
<br />
If you so wish you can now customize the panels and the plugins on them. This can be safely left to later, however. With XMonad, I typically only have one panel rather than the default two. In terms of panel plugins, I've removed the Task List, but kept the pager: with the EWMH settings in XMonad, Xfce's pager acts as a mini-preview of your various layouts!<br />
<br />
==XMonad Hacking==<br />
<br />
It's now time to customise XMonad. You have a wide variety of Layouts, Hooks, etc. to experiment with. Here are some basic changes that you ''should'' make:<br />
<br />
* Replace the old gaps setup with ManageDocks (especially since Gaps are deprecated in the current darcs version of XMonad and won't be present from 0.8 onwards). This also involves changing the keybinding to hide/show panels.<br />
* Use the EWMH hooks so that Xfce can obtain Workspace information from XMonad and vice versa. This lets the Pager plugin to the panel act as a mini workspace-previewer, and let you choose which workspace to view by clicking on the pager. Note that by using this, the pager will also automatically add/remove workspaces based upon how many workspaces XMonad has.<br />
* Use ''mod4'' (aka the "Windows" key) as the modifier key. Many applications - including Xfce - use the Alt key for keybindings themselve (e.g. Xfce uses Alt-F2 to show its run dialog).<br />
* With keybindings, ''xfce4-session-logout'' to exit for the Mod-Shift-q keybinding, rather than just exiting XMonad (which will leave Xfce still running).<br />
* Use Xfce's Terminal as the terminal program.<br />
<br />
Here is a minimal ~/.xmonad/xmonad.hs that demonstrates how to do this. Note that it is expected that you copy and edit the sample configuration file to get the remaining keybindings present, or else use something like the EZConfig extension in the Contrib library to selectively add/edit/remove keybindings from the default list. As it stands, this configuration file ''isn't'' sufficient, as it doesn't list all the keybindings and in fact won't compile due to the "..." present in the keybinding list.<br />
<br />
<haskell><br />
import XMonad<br />
import qualified Data.Map as M<br />
import XMonad.Hooks.ManageDocks<br />
import XMonad.Hooks.EwmhDesktops<br />
<br />
myTerminal = "Terminal"<br />
<br />
myKeys conf@(XConfig {XMonad.modMask = modMask}) = M.fromList $<br />
[<br />
...<br />
, ((modMask, xK_b), sendMessage ToggleStruts)<br />
...<br />
, ((modMask .|. shiftMask, xK_q), spawn "xfce4-session-logout")<br />
...<br />
]<br />
<br />
main = xmonad defaultConfig<br />
{ manageHook = manageDocks <+> manageHook defaultConfig<br />
, logHook = ewmhDesktopsLogHook<br />
, layoutHook = ewmhDesktopsLayout $ avoidStruts $ layoutHook defaultConfig<br />
, modMask = mod4Mask<br />
, keys = myKeys<br />
}<br />
</haskell><br />
<br />
If you so wish, you can also use ''xfrun4'' or ''xfce4-appfinder'' as the program launchers for the Mod-p and Mod-Shift-p keybindings instead of the default dmenu and gmrun.<br />
<br />
You may wish to run ghci or something on your ~/.xmonad/xmonad.hs configuration file to make sure it's correct before moving on to the next section.<br />
<br />
=Get XMonad Going!=<br />
<br />
It's now time to ditch Xfce's default Window Manager xfwm4 and replace it with something better (i.e. XMonad). To do so, it's probably easiest to run xfrun4 with Xfce's default key combination Alt-F2 and enter the following:<br />
<code><br />
killall xfwm4 && xmonad<br />
</code><br />
<br />
[[Image:Xmonad-screen-comp-xfce.jpg|200px|A screenshot of xmonad cooperating with gnome|center]]</div>Ivanmhttps://wiki.haskell.org/index.php?title=Gentoo&diff=17945Gentoo2007-12-24T11:23:32Z<p>Ivanm: Added warning messages related to overlay usage</p>
<hr />
<div>==Packages==<br />
[http://gentoo.org/ Gentoo Linux] has fairly good support for Haskell.<br />
<br />
There are packages for [[GHC]] and more than 60 other Haskell libraries and tools. There are also packages for other Haskell implementations like [[Hugs|Hugs98]] and [[Helium]].<br />
<br />
You can check the currently available versions of packages:<br />
<br />
* [http://packages.gentoo.org/category/dev-haskell libraries and tools]<br />
* [http://packages.gentoo.org/package/dev-lang/ghc ghc]<br />
* [http://packages.gentoo.org/package/dev-lang/hugs98 hugs98]<br />
* [http://packages.gentoo.org/package/dev-util/darcs darcs]<br />
* [http://packages.gentoo.org/package/x11-wm/xmonad xmonad]<br />
<br />
There is support for most packages on several architectures: ''x86'', ''amd64'', ''sparc'' and ''ppc''.<br />
There is support for some packages on ''ppc64'', ''alpha'', ''ia64'' and ''hppa''.<br />
<br />
==Gentoo Haskell Overlay==<br />
If you want the most up to date (but also most untested) packages you can use the Gentoo Haskell Overlay. "Overlays" are package trees for Portage. They contain additional ebuilds for Gentoo. They are maintained by Gentoo developers, but are distributed separately from the main Portage tree. Haskell has [http://www.haskell.org/~gentoo/gentoo-haskell/ its own] dedicated overlay containing lots of haskell projects. See the [http://www.gentoo.org/proj/en/overlays/userguide.xml Gentoo Overlays: Users' Guide] for how to use overlays. However, don't forget that like with all overlays, you use the ebuilds there at your own risk. '''Do not report errors in overlay ebuilds to the Gentoo Bugzilla!'''<br />
<br />
==Support and bugs==<br />
* Bugs found in ebuilds within the official tree should be reported in the [http://bugs.gentoo.org Gentoo bugzilla]. Bugs found in the overlay should be reported in the IRC channel.<br />
* There is a #gentoo-haskell [[IRC channel]] on freenode.net for people interested in developing and testing haskell-related ebuilds.<br />
<br />
Filing bugs can also be used to ask for new packages or new versions of existing packages. We would like to encourage users to suggest any packages they feel are useful but are currently not included in portage. Though note that we generally only package released versions of software where there are tarballs available and where there is an expectation that the software will be maintained. We also greatly prefer packages that are distributed via [http://hackage.haskell.org/ Hackage] as it allows us to use automated tools.<br />
<br />
[[Category:OS]]</div>Ivanmhttps://wiki.haskell.org/index.php?title=OzHaskell&diff=15645OzHaskell2007-09-18T01:49:09Z<p>Ivanm: </p>
<hr />
<div>'''There is AngloHaskell and now AmeroHaskell. Doesn't that call for OzHaskell?'''<br />
<br />
Who would be interested to have a Haskell event in Australia, possibly in Sydney? This is just a wild idea without any concrete date or format yet. Jot down any suggestions on this page.<br />
<br />
Interested Haskellers:<br />
<br />
* [[:User:Chak|Manuel Chakravarty]]<br />
* [[:User:TonyMorris|Tony Morris]]<br />
* [[:User:Brecknell|Matthew Brecknell]] (Brisbane)<br />
* [[:User:Mark_Wassell|Mark Wassell]]<br />
* [[:User:Rl|Roman Leshchinskiy]]<br />
* [[:User:cbrad|Brad Clow]]<br />
* [[:User:nornagon|Jeremy Apthorp]]<br />
* [[:User:AndrewA|Andrew Appleyard]]<br />
* [[:User:bjpop|Bernie Pope]]<br />
* [[:User:benl23|Ben Lippmeier]]<br />
* [[:User:RohanDrape|Rohan Drape]]<br />
* [[:User:ivanm|Ivan Miljenovic]] (Brisbane)</div>Ivanm