Re: hoogling GHC
Hi Ranjit, > Is there a command line option that allows one to change the default prefix > for the > URL returned by searches? No command line option, but you can change the .txt file itself by doing: @url http://www.haskell.org/ghc/docs/7.0.1/html/libraries/ghc-7.0.1/ @package ghc That should cause all the URL's in the GHC package that aren't explicit to have the above URL prepended to them. If there's demand, I can add a flag. Thanks, Neil > > On Mar 9, 2011, at 1:59 PM, Neil Mitchell wrote: > >> Hi Ranjit, >> >> It sounds like you've got quite far. Sadly the manual is a bit out of >> date with respect to generating databases, but generally you need to >> produce ghc.txt on your own (using tools such as GHC's make system), >> then you can do: >> >> hoogle convert ghc.txt default.hoo >> >> Then you can run the local server with: >> >> hoogle server --databases=. >> >> That will find databases from the current directory, and serve them. >> Alternatively, if you put ghc.hoo (or default.hoo) in >> $DATADIR/databases it will pick them up automatically (where $DATADIR >> is whatever Cabal configured it to be). If you name the database as >> default.hoo it will be searched by default, if you name it ghc.hoo >> then "foo +ghc" will search for foo in the GHC database. >> >> If a copy of ghc.txt was publicly available somewhere (and updated on >> some schedule), I'd be happy to make the official Hoogle server search >> it. Usually I just grab databases off Hackage, but I'll happily make >> an exception for GHC. >> >> Thanks, Neil >> >> On Sun, Mar 6, 2011 at 7:52 AM, Malcolm Wallace >> wrote: The final stumbling block is getting the local webserver (hoogle server) to also search the above database. I'm sure there must be some simple way I can pass the name of the database as an argument when I boot up the server, but I can't seem to find it... >>> >>> Have you found the various versions of the web deployment procedure yet? >>> >>> deploy.txt: instructions to follow manually (seems to be up-to-date) >>> deploy.sh: a shell script version to run locally (may be old) >>> Deploy.hs: a haskell version to run remotely (may also be old) >>> >>> Obviously those scripts are tailored to the official installation, but there >>> are some clues in there, for instance the steps >>> >>> cabal configure --datadir=/srv/web/haskell.org/hoogle/ >>> --datasubdir=datadir -O2 >>> >>> and >>> >>> Upload datadir/resources to /srv/web/haskell.org/hoogle/datadir/resources >>> Upload datadir/databases/* to >>> /srv/web/haskell.org/hoogle/datadir/databases >>> >>> Regards, >>> Malcolm >>> >>> ___ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users@haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> > > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hoogling GHC
Hi Neil -- Is there a command line option that allows one to change the default prefix for the URL returned by searches? For example, I managed to get a local hoogle server to index over ghc.foo but a query "dfun" returned the (dead) link http://hackage.haskell.org/packages/archive/ghc/latest/doc/html/Id.html#v:isDFunId presumably using the default prefix for hackage.haskell.org/... Instead, by manually tweaking the prefix to http://www.haskell.org/ghc/docs/7.0.1/html/libraries/ghc-7.0.1/Id.html#v:isDFunId I get something useful. Is there some way to rig the .txt --> .foo conversion to use a manually supplied prefix? Thanks for your help with this! Ranjit. On Mar 9, 2011, at 1:59 PM, Neil Mitchell wrote: > Hi Ranjit, > > It sounds like you've got quite far. Sadly the manual is a bit out of > date with respect to generating databases, but generally you need to > produce ghc.txt on your own (using tools such as GHC's make system), > then you can do: > > hoogle convert ghc.txt default.hoo > > Then you can run the local server with: > > hoogle server --databases=. > > That will find databases from the current directory, and serve them. > Alternatively, if you put ghc.hoo (or default.hoo) in > $DATADIR/databases it will pick them up automatically (where $DATADIR > is whatever Cabal configured it to be). If you name the database as > default.hoo it will be searched by default, if you name it ghc.hoo > then "foo +ghc" will search for foo in the GHC database. > > If a copy of ghc.txt was publicly available somewhere (and updated on > some schedule), I'd be happy to make the official Hoogle server search > it. Usually I just grab databases off Hackage, but I'll happily make > an exception for GHC. > > Thanks, Neil > > On Sun, Mar 6, 2011 at 7:52 AM, Malcolm Wallace > wrote: >>> The final stumbling block is getting the local webserver (hoogle server) >>> to also search the above database. I'm sure there must be some simple way >>> I >>> can pass the name of the database as an argument when I boot up the >>> server, >>> but I can't seem to find it... >> >> Have you found the various versions of the web deployment procedure yet? >> >> deploy.txt: instructions to follow manually (seems to be up-to-date) >> deploy.sh: a shell script version to run locally (may be old) >> Deploy.hs: a haskell version to run remotely (may also be old) >> >> Obviously those scripts are tailored to the official installation, but there >> are some clues in there, for instance the steps >> >>cabal configure --datadir=/srv/web/haskell.org/hoogle/ >> --datasubdir=datadir -O2 >> >> and >> >>Upload datadir/resources to /srv/web/haskell.org/hoogle/datadir/resources >>Upload datadir/databases/* to >> /srv/web/haskell.org/hoogle/datadir/databases >> >> Regards, >>Malcolm >> >> ___ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Linker error
The relevant GHC ticket is: http://hackage.haskell.org/trac/ghc/ticket/5011, which it seems has already been fixed in HEAD. You can also check this thread on Haskell-Cafe which contains a few workarounds for this problem: http://www.haskell.org/pipermail/haskell-cafe/2011-March/090051.html -Dave On Mar 14, 2011, at 10:55 AM, Don Stewart wrote: > There's an open bug ticket about XCode 4 not linking properly (I think > due to the new dtrace support making GHC builds tied to a specific > XCode version). > > Can you downgrade to XCode 3 in the meantime? > > On Mon, Mar 14, 2011 at 8:43 AM, Luca Ciciriello > wrote: >> Hi All. >> I've just installed the new Haskell platform (2011.2.0.0) on my MacOS X >> 10.6.6 with Xcode 4 >> >> Now the problem is that when I try to build my Haskel programs I receive the >> linker error: >> >> Linking lexer ... >> ld: library not found for -lcrt1.10.5.o >> collect2: ld returned 1 exit status >> >> Any idea? >> >> Thanks in advance. >> >> Luca >> ___ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Linker error
There's an open bug ticket about XCode 4 not linking properly (I think due to the new dtrace support making GHC builds tied to a specific XCode version). Can you downgrade to XCode 3 in the meantime? On Mon, Mar 14, 2011 at 8:43 AM, Luca Ciciriello wrote: > Hi All. > I've just installed the new Haskell platform (2011.2.0.0) on my MacOS X > 10.6.6 with Xcode 4 > > Now the problem is that when I try to build my Haskel programs I receive the > linker error: > > Linking lexer ... > ld: library not found for -lcrt1.10.5.o > collect2: ld returned 1 exit status > > Any idea? > > Thanks in advance. > > Luca > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Linker error
Hi All. I've just installed the new Haskell platform (2011.2.0.0) on my MacOS X 10.6.6 with Xcode 4 Now the problem is that when I try to build my Haskel programs I receive the linker error: Linking lexer ... ld: library not found for -lcrt1.10.5.o collect2: ld returned 1 exit status Any idea? Thanks in advance. Luca ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC build error: cannot satisfy -package ghc-7.1.20110217
On 10/03/2011 02:44, Dave Bayer wrote: I saw this same error, building GHC 7.0.2 from source on OS X. My builds are completely scripted, so I could attempt any experiments that would help. I always expect issues with major (here, 6 => 7) version changes; here all issues surrounded cabal-install in one way or another. My issues went away when I compiled GHC 7.0.2 using a bootstrap copy of GHC 7.0.2 (rather than from GHC 6.12.3). made the new install the active GHC, and then ran ./bootstrap.sh --global to install cabal-install-0.10.2. Either the change from cabal-install-0.10.0 helped (I couldn't track down release notes) or there is a subtle difference in a GHC 7.0.2 compiled from GHC 6.12.3, that gets exposed when one tries to install cabal-install. Can you tell us exactly which versions of GHC and Cabal you were using when the build failed? We should be able to reproduce the problem from that. Cheers, Simon I still can't use cabal-install on one copy of 7.0.2 to install to another copy of 7.0.2, but it looks like something I'll manage to sort out without help. I use PREFIX to localize the installation to e.g. /usr/local/ghc-7.0.2c. This requires that my script edits bootstrap.sh, as there's no way to change PREFIX from outside in --global mode. On Mar 8, 2011, at 9:44 AM, Simon Marlow wrote: I don't know what might case this I'm afraid. Is it reproducible from a completely clean tree? (i.e. make maintainer-clean first). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: trac ticket spam
On 12/03/2011 22:27, Ian Lynagh wrote: On Sat, Mar 12, 2011 at 10:13:07PM +, Simon Marlow wrote: On 12/03/11 09:00, Max Bolingbroke wrote: There is this plugin: https://software.sandia.gov/trac/fast/wiki/TicketModerator The TicketModerator plugin is an extension for the Trac project Possibly useful? Maybe. Before we look into that, I've also mentioned to Ian that I'm somewhat suspicious about the current spam plugin - I don't think it's actually working properly. The log is supposed to list every content submission, but it only has a paultry few, suggesting that most content submissions are not actually being piped through the spam filter. I was looking at this earlier today. Those that are in the monitor list have "anonymous" as the author (prsumably due to people getting logged out), so I wonder if comments from authenticated users are going via a different path. Could be, or maybe our database is wonky in some way? e.g. maybe we have some old cruft in the database of spam filter logs that is preventing it from working. Perhaps a suitable "DROP TABLE" would fix it. The page about TracSpamFilter mentions something like this: "Upgrading the environment is necessary to install the database table required for this logging." I fiddled with various things, and enabled logging, but am no further forward. The easiest way forward would probably be to upgrade to trac 0.12, except it's not packaged for Debian (even in unstable). Maybe installing trac from source is the best way forward. Fine by me... Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.ByteString.Lazy.ByteString vs Data.ByteString.Lazy.Internal.ByteString
On 14/03/2011 10:33, Christian Maeder wrote: Am 14.03.2011 06:26, schrieb C K Kashyap: Looks like a job for Data.Binary. > I'd like to use it with just the libraries that are part of the platform I forgot to mention, Data.Binary does not seem to be in the platform. Right, it is not in the platform, but I would recommend to install those packages that you find useful (and vote for packages to be included into later versions of the platform.) Interestingly, there is a hidden package ghc-binary-0.5.0.2, which almost looks like binary-0.5.0.2. Maybe ghc developers and platform maintainers could comment on any differences. If there are none you could simple "ghc-pkg expose ghc-binary". For future versions of ghc and the platform a single ghc-binary or binary version would be better. You shouldn't use ghc-binary. It is indeed the same as binary, and is required because GHC uses it internally, but binary is not a platform package so we renamed it to ghc-binary and set it to be "hidden" by default. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
testsuite missing was: Re: ANNOUNCE: GHC version 7.0.2
Why is the file still not being updated? http://www.haskell.org/ghc/dist/7.0.2/testsuite-7.0.2.tar.bz2 C. Am 10.03.2011 03:22, schrieb Jens Petersen: > On 4 March 2011 23:14, Christian Maeder wrote: >> http://www.haskell.org/ghc/dist/7.0.2/testsuite-7.0.2.tar.bz2 >> >> This archive does not seem to have the actual tests inside the testsuite >> subdirectory. At least the README is identical to the top-level one. > > Not just the readme, but most of the files actually! > > $ tar jxf ghc-7.0.2-src.tar.bz > $ tar jxf testsuite-7.0.2.tar.bz > $ mv ghc-7.0.2/testsuite testsuite-7.0.2 > $ diff -sr ghc-7.0.2 testsuite-7.0.2 | grep "are identical$" | wc -l > 1193 > > A week has passed now - can we please have a fixed > testsuite-7.0.2.tar.bz2? :) > > Thanks, Jens > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Data.ByteString.Lazy.ByteString vs Data.ByteString.Lazy.Internal.ByteString
The ghc-binary package is used internal to GHC, and isn't gauranteed to be present from one version to the next, nor do I expect the GHC team to promise it will have a stable interface. You'd really be better of instaling the package "binary", or something similar. On Mar 14, 2011 5:34 AM, "Christian Maeder" wrote: ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.ByteString.Lazy.ByteString vs Data.ByteString.Lazy.Internal.ByteString
Am 14.03.2011 06:26, schrieb C K Kashyap: > Looks like a job for Data.Binary. > > > I'd like to use it with just the libraries that are part of the > platform > > > I forgot to mention, Data.Binary does not seem to be in the platform. Right, it is not in the platform, but I would recommend to install those packages that you find useful (and vote for packages to be included into later versions of the platform.) Interestingly, there is a hidden package ghc-binary-0.5.0.2, which almost looks like binary-0.5.0.2. Maybe ghc developers and platform maintainers could comment on any differences. If there are none you could simple "ghc-pkg expose ghc-binary". For future versions of ghc and the platform a single ghc-binary or binary version would be better. Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
