From A.M.Gimblett at swansea.ac.uk  Wed Jan  2 20:30:34 2008
From: A.M.Gimblett at swansea.ac.uk (Andy Gimblett)
Date: Wed, 2 Jan 2008 19:30:34 +0000
Subject: [Hets-devel] Pretty printing symbols: extend latexSymbols,
	or is there another way?
Message-ID: <20080102193034.GB4554@cspcag2.swan.ac.uk>

Happy new year, Hets developers!

I have a (hopefully quick) question about pretty printing.

I want the LaTeX pretty print output for CspCASL specifications to use
macros from csp.sty for some (initially two, maybe more later)
symbols.  Should I/am I allowed to extend latexSymbols (in
Common/Doc.hs)?  Doing so will require that I import two (initially)
items from CspCASL/CspCASL_Keywords.hs to that module.  Or is there a
generic way to achieve this from my pretty printing code without
modifying Common/Doc.hs ?  I don't see it, but that doesn't mean it's
not there. :-)

If you want more context, let me know and I'll give you the long
version...

Best regards,

-Andy

-- 
Andy Gimblett
Computer Science Department
Swansea University
http://www.cs.swan.ac.uk/~csandy/

From Christian.Maeder at dfki.de  Wed Jan  2 20:48:19 2008
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Wed, 02 Jan 2008 20:48:19 +0100
Subject: [Hets-devel] Pretty printing symbols: extend latexSymbols,
 or is there another way?
In-Reply-To: <20080102193034.GB4554@cspcag2.swan.ac.uk>
References: <20080102193034.GB4554@cspcag2.swan.ac.uk>
Message-ID: <477BEA83.2010008@dfki.de>

Andy Gimblett wrote:
> Happy new year, Hets developers!
> 
> I have a (hopefully quick) question about pretty printing.
> 
> I want the LaTeX pretty print output for CspCASL specifications to use
> macros from csp.sty for some (initially two, maybe more later)
> symbols.  Should I/am I allowed to extend latexSymbols (in
> Common/Doc.hs)?  Doing so will require that I import two (initially)
> items from CspCASL/CspCASL_Keywords.hs to that module.  Or is there a
> generic way to achieve this from my pretty printing code without
> modifying Common/Doc.hs ?  I don't see it, but that doesn't mean it's
> not there. :-)

Please modify Common/Keywords.hs and extend latexSymbols Common/Doc.hs
for additional CspCASL latex-Symbols. There are already CoCASL (like
diamondS) and HasCASL symbols (like contFun). Use "symbol" to construct
a (latex-aware) Doc from strings like diamondS and contFun.

Maybe also hetcasl.sty should be extended rather than using a separate
csp.sty file.

I hope there are no symbol collisions.

Other ideas are welcome
Christian

From Christian.Maeder at dfki.de  Wed Jan 23 10:24:35 2008
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Wed, 23 Jan 2008 10:24:35 +0100
Subject: [Hets-devel] [Fwd: hets installation problems]
In-Reply-To: <4796672E.3050206@dfki.de>
References: <4796672E.3050206@dfki.de>
Message-ID: <479707D3.5030200@dfki.de>

Hi,

we need to make new installer packages considering the new Isabelle2007
(and possibly a new hets release).

> The installer from
> http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/installation_e.htm
> uses broken link to http://isabelle.in.tum.de/dist/Isabelle2005.tar.gz
> and thus the installation will fail (unless you already have Isabelle
> installed). Installation on 64bit SUSE needs gmp-32bit . PolyML is not
> easily relocatable because it uses shared libraries. This last point
> needs a bit of explanation. Shared libraries are searched for in
> standard locations. Now while it is possible to use environment
> variables (like LD_LIBRARY_PATH) to override the default places that
> should be looked in this SHOULD GENERALLY NOT BE DONE because it
> _replaces_ the default library search path - it does not augment it

>>> PolyML is not easily relocatable because it uses shared libraries.
> 
> I forgot to mention that http://www.eyrie.org/~eagle/notes/rpath.html has a 
> good explanation of the shared library problem.

