Sure you have by now heard the bad news.
If anyone has an interest in buying the Lisp part of their business,
he/she should contact the receivers as *soon* as possible to
express an interest, etc.
It would be a tragedy for the whole Lisp community, if we'd
lose LispWorks and LCL. A single vendor for Unix/Windows remaining
is not enough, I'd guess.
Rainer Joswig
In article <·······················@194.163.195.67>,
······@lavielle.com (Rainer Joswig) wrote:
> Sure you have by now heard the bad news.
>
> If anyone has an interest in buying the Lisp part of their business,
> he/she should contact the receivers as *soon* as possible to
> express an interest, etc.
Big picture: Does anyone have any idea what the going rate to purchase
a suite of programming languages might be?
In other words, if someone wanted to put together a bid to purchase
their CL, Dylan, and ML products, does anyone know of a way to come up
with a reasonable valuation on which to make an offer?
Personally, I would think it would be on a discounted basis of the cash
from their current support contracts. I say this because it seems
unlikely the products will generate strong growth from new customer
sales (let's face it--Lisp, ML and Dylan are pretty unpopular anyway. .
.a commercial version from a dying company. . .the old idiom of a f***
in church comes to mind).
Here's the scenario:
it appears that Harlequin is primarily known for it's RIP (some sort of
publishing tech) and law enforcement technology. It appears the
programming language products are a bit of an afterthought (they've an
extremely bizarre product mix!!!). Thus, I'd presume a potential
corporate buyer is most likely to come from the law enforcement
(unlikely. . .no $$$) or the publishing (most likely IMO. . .many $$$)
areas. As a result, it is unlikely they would be very interested in the
programming languages technologies from a business standpoint.
If the purchasing company is not interested in the language tools, they
might be persuaded to sell the tools at a _very_ reasonable price
(probably want to get rid of the support Ks as well. . .but that's a
different discussion). Anyhow, the question would be whether or not it
would be beneficial to try to raise money (via donations) to purchase
the products and then re-release them with a developer friendly (think
BSDish or artistic) license.
Personally, I think the most likely purchaser for the language products
comes from engineers within the company. I can picture of group of
engineers starting a small solutions company using the $$$ from the
support contracts as seed money as well as free (beer) software
infrastructure. It's also possible that another language company
(Franz) adds ML and Dylan offerings to their product mix.
My $.02. Sorry this is so long.
--Brad
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
········@my-deja.com wrote:
....
> Big picture: Does anyone have any idea what the going rate to purchase
> a suite of programming languages might be?
>
> In other words, if someone wanted to put together a bid to purchase
> their CL, Dylan, and ML products, does anyone know of a way to come up
> with a reasonable valuation on which to make an offer?
>
> Personally, I would think it would be on a discounted basis of the cash
> from their current support contracts.
As a software developer I may be biased, but as a commerical venture the dominating cost
here is really is can you afford pay the some signficant fragment of the Harlequin
Development team. If all you going to do is milk the products as a cash cow the Franz
marketing/sales folks are going to swooping out of the sky like an A-10 during Desert
Storm. You're gambling you can make it across the pontoon bridge before the plane blows it up.
The productive i-prop of most software companys is wrapped up in the developers head much
more than most company probably care to admit. It will take a long time to get a new
set of developers far enough up the learning curve to keep your support customers happy.
> it appears that Harlequin is primarily known for it's RIP (some sort of
> publishing tech) and law enforcement technology. It appears the
> programming language products are a bit of an afterthought (they've an
> extremely bizarre product mix!!!).
Not too bizarre. A RIP (raster image processor? )is built around a
postscript engine/interpreter. The result of the "compiler" is a result on a piece
of paper instead of bits into a file. I'd wager the law enforcement technology is layered
on top of their own tools. At least one would hope that they "ate their own
dog food". :-)
> If the purchasing company is not interested in the language tools, they
> might be persuaded to sell the tools at a _very_ reasonable price
However, it is always amazing how much people cling to "sunk costs". There is a
limit to that "very".
At a certain low "cents on the dollar" there is a tendency to collect pennies in
a jar on the dresser rather than do anything productive with them. Especially,
when there are other pieces that have a greater valuation.
> Personally, I think the most likely purchaser for the language products
> comes from engineers within the company. I can picture of group of
> engineers starting a small solutions company using the $$$ from the
The pain in the butt problem for them will be raising the start up capital.
The language products business doesn't have high margins/high profitability in
comparison to most other software categories, let alone have a "dot.com" like
potential.
That's why sometimes it is better to give a company some breathing room and let them
exit bankruptcy themselves instead of doing a "chop shop" job. The best entity to
take commerical advantage of the code is a, perhaps "reformed", Harlequin.
P.S. taking a collection to put the code into the "bazaar" is a bit misguided.
One part oftened overlooked in the bazaar model is that the an "owner/leader"
of the code. Without some focal point just casting the code out onto the
net isn't likely to lead to something very productive. The mulitple eyeball
thing only works after there is something "working".
However, I think there are some free/open source folks looking into this.
---
Lyman
In article <·················@mindspring.com>,
"Lyman S. Taylor" <············@mindspring.com> wrote:
> ········@my-deja.com wrote:
> As a software developer I may be biased, but as a commerical venture
> the dominating cost here is really is can you afford pay the some
> signficant fragment of the Harlequin Development team. If all you
> going to do is milk the products as a cash cow the Franz
> marketing/sales folks are going to swooping out of the sky like an
> A-10 during Desert Storm. You're gambling you can make it across
> the pontoon bridge before the plane blows it up.
Agreed about the development team part. WRT the A-10, that bridge has
probably already been targeted (I'd bet Franz has already contacted
every company they know of on Harlequin's customer list. . ."we're
sorry to hear about your chosen vendor. . .if any problems pop up, give
us a call."
> Not too bizarre. A RIP (raster image processor? )is built around a
> postscript engine/interpreter. The result of the "compiler" is a
> result on a piece of paper instead of bits into a file. I'd wager
> the law enforcement technology is layered on top of their own tools.
> At least one would hope that they "ate their own
> dog food". :-)
I agree that they probably "eat their own dog food." On the other hand,
it appears that they make too d*** many kinds of dogfood. I, the
investor, generally want to see a company with a reasonably coherent
business plan. It appears they have enough different product lines for
three different business plans.
> However, it is always amazing how much people cling to "sunk costs".
> There is a limit to that "very".
Worrying about "sunk costs" is irrational. This mainly (in my
experience) occurs with managers justifying past decisions. An outsider
is less likely to feel this pressure. However, it still comes in the
guise of overly rosy powerpoint presentations.
> The pain in the butt problem for them will be raising the start up
> capital. The language products business doesn't have high
> margins/high profitability in comparison to most other software
> categories, let alone have a "dot.com" like potential.
In general, I don't see programming languages as a highly profitable
product offering (Microsoft excepted).
> That's why sometimes it is better to give a company some breathing
> room and let them exit bankruptcy themselves instead of doing a
> "chop shop" job. The best entity to take commerical advantage of
> the code is a, perhaps "reformed", Harlequin.
I won't say Harlequin isn't a going concern. I would say that I would
be surprised if their not "chopped" down to a smaller (1 or 2 segment)
focus.
>
> P.S. taking a collection to put the code into the "bazaar" is a bit
> misguided. One part oftened overlooked in the bazaar model is that
> the an "owner/leader" of the code. Without some focal point just
> casting the code out onto the net isn't likely to lead to something
> very productive. The mulitple eyeball thing only works after there
> is something "working".
1) I presume their stuff basically works.
2) The "owner/leader" problem is a big (huge???) one. Frankly, I don't
know how that would be solved.
Earlier, someone in this thread had voiced the hope that Harlequin would
open up their programming tools. As a creditor, I wouldn't be very keen
to see this happen. On the other hand, I might be willing to sell
(donate) the code to a tax-exempt organization for some amount and
deduct the remaining market value donated (or some hocus pocus like
that. . .IANAL).
I would change the followups, but I don't know a more relevant place for
this particular discussion.
> Lyman
--Brad
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
In article <··········@world.std.com>, ··@world.std.com (Jeff DelPapa)
wrote:
> It was an interesting (for several values of interesting) place to
> work. It did some things very right, and others it got frustratingly
> wrong.
Could you expand on which ones?
Thanks,
-- O.L.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
On Wed, 07 Jul 1999 04:18:55 GMT, ········@my-deja.com wrote:
>In article <··········@world.std.com>, ··@world.std.com (Jeff DelPapa)
>wrote:
>
>> It was an interesting (for several values of interesting) place to
>> work. It did some things very right, and others it got frustratingly
>> wrong.
>
>Could you expand on which ones?
>
It was a lovely place to work with people who were generally
bright and friendly. There was and still is a belief that it is worth
doing things correctly. From a personnel perspective one of the things
it did wrong was the concept of being "The late binding company (tm)"
which appeared as a worker to mean that we were only told which way we
were heading when we needed to jump, this stresses your workforce. The
concept of having your development teams geographically diverse
probably cost a lot of money but had interesting and I think useful
repercussions. I count many people at harlequin past and present among
my friends and wish the company luck. I was sad to leave it but I am
happy in my new employment. If anyone organizes a collection to buy
the source to Dylan I will make a donation. Ask for a copy of HOPE
(Harlequin ongoing project Environment ( A distributed source control
system written in Perl, which was lovely :-) )) or at least the
changes translated to RCS.
In article <·················@mindspring.com>, "Lyman S. Taylor"
<············@mindspring.com> wrote:
> marketing/sales folks are going to swooping out of the sky like an A-10
during Desert
> Storm. You're gambling you can make it across the pontoon bridge before
the plane blows it up.
Pontoon bridges in the desert??
James McCartney asynth <at> io <dot> com
"Lyman S. Taylor" <············@mindspring.com> writes:
> P.S. taking a collection to put the code into the "bazaar" is a bit misguided.
> One part oftened overlooked in the bazaar model is that the an "owner/leader"
> of the code. Without some focal point just casting the code out onto the
> net isn't likely to lead to something very productive. The mulitple eyeball
> thing only works after there is something "working".
Well, since HD _is_ working, that's not a problem to worry about. The
"owner" problem is also solvable, by means of "he who writes code has
a voice".
The problem I see is that there aren't enough developers out there to
support two Dylan compilers. Heck, we have problems with Gwydion Dylan
alone, we have been working on it for a year now and I'm only
beginning to get the full picture of how the compiler works.
The most interesting bits of HD in terms of possible re-use are the
libraries, and they _are_ open source already (and praise your $DEITY
that they managed to release the beta version before that
bankruptcy). The only other major part that I would want to re-use is
the CORBA stuff.
Being able to look at the HD compiler guts would certainly be very
interesting (I would want to know how their GC works, how they do the
remote debugging, generic dispatch optimization, optimization,
etc...), but I only see a slim chance for a open-source HD to attract
enough developers to sustain maintenance.
Andreas
--
"We show that all proposed quantum bit commitment schemes are insecure because
the sender, Alice, can almost always cheat successfully by using an
Einstein-Podolsky-Rosen type of attack and delaying her measurement until she
opens her commitment." ( http://xxx.lanl.gov/abs/quant-ph/9603004 )
* Lyman S Taylor wrote:
> P.S. taking a collection to put the code into the "bazaar" is a
> bit misguided.
> One part oftened overlooked in the bazaar model is that the
> an "owner/leader" of the code. Without some focal point just
> casting the code out onto the net isn't likely to lead to
> something very productive. The mulitple eyeball thing only
> works after there is something "working".
Right. There is already one good-quality native-code open source Lisp
available (CMUCL) which has seen some but not a huge amount of
development. I don't see that simply dumping others out there as
public code will lead to some frenzy of activity & development. You
need an owner/leader and those people need to be able to get paid
somehow.
--tim
In article <···············@lostwithiel.tfeb.org>,
Tim Bradshaw <···@tfeb.org> wrote:
> * Lyman S Taylor wrote:
>
> > P.S. taking a collection to put the code into the "bazaar" is a
> > bit misguided.
> > One part oftened overlooked in the bazaar model is that the
> > an "owner/leader" of the code. Without some focal point just
> > casting the code out onto the net isn't likely to lead to
> > something very productive. The mulitple eyeball thing only
> > works after there is something "working".
>
> Right. There is already one good-quality native-code open source Lisp
> available (CMUCL) which has seen some but not a huge amount of
> development. I don't see that simply dumping others out there as
> public code will lead to some frenzy of activity & development. You
> need an owner/leader and those people need to be able to get paid
> somehow.
The trouble with CMUCL is that it is just so complex. I've never even
managed to get the system to build with or without instructions.
I'm amazed at the progress made by the CMUCL team.
However, if there was a lisp out there that was easier to get into I'm
sure people would fix problems and develop new code, even if it wasn't
a frenzied effort.
> --tim
>
barry
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
On Wed, 07 Jul 1999 10:40:06 GMT, ·········@computasoft.com wrote:
>
>The trouble with CMUCL is that it is just so complex. I've never even
>managed to get the system to build with or without instructions.
Get the debian packages and the .tar.gz file. Get CMUCL to work from the
debs. Unpack the tar.gz. Type "make". Look at the new bits.
There is also a "make new-gen" to make a new generation of the lisp in
/bin/ (this is what I use).
>However, if there was a lisp out there that was easier to get into I'm
>sure people would fix problems and develop new code, even if it wasn't
>a frenzied effort.
Look at src/code/bignum.lisp, notice the simple multiplication routine:
(defun multiply-bignums (a b)
(declare (type bignum-type a b))
(let* ((a-plusp (%bignum-0-or-plusp a (%bignum-length a)))
(b-plusp (%bignum-0-or-plusp b (%bignum-length b)))
(a (if a-plusp a (negate-bignum a)))
(b (if b-plusp b (negate-bignum b)))
(len-a (%bignum-length a))
(len-b (%bignum-length b))
(len-res (+ len-a len-b))
(res (%allocate-bignum len-res))
(negate-res (not (eq a-plusp b-plusp))))
(declare (type bignum-index len-a len-b len-res))
(dotimes (i len-a)
(declare (type bignum-index i))
(let ((carry-digit 0)
(x (%bignum-ref a i))
(k i))
(declare (type bignum-index k)
(type bignum-element-type carry-digit x))
(dotimes (j len-b)
(multiple-value-bind (big-carry res-digit)
(%multiply-and-add x (%bignum-ref b j)
(%bignum-ref res k)
carry-digit)
(declare (type bignum-element-type big-carry res-digit))
(setf (%bignum-ref res k) res-digit)
(setf carry-digit big-carry)
(incf k)))
(setf (%bignum-ref res k) carry-digit)))
(when negate-res (negate-bignum-in-place res))
(%normalize-bignum res len-res)))
(%bignum-length gives the length, %allocate-bignum makes a new bignum
%bignum-ref... you can see it's not _that_ difficult)
Take knuth #2, look at multiplications done the right way. Write a
replacement function in :user. Test it out. Send it to cmucl-imp. Done.
If you do you'll find this stuff interesting:
(defun print-it (x)
(format t "~%-> ")
(dotimes (i (bignum:%bignum-length x))
(format t " ~8,'0X " (bignum:%bignum-ref x i)))
(format t "~%<- ")
(loop for i from (1- (bignum:%bignum-length x)) downto 0 do
(format t " ~8,'0X " (bignum:%bignum-ref x i)))
(format t "~%"))
#|
* (print-it (expt 2 64))
-> 00000000 00000000 00000001
<- 00000001 00000000 00000000
* (print-it (1+ (expt 2 64)))
-> 00000001 00000000 00000001
<- 00000001 00000000 00000001
NIL
* (print-it (- (expt 2 64)))
-> 00000000 00000000 FFFFFFFF
<- FFFFFFFF 00000000 00000000
NIL
|#
Oh. And don't forget to _document_ what you've been trying to
figure out for so long...
Why I haven't done this? Because the debian package had to be rebuild,
the syscall interface should be revised and I need to read and use the new
policy/deb-helper/menu/dh-make debian packages...
Groetjes, Peter
--
It's logic Jim, but not as we know it. | ········@debian.org for pleasure,
"God, root, what is difference?" - Pitr| ········@inthan.be for more pleasure!
"God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd
In article <·······················@mail.inthan.be>,
Peter Van Eynde <········@inthan.be> wrote:
>On Wed, 07 Jul 1999 10:40:06 GMT, ·········@computasoft.com wrote:
>>
>>The trouble with CMUCL is that it is just so complex. I've never even
>>managed to get the system to build with or without instructions.
>
>Get the debian packages and the .tar.gz file. Get CMUCL to work from the
>debs. Unpack the tar.gz. Type "make". Look at the new bits.
><snip>
(I just started reading this thread; first parts gone)
QUESTION: the suggestion "get the debian packages": can you
do that on sparc/solaris?
QUESTION: "the debs.": What is that, "debs"?
On 10 Jul 1999 16:56:23 GMT, David Combs wrote:
>In article <·······················@mail.inthan.be>,
>Peter Van Eynde <········@inthan.be> wrote:
>>On Wed, 07 Jul 1999 10:40:06 GMT, ·········@computasoft.com wrote:
>>>
>>>The trouble with CMUCL is that it is just so complex. I've never even
>>>managed to get the system to build with or without instructions.
>>
>>Get the debian packages and the .tar.gz file. Get CMUCL to work from the
>>debs. Unpack the tar.gz. Type "make". Look at the new bits.
>><snip>
>
>(I just started reading this thread; first parts gone)
>
>QUESTION: the suggestion "get the debian packages": can you
>do that on sparc/solaris?
Ahem. I think so, I haven't checked lately but debian works (more or
less) on i86, alpha, sparc, arm and I think there is even a 68k project.
But as I have no sparc, there is no debian package of CMUCL for sparc.
There is however a normal tar.gz package at www.cons.org, IIRC.
>QUESTION: "the debs.": What is that, "debs"?
A .deb file is a debian package. It is actually a ar archive containing
the software itself and a package description that takes care of
dependencies, config files etc.
(note: With "alien" you can convert between .deb, .rpm and .tgz files.)
With apt-get you can now even do "apt-get install cmucl-small" and CMUCL
will be downloaded and installed for you...
Groetjes, Peter
--
It's logic Jim, but not as we know it. | ········@debian.org for pleasure,
"God, root, what is difference?" - Pitr| ········@inthan.be for more pleasure!
"God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd
Any chance a friend of yours DOES have access to a SPARC? Looks like
there's some neat programs that could benefit the many SPARC users.
By the way, Solaris has created a neat concept of what they
call a "package", with a lot of programs (in man (1)) named
with the prefix "pkg", eg "pkgadd", "pkginfo", "pkgrm", etc, etc,
making installation and management FAR easier.
(Probably something similar in linux?)
Thanks for whatever you can do.
David
In article <·······················@mail.inthan.be>,
Peter Van Eynde <········@inthan.be> wrote:
>On 10 Jul 1999 16:56:23 GMT, David Combs wrote:
>>In article <·······················@mail.inthan.be>,
>>Peter Van Eynde <········@inthan.be> wrote:
>>>On Wed, 07 Jul 1999 10:40:06 GMT, ·········@computasoft.com wrote:
>>>>
>>>>The trouble with CMUCL is that it is just so complex. I've never even
>>>>managed to get the system to build with or without instructions.
>>>
>>>Get the debian packages and the .tar.gz file. Get CMUCL to work from the
>>>debs. Unpack the tar.gz. Type "make". Look at the new bits.
>>><snip>
>>
>>(I just started reading this thread; first parts gone)
>>
>>QUESTION: the suggestion "get the debian packages": can you
>>do that on sparc/solaris?
>
>Ahem. I think so, I haven't checked lately but debian works (more or
>less) on i86, alpha, sparc, arm and I think there is even a 68k project.
>
>But as I have no sparc, there is no debian package of CMUCL for sparc.
>
>There is however a normal tar.gz package at www.cons.org, IIRC.
>
>>QUESTION: "the debs.": What is that, "debs"?
>
>A .deb file is a debian package. It is actually a ar archive containing
>the software itself and a package description that takes care of
>dependencies, config files etc.
>
>(note: With "alien" you can convert between .deb, .rpm and .tgz files.)
>
>With apt-get you can now even do "apt-get install cmucl-small" and CMUCL
>will be downloaded and installed for you...
>
>Groetjes, Peter
>
>--
>It's logic Jim, but not as we know it. | ········@debian.org for pleasure,
>"God, root, what is difference?" - Pitr| ········@inthan.be for more pleasure!
>"God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd
On 14 Jul 1999 00:17:29 GMT, David Combs wrote:
>Any chance a friend of yours DOES have access to a SPARC? Looks like
>there's some neat programs that could benefit the many SPARC users.
If you want, go to
http://www.uk.debian.org/debian/dists/stable/main/disks-sparc/current/
and install away... (replace uk with the appropriate country code)
>[solaris packages]
>
>(Probably something similar in linux?)
AFAIK debian packages are quite a bit more advanced.
Groetjes, Peter
--
It's logic Jim, but not as we know it. | ········@debian.org for pleasure,
"God, root, what is difference?" - Pitr| ········@inthan.be for more pleasure!
"God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd
Interesting, what NASA will do now? I mean, they successfully tested in
space their remote agent software based on LispWorks, should they test it
now with another system? It must be terribly expensive...
--
Eugene
In article <················@lxms.cit.org.by>,
Eugene Zaikonnikov <······@removeme.cit.org.by> wrote:
>Interesting, what NASA will do now? I mean, they successfully tested in
>space their remote agent software based on LispWorks, should they test it
>now with another system? It must be terribly expensive...
Well, they could buy the Lisp part, or better, fund a buyout by
Harlequin's Lisp people.
Bernhard, just day-dreaming
--
--------------------------------------------------------------------------
Bernhard Pfahringer
Austrian Research Institute for http://www.ai.univie.ac.at/~bernhard/
Artificial Intelligence ········@ai.univie.ac.at
"Eugene Zaikonnikov" <······@removeme.cit.org.by> writes:
> Interesting, what NASA will do now? I mean, they successfully tested in
> space their remote agent software based on LispWorks, should they test it
> now with another system? It must be terribly expensive...
>
They may well have escrow agreements I expect, big organisations often do.
--tim
In article <················@lxms.cit.org.by>,
Eugene Zaikonnikov <······@removeme.cit.org.by> wrote:
>Interesting, what NASA will do now? I mean, they successfully tested in
>space their remote agent software based on LispWorks, should they test it
>now with another system? It must be terribly expensive...
First off, let me point out that the Remote Agent Experiment was a
prototype, and was specifically tailored for the New Millenium Deep
Space One flight. Remote Agent depends heavily on behavioral models of
the particular spacecraft on which it is flying. Future deployments of
Remote Agent technologies will require substantial customization for the
particular flight environment, swamping the work involved in retargeting
to another Lisp implementation.
The Remote Agent was a combination of several research projects that
were integrated in a relatively short time. We learned a number of
things along the way, and future flight software based on Remote Agent
will be implemented differently.
As it is, the Remote Agent modules are written in fairly portable ANSI
CL, and were initially prototyped on Allegro CL; porting to Harlequin
was straightforward. I was responsible for porting the planner/
scheduler module to Harlequin, so I speak from experience here.
Excellent compliance to the ANSI standard by both implementations made
porting simple. The minor difficulties were largely in the not-quite-
standardized extensions, such as multitasking, and OS-specific issues,
such as file system interfaces.
The bad news: the Remote Agent modules are all being ported to C++
anyway, as C++ is seen as more "saleable" to risk-averse flight software
management. This despite the fact C++ was bumped from Deep Space One
because the compiler technology wasn't mature, which the Remote Agent
planner/scheduler team learned to its dismay.
Now for the good news. You may have seen Erann Gat's post about JPL's
successful port of Macintosh Common Lisp to VxWorks and LinuxPPC. One
of the MCL implementors was hired by JPL over a year ago, assuring JPL
the ability to maintain and customize MCL for space applications. And
MCL has certain advantages over Harlequin CL, not the least of which is
memory usage, primarily in the size of executable images. The MCL
compiler also produces screaming fast PowerPC code. MCL is definitely
*not* a toy!
For the intelligent execution module of the Remote Agent, Common Lisp
offers substantial advantages. Were we to port the Exec to C++, we'd
have to reimplement all the control structures CL provides
(e.g. UNWIND-PROTECT, condition handling, etc.). And then there's
memory management...
Erik Naggum is right: those who do not understand Lisp are doomed to
reimplement it.
So while Harlequin's uncertain future may seem to present a risk to
NASA's use of Common Lisp, I believe in the grand scheme of things it is
a very small risk.
Disclaimer: The above opinions are mine, and do not represent the
official opinions of NASA, Ames Research Center, the Jet Propulsion Lab,
Caelum Research, or anyone else involved in the Remote Agent Experiment.
-- Chuck, a member of, but not speaking for, the Remote Agent team
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
The addresses above are real. All spammers will be reported to their ISPs.
On 9 Jul 1999 09:06:19 -0700, ······@best.com (Chuck Fry) wrote:
> The bad news: the Remote Agent modules are all being ported to C++
> anyway, as C++ is seen as more "saleable" to risk-averse flight software
> management. This despite the fact C++ was bumped from Deep Space One
Would a Common Lisp to C translator such as Eclipse make management feel
more comfortable?
> Now for the good news. You may have seen Erann Gat's post about JPL's
> successful port of Macintosh Common Lisp to VxWorks and LinuxPPC. One
Is it just for research purposes? Are there any planned missions for which
that MCL port will be used?
Paolo
--
Paolo Amoroso <·······@mclink.it>
In article <················@news.mclink.it>,
Paolo Amoroso <·······@mclink.it> wrote:
>On 9 Jul 1999 09:06:19 -0700, ······@best.com (Chuck Fry) wrote:
>> The bad news: the Remote Agent modules are all being ported to C++
>> anyway, as C++ is seen as more "saleable" to risk-averse flight software
>> management. This despite the fact C++ was bumped from Deep Space One
>
>Would a Common Lisp to C translator such as Eclipse make management feel
>more comfortable?
No. Most of the teams are taking this as an opportunity to redesign as
well. We looked into Eclipse at one point, but at the time it wasn't
really ready for public use.
>> Now for the good news. You may have seen Erann Gat's post about JPL's
>> successful port of Macintosh Common Lisp to VxWorks and LinuxPPC. One
>
>Is it just for research purposes? Are there any planned missions for which
>that MCL port will be used?
For now, it's only for research purposes. While no mission has adopted
MCL/VxWorks that I know of, we hope one does.
-- Chuck, again not speaking for anyone but himself
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
The addresses above are real. All spammers will be reported to their ISPs.
hi,
I have a problem (novices problem I assume)
I need to concatenate two strings (add two string to form one string ) in
order to use them as a function name.
meaning :
i have two functions named: global-a, global-b
and i want to call one of them according to variable named c which have the
values of 'a or 'b.
I want to do:
(funcall (concatinate 'global- c ))
how can I concatenate those strings in Allegro CL (lite)???
thanks,
Noam Elbaum
[Disclaimer: I'm more fluent in Scheme than CL, so excuse me if I don't
say this exactly right...]
Noam Elbaum <····@ic.co.il> wrote:
+---------------
| I need to concatenate two strings (add two string to form one string ) in
| order to use them as a function name.
|
| meaning :
| i have two functions named: global-a, global-b
| and i want to call one of them according to variable named c which have the
| values of 'a or 'b.
|
| I want to do:
| (funcall (concatinate 'global- c ))
+---------------
Personally, I wouldn't do it that way at all! Try something like this
instead [note: I'm deliberately not using quasiquotes, since you said
you're a newbie]:
(defvar *global-funcs*
(list
(cons 'a #'global-a)
(cons 'b #'global-b)
...any others...
))
(defun callit (arg)
(let ((elem (assoc arg *global-funcs*)))
(if elem
(funcall (cdr elem))
...handle the error...)))
Then (callit 'a) would call the function "global-a", and so on.
Also, this way the keys & function names are *not* required to be
related in any way (though they still *may* be, if you like). That is,
if "*global-funcs*" contains "(cons 'foo #'bar)", then (callit 'foo)
will call "bar", not "global-foo".
-Rob
p.s. Later, if the "*global-funcs*" list gets too long [whatever
"too long" might mean, in your particular application], you might
consider changing it to a hash table, and changing "callit" accordingly.
None of the code that uses "callit" would need to change, though.
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
Noam Elbaum <····@ic.co.il> writes:
> meaning :
> i have two functions named: global-a, global-b
> and i want to call one of them according to variable named c which have the
> values of 'a or 'b.
If you really want to do this, here is how:
# USER(1): (defun global-a () 'a)
# GLOBAL-A
# USER(2): (defun global-b () 'b)
# GLOBAL-B
# USER(6): (defun call-switch (c)
# (funcall (intern (concatenate 'string "GLOBAL-" c))))
# CALL-SWITCH
# USER(7): (call-switch "A")
# A
# USER(8): (call-switch "B")
# B
Note that you have to take into account the reader-case. (GLOBAL and A
and B in uppercase). You also have to take into account that your
function call-switch now is package dependent.
Could you explain what you are trying to accomplish because they're
probably ways to do it that don't have as many traps and pitfalls as
the above?
If you want to make a mapping from a string or a symbol to a function
use alists or hashtables or a property on the symbol.
--
Lieven Marchand <···@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
In article <·················@ic.co.il>,
Noam Elbaum <····@ic.co.il> wrote:
> i have two functions named: global-a, global-b
> and i want to call one of them according to variable named c which
have the
> values of 'a or 'b.
>
> I want to do:
> (funcall (concatinate 'global- c ))
(funcall (if (eq 'a c) #'global-a #'global-b))
Notice that my solution doesn't depend on the actual function
names. I've found that if I think that I need to construct
a function name at run time, I need to think more about what
I'm doing. (I avoid it much as I avoid eval.)
I'd use case instead of the if so that I could have an error
function (or ecase if I was really sure about c's values). Or,
if the same sort of decision is made multiple places, I'd use
a hashtable to associate the keys with the functions.
-andy
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Chuck,
I would be interested why JPL ported the Remote Agent from ACL to
Lispworks. At the talk in Berkeley it was Allegro based, wasn't it?
······@best.com (Chuck Fry) wrote:
>As it is, the Remote Agent modules are written in fairly portable ANSI
>CL, and were initially prototyped on Allegro CL; porting to Harlequin
>was straightforward. I was responsible for porting the planner/
>scheduler module to Harlequin, so I speak from experience here.
>Excellent compliance to the ANSI standard by both implementations made
>porting simple. The minor difficulties were largely in the not-quite-
>standardized extensions, such as multitasking, and OS-specific issues,
>such as file system interfaces.
--
Reini
In article <···············@acs5.bu.edu>, David Bakhash <·····@bu.edu> wrote:
>what does the Remote Agent do?
See:
<http://rax.arc.nasa.gov/>
Essentially, the Remote Agent combines a generative planner/scheduler, a
mode identification and reconfiguration module (for automated
diagnosis), and a smart executive. The details are at the URL above.
-- Chuck, a member of the Remote Agent team
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
The addresses above are real. All spammers will be reported to their ISPs.
······@xarch.tu-graz.ac.at (Reini Urban) writes:
> ······@best.com (Chuck Fry) wrote:
> >As it is, the Remote Agent modules are written in fairly portable ANSI
> >CL, and were initially prototyped on Allegro CL; porting to Harlequin
> >was straightforward. I was responsible for porting the planner/
> >scheduler module to Harlequin, so I speak from experience here.
> >Excellent compliance to the ANSI standard by both implementations made
> >porting simple. The minor difficulties were largely in the not-quite-
> >standardized extensions, such as multitasking, and OS-specific issues,
> >such as file system interfaces.
>
> Chuck,
> I would be interested why JPL ported the Remote Agent from ACL to
> Lispworks. At the talk in Berkeley it was Allegro based, wasn't it?
No, it never was; Chuck discussed the porting issues at LUGM last November
as well. The issue was that they needed the runtime to run on
VxWorks, for which we don't have a port. I don't remember the exact
time, but I do recall that we were approached to do a port of Allegro
CL to VxWorks, but at the time we were so consumed with the 5.0 effort
that we had to decline for lack of extra resources. Harlequin stepped
up to the task and did the port.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane is correct. While prototyping was done on workstations in Allegro
CL, Harlequin provided the CL port for the VxWorks/RAD6000 flight
environment. (The RAD6000 is a radiation-hardened IBM RS/6000.)
Incidentally, JPL appears to have standardized on PowerPC processors and
VxWorks for their computing platform for future space flight projects.
Disclaimer: Please don't interpret any of the above as a NASA
"endorsement" of any of the products named. And of course, these are my
opinions only, not those of NASA, its research centers, or my employer.
-- Chuck, a member of, but not speaking for, the Remote Agent team
In article <·············@beta.franz.com>,
Duane Rettig <·····@franz.com> wrote:
>······@xarch.tu-graz.ac.at (Reini Urban) writes:
>> Chuck,
>> I would be interested why JPL ported the Remote Agent from ACL to
>> Lispworks. At the talk in Berkeley it was Allegro based, wasn't it?
>
>No, it never was; Chuck discussed the porting issues at LUGM last November
>as well. The issue was that they needed the runtime to run on
>VxWorks, for which we don't have a port. I don't remember the exact
>time, but I do recall that we were approached to do a port of Allegro
>CL to VxWorks, but at the time we were so consumed with the 5.0 effort
>that we had to decline for lack of extra resources. Harlequin stepped
>up to the task and did the port.
>
>--
>Duane Rettig Franz Inc. http://www.franz.com/ (www)
>1995 University Ave Suite 275 Berkeley, CA 94704
>Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
The addresses above are real. All spammers will be reported to their ISPs.
······@best.com (Chuck Fry) wrote:
>Duane is correct. While prototyping was done on workstations in Allegro
>CL, Harlequin provided the CL port for the VxWorks/RAD6000 flight
>environment. (The RAD6000 is a radiation-hardened IBM RS/6000.)
Ah, I remember now. I forgot it because your talk switched in in the
last minute and wasn't therefore in the papers.
--
Reini
"Eugene Zaikonnikov" <······@removeme.cit.org.by> writes:
> Interesting, what NASA will do now? I mean, they successfully tested in
> space their remote agent software based on LispWorks, should they test it
> now with another system? It must be terribly expensive...
From what little I know about NASA space qualification, it shouldn't
matter to them if Lispworks continues, so long as they have sufficient
licenses for the system that is already out.
If a vendor changes the software or hardware, then that often counts as
a new (or at the best modified) system and has to be re-qualified.
After all, the change could have had bad consequences. That would
suggest that NASA would want to have a frozen version of the software to
use on their deployed systems, and thus they don't necessarily need the
ongoing support. It might even make their lives simpler if there is no
new version.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu