https://wiki.haskell.org/api.php?action=feedcontributions&user=Oblosys&feedformat=atomHaskellWiki - User contributions [en]2024-03-28T15:49:44ZUser contributionsMediaWiki 1.35.5https://wiki.haskell.org/index.php?title=Mac_OS_X_Common_Installation_Paths&diff=45432Mac OS X Common Installation Paths2012-04-25T11:20:08Z<p>Oblosys: /* Implementations */</p>
<hr />
<div>The default layout for installed Haskell components follows the conventions of most unix-like systems. On Mac OS X, this layout isn't optimal, and a different layout is used. The layout presented here has several advantages:<br />
<br />
* Follows Apple's Guidelines for file system layout<br />
* Makes it easy for a user to locate all the Haskell components, especially user installed packages<br />
* Enables easy removal of a user installed package, whether they have installed it <tt>--user</tt> or <tt>--global</tt>.<br />
* Facilitate creation of unified, hyper-linked Haddock documentation, optionally with source<br />
<br />
Haskell Platform 2011.2.0.0 (March 2011) and later uses this layout and sets up cabal to use it for built packages. On new installs, if you didn't already have a <tt>~/.cabal/config</tt> file, then it is set up by default. Otherwise, the config file for this layout is placed in <tt>~/.cabal/config.platform</tt> and you can manually move it over, or incorporate it into your existing <tt>config</tt> file.<br />
<br />
<br />
== Implementations ==<br />
<br />
Haskell implementations are generally installed for use by all accounts on the<br />
system. They consist of large collections of executables, libraries, and other<br />
files. These are packaged using Apple's framework, versioning, and bundling<br />
techniques and installed in:<br />
/Library/Frameworks<br />
<br />
For example, GHC 7.0.2 is installed in:<br />
/Library/Frameworks/GHC.framework/Versions/7.0.2-i386<br />
<br />
Executables intended for use from the command line, are be symlink'd into:<br />
/usr/bin<br />
''[Q: Would <tt>/usr/local/bin</tt> be more appropriate? ]''<br />
<br />
Packages that come with the implementation, are be located within the Framework<br />
bundle.<br />
<br />
If the implementation has any GUI applications, these are installed in:<br />
/Applications<br />
<br />
'''NB:''' These guidelines allow for multiple implementations and multiple<br />
versions to co-exist. (With the exception of multiple versions of GUI applications<br />
which can only be done by distinct naming, and the symlinks in <tt>/usr/bin</tt><br />
which can achieved in the normal way: Append the version number to the executable<br />
and then symlink the 'bare' name to the most recent.<br />
<br />
If implementations want to be able to be installed "per user", then the above<br />
paths should be:<br />
~/Library/Frameworks<br />
~/bin<br />
~/Applications<br />
<br />
Not all software for Mac OS X offers a "per user" option on installation, and while<br />
nice, it is by no means universal.<br />
<br />
== User Installed Packages ==<br />
<br />
User installed packages are placed under a "prefix" that depends on if the user<br />
choose to install for all users (<tt>--global</tt>) for just their own use (<tt>--user</tt>):<br />
/Library/Haskell --global<br />
~/Library/Haskell --user<br />
<br />
== Package Component Layout ==<br />
<br />
Cabal offers a large amount of flexibility in where the various pieces of a package<br />
are installed. The GHC package system is rather agnostic about where these pieces are,<br />
and insulates the implementation from such differences. These combine to enable the<br />
choice of package layout to be largely to serve the user.<br />
<br />
For both <tt>--global</tt> and <tt>--user</tt> installs, this is the recommended package layout on Mac OS X:<br />
<br />
{prefix}<br />
{compiler}<br />
lib<br />
{pkgid}<br />
bin -- binaries ($bindir)<br />
lib -- libraries & .hi files ($libdir, $libdir/$libsubdir, $dynlibdir)<br />
include -- include files ($includedir)<br />
libexec -- private binaries ($libexecdir)<br />
share -- data files ($datadir, $datadir/$datasubdir) <br />
doc -- documentation ($docdir)<br />
html -- html doc ($htmldir, $haddockdir)<br />
man -- man pages ($mandir)<br />
<br />
This can be achieved with the following cabal configuration defaults:<br />
install-dirs user<br />
prefix: ~/Library/Haskell/$compiler/lib/$pkgid<br />
bindir: $prefix/bin<br />
libdir: $prefix/lib<br />
libsubdir: <br />
libexecdir: $prefix/libexec<br />
datadir: $prefix/share<br />
datasubdir:<br />
docdir: $datadir/doc<br />
htmldir: $docdir/html<br />
haddockdir: $htmldir<br />
<br />
install-dirs global<br />
prefix: /Library/Haskell/$compiler/lib/$pkgid<br />
bindir: $prefix/bin<br />
libdir: $prefix/lib<br />
libsubdir: <br />
libexecdir: $prefix/libexec<br />
datadir: $prefix/share<br />
datasubdir:<br />
docdir: $datadir/doc<br />
htmldir: $docdir/html<br />
haddockdir: $htmldir<br />
<br />
'''N.B.:'''<br />
* Cabal configuration files don't actually support <tt>~</tt>. You must replace that with <tt>/Users/xxx</tt> where <tt>xxx</tt> is your account name.<br />
* All packages for a given compiler are under a single directory. When an old compiler is removed, all the packages compiled for it can be easily removed too.<br />
* All components for a package are under a single directory. This facilitates easy location and removal of a single package, for either a single compiler, or all installed versions.<br />
* If a package generates different doc for different compilers (it may have different APIs available), then this structure preserves each.<br />
* Executables are also per compilation, which is sometimes important (for Haddock, for example).<br />
<br />
== Executables ==<br />
<br />
Packages that build executables to be run from the command line present a <br />
difficultly. They are built into a per-package <tt>bin</tt> directory, and then should be symlink'd somewhere on the user's PATH. For global installs, the logical place is one of:<br />
/usr/bin<br />
/usr/local/bin<br />
<br />
For user installs, since <tt>~/bin</tt> is not on the <tt>PATH</tt> by default on Mac OS X and may not exist, binaries are symlink'd into:<br />
~/Library/Haskell/bin<br />
<br />
Alas, cabal only supports one location for both kinds of build, and so it is set to tbe the later.<br />
<br />
<br />
----<br />
== References ==<br />
# [http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html#//apple_ref/doc/uid/20002282-BAJHCHJI Apple guidelines for the /Library and ~/Library files]<br />
# [http://www.haskell.org/pipermail/haskell-cafe/2009-December/071150.html MtnViewMark's original e-mail on this topic.]</div>Oblosyshttps://wiki.haskell.org/index.php?title=DHD_UHac/DHD_Program&diff=45422DHD UHac/DHD Program2012-04-24T14:58:36Z<p>Oblosys: /* Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project */</p>
<hr />
<div>__NOTOC__<br />
<br />
This is the final program for the Dutch HUG Day.<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Title<br />
! Speaker<br />
|-<br />
| 9:30<br />
| colspan="2" | ''Coffee and Tea''<br />
|-<br />
| 10:00<br />
| Welcome<br />
| Sean Leather, Stef Joosten<br />
|-<br />
| 10:15<br />
| [[#websockets|Supporting Different Versions of the WebSockets Protocol]]<br />
| Jasper Van der Jeugt<br />
|-<br />
| 10:45<br />
| [[#hesselink|Building Your Own Haskell Ecosystem]]<br />
| Erik Hesselink<br />
|-<br />
| 11:15<br />
| [[#pascal|Model Checking Abstract Syntax Trees]]<br />
| Pascal Hof<br />
|-<br />
| 11:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#dotfs|DotFS - or How Fred Solved His Config Clutter]]<br />
| Paul van der Walt, Sjoerd Timmer<br />
|-<br />
|<br />
| [[#gruze|Snap and Gruze]]<br />
| Kevin Jardine<br />
|-<br />
|<br />
| [[#case-study|Invitation to Participate in a Functional Programming Case Study]]<br />
| Jurriaan Hage<br />
|-<br />
| 12:15<br />
| colspan="2" | ''Lunch (provided by Ordina)''<br />
|-<br />
| 13:15<br />
| [[#practice|Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project]]<br />
| Stef Joosten, Martijn Schrage<br />
|-<br />
| 13:45<br />
| [[#fclabels|fclabels: First Class Record Labels for Haskell]]<br />
| Sebastiaan Visser<br />
|-<br />
| 14:15<br />
| [[#kinds|GHC 7.6, More Well-Typed Than Ever]]<br />
| José Pedro Magalhães<br />
|-<br />
| 14:45<br />
|colspan="2"| ''Lightning Talks''<br />
|-<br />
|<br />
| [[#holes|Holes in GHC]]<br />
| Thijs Alkemade<br />
|-<br />
|<br />
| [[#regex-applicative|Applicative Regular Expressions]]<br />
| Roman Cheplyaka<br />
|-<br />
|<br />
| [[#homepage|How I Generate My Homepage]]<br />
| Wouter Swierstra<br />
|-<br />
| 15:15<br />
| Closing<br />
| Jurriën Stutterheim<br />
|-<br />
| 15:30<br />
|colspan="2"| ''Depart for UHac''<br />
|}<br />
<br />
== Summaries ==<br />
<br />
=== <span id="websockets"></span>Supporting Different Versions of the WebSockets Protocol ===<br />
<br />
Jasper Van der Jeugt (UGent)<br />
<br />
The Haskell websockets library allows you to write WebSocket-enabled<br />
servers in Haskell, bidirectional communication with the browser.<br />
However, browsers and their related specifications change fast, and<br />
there are different versions of the WebSockets protocol. This talk<br />
discusses a type-safe technique which disallows the programmer from<br />
using primitives not available in the chosen version, while still<br />
allowing the latest features.<br />
<br />
* [http://jaspervdj.be/files/2012-dutchhug-websockets.pdf Slides]<br />
* [http://jaspervdj.be/websockets/ websockets] home page<br />
* [http://hackage.haskell.org/package/websockets websockets] on Hackage<br />
* [https://github.com/jaspervdj/websockets websockets] on GitHub<br />
<br />
=== <span id="hesselink"></span>Building Your Own Haskell ecosystem ===<br />
<br />
Erik Hesselink (Silk)<br />
<br />
When you develop a lot of different Haskell packages that work together, managing all these packages and their versions can be difficult. In this talk, I'll explain how we deal with this at Silk. I will show how to use Hackage 2.0 to build your own internal package repository, how to use cabal-dev to manage installed packages, and show a tool for bumping package versions. Together, this makes working on large amounts of packages with multiple people much easier.<br />
<br />
* [https://github.com/spl/dhd-2012-slides/raw/master/erik-hesselink-ecosystem.pdf Slides]<br />
* [http://hackage.haskell.org/package/bumper bumper] on Hackage<br />
* [https://github.com/silkapp/bumper bumper] on GitHub<br />
<br />
=== <span id="pascal"></span>Model Checking Abstract Syntax Trees ===<br />
<br />
Pascal Hof (TU Dortmund)<br />
<br />
Model checking turned out to be a useful tool for the analysis of programs. Usually one transforms abstract syntax trees to control flow graphs, which offer a abstract representation of program behavior. Whenever one is not focused on program behavior but on structural properties of the program (e.g. semantic analysis of a compiler), model checking the abstract syntax tree comes in handy. My talk introduces a problem, which can be solved using model checking abstract syntax trees. Additionally, different approaches for a implementation will be discussed.<br />
<br />
=== <span id="dotfs"></span>DotFS - or How Fred Solved His Config Clutter ===<br />
<br />
Paul van der Walt (UU), Sjoerd Timmer (UU)<br />
<br />
Everyone who has more than one account on Linux/Unix/OS X systems knows how hard is can be to keep track of all the different config files in your home directory. <tt>.vimrc</tt>, <tt>.muttrc</tt>, <tt>.hgrc</tt>, <tt>.screenrc</tt>, <tt>.bashrc</tt>, and <tt>.xinitrc</tt> are just a few, but we're sure you can come up with many more yourself. Imagine how wonderful your life could be if you just had an easy tool to keep track of different versions of all these files on all your machines. We argue that traditional version control systems on their own are not up the task and we provide an alternative.<br />
<br />
* [http://prezi.com/-acujvowpciq/dotfs Slides] on prezi.com<br />
* [http://hackage.haskell.org/package/dotfs dotfs] on Hackage<br />
* [https://github.com/toothbrush/dotfs dotfs] on GitHub<br />
<br />
=== <span id="gruze"></span>Snap and Gruze ===<br />
<br />
Kevin Jardine<br />
<br />
Developing an astronomy application using Snap and an experimental entity-attribute-value store for Haskell.<br />
<br />
* [https://github.com/kevinjardine/Gruze-Store Gruze-Store] on GitHub<br />
<br />
=== <span id="case-study"></span>Invitation to Participate in a Functional Programming Case Study ===<br />
<br />
Jurriaan Hage (UU)<br />
<br />
I want to invite you to participate in an experiment in Haskell.<br />
In this experiment we are going to pit HaRe (the Haskell Refactorer)<br />
against Holmes (my plagiarism detector). The goal is to find out how much<br />
time somebody needs to refactor a Haskell program into something that<br />
is not recognizable by Holmes as plagiarism. We shall be looking at<br />
two groups of study: experienced programmers (we shall pretend they<br />
are paid for by newbies to make their assignments for them, and to do<br />
so without starting from scratch), and the newbies themselves.<br />
This experiment is a collaboration with Simon Thompson of Kent.<br />
He will take charge of the newbies, my task is to perform the experiment<br />
with experienced Haskell programmers, which is why I am now seeking for<br />
participants.<br />
<br />
* [http://www.cs.uu.nl/wiki/pub/Hage/ResearchTalks/holmes-slides.pdf Slides] <br />
=== <span id="practice"></span>Haskell in Practice: How Haskell Has Been Used in a (Paid) IT Project ===<br />
<br />
Stef Joosten (Ordina), Martijn Schrage ([http://www.oblomov.com Oblomov Systems])<br />
<br />
This presentation shows how new thinking helps the judiciary to gain control over and to reduce cost in a landscape of many different IT systems that serve the courts of law in the Netherlands.<br />
<br />
Although Haskell plays a role outside the limelight, the results have become possible because of a tool, Ampersand, which has been built in Haskell.<br />
<br />
The presentation is accompanied by a brief demonstration.<br />
<br />
* [http://www.oblomov.com/Documents/AmpersandJoosten-DHD2012.pdf Slides Stef]<br />
* [http://www.oblomov.com/Documents/Ampersand101-DHD2012.pdf Slides Martijn]<br />
* [http://ampersand.sourceforge.net Ampersand] on Sourceforge<br />
<br />
=== <span id="fclabels"></span>fclabels: First Class Record Labels for Haskell ===<br />
<br />
Sebastiaan Visser (Silk)<br />
<br />
Haskell's record system for algebraic datatypes uses labels as accessors for fields within constructors. Record labels can be used for both selection and modification of individual fields within value, but only selection can be composed in a natural way. The special syntax for updates makes composing modifications very cumbersome. The fclabels package tries to solve this problem by implementing field accessors as first class Haskell values instead of special syntax. Labels are implemented as lenses and can easily be composed for both selection and modification. To avoid boilerplate labels can be derived using Template Haskell. This talk will give a brief introduction into the usage of the library and will show a bit of the inner workings as a bridge to future <br />
extensions.<br />
<br />
* [http://hackage.haskell.org/package/fclabels fclabels] on Hackage<br />
* [https://github.com/sebastiaanvisser/fclabels fclabels] on GitHub<br />
<br />
=== <span id="kinds"></span>GHC 7.6, More Well-Typed Than Ever ===<br />
<br />
José Pedro Magalhães (UU)<br />
<br />
With each new version, GHC brings new and exciting type-level features to the<br />
Haskell language. In this talk we look at some upcoming features for GHC 7.6:<br />
data kinds, kind polymorphism, type-level literals, and deferred type errors.<br />
We show through some example programs how to take advantage of the new features,<br />
and what possibilities they open for Haskell programmers.<br />
<br />
* [http://dreixel.net/research/pdf/ghc7.6mwtte_pres_dhd2012.pdf Slides]<br />
<br />
=== <span id="holes"></span>Holes in GHC ===<br />
<br />
Thijs Alkemade (UU)<br />
<br />
This will be a demonstration of work-in-progress on adding holes for type-based debugging with GHC. See the [http://hackage.haskell.org/trac/ghc/wiki/Holes GHC Trac page] for details.<br />
<br />
=== <span id="regex-applicative">Applicative Regular Expressions</span> ===<br />
<br />
Roman Cheplyaka<br />
<br />
In this short talk I am going to describe the<br />
[https://github.com/feuerbach/regex-applicative regex-applicative] project:<br />
* what it is about<br />
* how it compares to other parsing combinator libraries<br />
* its current state and unsolved problems<br />
<br />
I'll be glad to accept any help<br />
[http://www.haskell.org/haskellwiki/DHD_UHac/Projects#regex-applicative during UHac].<br />
<br />
* [http://hackage.haskell.org/package/regex-applicative regex-applicative] on Hackage<br />
<br />
=== <span id="homepage">How I Generate My Homepage</span> ===<br />
<br />
Wouter Swierstra (UU)<br />
<br />
* [https://github.com/spl/dhd-2012-slides/raw/master/wouter-swierstra-homepage.pdf Slides]</div>Oblosys