Also our hets binary needs gmp-32bit. We could link it statically but
that would not help with PolyML (although it could be linked statically
for PolyML, too, but that's not our job).

Setting LD_LIBRARY_PATH is not as bad as described above as long as that
path does contain libraries that should be taken from the default
library search path. It does not _replace_ the default library search
path, LD_LIBRARY_PATH is only searched before it.

Another alternative is to write a shell wrapper around binaries that set
LD_LIBRARY_PATH locally for the binary only.

Yet better, if the system admin installed a 32bit-gmp under /usr/lib (or
another path in the default library search path).

Cheers Christian


From A.M.Gimblett at swansea.ac.uk  Wed Jan 30 22:00:35 2008
From: A.M.Gimblett at swansea.ac.uk (Andy Gimblett)
Date: Wed, 30 Jan 2008 21:00:35 +0000
Subject: [Hets-devel] Pretty printing symbols: extend latexSymbols,
	or is there another way?
In-Reply-To: <477BEA83.2010008@dfki.de>
Message-ID: <20080130210035.GA4297@cspcag2.swan.ac.uk>

Hi all,

Just an update on this...

> > I want the LaTeX pretty print output for CspCASL specifications to use
> > macros from csp.sty for some (initially two, maybe more later)
> > symbols.  Should I/am I allowed to extend latexSymbols (in
> > Common/Doc.hs)?  Doing so will require that I import two (initially)
> > items from CspCASL/CspCASL_Keywords.hs to that module.  Or is there a
> > generic way to achieve this from my pretty printing code without
> > modifying Common/Doc.hs ?  I don't see it, but that doesn't mean it's
> > not there. :-)
> 
> Please modify Common/Keywords.hs and extend latexSymbols
> Common/Doc.hs for additional CspCASL latex-Symbols. There are
> already CoCASL (like diamondS) and HasCASL symbols (like
> contFun). Use "symbol" to construct a (latex-aware) Doc from strings
> like diamondS and contFun.

I've done this today for a number of CspCASL process operators, and it
works out reasonably well (changes are committed to svn).

There are a couple of issues, but nothing which needs fixing
immediately - I just wanted to report them.

First, I have two symbols with identical ASCII representations but
differing LaTeX, which the current system doesn't seem to be able to
handle, because at its heart is a map from ASCII to LaTeX.  The
problem basically arises because we're trying to emulate CSP as much
as possible (both in machine-readable ASCII and pretty printed LaTeX).
With some flexibility of syntax it's no problem for me, but it might
be worth thinking about if this could be solved in general...

Details:

  - The "synchronous parallel" operator is || in both ASCII and LaTeX
    (csp.sty has a macro \parallel, which is essentially \mid\mid).

    eg we might write A || B, with processes A and B.

  - The "alphabetised parallel operator" has three parts: an open, a
    close, and a separator.  In ASCII, it's written as:

        A [ x,y || z,w ] B

    where A and B are processes, and x,y,z,w are "event sets".

    Unfortunately, the conventional LaTeX representation of the middle
    part is just a _single_ bar - csp.sty defines \lpar, \cpar, \and
    \rpar, with \cpar being essentially \mid.  So the LaTeX looks more
    like:

        A [ x,y | z, w ] B

    I'm not sure why this is the case in the CSP world, but there it
    is.

For now, I'm just accepting having || in both ASCII and LaTeX; that's
fine, but I thought I'd raise this as a potentially interesting issue.
:-)

> Maybe also hetcasl.sty should be extended rather than using a separate
> csp.sty file.  I hope there are no symbol collisions.

At present I'm leaving hetcasl.sty unchanged and using both.  Longer
term, I think extending hetcasl.sty is the right path.  I had thought
hetcasl.sty and csp.sty co-existed OK (I use both in my thesis), but I
realised today that there at least is a name clash on \then - csp.sty
uses it for prefix arrows in, eg, "a -> P" (\then renders as
\rightarrow).  I noticed this today because I tried to write "then" in
a structured specification in my thesis for the first time.  :-) I've
fixed it for my thesis by tweaking a local copy of hetcasl.sty, but
that's no long term solution, obviously.  Sadly, some careful work is
required I think.

Cheers,

-Andy

-- 
Andy Gimblett
Computer Science Department
Swansea University
http://www.cs.swan.ac.uk/~csandy/

From Christian.Maeder at dfki.de  Thu Jan 31 10:18:59 2008
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Thu, 31 Jan 2008 10:18:59 +0100
Subject: [Hets-devel] Pretty printing symbols: extend latexSymbols,
 or is there another way?
In-Reply-To: <20080130210035.GA4297@cspcag2.swan.ac.uk>
References: <20080130210035.GA4297@cspcag2.swan.ac.uk>
Message-ID: <47A19283.3000209@dfki.de>

Andy Gimblett wrote:
> First, I have two symbols with identical ASCII representations but
> differing LaTeX, which the current system doesn't seem to be able to
> handle, because at its heart is a map from ASCII to LaTeX.  The

Maybe that can be handled like our dot, which may be a decimal point (or
part of an identifier like __..__) or the centered dot (lambda dot)
before formulas. The text-dot does not go via the latex symbol map.

dot = text dotS
bullet = symbol dotS

Cheers Christian