Bug#538802: ITP: mercury -- The Mercury programming system, a pure logical/functional programming language.
Package: wnpp Severity: wishlist Owner: Paul Bone -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: mercury Version : 0.13.1-rotd20090725 Upstream Author : Mercury Group * URL : http://www.mercury.csse.unimelb.edu.au/ * License : GPL2 Programming Lang: Mercury Description : The Mercury programming system, a pure logical/functional programming language. Mercury is a logic/functional programming language, which combines the clarity and expressiveness of declarative programming with advanced static analysis and error detection features. Its highly optimized execution algorithm delivers efficiency far in excess of existing logic programming systems, and close to conventional programming systems. Mercury addresses the problems of large-scale program development, allowing modularity, separate compilation, and numerous optimization/time trade-offs. - -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkptWJAACgkQ5BL8BUmFfuXH+ACfX/iUhm+zlv0V85zTT/QXzNHg R8oAoI3JqP0TdK3p75QkCesNUgnwogDs =bi3e -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#538802: ITP: mercury -- The Mercury programming system, a pure logical/functional programming language.
On Mon, Jul 27, 2009 at 05:13:06PM +, brian m. carlson wrote: > On Mon, Jul 27, 2009 at 05:34:44PM +1000, Paul Bone wrote: > > * Package name: mercury > > Version : 0.13.1-rotd20090725 > > Upstream Author : Mercury Group > > * URL : http://www.mercury.csse.unimelb.edu.au/ > > * License : GPL2 > > Programming Lang: Mercury > > Description : The Mercury programming system, a pure > > logical/functional programming language. > > This used to be in Debian some time ago, because I remember trying to > work on the package for some reason. I believe that it is > self-hosting[0], which may be a problem, except that it supposedly comes > with a C version of the compiler as well. To make life easy for porters, > I'd request that you always build the C compiler and then, if you want > to, bootstrap the Mercury compiler from that. > > If I'm remembering incorrectly, or that's no longer the case, feel free > to disregard this. > This is mostly correct. Mercury is indeed self-hosting and was previously included in Debian. Mercury has a number of different backends two of these target C, high-level C and low-level C. The Mercury source distribution includes C intermediate files for the standard library and compiler generated by the low-level C backend, these can be compiled with GCC to generate binaries which can be used to bootstrap an installation by re-compiling the Mercury sources. I have a working Debian package that builds and bootstraps Mercury from the source distribution. It requires gcc-3.4 as a build-depend and is able to bootstrap itself so that the resulting binaries are optimal on 32bit and 64bit machines (the explanation involves a discussion of tagged pointers). I hope that this will be acceptable by the Debian project and that distributing intermediate files in the .orig.tar.gz file is not a problem. Mercury should build from the Debian source package equally as well as it can build from the upstream source distribution on all architectures. Cross-compilation should not be necessary. See also the list of supported architectures here: http://www.mercury.csse.unimelb.edu.au/download/rotd.html I hope this helps. If you have any more questions please let us know. Thanks. signature.asc Description: Digital signature
Re: Bug#538802: ITP: mercury -- The Mercury programming system, a pure logical/functional programming language.
On Tue, Jul 28, 2009 at 08:35:14AM +0200, Reinhard Tartler wrote: > Paul Bone writes: > > > This is mostly correct. Mercury is indeed self-hosting and was > > previously included in Debian. Mercury has a number of different > > backends two of these target C, high-level C and low-level C. The > > Mercury source distribution includes C intermediate files for the > > standard library and compiler generated by the low-level C backend, > > these can be compiled with GCC to generate binaries which can be used to > > bootstrap an installation by re-compiling the Mercury sources. > > > > I have a working Debian package that builds and bootstraps Mercury from > > the source distribution. It requires gcc-3.4 as a build-depend and is > > able to bootstrap itself so that the resulting binaries are optimal on > > 32bit and 64bit machines (the explanation involves a discussion of > > tagged pointers). > > > > I hope that this will be acceptable by the Debian project and that > > distributing intermediate files in the .orig.tar.gz file is not a > > problem. > > The same applies to the package aspectc++, a package that I maintain > since some time. AspectC++ is a language extension for C++ for aspect > oriented programming (AOP). It is built on top of an C/C++ Parsing and > Manipulation framework (PUMA), where some functionality (e.g. support > for various GNU language extension) is implemented using AspectC++ > aspects. There you have a pretty similar situation, and I'm doing a very > similar approach: Shipping intermediate files that can be processed with > gcc. > > I suggest that you use these intermediate files only for compiling an > intermediate compiler for bootstrapping. With that compiler, redo all > intermediate files and build the binaries of the compiler that will > eventually end up in the package. This ensures that you'll end with a > working compiler on all architectures. Yep, That's what we do. > BTW, this approach was actually suggested to me by Lamont Jones a few > years ago. It seems to be a quite common approach, FWIW. Thanks. signature.asc Description: Digital signature
Re: Bug#538802: ITP: mercury -- The Mercury programming system, a pure logical/functional programming language.
On Tue, Jul 28, 2009 at 09:30:58AM +0200, Lucas Nussbaum wrote: > On 28/07/09 at 10:58 +1000, Paul Bone wrote: > > On Mon, Jul 27, 2009 at 05:13:06PM +, brian m. carlson wrote: > > > On Mon, Jul 27, 2009 at 05:34:44PM +1000, Paul Bone wrote: > > > > * Package name: mercury > > > > Version : 0.13.1-rotd20090725 > > > > Upstream Author : Mercury Group > > > > * URL : http://www.mercury.csse.unimelb.edu.au/ > > > > * License : GPL2 > > > > Programming Lang: Mercury > > > > Description : The Mercury programming system, a pure > > > > logical/functional programming language. > > > > > > This used to be in Debian some time ago, because I remember trying to > > > work on the package for some reason. I believe that it is > > > self-hosting[0], which may be a problem, except that it supposedly comes > > > with a C version of the compiler as well. To make life easy for porters, > > > I'd request that you always build the C compiler and then, if you want > > > to, bootstrap the Mercury compiler from that. > > > > > > If I'm remembering incorrectly, or that's no longer the case, feel free > > > to disregard this. > > > > > > > This is mostly correct. Mercury is indeed self-hosting and was > > previously included in Debian. Mercury has a number of different > > backends two of these target C, high-level C and low-level C. The > > Mercury source distribution includes C intermediate files for the > > standard library and compiler generated by the low-level C backend, > > these can be compiled with GCC to generate binaries which can be used to > > bootstrap an installation by re-compiling the Mercury sources. > > > > I have a working Debian package that builds and bootstraps Mercury from > > the source distribution. It requires gcc-3.4 as a build-depend and is > > able to bootstrap itself so that the resulting binaries are optimal on > > 32bit and 64bit machines (the explanation involves a discussion of > > tagged pointers). > > Hi, > > gcc-3.4 is about to be removed from Debian (#536777). How do you plan to > deal with that? We use a comple of GCC extensions that cause problems with more recent versions of GCC, we can turn those off or use the high-level C backend. Either way, we can deal with it but we mightn't like to :-) since in some cases it will make things slower, and we don't as yet have a way to prevent this in profiling and debugging builds. signature.asc Description: Digital signature
Bug#556646: ITP: haskell-hscurses -- NCurses bindings for Haskell
Package: wnpp Severity: wishlist Owner: Paul Bone * Package name: haskell-hscurses Version : 1.3.0.2 Upstream Authors: John Meacham : Tuomo Valkonen : Don Stewart <http://www.cse.unsw.edu.au/~dons> : Stefan Wehr <http://www.informatik.uni-freiburg.de/~wehr/> * URL : http://hackage.haskell.org/package/hscurses-1.3.0.2 * License : LGPL Programming Lang: Haskell Description : NCurses bindings for Haskell Bindings to NCurses, a library of functions that manage an application's display on character-cell terminals. Additionally, it contains some basic widgets such as a text input widget and a table widget. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) signature.asc Description: Digital signature
Bug#507337: ITP: zoneclient -- Update DNS records kept by zoneedit.com as necessary
Package: wnpp Severity: wishlist Owner: Paul Bone <[EMAIL PROTECTED]> * Package name: zoneclient Version : 0.60 Upstream Author : Kal <[EMAIL PROTECTED]> * URL : http://zoneclient.sourceforge.net/ * License : GPL2 Programming Lang: Python Description : Update DNS records kept by zoneedit.com as necessary This package contains the zoneclient script which updates dynamic DNS records kept by zoneedit.com. Local information such as the IP of a network interface or the status of many DNS routers are used to determine if and how zoneedit's records should be updated. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#538802: ITP: mercury -- The Mercury programming system, a pure logical/functional programming language.
On Tue, Jul 28, 2009 at 05:48:07PM +1000, Paul Bone wrote: > On Tue, Jul 28, 2009 at 09:30:58AM +0200, Lucas Nussbaum wrote: > > > > gcc-3.4 is about to be removed from Debian (#536777). How do you plan to > > deal with that? > > We use a comple of GCC extensions that cause problems with more recent > versions > of GCC, we can turn those off or use the high-level C backend. Either way, we > can deal with it but we mightn't like to :-) since in some cases it will make > things slower, and we don't as yet have a way to prevent this in profiling and > debugging builds. > This has now been solved in newer upstream versions of Mercury. Thanks. signature.asc Description: Digital signature
