Re: [Haskell-cafe] Packages in distro mentioned on hackage?
Hi Magnus, How does a distro get to be added like that? check out http://hackage.haskell.org/trac/hackage/ticket/570. Take care, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages all screwed up
This is the easiest way conceptually. You can also try to --reinstall every package that 'ghc-pkg check' report is broken. If you pick up the right version and compilation options will match there is a high chance you can fix this state. I've done this before and it worked. Best regards, Krzysztof Skrzętnicki On Tue, Feb 1, 2011 at 08:16, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hi, Thanks for your answers. I did cabal upgrade yesod As for the user/global issue, I think I tried a user install, this is default isn't it? Looks like I will have to reinstall everything :-( Arnaud On Tue, Feb 1, 2011 at 1:34 AM, Antoine Latter aslat...@gmail.com wrote: On Mon, Jan 31, 2011 at 4:59 PM, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hello, I recently tried to upgrade some package (eg. yesod) and it seems that, in the process, I screwed up my Haskell packages setup. When I am trying to do a simple: ghc --make Crete1941 What command(s) did you issue to upgrade some packages? Were you trying to do a user or global install? When ghc loads packages, I've had cases where packages in the user db would shadow packages in the global db, causing *other* packages in the global db to report as broken. Thanks, Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages all screwed up
I started that way but quickly ran into issues about compilers toolchain for certain packages: I am on windows and some core packages require mingw toolchain. 2011/2/1 Krzysztof Skrzętnicki gte...@gmail.com: This is the easiest way conceptually. You can also try to --reinstall every package that 'ghc-pkg check' report is broken. If you pick up the right version and compilation options will match there is a high chance you can fix this state. I've done this before and it worked. Best regards, Krzysztof Skrzętnicki On Tue, Feb 1, 2011 at 08:16, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hi, Thanks for your answers. I did cabal upgrade yesod As for the user/global issue, I think I tried a user install, this is default isn't it? Looks like I will have to reinstall everything :-( Arnaud On Tue, Feb 1, 2011 at 1:34 AM, Antoine Latter aslat...@gmail.com wrote: On Mon, Jan 31, 2011 at 4:59 PM, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hello, I recently tried to upgrade some package (eg. yesod) and it seems that, in the process, I screwed up my Haskell packages setup. When I am trying to do a simple: ghc --make Crete1941 What command(s) did you issue to upgrade some packages? Were you trying to do a user or global install? When ghc loads packages, I've had cases where packages in the user db would shadow packages in the global db, causing *other* packages in the global db to report as broken. Thanks, Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages all screwed up
AFAIK GHC on Windows comes with it's own mingw, but I'm not sure if the toolchain is complete. But I wouldn't try to reinstall core packages anyway. They are best picked from installation package. Best regards, Krzysztof Skrzętnicki 2011/2/1 Arnaud Bailly arnaud.oq...@gmail.com I started that way but quickly ran into issues about compilers toolchain for certain packages: I am on windows and some core packages require mingw toolchain. 2011/2/1 Krzysztof Skrzętnicki gte...@gmail.com: This is the easiest way conceptually. You can also try to --reinstall every package that 'ghc-pkg check' report is broken. If you pick up the right version and compilation options will match there is a high chance you can fix this state. I've done this before and it worked. Best regards, Krzysztof Skrzętnicki On Tue, Feb 1, 2011 at 08:16, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hi, Thanks for your answers. I did cabal upgrade yesod As for the user/global issue, I think I tried a user install, this is default isn't it? Looks like I will have to reinstall everything :-( Arnaud On Tue, Feb 1, 2011 at 1:34 AM, Antoine Latter aslat...@gmail.com wrote: On Mon, Jan 31, 2011 at 4:59 PM, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hello, I recently tried to upgrade some package (eg. yesod) and it seems that, in the process, I screwed up my Haskell packages setup. When I am trying to do a simple: ghc --make Crete1941 What command(s) did you issue to upgrade some packages? Were you trying to do a user or global install? When ghc loads packages, I've had cases where packages in the user db would shadow packages in the global db, causing *other* packages in the global db to report as broken. Thanks, Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages all screwed up
On Tue, Feb 1, 2011 at 1:16 AM, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hi, Thanks for your answers. I did cabal upgrade yesod As for the user/global issue, I think I tried a user install, this is default isn't it? Looks like I will have to reinstall everything :-( Well, since you went wrong with a user install you should be fine clearing out your user package DB. So you'll only need to reinstall most things :-) There might be a path forward, but I get frustrated easily with this sort of thing - I would have cleared by user package DB by no, I think. Arnaud On Tue, Feb 1, 2011 at 1:34 AM, Antoine Latter aslat...@gmail.com wrote: On Mon, Jan 31, 2011 at 4:59 PM, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hello, I recently tried to upgrade some package (eg. yesod) and it seems that, in the process, I screwed up my Haskell packages setup. When I am trying to do a simple: ghc --make Crete1941 What command(s) did you issue to upgrade some packages? Were you trying to do a user or global install? When ghc loads packages, I've had cases where packages in the user db would shadow packages in the global db, causing *other* packages in the global db to report as broken. Thanks, Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages all screwed up
That's what my experience tell me :-) I guess it is mainly my private packages that are screwed up. I will first try moving this out of the way before reinstalling Haskell Platform. On Tue, Feb 1, 2011 at 1:41 PM, Antoine Latter aslat...@gmail.com wrote: On Tue, Feb 1, 2011 at 1:16 AM, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hi, Thanks for your answers. I did cabal upgrade yesod As for the user/global issue, I think I tried a user install, this is default isn't it? Looks like I will have to reinstall everything :-( Well, since you went wrong with a user install you should be fine clearing out your user package DB. So you'll only need to reinstall most things :-) There might be a path forward, but I get frustrated easily with this sort of thing - I would have cleared by user package DB by no, I think. Arnaud On Tue, Feb 1, 2011 at 1:34 AM, Antoine Latter aslat...@gmail.com wrote: On Mon, Jan 31, 2011 at 4:59 PM, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hello, I recently tried to upgrade some package (eg. yesod) and it seems that, in the process, I screwed up my Haskell packages setup. When I am trying to do a simple: ghc --make Crete1941 What command(s) did you issue to upgrade some packages? Were you trying to do a user or global install? When ghc loads packages, I've had cases where packages in the user db would shadow packages in the global db, causing *other* packages in the global db to report as broken. Thanks, Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages all screwed up
On Mon, Jan 31, 2011 at 11:16 PM, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hi, Thanks for your answers. I did cabal upgrade yesod I think 'upgrade' is deprecated, and known to break things on occasion (or at least have unexpected behavior--I'm not clear on the details). You can use 'cabal install' to upgrade packages. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages all screwed up
On Monday 31 January 2011 23:59:57, Arnaud Bailly wrote: Hello, I recently tried to upgrade some package (eg. yesod) and it seems that, in the process, I screwed up my Haskell packages setup. Big time. When I am trying to do a simple: ghc --make Crete1941 It fails with message: Loader\Communication.hs:14:7: Could not find module `System.Process': Use -v to see a list of the files searched for. Scary. Does 'ghc-pkg list process' list - no package process at all - one package process in the global db - more than one process (one in the global db) - process in user db but not global ? The first would mean your GHC is really borked and you'd need to reinstall. The second and third would mean there's hope, four looks like a reinstall again. Unfortunately, the error message lets me fear the first. which is quite annoying ! Is there a way to reconstruct a sane baseline ? 1. Check whether ghc itself is affected, rename (or move, or delete if you think it's not worth saving) the directory your user db is in (ghc-pkg list process should tell you where if you don't know), so ghc doesn't see it. ghc-pkg check. If nothing is reported as broken, try compiling a programme or two using only the core libs, if it works, you probably don't need to reinstall ghc, if not, you have to start from zero. 2. If ghc itself is okay, you can decide whether you want to start fresh, then delete the old directory and cabal install what you need/want. If you think trying to rescue what you have and is not broken is worth the effort, ghc-pkg unregister the broken packages and cabal install them again. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages all screwed up
On Mon, Jan 31, 2011 at 4:59 PM, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hello, I recently tried to upgrade some package (eg. yesod) and it seems that, in the process, I screwed up my Haskell packages setup. When I am trying to do a simple: ghc --make Crete1941 What command(s) did you issue to upgrade some packages? Were you trying to do a user or global install? When ghc loads packages, I've had cases where packages in the user db would shadow packages in the global db, causing *other* packages in the global db to report as broken. Thanks, Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages all screwed up
Hi, Thanks for your answers. I did cabal upgrade yesod As for the user/global issue, I think I tried a user install, this is default isn't it? Looks like I will have to reinstall everything :-( Arnaud On Tue, Feb 1, 2011 at 1:34 AM, Antoine Latter aslat...@gmail.com wrote: On Mon, Jan 31, 2011 at 4:59 PM, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hello, I recently tried to upgrade some package (eg. yesod) and it seems that, in the process, I screwed up my Haskell packages setup. When I am trying to do a simple: ghc --make Crete1941 What command(s) did you issue to upgrade some packages? Were you trying to do a user or global install? When ghc loads packages, I've had cases where packages in the user db would shadow packages in the global db, causing *other* packages in the global db to report as broken. Thanks, Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages on hackage: how to download files which are not included in the darcs inventory
Andrew U. Frank fran...@geoinfo.tuwien.ac.at writes: i try to use jsmw. i see that there are multiple example files in a directory. this directory is not included in darcs and does not download automatically. is there an easy way to download directories (i can get the files individually with curl - but this is slow and errorprone)? http://code.haskell.org/yc2js/examples/ (using wget, curl or the down-them-all extension for firefox) ? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages on Hackage?
On Thu, 2009-06-18 at 23:26 -0500, Vasili I. Galchin wrote: Hello, Haskell packages on Hackage can be hosted anywhere, yes? Yes. If a Haskell package is hosted on Hackage, how often is it backed up? It's not especially wise to rely on Hackage for your backup needs since it obviously does not cover your revision control history or changes since the last release. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages on Hackage?
ok ... thx On Sun, Jun 21, 2009 at 12:14 PM, Duncan Coutts duncan.cou...@worc.ox.ac.uk wrote: On Thu, 2009-06-18 at 23:26 -0500, Vasili I. Galchin wrote: Hello, Haskell packages on Hackage can be hosted anywhere, yes? Yes. If a Haskell package is hosted on Hackage, how often is it backed up? It's not especially wise to rely on Hackage for your backup needs since it obviously does not cover your revision control history or changes since the last release. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages on Hackage?
vigalchin: Hello, Haskell packages on Hackage can be hosted anywhere, yes? If a Haskell package is hosted on Hackage, how often is it backed up? Nightly. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages
A reminder: When I wanted to upgrade to yi 0.4.6.2, I needed to download the new package list first cabal update#download list of new packages cabal upgrade #install newer versions of all packages see cabal help upgrade for more, for upgrading a single package cabal upgrade yi Regards, CS 2008/9/23 Cetin Sert [EMAIL PROTECTED] Does that answer your query? Yep it does, ^__^ Thank you very much. Cetin 2008/9/23 Austin Seipp [EMAIL PROTECTED] Excerpts from Dougal Stanton's message of Tue Sep 23 06:09:58 -0500 2008: That should happen automatically with cabal-install if the version number in the .cabal file has changed. There doesn't seem to be a good way of forcing cabal-install to recreate a build (eg, if you want to rebuild/reinstall with profiling). I think you need to unregister the package manually first. :-( With cabal-install 0.5.2, you simply have to pass the '--reinstall' flag to the 'install' command and it will reconfigure, rebuild and reinstall the packages with whatever flags you specify. Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages
Am Sonntag, 21. September 2008 09:44 schrieb Andrew Coppin: […] 2. If we already have a Cabal package, why do we also need seperate packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform? If I want to install gtk2hs on Debian, I’d like gtk (the C library) to be automatically installed. And I want Debian’s gtk package because this is the one, other Debian-packaged software uses. And a Debian user installing an application written in Haskell wants to use the Debian package manager. […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages
Austin: Of course, if you are doing haskell development, the best possible way to go (IMO) full-blown cabal install since you will always get the most up-to-date code Let's say I go and compile a library from sources and install it through Cabal. How can I update the binary version of the library Cabal installed after recompiling the library using newer/modified sources? Cetin 2008/9/23 Wolfgang Jeltsch [EMAIL PROTECTED] Am Sonntag, 21. September 2008 09:44 schrieb Andrew Coppin: […] 2. If we already have a Cabal package, why do we also need seperate packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform? If I want to install gtk2hs on Debian, I'd like gtk (the C library) to be automatically installed. And I want Debian's gtk package because this is the one, other Debian-packaged software uses. And a Debian user installing an application written in Haskell wants to use the Debian package manager. […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages
Excerpts from Cetin Sert's message of Tue Sep 23 05:55:21 -0500 2008: Let's say I go and compile a library from sources and install it through Cabal. How can I update the binary version of the library Cabal installed after recompiling the library using newer/modified sources? I'm not quite sure I understand the question - if you for example install foo 0.1 using cabal, and then you want foo 0.2, you just install it with the same procedures. In this case, the higher version number means the other is 'shadowed' by it, and if you explicitly need to use foo 0.1, you can either specify this as a constraint of the form: build-depends: foo == 0.1 in the package's .cabal file, or you will have to explicitly pass ghc/ghci the flag: -hide-package foo-0.2 Otherwise, GHC will default to building anything that depends on foo against the newest version. OTOH, if you for example install foo 0.1 from stable sources, then checkout the HEAD version which is also listed as v0.1 in the .cabal file, reinstalling it will simply overwrite the old version entirely. Does that answer your query? Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages
2008/9/23 Cetin Sert [EMAIL PROTECTED]: Austin: Let's say I go and compile a library from sources and install it through Cabal. How can I update the binary version of the library Cabal installed after recompiling the library using newer/modified sources? That should happen automatically with cabal-install if the version number in the .cabal file has changed. There doesn't seem to be a good way of forcing cabal-install to recreate a build (eg, if you want to rebuild/reinstall with profiling). I think you need to unregister the package manually first. :-( D -- Dougal Stanton [EMAIL PROTECTED] // http://www.dougalstanton.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages
Excerpts from Dougal Stanton's message of Tue Sep 23 06:09:58 -0500 2008: That should happen automatically with cabal-install if the version number in the .cabal file has changed. There doesn't seem to be a good way of forcing cabal-install to recreate a build (eg, if you want to rebuild/reinstall with profiling). I think you need to unregister the package manually first. :-( With cabal-install 0.5.2, you simply have to pass the '--reinstall' flag to the 'install' command and it will reconfigure, rebuild and reinstall the packages with whatever flags you specify. Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages
Does that answer your query? Yep it does, ^__^ Thank you very much. Cetin 2008/9/23 Austin Seipp [EMAIL PROTECTED] Excerpts from Dougal Stanton's message of Tue Sep 23 06:09:58 -0500 2008: That should happen automatically with cabal-install if the version number in the .cabal file has changed. There doesn't seem to be a good way of forcing cabal-install to recreate a build (eg, if you want to rebuild/reinstall with profiling). I think you need to unregister the package manually first. :-( With cabal-install 0.5.2, you simply have to pass the '--reinstall' flag to the 'install' command and it will reconfigure, rebuild and reinstall the packages with whatever flags you specify. Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages
Excerpts from Andrew Coppin's message of Sun Sep 21 02:44:10 -0500 2008: 1. How is putting something into a Cabal package different from just handing somebody the source code and telling them to run ghc --make? Cabal can handle things for you like when your package depends on external data files; when cabal compiles the code it autogenerates a module which you import that will give you the path name to where-ever it is installed, which is nifty in case you for example are uploading a language for an interpreter and want to store the languages' prelude somewhere. It also allows for more tight constraints on dependent package versions i.e. with it you can specify the exact package and version you need to build (for example, parsec 2.1 3.0 which a few packages do.) With --make you would have to include a lot of -hide-package flags and a lot of other things, too. It is also naturally the easiest way to actually install libraries since it will register that library with ghc-pkg for you. 2. If we already have a Cabal package, why do we also need seperate packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform? Having these packages available as native packages for a package manager lets you distribute applications easier for example; if someone just wants to install appname from say, the archlinux user repository (which is source-based, mind you - the official repo is binary based,) it may also depend on parsec, haskell98, HTTP, etc.. Having these packages available natively to the manager means it can track the dependencies and install the application by itself - this is useful for example if someone just wants to use a haskell application but they don't code haskell (example: darcs or pandoc.) Of course, if you are doing haskell development, the best possible way to go (IMO) full-blown cabal install since you will always get the most up-to-date code - plus mixing and matching native package managers and e.g. cabal install doesn't really work well IME; for example if you want to install alex from macports, it will automatically install ghc too, even if you actually have it installed, but you didn't install it through macports (I just used the .dmg file that Manual Chak. made.) Likewise you may want to get something and it might depend on the HTTP library - it could very well already be installed via cabal-install, but the native manager won't dig into GHC to find out and will instead just work based on what it knows is installed in its package database. Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages
andrewcoppin: Ivan Lazar Miljenovic wrote: On Sat, 20 Sep 2008 23:38:16 -0700 Don Stewart [EMAIL PROTECTED] wrote: And by now you know where which distro has it: http://aur.archlinux.org/packages.php?ID=18343 I'm sorry, Don, but you're late... Gentoo had it last night (as soon as Matthew told me he uploaded it to Hackage)! ;-) I'm sorry, I'm confused... 1. How is putting something into a Cabal package different from just handing somebody the source code and telling them to run ghc --make? 2. If we already have a Cabal package, why do we also need seperate packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform? 3. Why isn't any of this explained in print anywhere? It's all about users. To see more of the philosophy here, check out, Haskell: Batteries Included http://www.cse.unsw.edu.au/~dons/papers/CPJS08.html Ubiquitous, easy, complete Haskell. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages
Austin Seipp wrote: Cabal can handle things for you like when your package depends on external data files; when cabal compiles the code it autogenerates a module which you import that will give you the path name to where-ever it is installed, which is nifty in case you for example are uploading a language for an interpreter and want to store the languages' prelude somewhere. OK, fair enough. I'm unlikely to ever need this personally, but it has utility. It also allows for more tight constraints on dependent package versions i.e. with it you can specify the exact package and version you need to build (for example, parsec 2.1 3.0 which a few packages do.) With --make you would have to include a lot of -hide-package flags and a lot of other things, too. So you're saying that using Cabal allows you to check that all your build dependencies are already installed? (Certainly just building something with GHC means that if some package isn't installed, you're going to have a hard time figuring out what's missing.) It is also naturally the easiest way to actually install libraries since it will register that library with ghc-pkg for you. Mmm, OK. 2. If we already have a Cabal package, why do we also need seperate packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform? Having these packages available as native packages for a package manager lets you distribute applications easier for example; if someone just wants to install appname from say, the archlinux user repository (which is source-based, mind you - the official repo is binary based,) it may also depend on parsec, haskell98, HTTP, etc.. Having these packages available natively to the manager means it can track the dependencies and install the application by itself - this is useful for example if someone just wants to use a haskell application but they don't code haskell (example: darcs or pandoc.) Of course, if you are doing haskell development, the best possible way to go (IMO) full-blown cabal install. Having native packages for stand-alone applications such as Darcs makes sense to me - after all, you don't need to install GCC just to use (say) KEdit, so why would you need to install GHC and build Darcs from source just to use it? However, managing individual Haskell libraries via the local package management system seems slightly redundant to me. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages and QuickCheck
Has there ever been a discussion of typed, user-definable, user-processable source code annotations for Haskell? afair it was on haskell-prime list http://hackage.haskell.org/trac/haskell-prime/ticket/88 if you can call that a discussion :-) signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages and QuickCheck
Am Dienstag, 9. September 2008 15:46 schrieb Sean Leather: […] Testing non-exported functionality without exporting the test interface seems difficult in general. Is there a way to hide part of a module interface with Cabal? Then, you could have a 'test' function exported from each module for testing but hidden for release. You can have modules not included in the Exposed-Modules section which contain the actual implementation and export also some internals used for testing. Then you can let the exposed modules import these internal modules and reexport the stuff intended for the public. […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages and QuickCheck
Am Dienstag, 9. September 2008 16:05 schrieb Conal Elliott: […] My current leaning is to split a package foo into packages foo and foo-test What benefit does this provide? It keeps the library and its dependencies small. Do you publish foo-test on Hackage? If yes than the HackageDB gets cluttered with test packages. If not, there is no easy way for users to run your tests. […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages and QuickCheck
If I do foo and foo-test, then I would probably place foo-test on Hackage. Alternatively, just give foo a pointer to the location of the foo-test darcs repo location. But then it might not be easy for users to keep the versions in sync. On Wed, Sep 10, 2008 at 10:24 AM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Dienstag, 9. September 2008 16:05 schrieb Conal Elliott: […] My current leaning is to split a package foo into packages foo and foo-test What benefit does this provide? It keeps the library and its dependencies small. Do you publish foo-test on Hackage? If yes than the HackageDB gets cluttered with test packages. If not, there is no easy way for users to run your tests. […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages and QuickCheck
Sean Leather wrote: How do folks like to package up QuickCheck tests for their libraries? In the main library? As a separate repo package? Same repo separate package? Keeping tests with the tested code allows testing of non-exported functionality, but can add quite a lot of clutter. I have QuickCheck properties plus HUnit tests, but I think the question is the same. For me, it's in the same repository and shipped with the package source. I think that if you ship source (even via Hackage), you should also ship tests. So, if somebody wants to modify the source, they can run the tests. And making it convenient to test is very important, so I have cabal test (or runhaskell Setup.hs test without cabal-install) configured to run the tests. I don't think tests should (in general) be part of the user-visible API, so I have them external to the module hierarchy. Do you have a quick-and-easy recipe you could post for making this stuff work well? In particular, it would be helpful to have it not install the test program as well. I'm not as fluent in the intracacies of Cabal as I ought to be, I'm afraid. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages and QuickCheck
Ketil Malde wrote: Conal Elliott [EMAIL PROTECTED] writes: Thanks a bunch for these tips. I haven't used the flags feature of cabal before, and i don't seem to be able to get it right. Another option might be to have the test command build via 'ghc --make' instead of Cabal - this way, you can avoid mentioning testing libraries altogether in the cabal file. This is the approach I have often taken in the past, but it imposes somewhat of a maintenance burden because you mus tthen make sure that the ghc command line flags are kept in-sync what what you're doing in the cabal file -- -X options, packages used, etc. This becomes even more difficult if your cabal file is doing any sort of dynamic configuration. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages and QuickCheck
Sean Leather wrote: My tests are making use of a nice console test runner I wrote that supports both HUnit and QuickCheck (and is extensible to other test providers by the user): http://hackage.haskell.org/cgi-bin/hackage-scripts/package/test-framework. The description looks great! I might have to try it out. I used HUnit with QuickCheck 2, so that I could run QC properties as HUnit tests. QC2 has the added ability (over QC1) to run a property and return a Bool instead of just exiting with an error, and that works nicely within HUnit. Does test-framework do something else to support QC running side-by-side with HUnit? See: http://software.complete.org/static/missingh/doc/MissingH/Test-HUnit-Utils.html Also some examples at http://git.complete.org/offlineimap?a=tree;f=testsrc;h=217ee16404384ba2ae3ad01bcdb5696fe495bbdf;hb=refs/heads/v7 see runtests.hs and TestInfrastructure.hs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages and QuickCheck
2008/9/9 Conal Elliott [EMAIL PROTECTED]: How do folks like to package up QuickCheck tests for their libraries? In the main library? As a separate repo package? Same repo separate package? Keeping tests with the tested code allows testing of non-exported functionality, but can add quite a lot of clutter. If they're in a separate package it's less easy to wire quickcheck tests into the commit procedure. Cheers, D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages and QuickCheck
On Tue, Sep 9, 2008 at 2:05 PM, Dougal Stanton [EMAIL PROTECTED] wrote: If they're in a separate package it's less easy to wire quickcheck tests into the commit procedure. And by package there, I mean repo. Obviously ;-) D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages and QuickCheck
How do folks like to package up QuickCheck tests for their libraries? In the main library? As a separate repo package? Same repo separate package? Keeping tests with the tested code allows testing of non-exported functionality, but can add quite a lot of clutter. I have QuickCheck properties plus HUnit tests, but I think the question is the same. For me, it's in the same repository and shipped with the package source. I think that if you ship source (even via Hackage), you should also ship tests. So, if somebody wants to modify the source, they can run the tests. And making it convenient to test is very important, so I have cabal test (or runhaskell Setup.hs test without cabal-install) configured to run the tests. I don't think tests should (in general) be part of the user-visible API, so I have them external to the module hierarchy. Testing non-exported functionality without exporting the test interface seems difficult in general. Is there a way to hide part of a module interface with Cabal? Then, you could have a 'test' function exported from each module for testing but hidden for release. My current leaning is to split a package foo into packages foo and foo-test What benefit does this provide? Thanks, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages and QuickCheck
Thanks, Sean. On Tue, Sep 9, 2008 at 3:46 PM, Sean Leather [EMAIL PROTECTED] wrote: How do folks like to package up QuickCheck tests for their libraries? In the main library? As a separate repo package? Same repo separate package? Keeping tests with the tested code allows testing of non-exported functionality, but can add quite a lot of clutter. I have QuickCheck properties plus HUnit tests, but I think the question is the same. For me, it's in the same repository and shipped with the package source. I think that if you ship source (even via Hackage), you should also ship tests. So, if somebody wants to modify the source, they can run the tests. And making it convenient to test is very important, so I have cabal test (or runhaskell Setup.hs test without cabal-install) configured to run the tests. I don't think tests should (in general) be part of the user-visible API, so I have them external to the module hierarchy. How do you set up cabal to do these tests? Do your libraries depend on HUnit? Where do you like to place your tests? In the functionality modules? A parallel structure? A single Test.hs file somewhere? Testing non-exported functionality without exporting the test interface seems difficult in general. Is there a way to hide part of a module interface with Cabal? Then, you could have a 'test' function exported from each module for testing but hidden for release. My current leaning is to split a package foo into packages foo and foo-test What benefit does this provide? It keeps the library and its dependencies small. Probably some of the alternatives do as well. For testing, I'm using checkershttp://haskell.org/haskellwiki/Checkersin addition to QuickCheck, and I'd prefer not to make casual library users have to pull in those libraries as well. - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages and QuickCheck
How do folks like to package up QuickCheck tests for their libraries? In
the main library? As a separate repo package? Same repo separate
package? Keeping tests with the tested code allows testing of non-exported
functionality, but can add quite a lot of clutter.
I have QuickCheck properties plus HUnit tests, but I think the question is
the same. For me, it's in the same repository and shipped with the package
source. I think that if you ship source (even via Hackage), you should also
ship tests. So, if somebody wants to modify the source, they can run the
tests. And making it convenient to test is very important, so I have cabal
test (or runhaskell Setup.hs test without cabal-install) configured to
run the tests. I don't think tests should (in general) be part of the
user-visible API, so I have them external to the module hierarchy.
How do you set up cabal to do these tests?
I use the runTests hook in Distribution.Simple. The code below works on
Windows and Mac, because that's what we use.
\begin{code}
module Main (main) where
import Distribution.Simple
import System.Cmd (system)
import System.FilePath ((/))
main :: IO ()
main = defaultMainWithHooks hooks where
hooks = simpleUserHooks { runTests = runTests' }
runTests' _ _ _ _ = system cmd return ()
where testdir = dist / build / test
testcmd = . / test
cmd = cd ++ testdir ++++ testcmd
\end{code}
Do your libraries depend on HUnit?
No, because I use an ultra-secret trick. ;) I have a Library in my .cabal
file and an Executable for testing. Part of the test description follows.
\begin{cabal}
Executable test
hs-source-dirs: src, tests, examples
main-is: Main.hs
-- Only enable the build-depends here if configured with -ftest. This
-- keeps users from having to install QuickCheck 2 in order to use EMGM.
if flag(test)
build-depends: QuickCheck = 2.0, HUnit = 1.2
else
buildable: False
\end{cabal}
With that last flag-based if/else, I hide the dependencies for normal
building ('test' by default is False). If 'test' is False, then the
executable also cannot be built.
Where do you like to place your tests? In the functionality modules? A
parallel structure? A single Test.hs file somewhere?
In a separate tests directory at the same level as the src directory
containing the module hierarchy. It has a number of files, mostly one per
module tested.
Testing non-exported functionality without exporting the test interface
seems difficult in general. Is there a way to hide part of a module
interface with Cabal? Then, you could have a 'test' function exported from
each module for testing but hidden for release.
My current leaning is to split a package foo into packages foo and
foo-test
What benefit does this provide?
It keeps the library and its dependencies small. Probably some of the
alternatives do as well. For testing, I'm using
checkershttp://haskell.org/haskellwiki/Checkersin addition to QuickCheck,
and I'd prefer not to make casual library users
have to pull in those libraries as well.
Ah, so you're handling the same problem we are in a different way. Nice!
Sean
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages and QuickCheck
Hi Sean.
Thanks a bunch for these tips. I haven't used the flags feature of cabal
before, and i don't seem to be able to get it right. I have:
Flag test
Description: Enable testing
Default: False
And I get Warning: unamb.cabal: Unknown section type: flag ignoring
If I indent, I instead get These flags are used without having been
defined: test. Any idea what I'm doing wrong here?
- Conal
On Tue, Sep 9, 2008 at 4:32 PM, Sean Leather [EMAIL PROTECTED] wrote:
How do folks like to package up QuickCheck tests for their libraries? In
the main library? As a separate repo package? Same repo separate
package? Keeping tests with the tested code allows testing of non-exported
functionality, but can add quite a lot of clutter.
I have QuickCheck properties plus HUnit tests, but I think the question
is the same. For me, it's in the same repository and shipped with the
package source. I think that if you ship source (even via Hackage), you
should also ship tests. So, if somebody wants to modify the source, they can
run the tests. And making it convenient to test is very important, so I have
cabal test (or runhaskell Setup.hs test without cabal-install)
configured to run the tests. I don't think tests should (in general) be part
of the user-visible API, so I have them external to the module hierarchy.
How do you set up cabal to do these tests?
I use the runTests hook in Distribution.Simple. The code below works on
Windows and Mac, because that's what we use.
\begin{code}
module Main (main) where
import Distribution.Simple
import System.Cmd (system)
import System.FilePath ((/))
main :: IO ()
main = defaultMainWithHooks hooks where
hooks = simpleUserHooks { runTests = runTests' }
runTests' _ _ _ _ = system cmd return ()
where testdir = dist / build / test
testcmd = . / test
cmd = cd ++ testdir ++++ testcmd
\end{code}
Do your libraries depend on HUnit?
No, because I use an ultra-secret trick. ;) I have a Library in my .cabal
file and an Executable for testing. Part of the test description follows.
\begin{cabal}
Executable test
hs-source-dirs: src, tests, examples
main-is: Main.hs
-- Only enable the build-depends here if configured with -ftest. This
-- keeps users from having to install QuickCheck 2 in order to use EMGM.
if flag(test)
build-depends: QuickCheck = 2.0, HUnit = 1.2
else
buildable: False
\end{cabal}
With that last flag-based if/else, I hide the dependencies for normal
building ('test' by default is False). If 'test' is False, then the
executable also cannot be built.
Where do you like to place your tests? In the functionality modules? A
parallel structure? A single Test.hs file somewhere?
In a separate tests directory at the same level as the src directory
containing the module hierarchy. It has a number of files, mostly one per
module tested.
Testing non-exported functionality without exporting the test interface
seems difficult in general. Is there a way to hide part of a module
interface with Cabal? Then, you could have a 'test' function exported from
each module for testing but hidden for release.
My current leaning is to split a package foo into packages foo and
foo-test
What benefit does this provide?
It keeps the library and its dependencies small. Probably some of the
alternatives do as well. For testing, I'm using
checkershttp://haskell.org/haskellwiki/Checkersin addition to QuickCheck,
and I'd prefer not to make casual library users
have to pull in those libraries as well.
Ah, so you're handling the same problem we are in a different way. Nice!
Sean
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages and QuickCheck
Conal Elliott [EMAIL PROTECTED] writes: Thanks a bunch for these tips. I haven't used the flags feature of cabal before, and i don't seem to be able to get it right. Another option might be to have the test command build via 'ghc --make' instead of Cabal - this way, you can avoid mentioning testing libraries altogether in the cabal file. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages and QuickCheck
2008/9/9 Conal Elliott [EMAIL PROTECTED]: Hi Sean. Thanks a bunch for these tips. I haven't used the flags feature of cabal before, and i don't seem to be able to get it right. I have: Flag test Description: Enable testing Default: False And I get Warning: unamb.cabal: Unknown section type: flag ignoring If I indent, I instead get These flags are used without having been defined: test. Any idea what I'm doing wrong here? I don't know exactly what your problem is, but perhaps you have not specified Cabal-Version: = 1.2? For another example .cabal file that uses something like the technique Sean describes you can look at my edit-distance library on GitHub: http://github.com/batterseapower/edit-distance/tree/master/edit-distance.cabal. It exports a library with the edit distance algorithms and a test executable which is only buildable when configured with -ftests. I haven't made use of the Cabal test hook, but you can run the tests just by running that single executable: the procedure is described in my README: http://github.com/batterseapower/edit-distance/tree/master/README.textile My tests are making use of a nice console test runner I wrote that supports both HUnit and QuickCheck (and is extensible to other test providers by the user): http://hackage.haskell.org/cgi-bin/hackage-scripts/package/test-framework. Cheers, Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages and QuickCheck
Thanks a bunch for these tips. I haven't used the flags feature of cabal before, and i don't seem to be able to get it right. This is also my first time, so I'm not sure exactly what I'm doing right. ;) I have: Flag test Description: Enable testing Default: False And I get Warning: unamb.cabal: Unknown section type: flag ignoring If I indent, I instead get These flags are used without having been defined: test. Any idea what I'm doing wrong here? No, but you can take a look at my .cabal file to see if you can figure out what's different. The code's not yet released, but I'm fairly confident the .cabal file does everything we need. https://svn.cs.uu.nl:12443/viewvc/dgp-haskell/EMGM/emgm.cabal?view=markup Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages and QuickCheck
My tests are making use of a nice console test runner I wrote that supports both HUnit and QuickCheck (and is extensible to other test providers by the user): http://hackage.haskell.org/cgi-bin/hackage-scripts/package/test-framework. The description looks great! I might have to try it out. I used HUnit with QuickCheck 2, so that I could run QC properties as HUnit tests. QC2 has the added ability (over QC1) to run a property and return a Bool instead of just exiting with an error, and that works nicely within HUnit. Does test-framework do something else to support QC running side-by-side with HUnit? Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages and QuickCheck
2008/9/9 Conal Elliott [EMAIL PROTECTED]: Where do you like to place your tests? In the functionality modules? A parallel structure? A single Test.hs file somewhere? The last time I had a chance to experiment with how to do this I used a single Test.hs for the whole project and I think that is a bad idea now. I agree that you don't want to clutter your code with the test cases. While it's good to have the tests accessible and near to the actual code it can be distracting too. The approach I used is here: http://blog.codersbase.com/2006/09/01/simple-unit-testing-in-haskell/ Basically, I used the H98 parser plus TH to collect all the test cases together and generate the test harness at compile time. This meant that any module that had a test case had to be plain H98 (but again, only Test.hs had test cases). On the other hand, specifying tests was as simple as starting a function name with prop_. You could also modify my technique to look through all modules, or modules with specific names. Another approach is to use conditional compilation with something like CPP. This could allow you to export everything from modules only while testing and then you could have Foo.hs and FooTests.hs for every module. The latter one would import everything from Foo.hs and define the tests. If you don't like conditional compilation, another approach I think is decent is to have FooPrivate.hs (or FooInternal.hs), which is imported into Foo.hs and FooTests.hs. You could set things up so that only Foo.hs and FooTests.hs are allowed to import FooPrivate.hs. You could of course write a script to enforce this, but something that tends to be simpler and equally effective is just to politely ask that people do not import FooPrivate.hs except in FooTests.hs and Foo.hs. I hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages and QuickCheck
2008/9/9 Sean Leather [EMAIL PROTECTED]: My tests are making use of a nice console test runner I wrote that supports both HUnit and QuickCheck (and is extensible to other test providers by the user): http://hackage.haskell.org/cgi-bin/hackage-scripts/package/test-framework. The description looks great! I might have to try it out. Great! I used HUnit with QuickCheck 2, so that I could run QC properties as HUnit tests. QC2 has the added ability (over QC1) to run a property and return a Bool instead of just exiting with an error, and that works nicely within HUnit. Does test-framework do something else to support QC running side-by-side with HUnit? You can see the approach I've taken in the QuickCheck test provider source code: http://github.com/batterseapower/test-framework/tree/master/Test/Framework/Providers/QuickCheck.hs. Basically, I just copy-pasted the relevant part of the QuickCheck source code so I could customise it to my whim :-). I'm not familiar with the QC2 API, but it's possible I would have had to do this anyway in order to get progress reporting for QuickCheck tests without them writing directly to the console (which is _bad_ when there are several property running at once!) and to obtain the random seed. Cheers, Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packages and QuickCheck
Jason Dagit wrote: On the other hand, specifying tests was as simple as starting a function name with prop_ [...] which of course reminds us of JUnit of the dark ages (up to 3.8), before they finally used annotations to declare test cases. Has there ever been a discussion of typed, user-definable, user-processable source code annotations for Haskell? J.W. signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages and how to load them
On Thu, 27 Sep 2007, bbrown wrote: If I have a set of haskell code and I create a directory with the source that has the following imports. (some_dir/MyLib.hs) module MyLib where And then I want to use that set of code at the top level directory, eg: MyTest.hs import MyLib How would I compile with ghc such that it loads the code from some_dir without it having to have the module as module some_dir.MyLib. I think this is a basic packaging question but couldnt figure it out. If you intend to write a library, you might also want to check Cabal. http://www.haskell.org/haskellwiki/How_to_write_a_Haskell_program ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages and how to load them
On Thu, Sep 27, 2007 at 06:10:37PM -0400, bbrown wrote: If I have a set of haskell code and I create a directory with the source that has the following imports. (some_dir/MyLib.hs) module MyLib where And then I want to use that set of code at the top level directory, eg: MyTest.hs import MyLib How would I compile with ghc such that it loads the code from some_dir without it having to have the module as module some_dir.MyLib. I think this is a basic packaging question but couldnt figure it out. ghc -isome_dir Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages and modules
I'm not sure on which mail of this thread I should append MHO. What happens if two programmers happen to choose the same package name? (Prepend the location on the filesystem? ;-) If something like a package name is introduced I would prefer not separating package and module name with a . because you might then even use the package name to point to a web address from where to load code (source/ binary/ byte code??) from.. Then creating something like Java applets would be more easy. We can't ignore this completely as the world (or important parts eg Windows) will try to bring more richness to internet applications/ the user.. They strive to integrate web applications so that you as user can't see if you're running a native or a downloaded application... If you use eg , as separator you can use dots in the package name without hassle. Marc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages and modules
Marc Weber wrote: I'm not sure on which mail of this thread I should append MHO. What happens if two programmers happen to choose the same package name? (Prepend the location on the filesystem? ;-) If something like a package name is introduced I would prefer not separating package and module name with a . because you might then even use the package name to point to a web address from where to load code (source/ binary/ byte code??) from.. Then creating something like Java applets would be more easy. We can't ignore this completely as the world (or important parts eg Windows) will try to bring more richness to internet applications/ the user.. They strive to integrate web applications so that you as user can't see if you're running a native or a downloaded application... If you use eg , as separator you can use dots in the package name without hassle. I think the package alias syntax would help here eg (non-existent url): package http://www.metamilk.com/packages/duma-1.0 as Duma import Duma/Text.Line -- etc I don't think the package name should ever be written directly into the import statement, because the package name needs to be able to use normal filename syntax but a component of a module identifier needs to conform to Haskell syntax because it could be used anywhere (*) eg let x = Duma/Text.Line.take 5 y Also, to clarify my reasons for wanting to make the package part of the module id syntactically distinct (by using eg / instead of .), the entire namespace of hierarchical modules is supposed to be internal to each package, and therefore any id of the form A.B.C belongs to this internal namespace and therefore must refer to an internal module. All modules in external packages have ids of the form PackageAlias/ModulePath so when you read the source you (and the compiler) can tell at a glance whether you're referring to an internal or external module. An extra advantage of making the package alias part syntactically visible is that we could make package directives optional in the common case where we want to just use the latest version of a package that has a globally agreed name eg import Fps/Data.ByteString -- uses latest fps package whereas if we just used import Fps.Data.ByteString the compiler would have no way to tell whether we're referring to an external package Fps or another module in our own package, and, imho, this would just simply be messy and inconsistent. Also, although this requires changes to existing code, it should be possible to completely automate the change by using a simple conversion utility which knows about current packages, their prefixes, and what modules they contain (and therefore should be much less troublesome than the change from flat module namespace to hierarchical namespace). (*) As an aside, it is a question to me whether identifiers in the body of a module should be allowed to be qualified with anything other than a module *alias*. Haskell98 just had flat modules, so the qualification was of the form A.val, whereas with the hierarchical extension you can use A.B.C.val etc. However does anyone actually ever use this rather than specifying an alias for A.B.C and using the alias to qualify val instead? This becomes a more urgent question if the lexical syntax for a module id needs to use another symbol such as /. Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Packages and modules
Simon and I have been thinking about fixing this, and we think we might actually do so for GHC 6.6. Your message provoked us to write up the design. It's here http://hackage.haskell.org/trac/ghc/wiki/GhcPackages Feedback welcome It's worth reading the old threads; for example http://www.haskell.org//pipermail/libraries/2005-August/004281.html But there are many others! Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian | Hulley | Sent: 25 June 2006 10:16 | To: Haskell-cafe | Subject: [Haskell-cafe] Packages and modules | | Hi - | At the moment there is a problem in that two packages P and Q could contain | the same hierarchical module eg Data.Foo, and the only way for user code to | ensure the right Data.Foo is used is to ensure that packages P and Q are | searched in the right order. | However suppose P and Q also contain another module with the same name, eg | Data.Bar. | And suppose a user module wants to use Data.Foo from P but Data.Bar from | Q!!! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages and modules
Simon Peyton-Jones wrote: Simon and I have been thinking about fixing this, and we think we might actually do so for GHC 6.6. Your message provoked us to write up the design. It's here http://hackage.haskell.org/trac/ghc/wiki/GhcPackages Feedback welcome It's worth reading the old threads; for example http://www.haskell.org//pipermail/libraries/2005-August/004281.html But there are many others! [from wiki] ghc -c -package P1 M1.hs ghc -c -package P2 M2.hs ...compile other modules... ghc -o app M1.o M2.o ... -package P1 -package P2 I don't think this solves the whole problem. Suppose M1 needs to use A.B.C from P1 *and* A.B.C from P2, then it would need to be compiled with P1 and P2, and there is no way (from the part of the proposal in this section alone) to distinguish between these packages from within M1 itself if we're still to be limited by the import A.B.C syntax. It only seems to address the problem of app needing to use M1 and M2 but not A.B.C directly where M1 only uses P1 and M2 only uses P2. [from wiki] import Packages.Gtk-1_3_4.Widget.Button Allowing package aliases in the source could make this easier to type and avoid the necessity to capitalise and change underscores to dots: package gtk-1_3_4 as Gtk or package gtk as Gtk -- use the current version of gtk or if package directive is omitted an import Xyz/Mod is equivalent to: package xyz as Xyz -- initial letter capitalised import Xyz/Mod and making the package part of the module id explicit prevents ambiguity problems (David House's idea) though at the expense of using more syntax ie import Widget.Button from Gtk or import Gtk/Widget.Button -- instead of grafting In all cases I think it would be an absolute disaster to allow modules to be imported without an explicit package id because this would defeat the whole purpose of having a simple per-package namespace for modules and wouldn't allow the reader of source to know which packages it's referring to. Of course all code would need to be changed, but this could be accomplished by a conversion program which, given a list of packages and alias names, would just recursively traverse a source directory replacing imports and module exports by package directives and the fully qualified name of each module. [from wiki] Optional extra: grafting ambiguity ( http://www.haskell.org//pipermail/haskell-cafe/2006-June/016317.html ) The use of / instead of . (or from) gives the advantage of grafting in terms of succinct qualified module names without this ambiguity. Summary of my suggestions: 1) All module names would be of the form PackageAlias/ModId 2) package directives in the source bind aliases to actual packages 3) version number or package directive can be omitted when we are only interested in using the current version of that package 4) Package aliases have their own namespace Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages and modules
On Mon, Jun 26, 2006 at 04:20:16PM +0100, Brian Hulley wrote: I don't think this solves the whole problem. Suppose M1 needs to use A.B.C from P1 *and* A.B.C from P2 For a simple example of a case where this might arise, suppose M1 is the migration module for data (stored in a database, received over a network, or some other such case) in P version 1's format to P version 2's format. [from wiki] import Packages.Gtk-1_3_4.Widget.Button I'm also not a fan of this magic Packages.* hierarchy, nor the package name change hoops it makes us jump through. package gtk-1_3_4 as Gtk or package gtk as Gtk -- use the current version of gtk or if package directive is omitted an import Xyz/Mod is equivalent to: package xyz as Xyz -- initial letter capitalised import Xyz/Mod The package gtk as Gtk bit makes sense to me, but I'd expect then to use Gtk.Foo.Bar for module Foo.Bar in package Gtk. import gtk-1.3.4/Foo.Bar also makes sense, although personally I'd prefer the syntax from gtk-1.3.4 import Foo.Bar where either from packagename is an optional prefix to current import declaration syntax, or from packagename starts a block so we can say from gtk1 import Foo.Bar as Gtk1.Foo.Bar import Baz.Quux as Gtk1.Baz.Quux from gtk2 import Foo.Bar as Gtk2.Foo.Bar import Baz.Quux as Gtk2.Baz.Quux If we have gtk-1.something and gtk-2.something (rather than gtk1-version and gtk2-version as above) then we'd probably instead want the wiki's -package gtk-2.0.1=Gtk2 which could be generated due to a .cabal build-depends of gtk (= 2) as Gtk2 Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Packages and modules
Simon, We covered this extensively in the Cabal vs Haskell thread starting here: http://www.haskell.org//pipermail/libraries/2005-April/003607.html You concluded it by saying on April 22: And this observation points towards a simpler solution: rather than invisibly pre-pend the package name, just get the programmer to do so. So package P exposes a module called P.M and package Q exposes Q.M. All P's internal modules are called P.something, and similarly for Q. (We rely on some social mechanism for allocating new package names, as now.) Now of course you can import P.M and Q.M in a single module. That would be simple. It might be pretty inconvenient to say 'import Base.Data.List' rather than just 'import Data.List'. But nothing forces you to do this -- and indeed we don't do it for the current 'base' package. The point is that it's an easy way for a package author to ensure their package won't conflict with others. If they choose not to avail themselves of it, it's more likely that their package will be unusable because of accidental name conflicts. Bottom line: the current story is pretty defensible. I'm not sure that keeping names unique by implicitly using package-ids is worth the bother. http://www.haskell.org//pipermail/libraries/2005-April/003672.html It seems like you are changing your position with this proposal? Any reason for doing so? -Alex- __ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Mon, 26 Jun 2006, Simon Peyton-Jones wrote: Simon and I have been thinking about fixing this, and we think we might actually do so for GHC 6.6. Your message provoked us to write up the design. It's here http://hackage.haskell.org/trac/ghc/wiki/GhcPackages Feedback welcome It's worth reading the old threads; for example http://www.haskell.org//pipermail/libraries/2005-August/004281.html But there are many others! Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian | Hulley | Sent: 25 June 2006 10:16 | To: Haskell-cafe | Subject: [Haskell-cafe] Packages and modules | | Hi - | At the moment there is a problem in that two packages P and Q could contain | the same hierarchical module eg Data.Foo, and the only way for user code to | ensure the right Data.Foo is used is to ensure that packages P and Q are | searched in the right order. | However suppose P and Q also contain another module with the same name, eg | Data.Bar. | And suppose a user module wants to use Data.Foo from P but Data.Bar from | Q!!! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages and modules
Apologies to Brian for the multiple copies, this wasn't originally sent to the list. On 25/06/06, Brian Hulley [EMAIL PROTECTED] wrote: I'm wondering: would it not be easier to just make it that the package name is prepended to the hierarchical module name, so the modules would instead be called by the names P.Data.Foo and Q.Data.Bar? This has the disavantage that if you move a module from one package to another, all existing code using that module breaks. Perhaps we need something analoguous to qualified imports: as well as specifying the modules hierarchical path, you could also specify its package. E.g., import Network.HTTP from HTTP Or, using your syntax: import HTTP.Network.HTTP I prefer mine because we could also allow not qualifying the package: import Network.HTTP -- will search all known packages for a Network.HTTP package This is likely to be less of a pain in the majority of cases when the module names don't overlap. Also, ambiguity. Given 'import HTTP.Network.HTTP', the compiler has to search for both packages named HTTP and modules with a full hierarchical name of HTTP.Network.HTTP. In the unlikely sitatution where a different package did indeed provide a module called HTTP.Network.HTTP, there would be an overlap. Finally the compiler could give better error messages if the module doesn't exist. I.e. one of 'Package X not found' or 'Module Y not found within package X' instead of 'Module Y not found'. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages and modules
David House wrote: Apologies to Brian for the multiple copies, this wasn't originally sent to the list. On 25/06/06, Brian Hulley [EMAIL PROTECTED] wrote: I'm wondering: would it not be easier to just make it that the package name is prepended to the hierarchical module name, so the modules would instead be called by the names P.Data.Foo and Q.Data.Bar? This has the disavantage that if you move a module from one package to another, all existing code using that module breaks. Existing code also breaks when you rename a module, although perhaps that's not so common as moving a module to another package (it's probably just me that has a bad habit of always wanting to rename everything later ;-) ) Perhaps we need something analoguous to qualified imports: as well as specifying the modules hierarchical path, you could also specify its package. E.g., import Network.HTTP from HTTP Or, using your syntax: import HTTP.Network.HTTP [rearranged] Also, ambiguity. Given 'import HTTP.Network.HTTP', the compiler has to search for both packages named HTTP and modules with a full hierarchical name of HTTP.Network.HTTP. In the unlikely sitatution where a different package did indeed provide a module called HTTP.Network.HTTP, there would be an overlap. Finally the compiler could give better error messages if the module doesn't exist. I.e. one of 'Package X not found' or 'Module Y not found within package X' instead of 'Module Y not found'. I agree with the advantages of making the package part explicit for preventing ambiguity and getting better error messages. [rearranged] I prefer mine because we could also allow not qualifying the package: import Network.HTTP -- will search all known packages for a Network.HTTP package This is likely to be less of a pain in the majority of cases when the module names don't overlap. I think though that a problem with allowing the package part to be omitted would be that when code is shared people would get different results when trying to compile it depending on which packages they happen to have installed. At the moment, although different packages can define modules with the same name, everyone afaik takes great care to try and avoid this so that the hierarchical namespace is hopefully unique regardless of the search order of packages. However if we are allowed to qualify a hierarchical name by a package name, we might end up with a lot less uniqueness in the hierarchical namespace (since this is partly the whole point since uniqueness can't be guaranteed at the moment anyway unless everyone knows about everything that everyone else is developing or intending to make globally available) leading to more unintended combinations of modules when they're imported unqualified. Therefore to get 100% safe code (assuming uniqueness of package names), I think it would be better to make the package qualification mandatory. import Network.HTTP from HTTP import qualified Newtork.HTTP from HTTP as H Other possibilities: import HTTP\Network.HTTP import Com.Company\Network.HTTP package Com.Company as C -- a package alias import qualified C\Network.HTTP as H Not that I'm necessarily suggesting \ but just trying to find some character that is easy to type (perhaps /) and can also be used in the lexical syntax without making too much impact on the CFG. Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages and modules
On Sunday 25 June 2006 05:16 am, Brian Hulley wrote: Hi - At the moment there is a problem in that two packages P and Q could contain the same hierarchical module eg Data.Foo, and the only way for user code to ensure the right Data.Foo is used is to ensure that packages P and Q are searched in the right order. However suppose P and Q also contain another module with the same name, eg Data.Bar. And suppose a user module wants to use Data.Foo from P but Data.Bar from Q!!! I'm wondering: would it not be easier to just make it that the package name is prepended to the hierarchical module name, so the modules would instead be called by the names P.Data.Foo and Q.Data.Bar? [snip discussion of this idea] The idea of improving the module system has been discussed a number of times before. Here is a thread started by a suggestion from the simons which generated a fair bit of discussion: http://www.haskell.org/pipermail/libraries/2003-August/001310.html I'm not sure whatever became of this idea; discussion seemed to sort of reach a consensus, and then nothing happened. The module grafting mechanism always seemed kind of nice to me. I think some of the problems discussed in this thread could be by using cabal, especially to specify the graftings expected for compilation. It seems like grafting can give a plausible story for dealing with dynamicly loaded code, which is a nice bonus. -- Rob Dockins Talk softly and drive a Sherman tank. Laugh hard, it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages and modules
Robert Dockins wrote: On Sunday 25 June 2006 05:16 am, Brian Hulley wrote: [snip] I'm wondering: would it not be easier to just make it that the package name is prepended to the hierarchical module name, so the modules would instead be called by the names P.Data.Foo and Q.Data.Bar? [snip discussion of this idea] The idea of improving the module system has been discussed a number of times before. Here is a thread started by a suggestion from the simons which generated a fair bit of discussion: http://www.haskell.org/pipermail/libraries/2003-August/001310.html I'm not sure whatever became of this idea; discussion seemed to sort of reach a consensus, and then nothing happened. Thanks for the link... At the risk of being a devil's advocate I think the above idea is too flexible and overly complicated. Imho it would be like trying to have a conversation with a group of people where each person is constantly jumping about, changing their name and appearance, and might be replicated in several places at once... :-) I'd have thought all that's needed is a nice simple cathedralish design where each module knows its globally unique place and just stays there forever so that it's easy to develop and share code which uses it. (Could Java be seen as a proof of concept here? ) Package aliases in the code would then make it easy to upgrade to the latest package eg package Graphics.Rendering.OpenGL-8-9 as OpenGL import OpenGL/GL.Bitmaps In a sense the package alias idea is a little bit like grafting, except the aliasing is specified in the source code instead of somewhere else. Perhaps package aliases could even be inherited from parent modules... The module grafting mechanism always seemed kind of nice to me. I think some of the problems discussed in this thread could be by using cabal, especially to specify the graftings expected for compilation. You'd then have to keep the Cabal info in sync with the source. At the moment I can just use ghc --make and don't need to know about Cabal at all unless I want to distribute a package (or install one). It seems like grafting can give a plausible story for dealing with dynamicly loaded code, which is a nice bonus. I hadn't thought of dynamically loaded code though... Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
