[Haskell-cafe] A cabal odyssey
Andrew Coppin
the way, I encountered a number of... "glitches", if you will.
First of all, I tried to get it to work on Windows. I fired up a new
Windows VM and installed Haskell Platform 2010.1.0.0. It seems that
(finally) this includes the cabal-install tool, which is nice. It seems
it includes cabal-install 0.8.0, so as soon as I tried "cabal update",
it tells me a new version is available. It claims I just need to "cabal
install cabal-install" (which is amusingly riddle-like). Unfortunately,
although doing this *does work*, the new cabal.exe is installed lower
down the search path than the existing one, so you still get the old
version (unless you manually fiddle with the search path). In fact, it
seems that the HP install folder is higher up the search path than the
"global" binary target, which is higher than the "local" binary target.
It seems to me like this ought to be the other way around.
The next problem is that "cabal install sifflet" gets mighty confused
and outright fails. Basically it can't figure out how to resolve all the
dependencies. It seems that Sifflet demands GTK 0.11.0 (i.e.,
gtk-0.11.0, pango-0.11.0, glib-0.11.0, etc.) However, Cabal looks at
gtk-0.11.0, sees it depends on (say) "glib-0.11.*", and wants to use
glib-0.11.1 (the latest one). But then Sifflet wants glib-0.11.0, not
glib-0.11.1, and it seems Cabal just can't figure out what the heck to
do. Which is slightly surprising, really.
The solution (of sorts) is to painstakingly resolve the dependencies by
hand, by asking Cabal to install the correct packages one at a time in
the correct order. (I still love the way Gtk2hs *actually compiles* on
Windows now. That's pretty sweet!)
That reminds me. What the heck is actually *in* file 126? I don't know
why, but compiling file 126 (Graphics.UI.Gtk.Gdk.Cursor) takes up 75% of
the entire Gtk2hs build time! What's that all about?
Anyway, having finally built Gtk2hs version 0.11.0 successfully, I
continued trying to get Sifflet working... only to discover it wants the
"curl" package. And when I ask Cabal to build it, it just retorts that
it has a configure script. *sigh* So that's the end of that. I have
absolutely no idea why a tool like Sifflet would need access to the Curl
library. Presumably this is just another one of those obscure
dependency-chasing artifacts that happen from time to time? (After
dealing with Linux, I'm used to this kind of weirdness.)
OK, so it's only possible to run Sifflet under Linux. Let's give that a
try...
So I fire up a new OpenSUSE VM. I quickly discovered that gtk seems to
want Alex and Happy, but cabal-install is defaulting to doing a "local"
rather than "global" install, and thereafter it can't "find" Alex or
Happy, even though they're installed. (Yeah, great, thanks for that...)
So I rewind the VM, build the latest version of cabal-install, and edit
the configuration to do global installs instead of local. The amusing
part is, if you "sudo cabal install" so it has permission to put the
installed files into place, it then uses root's configuration file
instead. *sigh* Well anyway, I managed to work around that. But... Cabal
*still* fails to find Alex or Happy, even though they're now in the
search path.
Oh, wait. They're in *my* search path. They're not in root's search
path. (As per good security practise, root's search path is rather
short.) I can pass some CLI switches to tell it where these are, but
then gtk2hs-buildtools makes a whole bunch of stuff which Cabal also
can't find. Eventually, the easiest thing I could come up with was to do
"cabal unpack" to get a source tree, configure and build as me, and sudo
for the install. Except that then it tries to reconfigure...? Wuh? So
instead of "sudo cabal install", I tried "sudo runhaskell Setup
install", which works just fine (although obviously it's rather wordy!)
So, I manually hold Cabal's hand through the process of building all the
0.11.0 packages one at a time, in a way that it can find all the stuff
at configure-time. Gosh this is a faff! Well anyway, it worked. Trips
over when I reach Curl, but that's because I need to ask YaST to install
the curl-devel package. And, finally, I can build and install Sifflet
itself.
After 4 hours or so of typing commands, it was nice to do some stuff
with my mouse. ;-) I spent about 20 minutes trying to figure out how to
build high-order functions before I discovered that you can't. Still,
the stated design goal of Sifflet is "to teach beginners about
recursion". Clearly it's design achieves this goal quite well. Equally
clearly, Haskell has damaged my mind. I actually cannot think of *any*
interesting low-order functions! 5 years of programming in Pascal with
low-order *monomorphic* functions, and today I can't think of a single
interesting use for such a thing. ;-)
Heh, well anyway... I don't know how many of the things I've mentioned
are known or likely to be fixed. Just thought I'd share.
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Kevin Jardine
2010.2.0.0.
However, even with the latest version,
cabal install cabal-install
installs cabal in the wrong place (not in extralibs/bin) under Windows
at least so it is impossible to upgrade cabal.
Having said that perhaps it is for the best as I have had bad
experiences upgrading bits of the Haskell Platform.
It is probably safer just to be satisfied with whatever comes with the
latest version of the Platform and wait patiently for the next
release.
Kevin
> Haskell-C...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe
Don Stewart
> > And so today, just for giggles, I tried to get Sifflet to work. Along
> > the way, I encountered a number of... "glitches", if you will.
> >
> > First of all, I tried to get it to work on Windows. I fired up a new
> > Windows VM and installed Haskell Platform 2010.1.0.0. It seems that
> > (finally) this includes the cabal-install tool, which is nice.
Can I ask why you chose 2010.1.0.0 ?
The download page clearly says "Current stable release: 2010.2.0.0"
Clicking on the windows button links to a page with "The Windows installer for
the 2010.2.0.0 Haskell Platform"
I hope the download site for the HP isn't leading people astray.
-- Don
Andrew Coppin
> Can I ask why you chose 2010.1.0.0 ?
>
That's easy; the installer is already on my harddrive.
> I hope the download site for the HP isn't leading people astray.
>
Nope. I just hadn't noticed that what I downloaded a few months ago was
no longer the latest, that's all.
Andrew Coppin
> The latest version of the Haskell Platform is Haskell Platform
> 2010.2.0.0.
>
> However, even with the latest version,
>
> cabal install cabal-install
>
> installs cabal in the wrong place (not in extralibs/bin) under Windows
> at least so it is impossible to upgrade cabal.
>
Well, there's nothing inherantly "wrong" with where it puts the binary.
All the other binaries (the ones that don't come with HP in the first
place) get put there too. As far as I can see, the only really "wrong"
thing is the search path order.
> Having said that perhaps it is for the best as I have had bad
> experiences upgrading bits of the Haskell Platform.
>
> It is probably safer just to be satisfied with whatever comes with the
> latest version of the Platform and wait patiently for the next
> release.
>
Yeah, perhaps. (But in that case, we might want to turn off the
automatic prompting to upgrade it...)
Ben Millwood
<andrew...@btinternet.com> wrote:
> The amusing part is, if you "sudo cabal
> install" so it has permission to put the installed files into place, it then
> uses root's configuration file instead. *sigh* Well anyway, I managed to
> work around that. But... Cabal *still* fails to find Alex or Happy, even
> though they're now in the search path.
>
> Oh, wait. They're in *my* search path. They're not in root's search path.
It sounds to me like your life would be a lot easier if you knew about
cabal-install's root-cmd configuration parameter! Open your
.cabal/config file and uncomment and set:
root-cmd: sudo
Now cabal-install will take up root permissions when and only when necessary :)
I only found this out after asking #haskell about similar problems.
Perhaps it should be more prominent somehow.
Andrew Coppin
> It sounds to me like your life would be a lot easier if you knew about
> cabal-install's root-cmd configuration parameter! Open your
> .cabal/config file and uncomment and set:
>
> root-cmd: sudo
>
> Now cabal-install will take up root permissions when and only when necessary :)
> I only found this out after asking #haskell about similar problems.
> Perhaps it should be more prominent somehow.
>
Thank you for that. I was hoping such a thing had been implemented
somewhere...
Evan Laforge
> cabal-install's root-cmd configuration parameter! Open your
> .cabal/config file and uncomment and set:
>
> root-cmd: sudo
I didn't know about this either. As an aside, is the cabal config
file documented at all? I haven't been able to find any. That means
it's easy to accidentally install everything with no documentation
(why is that the default?) or without profiling libs, which will mess
you up much later when you want profiling and now dependency checking
won't help you reinstall everything.
I was trying to turn on --global by default (which is another one of
those traps... Setup.hs defaults to global but cabal doesn't... and
~/.cabal is not the most obvious place to look for your installed
stuff), but couldn't find a way, and no documentation telling me how.
Is there a way?
And... is the 'cabal' command supposed to have a man page?
Ben Millwood
> I was trying to turn on --global by default
user-install: False
I think it's not completely a stupid idea to have profiling default
off. I personally do not really enjoy the fact that I compile
everything three times nowadays :)
Andrew Coppin
> I think it's not completely a stupid idea to have profiling default
> off. I personally do not really enjoy the fact that I compile
> everything three times nowadays :)
>
Fair enough. However, having documentation off by default is just
annoying...
On that note, I just remembered something else: During the course of
playing with all this Cabal stuff, I discovered that I had somehow
acquired a global package index. As in, an HTML file that links to the
documentation of *all* installed packages, not just the ones that come
with GHC. And when I installed more packages, it seemed to add them to
this index. Alas, removing packages doesn't remove them. I tried
deleting the file to see if Cabal would rebuild it, and now I just have
no file at all, and no idea how to get it back.
Then again, all the links were broken anyway. They all had paths like
"C:\Program Files\Haskell\...whatever", and Mozilla apparently expects
them to say "file://C:/Program Files/Haskell/...whatever". It kept
whining that "the C:\ protocol is not registered".
Does anybody know anything about this feature?
Daniel Fischer
> Ben Millwood wrote:
> > I think it's not completely a stupid idea to have profiling default
> > off. I personally do not really enjoy the fact that I compile
> > everything three times nowadays :)
>
> Fair enough. However, having documentation off by default is just
> annoying...
>
>
>
> On that note, I just remembered something else: During the course of
> playing with all this Cabal stuff, I discovered that I had somehow
> acquired a global package index. As in, an HTML file that links to the
> documentation of *all* installed packages, not just the ones that come
> with GHC. And when I installed more packages, it seemed to add them to
> this index.
Yes, when cabal runs haddock on a package, it generates a comprehensive
index if none is present or expands it with the new docs.
Quite cool that :)
> Alas, removing packages doesn't remove them.
Since cabal isn't involved in removing packages, that can't be done.
Of course, a `cabal unregister foo' command that took care of all that
would be nice, but so far the cabal devs have had more important things to
do.
> I tried deleting the file to see if Cabal would rebuild it,
> and now I just have no file at all, and no idea how to get it back.
Maybe it's still in the Trashcan? If not, an undelete programme?
Generally, until you know it's safe to delete, move or rename first, so if
something breaks, it's not gone for good.
If your index is not recoverable, I think you'd have to run cabal haddock
on your cabal-installed packages to regenerate it.
>
> Then again, all the links were broken anyway. They all had paths like
> "C:\Program Files\Haskell\...whatever", and Mozilla apparently expects
> them to say "file://C:/Program Files/Haskell/...whatever". It kept
> whining that "the C:\ protocol is not registered".
>
> Does anybody know anything about this feature?
>
Apparently, haddock links to absolute paths. That's of course not the right
thing to do if the path begins with an invalid protocol specifier ("C:").
And it's annoying if you want to move the docs.
As a workaround, you could replace all 'HREF="C:' with 'HREF="file://C:' in
the index.html (but if '\' isn't a valid path separator in urls, that
probably wouldn't work and replacing all '\'s with '/' would be wrong).
Of course that should be dealt with properly in haddock, file a bug report.
Duncan Coutts
> Then again, all the links were broken anyway. They all had paths like
> "C:\Program Files\Haskell\...whatever", and Mozilla apparently expects them
> to say "file://C:/Program Files/Haskell/...whatever". It kept whining that
> "the C:\ protocol is not registered".
>
> Does anybody know anything about this feature?
Andrew, I just wanted to let you know that Cabal/cabal-install/hackage
has a bug tracker:
http://hackage.haskell.org/trac/hackage/
We rely on users reporting bugs so that we know there is anything
wrong. There is a guest account so that anyone can file tickets. There
is a search feature to see if anyone has reported a similar problem
previously (though we prefer getting duplicates than no reports at
all). For bugs that really annoy you, you can add your email address
to the 'cc list so that you get notified when the ticket is updated.
That also counts as a "vote" for that ticket, we take that into
account when prioritising things.
Thanks!
Duncan
Ivan Lazar Miljenovic
> Ben Millwood wrote:
>>
>> I think it's not completely a stupid idea to have profiling default
>> off. I personally do not really enjoy the fact that I compile
>> everything three times nowadays :)
>>
>
> Fair enough. However, having documentation off by default is just
> annoying...
My guess is that this is aimed at people who just want to use Haskell
software (darcs, xmonad, etc.) and don't actually develop in Haskell.
This saves some storage space and also compile times.
--
Ivan Lazar Miljenovic
Ivan.Mi...@gmail.com
IvanMiljenovic.wordpress.com
Andrew Coppin
> On Wednesday 18 August 2010 19:13:48, Andrew Coppin wrote:
>
>> On that note, I just remembered something else: During the course of
>> playing with all this Cabal stuff, I discovered that I had somehow
>> acquired a global package index. As in, an HTML file that links to the
>> documentation of *all* installed packages, not just the ones that come
>> with GHC. And when I installed more packages, it seemed to add them to
>> this index.
>>
>
> Yes, when cabal runs haddock on a package, it generates a comprehensive
> index if none is present or expands it with the new docs.
> Quite cool that :)
>
It's something I've always _wanted_ Cabal to do, but this is the first
time I've ever seen it happen. I don't know what particularly I did to
make this happen, and now it seems to be gone, so...
>> Alas, removing packages doesn't remove them.
>>
>
> Since cabal isn't involved in removing packages, that can't be done.
>
I gathered. Apparently there's no "cabal uninstall" or even merely a
"cabal unregister" yet... (There must surely be a ticket for that already?)
>> I tried deleting the file to see if Cabal would rebuild it,
>> and now I just have no file at all, and no idea how to get it back.
>>
>
> Generally, until you know it's safe to delete, move or rename first, so if
> something breaks, it's not gone for good.
>
Well, the worst thing that can happen is I get no documentation, which
isn't exactly a disaster. I'm just wondering how these files got created
to start with; adding more packages doesn't appear to recreate it. I
suppose I could try reinstalling all of them...
>> Then again, all the links were broken anyway. They all had paths like
>> "C:\Program Files\Haskell\...whatever", and Mozilla apparently expects
>> them to say "file://C:/Program Files/Haskell/...whatever". It kept
>> whining that "the C:\ protocol is not registered"
>
> Apparently, haddock links to absolute paths. That's of course not the right
> thing to do if the path begins with an invalid protocol specifier ("C:").
> And it's annoying if you want to move the docs.
>
I imagine it's so that each package can be placed in a completely
arbitrary place in the filesystem, and the links still work. I'd
actually be surprised if these URLs work on Linux either; they don't
appear to follow the requisit web standards.
Andrew Coppin
> On 19 August 2010 03:13, Andrew Coppin <andrew...@btinternet.com> wrote:
>
>> Ben Millwood wrote:
>>
>>> I think it's not completely a stupid idea to have profiling default
>>> off. I personally do not really enjoy the fact that I compile
>>> everything three times nowadays :)
>>>
>>>
>> Fair enough. However, having documentation off by default is just
>> annoying...
>>
>
> My guess is that this is aimed at people who just want to use Haskell
> software (darcs, xmonad, etc.) and don't actually develop in Haskell.
> This saves some storage space and also compile times.
>
Mmm, I hadn't thought of that.
Then again, if you just want some tool, why not just grab a prebuilt
binary? Oh, wait - it's Unix...
Andrew Coppin
> On 18 August 2010 18:13, Andrew Coppin <andrew...@btinternet.com> wrote:
>
>
>> Then again, all the links were broken anyway. They all had paths like
>> "C:\Program Files\Haskell\...whatever", and Mozilla apparently expects them
>> to say "file://C:/Program Files/Haskell/...whatever". It kept whining that
>> "the C:\ protocol is not registered".
>>
>> Does anybody know anything about this feature?
>>
>
> Andrew, I just wanted to let you know that Cabal/cabal-install/hackage
> has a bug tracker:
>
> http://hackage.haskell.org/trac/hackage/
>
> We rely on users reporting bugs so that we know there is anything
> wrong. There is a guest account so that anyone can file tickets. There
> is a search feature to see if anyone has reported a similar problem
> previously (though we prefer getting duplicates than no reports at
> all). For bugs that really annoy you, you can add your email address
> to the 'cc list so that you get notified when the ticket is updated.
> That also counts as a "vote" for that ticket, we take that into
> account when prioritising things.
>
I guess I just figured that since Cabal is used by hundreds of millions
of people every single day, any little glitches I might have come across
have already been seen by at least 1,000 people before me (and hence,
the developers already know about it and just haven't had time to fix it
yet).
Then again, I thought the same thing the very first time I tried Gtk2hs,
and the Windows build was trivially broken. (I hadn't noticed it, but it
was actually a new 2-day-old release.)
I know Windows is a rare platform for Haskell, but presumably the
Cabal's dependency-related stuff is the same on any platform. (?) I'm
also interested to know if the master index works on other platforms
too. (I suppose that's really a Haddock issue rather than Cabal.) For
that matter, I notice that Hackage seems to be using a much higher
version number of Haddock than what I currently have installed. So maybe
what I ought to do is go fetch the latest versions of all the tools and
see what works. Some of the stuff I'm seeing might be fixed already.
My reason in posting here was really to see if others had similar
experiences, and see if there are easier ways of getting things done.
(And, for example, I now know about the root-cmd command.) Posting
actual bug tickets requires a lot of time, energy and effort to
determine exactly what the problem is and build a reproducible test
case. And, like I said, I kind of assumed that all this stuff must
already be "well known", given how popular Cabal is.
wren ng thornton
> I guess I just figured that since Cabal is used by hundreds of millions
> of people every single day, any little glitches I might have come across
> have already been seen by at least 1,000 people before me (and hence,
> the developers already know about it and just haven't had time to fix it
> yet).
Which is why, when filing a report, you scan/search the bug tracker
first to make sure you're not filing a duplicate :)
Just remember, those thousands of other people are probably thinking the
same thing you are. This is well a well-documented phenomenon in more
serious circumstances:
http://en.wikipedia.org/wiki/Bystander_effect
--
Live well,
~wren
Daniel Fischer
>
> It's something I've always _wanted_ Cabal to do, but this is the first
> time I've ever seen it happen. I don't know what particularly I did to
> make this happen, and now it seems to be gone, so...
>
Hm, I just renamed my ~/.cabal/share/doc and installed a new package. cabal
created a new doc directory and an index linking to a) the docs of the libs
that came with GHC and b) the new package(s), as expected.
If you have documentation: True in your config, your cabal should do the
same. Double-check and perhaps file a bug report.
>
> I gathered. Apparently there's no "cabal uninstall" or even merely a
> "cabal unregister" yet... (There must surely be a ticket for that
> already?)
>
Probably. But since so far cabal doesn't track what it installed, it would
be a major change.
>
> Well, the worst thing that can happen is I get no documentation, which
> isn't exactly a disaster.
No, but a major inconvenience :)
> I'm just wondering how these files got created
> to start with; adding more packages doesn't appear to recreate it. I
> suppose I could try reinstalling all of them...
>
Maybe running cabal haddock on them is enough.
>
> I imagine it's so that each package can be placed in a completely
> arbitrary place in the filesystem, and the links still work.
The links won't work if you move the docs around. That's a bit annoying
since thus I can't simply rename ~/.cabal/share/doc when I build a new GHC
and have the docs for the old GHCs libraries working, I have to change the
links in all the .html files too.
> I'd actually be surprised if these URLs work on Linux either; they don't
> appear to follow the requisit web standards.
>
I'm not an expert, but I think
<a href="/home/user/.cabal/share/doc/package/html/Module.html">Module</a>
is correct. Anyway, they work.
Duncan Coutts
> Daniel Fischer wrote:
>> Yes, when cabal runs haddock on a package, it generates a comprehensive
>> index if none is present or expands it with the new docs.
>> Quite cool that :)
>>
>
> It's something I've always _wanted_ Cabal to do, but this is the first time
> I've ever seen it happen. I don't know what particularly I did to make this
> happen, and now it seems to be gone, so...
If you have documentation enabled then it is recreated every time you
install a package.
(Though only for user packages, since we have not yet worked out
somewhere sensible we can stick a global index).
> I gathered. Apparently there's no "cabal uninstall" or even merely a "cabal
> unregister" yet... (There must surely be a ticket for that already?)
Yup, there's a ticket for it.
> Well, the worst thing that can happen is I get no documentation, which isn't
> exactly a disaster. I'm just wondering how these files got created to start
> with; adding more packages doesn't appear to recreate it. I suppose I could
> try reinstalling all of them...
If you have documentation enabled (ie use --enable-documentation on
the command line, or have "documentation: True" in the ~/.cabal/config
file) then docs get created for each package you install, and the
haddock index/contents of all installed docs gets updated.
>>> Then again, all the links were broken anyway. They all had paths like
>>> "C:\Program Files\Haskell\...whatever", and Mozilla apparently expects
>>> them to say "file://C:/Program Files/Haskell/...whatever". It kept
>>> whining that "the C:\ protocol is not registered"
>>
>> Apparently, haddock links to absolute paths. That's of course not the
>> right thing to do if the path begins with an invalid protocol specifier
>> ("C:"). And it's annoying if you want to move the docs.
>>
>
> I imagine it's so that each package can be placed in a completely arbitrary
> place in the filesystem, and the links still work. I'd actually be surprised
> if these URLs work on Linux either; they don't appear to follow the requisit
> web standards.
You may be right, or perhaps URL syntax is just liberal enough to let
unix style paths work. It's still a bug of course that we're not using
the file:// protocol which makes it not work on windows. I filed it
here:
http://hackage.haskell.org/trac/hackage/ticket/516#comment:6
Duncan
Ivan Lazar Miljenovic
> On 19 August 2010 21:15, Andrew Coppin <andrew...@btinternet.com> wrote:
>> Daniel Fischer wrote:
>
>>> Yes, when cabal runs haddock on a package, it generates a comprehensive
>>> index if none is present or expands it with the new docs.
>>> Quite cool that :)
>>>
>>
>> It's something I've always _wanted_ Cabal to do, but this is the first time
>> I've ever seen it happen. I don't know what particularly I did to make this
>> happen, and now it seems to be gone, so...
>
> If you have documentation enabled then it is recreated every time you
> install a package.
>
> (Though only for user packages, since we have not yet worked out
> somewhere sensible we can stick a global index).
/usr/share/doc/haskell/ ? However I think distros usually don't like
un-versioned directories there... :(
One thing I always find slightly irritating is that when using what
seems to be the default "/usr/share/doc/packagename-packageversion",
then every time I upgrade something then my bookmark links are all wrong
(and my browse history is full of now-useless links).
--
Ivan Lazar Miljenovic
Ivan.Mi...@gmail.com
IvanMiljenovic.wordpress.com
Andrew Coppin
>>> Yes, when cabal runs haddock on a package, it generates a comprehensive
>>> index if none is present or expands it with the new docs.
>>> Quite cool that :)
>>>
>>>
>> It's something I've always _wanted_ Cabal to do, but this is the first time
>> I've ever seen it happen. I don't know what particularly I did to make this
>> happen, and now it seems to be gone, so...
>>
>
> If you have documentation enabled then it is recreated every time you
> install a package.
>
That's what I was expecting to happen... but no. Each package gets its
documentation generated, but the master index I deleted seems to be gone
forever.
> (Though only for user packages, since we have not yet worked out
> somewhere sensible we can stick a global index).
>
Uh... maybe that's it then? Yes, I think I changed it from local to
global. It was putting all the binaries and documentation under
Documents and Settings. I changed the install type to global, and it
went back to putting stuff under Program Files\Haskell like it always
used to.
I'm not sure what "somewhere sensible" is supposed to mean; until I
deleted it, the master index was under Program Files\Haskell\doc, right
next to all the globally-installed packages. Or did you mean there isn't
a good place on Unix?
> Yup, there's a ticket for it.
>
In fact, there appears to be a ticket for every single thing I
originally mentioned. And they're all ancient tickets too. So, yeah...
nothing to do here.
(Unless you're suggesting that I should try to actually *fix* these
things. The way I figure it, if an army of developers who are already
experts on the subject haven't been able to fix it yet, it must be
extremely hard, and so there's no way *I* can fix it.)
> If you have documentation enabled (ie use --enable-documentation on
> the command line, or have "documentation: True" in the ~/.cabal/config
> file) then docs get created for each package you install, and the
> haddock index/contents of all installed docs gets updated.
>
Right. I still get documentation for each package, just no master index.
That's the way it always used to work, and that apparently is the way it
works again now...
>> I imagine it's so that each package can be placed in a completely arbitrary
>> place in the filesystem, and the links still work. I'd actually be surprised
>> if these URLs work on Linux either; they don't appear to follow the requisit
>> web standards.
>>
>
> You may be right, or perhaps URL syntax is just liberal enough to let
> unix style paths work. It's still a bug of course that we're not using
> the file:// protocol which makes it not work on windows. I filed it
> here:
> http://hackage.haskell.org/trac/hackage/ticket/516#comment:6
>
Yeah, I believe at least under HTTP, "/" refers to the root folder of
the current server, so that probably works for an absolute path. "C:\"
isn't going to be valid without a protocol spec. (I actually cannot
remember now whether the Windows paths had forward or backward slashes.)
I think either removing the drive spec or adding a protocol spec should
fix this; the latter would seem more "correct". (Again, this is a
Haddock issue rather than Cabal, isn't it?)
Andrew Coppin
> Andrew Coppin wrote:
>> I guess I just figured that since Cabal is used by hundreds of
>> millions of people every single day, any little glitches I might have
>> come across have already been seen by at least 1,000 people before me
>> (and hence, the developers already know about it and just haven't had
>> time to fix it yet).
>
> Which is why, when filing a report, you scan/search the bug tracker
> first to make sure you're not filing a duplicate :)
>
> Just remember, those thousands of other people are probably thinking
> the same thing you are. This is well a well-documented phenomenon in
> more serious circumstances:
>
> http://en.wikipedia.org/wiki/Bystander_effect
>
Well, I just had a look, and it seems every issue I've mentioned already
has a (very old) ticket. So apparently these are all very well-known
issues (and presumably too hard to fix).
Ivan Lazar Miljenovic
> Duncan Coutts wrote:
>> Yup, there's a ticket for it.
>>
>
> In fact, there appears to be a ticket for every single thing I
> originally mentioned. And they're all ancient tickets too. So,
> yeah... nothing to do here.
>
> (Unless you're suggesting that I should try to actually *fix* these
> things. The way I figure it, if an army of developers who are already
> experts on the subject haven't been able to fix it yet, it must be
> extremely hard, and so there's no way *I* can fix it.)
Or maybe they have other things to do (e.g. Duncan is working, finishing
off his PhD thesis and answering queries like this; when do you expect
him to get any hacking done? :p).
--
Ivan Lazar Miljenovic
Ivan.Mi...@gmail.com
IvanMiljenovic.wordpress.com
Andrew Coppin
> Andrew Coppin <andrew...@btinternet.com> writes:
>
>> (Unless you're suggesting that I should try to actually *fix* these
>> things. The way I figure it, if an army of developers who are already
>> experts on the subject haven't been able to fix it yet, it must be
>> extremely hard, and so there's no way *I* can fix it.)
>>
>
> Or maybe they have other things to do (e.g. Duncan is working, finishing
> off his PhD thesis and answering queries like this; when do you expect
> him to get any hacking done? :p).
>
I wonder... How many people are actually working on Cabal?
When I first started using Haskell, I got the impression that there were
hundreds, maybe even thousands, of developers working on GHC. (After
all, how else could you write such a huge codebase in less than two
centuries?) But now it appears the number of active developers is nearer
to 3. This is obviously a jaw-droppingly tiny number of people to be
working on such a gigantic piece of software. If it's really true, it's
amazing anything ever gets done at all!
So now I wonder about Darcs, Cabal, Haddock, Hackage, and all those
other big projects. Do they really have a bazillion people working on
them? Or is it just two blokes in their spare time? (And, more
importantly, how do you find out?)
Ivan Lazar Miljenovic
> Ivan Lazar Miljenovic wrote:
>> Andrew Coppin <andrew...@btinternet.com> writes:
>>
>>> (Unless you're suggesting that I should try to actually *fix* these
>>> things. The way I figure it, if an army of developers who are already
>>> experts on the subject haven't been able to fix it yet, it must be
>>> extremely hard, and so there's no way *I* can fix it.)
>>>
>>
>> Or maybe they have other things to do (e.g. Duncan is working, finishing
>> off his PhD thesis and answering queries like this; when do you expect
>> him to get any hacking done? :p).
>>
>
> I wonder... How many people are actually working on Cabal?
>
> When I first started using Haskell, I got the impression that there
> were hundreds, maybe even thousands, of developers working on
> GHC. (After all, how else could you write such a huge codebase in less
> than two centuries?) But now it appears the number of active
> developers is nearer to 3. This is obviously a jaw-droppingly tiny
> number of people to be working on such a gigantic piece of
> software. If it's really true, it's amazing anything ever gets done at
> all!
>
> So now I wonder about Darcs, Cabal, Haddock, Hackage, and all those
> other big projects. Do they really have a bazillion people working on
> them? Or is it just two blokes in their spare time? (And, more
> importantly, how do you find out?)
Seeing as how we don't have a bazillion people using Haskell... ;-)
My understanding is that Cabal, Haddock, Hackage (as in the web
infrastructure, etc.) and GHC all have a small core team of about 3
developers and a whole bunch of people who have committed patches at one
time or another and might even do so on an irregular basis. Darcs seems
to have a larger team behind it.
--
Ivan Lazar Miljenovic
Ivan.Mi...@gmail.com
IvanMiljenovic.wordpress.com
Andrew Coppin
> Andrew Coppin <andrew...@btinternet.com> writes:
>
>
>> So now I wonder about Darcs, Cabal, Haddock, Hackage, and all those
>> other big projects. Do they really have a bazillion people working on
>> them? Or is it just two blokes in their spare time? (And, more
>> importantly, how do you find out?)
>>
>
> Seeing as how we don't have a bazillion people using Haskell... ;-)
>
I don't know - how many packages are on Hackage now? That's a few GB of
source code, right? It didn't write itself. ;-)
> My understanding is that Cabal, Haddock, Hackage (as in the web
> infrastructure, etc.) and GHC all have a small core team of about 3
> developers and a whole bunch of people who have committed patches at one
> time or another and might even do so on an irregular basis. Darcs seems
> to have a larger team behind it.
>
OK, wow. Makes you wonder how anything ever gets done at all, eh?
Daniel Fischer
> Ivan Lazar Miljenovic wrote:
> > Andrew Coppin <andrew...@btinternet.com> writes:
> >> So now I wonder about Darcs, Cabal, Haddock, Hackage, and all those
> >> other big projects. Do they really have a bazillion people working on
> >> them? Or is it just two blokes in their spare time? (And, more
> >> importantly, how do you find out?)
> >
> > Seeing as how we don't have a bazillion people using Haskell... ;-)
>
> I don't know - how many packages are on Hackage now? That's a few GB of
> source code, right? It didn't write itself. ;-)
>
How many people have hackage accounts? Much fewer than a bazillion (I
think, how much is a bazillion anyway?).
Some of them are *very* productive.
> > My understanding is that Cabal, Haddock, Hackage (as in the web
> > infrastructure, etc.) and GHC all have a small core team of about 3
> > developers and a whole bunch of people who have committed patches at
> > one time or another and might even do so on an irregular basis. Darcs
> > seems to have a larger team behind it.
>
> OK, wow. Makes you wonder how anything ever gets done at all, eh?
>
It's a kind of magic.
Ivan Lazar Miljenovic
> On Saturday 21 August 2010 14:57:26, Andrew Coppin wrote:
>> Ivan Lazar Miljenovic wrote:
>> > Andrew Coppin <andrew...@btinternet.com> writes:
>> >> So now I wonder about Darcs, Cabal, Haddock, Hackage, and all those
>> >> other big projects. Do they really have a bazillion people working on
>> >> them? Or is it just two blokes in their spare time? (And, more
>> >> importantly, how do you find out?)
>> >
>> > Seeing as how we don't have a bazillion people using Haskell... ;-)
>>
>> I don't know - how many packages are on Hackage now? That's a few GB of
>> source code, right? It didn't write itself. ;-)
>>
>
> How many people have hackage accounts? Much fewer than a bazillion (I
> think, how much is a bazillion anyway?).
> Some of them are *very* productive.
A Bazillion is an imaginary number meant to indicate something extremely
large: http://en.wikipedia.org/wiki/Bazillion#-illion
Since the population of the planet is roughly 6 Billion, I would guess
that Andrew is under the miscomprehension that aliens make up the vast
majority of Haskell users (or else he is taking into account everyone
who will ever use Haskell as well, since after all Haskell will
eventually replace all other inferior languages to become the One True
Language!).
>> > My understanding is that Cabal, Haddock, Hackage (as in the web
>> > infrastructure, etc.) and GHC all have a small core team of about 3
>> > developers and a whole bunch of people who have committed patches at
>> > one time or another and might even do so on an irregular basis. Darcs
>> > seems to have a larger team behind it.
>>
>> OK, wow. Makes you wonder how anything ever gets done at all, eh?
>>
>
> It's a kind of magic.
I believe Don wrote a successor to lambdabot to generate all of his
libraries for him, and Galois is just a front to make it appear that
multiple people are working on these libraries when in reality it's just
his bot.
--
Ivan Lazar Miljenovic
Ivan.Mi...@gmail.com
IvanMiljenovic.wordpress.com
Daniel Fischer
>
> A Bazillion is an imaginary number meant to indicate something extremely
> large: http://en.wikipedia.org/wiki/Bazillion#-illion
Yes, but 'extremely large' numbers mean different things, depending on
whether we talk about for example midges in Scotland (bazillion >= 10^20),
people in a football stadium (bazillion >= 5*10^4) or people at your
sister's wedding (bazillion >= 50).
So how much is a bazillion when it comes to Haskell programmers?
>
> Since the population of the planet is roughly 6 Billion, I would guess
> that Andrew is under the miscomprehension that aliens make up the vast
> majority of Haskell users
Ordinary people don't use Haskell, so if you're using Haskell, you're ipso
facto an alien ;-)
> (or else he is taking into account everyone
> who will ever use Haskell as well, since after all Haskell will
> eventually replace all other inferior languages to become the One True
> Language!).
That'd be Haskell''' rather than Haskell.
> >
> > It's a kind of magic.
>
> I believe Don wrote a successor to lambdabot to generate all of his
> libraries for him, and Galois is just a front to make it appear that
> multiple people are working on these libraries when in reality it's just
> his bot.
Or that.
Andrew Coppin
> Since the population of the planet is roughly 6 Billion, I would guess
> that Andrew is under the miscomprehension that aliens make up the vast
Let's face it, Haskell *does* look like a technology invented by an
alien intelligence immesurably superior to our own. No surprise, then,
that most of its users are also from another planet.
Evan Laforge
>
> When I first started using Haskell, I got the impression that there were
> hundreds, maybe even thousands, of developers working on GHC. (After all,
> how else could you write such a huge codebase in less than two centuries?)
> But now it appears the number of active developers is nearer to 3. This is
> obviously a jaw-droppingly tiny number of people to be working on such a
> gigantic piece of software. If it's really true, it's amazing anything ever
> gets done at all!
I haven't seen any studies about this, but my impression is that most
successful open source projects will be doing well to have 3 full time
contributors. There will be a much larger cloud of people who come
and go and contribute a few patches, but if you've got 3 people
working consistently, after a number of years that really starts to
add up.
Even in the closed source world... the (internal) application I work
on really only has about 3 people who really understand the whole
thing and wrote large parts of it. The rest of us hang out on the
edges, fixing the odd bug or two.
Looking at the ardour commits, it seems like basically two guys doing
most of the work. When I looked at the gimp a number of years back,
it was a similar story. With say python, it's maybe around 5 or so,
but that includes a huge library. When you look at the core, the same
names come back again and again. Anyone with experience of any other
large successful open source programs care to support or refute?
I do agree, though, that what Ian and the Simons (and the Ganeshs and
Manuels and assorted MSR interns and...) have built over the years is
remarkable and inspiring, not to mention very useful.
wren ng thornton
> On Saturday 21 August 2010 15:35:08, Ivan Lazar Miljenovic wrote:
>> A Bazillion is an imaginary number meant to indicate something extremely
>> large: http://en.wikipedia.org/wiki/Bazillion#-illion
>
> Yes, but 'extremely large' numbers mean different things, depending on
> whether we talk about for example midges in Scotland (bazillion >= 10^20),
> people in a football stadium (bazillion >= 5*10^4) or people at your
> sister's wedding (bazillion >= 50).
>
> So how much is a bazillion when it comes to Haskell programmers?
Three!
--
Live well,
~wren
Mathew de Detrich
What haskell really needs is a big ' hit' where someone shows how powerful haskell is in some environment.
Ruby had RoR, which is what splurged the language into the open
On 22/08/2010 3:46 PM, "wren ng thornton" <wr...@freegeek.org> wrote:
Daniel Fischer wrote:
>
> On Saturday 21 August 2010 15:35:08, Ivan Lazar Miljenovic wrote:
>>
>> A ...
Three!
--
Live well,
~wren
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
...
John Meacham
> When I first started using Haskell, I got the impression that there were
> hundreds, maybe even thousands, of developers working on GHC. (After
> all, how else could you write such a huge codebase in less than two
> centuries?) But now it appears the number of active developers is nearer
> to 3. This is obviously a jaw-droppingly tiny number of people to be
> working on such a gigantic piece of software. If it's really true, it's
> amazing anything ever gets done at all!
Now you see the power of Haskell. By offloading tasks from your brain to
the type system you can tackle wildly larger tasks than you would be
able to with a lesser language. Haskell programs end up being a tiny
fraction of the size and complexity of programs in other languages to
acomplish the same task and the difference gets more pronounced as
programs get larger. It is how I was able to write jhc for the most part
by myself. Haskell is an intelligence multiplier.
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/