From hiben at tzi.de Thu Dec 7 21:47:58 2006 From: hiben at tzi.de (Hendrik Iben) Date: Thu, 07 Dec 2006 21:47:58 +0100 Subject: [Hets-devel] build error due to ARCH Message-ID: <45787DFE.4060809@tzi.de> Hi all, The Makefile uses 'uname -p' (processor type) to determine the architecture for installing libraries. This breaks the build for me because this results in 'AMD Athlon(tm) 64...' on my machine (the parenthesis causes an error). I think this could be fixed by using 'uname -m' (machine hardware), resulting in 'x86_64' here. While this works for me, would this break things for others ? Hendrik From rwagner at informatik.uni-bremen.de Thu Dec 7 23:42:48 2006 From: rwagner at informatik.uni-bremen.de (Rene Wagner) Date: Thu, 07 Dec 2006 23:42:48 +0100 Subject: [Hets-devel] build error due to ARCH In-Reply-To: <45787DFE.4060809@tzi.de> References: <45787DFE.4060809@tzi.de> Message-ID: <1165531368.6573.21.camel@localhost.localdomain> On Thu, 2006-12-07 at 21:47 +0100, Hendrik Iben wrote: > The Makefile uses 'uname -p' (processor type) to determine the > architecture for installing libraries. FWIW, 'uname -p' in GNU coreutils unconditionally returns "unknown" on a number of systems. In Debian it was removed altogether for a while [1]. Where it returns anything else, the semantics appear to vary greatly depending on the coreutils release and/or system vendor (possibly due to vendor patches) according to a quick web search. 'uname -m' is a wrapper around uname(2) (POSIX) in GNU coreutils, so this should be reasonably safe on Linux. I don't know about Solaris or OS X/Darwin. Regards, Rene [1] Debian Sarge (plus derivatives including some Ubuntu releases) ships a coreutils release without 'uname -p' support. From maeder at tzi.de Fri Dec 8 12:33:51 2006 From: maeder at tzi.de (Christian Maeder) Date: Fri, 08 Dec 2006 12:33:51 +0100 Subject: [Hets-devel] build error due to ARCH In-Reply-To: <1165531368.6573.21.camel@localhost.localdomain> References: <45787DFE.4060809@tzi.de> <1165531368.6573.21.camel@localhost.localdomain> Message-ID: <45794D9F.7000706@tzi.de> Rene Wagner schrieb: > On Thu, 2006-12-07 at 21:47 +0100, Hendrik Iben wrote: >> The Makefile uses 'uname -p' (processor type) to determine the >> architecture for installing libraries. > > FWIW, 'uname -p' in GNU coreutils unconditionally returns "unknown" > on a number of systems. In Debian it was removed altogether for a > while [1]. > > Where it returns anything else, the semantics appear to vary greatly > depending on the coreutils release and/or system vendor (possibly due > to vendor patches) according to a quick web search. > > 'uname -m' is a wrapper around uname(2) (POSIX) in GNU coreutils, so > this should be reasonably safe on Linux. I don't know about Solaris or > OS X/Darwin. Ok, changed now. I had a slight problem with the blank in: bigmac:~ maeder$ uname -m Power Macintosh Christian I've also tried 'uname -i' that does work under linux but not under both (power and intel) mac types. On our x86_64 machines 'uname -p' works fine: maeder at pollux:~> uname -mp x86_64 x86_64 intel-mac: m29:~ maeder$ uname -mp i386 i386 bigmac:~ maeder$ uname -mp Power Macintosh powerpc sparc-solaris: -bash-3.00$ uname -mp sun4u sparc pc-solaris: -bash-3.1$ uname -mp i86pc i386 maeder at denebola:~> uname -mp i686 i686 From till at informatik.uni-bremen.de Fri Dec 8 12:56:25 2006 From: till at informatik.uni-bremen.de (Till Mossakowski) Date: Fri, 08 Dec 2006 12:56:25 +0100 Subject: [Hets-devel] Book by Peter Andrews Message-ID: <457952E9.5040502@informatik.uni-bremen.de> Hi, has anyone of you my book about higher-order logic by Peter Andrews? Greetings, Till -- Till Mossakowski Office: Phone +49-421-218-64226 DFKI Lab Bremen Cartesium Fax +49-421-218-9864226 Robert-Hooke-Str. 5 Enrique-Schmidt-Str. 5 till at tzi.de D-28359 Bremen Room 2.051 http://www.tzi.de/~till From maeder at tzi.de Wed Dec 13 16:32:52 2006 From: maeder at tzi.de (Christian Maeder) Date: Wed, 13 Dec 2006 16:32:52 +0100 Subject: [Hets-devel] switch to ghc-6.6 / trac Message-ID: <45801D24.5090605@tzi.de> Hi all, recent changes to the building of hets require now to use the new ghc version 6.6. ghc-6.4.2 works mostly. It does not work if the released sources are compiled via "make depend" (in the ReleaseMakefile). (Removing hets.o from this (Release)Makefile makes ghc-6.4.2 work again, but this way is too slow and memory exhausting in general.) Earlier ghc versions (like ghc-6.4.1) are not capable of building the cabal packages that hets rely on: HTTP-2006.7.7, Shellac-0.5, Shellac-readline-0.2, hxt-7.0, syb-generics-2.9 These packages are installed in your home directory under ./ghc when you call "make" (or "make packages") the first time after checking out HetCATS from cvs. Look up your packages using: ghc-pkg list ghc-pkg describe HTTP Note: I will switch our default compiler (i.e. under /home/linux-bkb/bin) to ghc-6.6. I will also merge the ghc-6-06 branch of uni to the HEAD if nobody objects in time. uni for ghc-6.6 relies on HaXml-1.13.2 that must be installed as cabal package before. Within HaXml-1.13.2 call: runhaskell Setup.hs configure [--prefix=...] runhaskell Setup.hs build runhaskell Setup.hs install [--user] (parts in square brackets are optional, the dots following "prefix=" stay for a user-defined installation path.) For more options use: runhaskell Setup.hs help Cheers Christian P.S. Our new bug and feature tracking system is reachable under http://trac.informatik.uni-bremen.de:8080/hets Click on "View Tickets" followed by "Active Tickets" or "New Tickets". Users listed under "Assign to" (after "New Tickets") may login using their userid as password. To change your password send me your encrypted password that is generated by: /usr/sbin/htdigest2 -c htdigest hets-trac cat htdigest This trac installation does not use email-notifications yet, so you have to look for changes yourself, currently. Eventually, the parts of our top-level todo file will be converted to trac tickets. From maeder at tzi.de Fri Dec 15 12:39:31 2006 From: maeder at tzi.de (Christian Maeder) Date: Fri, 15 Dec 2006 12:39:31 +0100 Subject: [Hets-devel] label, identifier translation Message-ID: <45828973.5050905@tzi.de> Hi, before trying to resolve the tickets http://trac.informatik.uni-bremen.de:8080/hets/ticket/10 http://trac.informatik.uni-bremen.de:8080/hets/ticket/12 I need a concept! (or a good theory) The problem: For most co-morphisms the identifiers need to be translated at first. In order to do so we have to: a) avoid keywords of the target logic b) match the legal lexical syntax of the target logic c) often code out overloading (because the target logic does not allow it) We want to have a total translation, because rejecting a translation merely because of an unlucky and uncontrollable choice of names in the source logic is unsatisfactory. The current State: Right now it is almost unpredictable _how_ identifiers will be translated and many of them are unreadable. Examples: __+__ (overloaded) in CASL gets X__XPlus__XX1 for Isabelle o__Plus__ for SPASS a___2_P_2_02 for Haskell (Constructors in Haskell get a capital starting A) I distinguish identifiers for sorts/types and operations/predicates and labels. I do not currently distinguish alphanumeric and symbolic identifiers, therefore symbols are converted to letters. for Haskell: + -> _P _ -> _1 for Isabelle: + -> XPlus X -> XX The translations for Haskell and Isabelle are (supposed to be) injective , "_" resp. "X" serve as _escape_ symbols (Isabelle does not allow a leading or trailing "_"). SPASS keeps a mapping of identifiers, so the same identifier may be translated differently in different contexts as may happen with overloaded identifiers, non-unique labels or (I'm afraid) with identifiers that are keywords of the target logic. In these cases digits are appended until a the name is unique in the current context. The trac-tickets now expect me to deal _readably_ with spaces in labels and multi-line labels! Possible Solutions: a) Deal with overloading and non-unique labels within a separate CASL co-morphism. This applies to HasCASL and extensions as well and is no solution but only a different (better?) structuring. Considering the profile of overloaded entities could make the translation globally unique but the names would get too long. Adding a number is short, but obscures the profile and the number may differ in a context with a different degree of overloading. b) Restrict the CASL label syntax. Some labels are supposed to be printed flush_right already. At least the number of consecutive spaces and line-breaks should not matter. This would mean to extend the annotation parser. c) Add another hack and replace spaces and newlines by underscores and somehow avoid conflicts with explizit underscores. What should we do? Christian From rwagner at informatik.uni-bremen.de Sat Dec 23 22:20:27 2006 From: rwagner at informatik.uni-bremen.de (Rene Wagner) Date: Sat, 23 Dec 2006 22:20:27 +0100 Subject: [Hets-devel] build error due to ARCH In-Reply-To: <45794D9F.7000706@tzi.de> References: <45787DFE.4060809@tzi.de> <1165531368.6573.21.camel@localhost.localdomain> <45794D9F.7000706@tzi.de> Message-ID: <1166908827.21425.58.camel@localhost.localdomain> Hi Christian, On Fri, 2006-12-08 at 12:33 +0100, Christian Maeder wrote: > Ok, changed now. > > I had a slight problem with the blank in: > bigmac:~ maeder$ uname -m > Power Macintosh Ah, the joys GNU vs. *BSD... Anyways, it's working fine now. The same goes for building with GHC 6.6 BTW. If anyone's interested I can provide some hints on how to get the latter done on (the soon to be released) Debian Etch. Thanks, Rene