From: Tim Bradshaw
Subject: Re: Xerox grapher in common lisp?
Date:
Message-ID: <nkjsnp9mc5g.fsf@tfeb.org>
"Jon A. Pastor" <···@navpoint.com> writes:
> Has anyone ever come across a port of the Xerox Interlisp-D grapher to
> Common Lisp? If so, can you refer me to the sources?
>
I looked for this a long time ago, and I don't think it exists
unfortunately. Apart from anything else it was probably entangled
with the window system.
I think there is at least one CL/X11 grapher out there of (probably)
independent ancestry, and there s also the CLIM grapher which is
reasonably flexible too (and at least theoretically extensible).
CLIM's not (yet?) free of course but it's probably a whole lot cheaper
than writing your own...
--tim
Tim Bradshaw wrote in message ...
>"Jon A. Pastor" <···@navpoint.com> writes:
>
>> Has anyone ever come across a port of the Xerox Interlisp-D grapher to
>> Common Lisp? If so, can you refer me to the sources?
>>
>
>I looked for this a long time ago, and I don't think it exists
>unfortunately. Apart from anything else it was probably entangled
>with the window system.
>
>I think there is at least one CL/X11 grapher out there of (probably)
>independent ancestry, and there s also the CLIM grapher which is
>reasonably flexible too (and at least theoretically extensible).
>CLIM's not (yet?) free of course but it's probably a whole lot cheaper
>than writing your own...
Dylan's UI toolkit -- DUIM -- also includes a grapher. DUIM is
open-source (well, once you've bought the license), so you are free
to copy that code. Turning Dylan code back into Lisp code is
dead easy, simpler than the other way `round.
You can get DUIM as part of Functional Developer, from
www.functionalobjects.com
"Scott McKay" <···@mediaone.net> writes:
> Dylan's UI toolkit -- DUIM -- also includes a grapher. DUIM is
> open-source (well, once you've bought the license), so you are free
> to copy that code. Turning Dylan code back into Lisp code is
> dead easy, simpler than the other way `round.
If it's licensed, it's usually for a purpose, often that doesn't include
translation. Are you saying that the "open source" nature of this requires
purchase but then doesn't restrict usage after that? Sounds odd to me.
I don't think I'd do this without consulting an IP law attorney, even if
it was suggested by someone who worked on it.
And anyway, this presumably only works on the same platform as Dylan
runs on, either for technical or legal reasons. If the license is
really weak enough to let someone translate it and redistribute it on
other platforms, it's not going to leverage very many sales...
> You can get DUIM as part of Functional Developer, from
> www.functionalobjects.com
Does Dylan cross-call Lisp or vice versa? If not, they should. Be a
darned pity to have these two markets isolated from one another. If it
did, one could just cross=call from one language to the other.
Kent M Pitman wrote in message ...
>"Scott McKay" <···@mediaone.net> writes:
>
>> Dylan's UI toolkit -- DUIM -- also includes a grapher. DUIM is
>> open-source (well, once you've bought the license), so you are free
>> to copy that code. Turning Dylan code back into Lisp code is
>> dead easy, simpler than the other way `round.
>
>If it's licensed, it's usually for a purpose, often that doesn't include
>translation. Are you saying that the "open source" nature of this requires
>purchase but then doesn't restrict usage after that? Sounds odd to me.
>I don't think I'd do this without consulting an IP law attorney, even if
>it was suggested by someone who worked on it.
I hardly think anybody from Functional Objects will sue you.
I see nothing odd about charging for a distribution of open
source software. Linux distributors do this.
>And anyway, this presumably only works on the same platform as Dylan
>runs on, either for technical or legal reasons. If the license is
>really weak enough to let someone translate it and redistribute it on
>other platforms, it's not going to leverage very many sales...
>
>> You can get DUIM as part of Functional Developer, from
>> www.functionalobjects.com
>
>Does Dylan cross-call Lisp or vice versa? If not, they should. Be a
>darned pity to have these two markets isolated from one another. If it
>did, one could just cross=call from one language to the other.
Fun-O Dylan just produces Windoze DLL's. Just wrap up
Dylan functions with a c-callable wrapper, then use Lisp FFI.
I can't speak for Gwydion, but it's probably similar.
"Scott McKay" <···@mediaone.net> writes:
> I hardly think anybody from Functional Objects will sue you.
I can envision circumstances in which a lawyer might advise the
principals of Functional Objects that if they fail to sue someone they
have a right to sue, it could leave them open to suit themselves from
their stockholders. This may sound dumb as hell, but I think you and
I have seen similar things played out with very real consequences.
Relying on people to act according to their natural goodwill doesn't
always work.
Anyway, my point was only to identify this as a potential issue to
anyone reading; anyone making a decision to copy or translate or
redeploy code should consult at minimum the license they are working
under and perhaps also a lawyer, so they're sure of their rights.
> I see nothing odd about charging for a distribution of open
> source software. Linux distributors do this.
If they do, then the thing that enables its use is not having "bought a
license" but rather "merely having obtained the bits".
> Fun-O Dylan just produces Windoze DLL's. Just wrap up
> Dylan functions with a c-callable wrapper, then use Lisp FFI.
That sounds pretty good.
On 03 Nov 2000 13:13:31 +0000, Tim Bradshaw <···@tfeb.org> wrote:
> I think there is at least one CL/X11 grapher out there of (probably)
> independent ancestry, and there s also the CLIM grapher which is
> reasonably flexible too (and at least theoretically extensible).
A collection of graphers for Lisp-based GUIs (CLIM, CLX, CLIO/CLUE and
more) is available at the CMU Common Lisp Repository.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
On Fri, 03 Nov 2000 12:01:06 GMT, "Jon A. Pastor" <···@navpoint.com> wrote:
>Has anyone ever come across a port of the Xerox Interlisp-D grapher to
>Common Lisp? If so, can you refer me to the sources?
What is this grapher thing? O:-)
TIA
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
In article <························@news1.rdc2.pa.home.com>, "Jon A.
Pastor" <···@navpoint.com> wrote:
> Has anyone ever come across a port of the Xerox Interlisp-D grapher to
> Common Lisp? If so, can you refer me to the sources?
Do you need exactly this grapher? Does it provide special
features? Would another grapher be sufficient? For
which platform?
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
"Need" is a strong word. I would *like* the Xerox grapher, because it was
designed in what I considered an intelligent way, and was remarkably easy to
use.
You could graph any SEXPR right out of the box, so if the data structure you
wanted to depict was (or could easily be converted to) a SEXPR, the amount
of work you had to do to get it displayed as a graph was 0. This tended to
work well for homogeneous data structures.
If you needed more sophistication -- in particular, you wanted to depict
heterogeneous data structures -- all you had to do was specify, for each
kind of object, how to depict it and how to generate its successors; this
was done in a well-documented data structure that described the state
transitions. Every other grapher I've looked at makes it much harder to do
this.
The ACL grapher I'm using at the moment takes a more object-oriented
approach, but while it's conceptually cleaner, it's a lot more work to use.
The ACL grapher is also undocumented, unsupported, and the graphs it draws
are not particularly pretty or easy to modify; it also uses an incredibly
complex underlying model, which (since it's undocumented) makes it really
messy to work with -- particularly compared to the Xerox grapher, with which
you could put up a graph of a simple data structure in minutes and a more
complex one in hours.
The Xerox grapher was also set up to be easy to parameterize, and gave lots
of display options.
I am aware of the graphers at the CMU repository. Aside from being a bit
simpler than the Xerox grapher, none of them appears to have a good layout
algorithm (if any at all). I am also aware of the existence of a grapher for
CLIM, but unless CLIM has changed a lot since the last time I tried to use
it, I didn't care for it much.
So -- I am willing and able to work with any grapher for which I can get
source code, which includes a decent layout algorithm, provides decent
control over layout and appearance of nodes, and has facilities for
displaying heterogeneous data structures easily -- but I have a very strong
preference for the Xerox grapher because I know that it meets all of my
requirements.
Rainer Joswig <······@corporate-world.lisp.de> wrote in message
·································@news.is-europe.net...
In article <························@news1.rdc2.pa.home.com>, "Jon A.
Pastor" <···@navpoint.com> wrote:
> Has anyone ever come across a port of the Xerox Interlisp-D grapher to
> Common Lisp? If so, can you refer me to the sources?
Do you need exactly this grapher? Does it provide special
features? Would another grapher be sufficient? For
which platform?
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
In article <························@news1.rdc2.pa.home.com>, "Jon A.
Pastor" <···@navpoint.com> wrote:
> If you needed more sophistication -- in particular, you wanted to depict
> heterogeneous data structures -- all you had to do was specify, for each
> kind of object, how to depict it and how to generate its successors; this
> was done in a well-documented data structure that described the state
> transitions. Every other grapher I've looked at makes it much harder to do
> this.
Here is the CLIM version of displaying cons trees:
(defun graph-cons (sexp)
(clim:format-graph-from-roots (list sexp)
(lambda (item stream)
(when (atom item)
(princ item stream)))
(lambda (item)
(when (consp item)
(list (car item)
(cdr item))))
:orientation :vertical))
From the docs:
format-graph-from-roots [Function]
Arguments:
root-objects object-printer inferior-producer
&key stream orientation cutoff-depth merge-duplicates
duplicate-key duplicate-test generation-separation
within-generation-separation center-nodes arc-drawer
arc-drawing-options graph-type (move-cursor t)
Summary:
Draws a graph whose roots are specified by the sequence
root-objects. The nodes of the graph are displayed by calling the
function object-printer, which takes two arguments, the node to
display and a stream. inferior-producer is a function of one
argument that is called on each node to produce a sequence of
inferiors (or nil if there are none). Both object-printer and
inferior-producer have dynamic extent.
...
Most of the time this is powerful enough for me.
> So -- I am willing and able to work with any grapher for which I can get
> source code, which includes a decent layout algorithm, provides decent
> control over layout and appearance of nodes, and has facilities for
> displaying heterogeneous data structures easily -- but I have a very strong
> preference for the Xerox grapher because I know that it meets all of my
> requirements.
Please post a summary if you get some feedback.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
On Sat, 04 Nov 2000 19:23:33 GMT, "Jon A. Pastor" <···@navpoint.com> wrote:
> "Need" is a strong word. I would *like* the Xerox grapher, because it was
You might check with the Venue folks:
http://Top2bottom.net/venue.html
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/