Harlequin
Rainer Joswig
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
knot...@my-deja.com
jos...@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.
Lyman S. Taylor
....
> 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
knot...@my-deja.com
"Lyman S. Taylor" <lyman....@mindspring.com> wrote:
> knot...@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
James McCartney
> 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
Paul R. Potts
work today... just on a whim. I rarely wear it.
Now I read Harlequin is bankrupt?
Is Dylan the cursed language? Or are all languages coming out of the Lisp
tree cursed?
Why is it that the business model for advanced languages is, for the most
part, not working?
What would a workable model look like?
I am very disappointed. I became interested in Dylan when Apple was giving
out its free book (based on the parenthesized syntax version) to drum up
interest. I was a tester of Apple Dylan and some of my (early, not very
idiomatic, messy) code made it as a user contribution on the Technology
Release.
At the time I was working with C++ and NewtonScript. NewtonScript is a very,
very small but very cleverly designed language; Apple had a simple, compact,
byte-code or native compilation language. It lacked a few niceties, but it
is still amazing how well it works. A Pascal-like syntax and a Java-like
runtime model and closures and true dynamic behavior. NewtonScript got me
interested in other dynamic languages like Scheme and Dylan.
Apple Dylan was way ahead of its time... it ran so slowly on the machines at
the time (68040 class) that it was painful and nearly useless. It is quite
snappy now on a PowerPC... but not quite stable enough for real work.
I was very excited to see Harlequin jump in. I beta-tested Harlequin
Dylan... it too had some pretty serious performance problems, although they
have improved a lot. I could never fathom how their program required over
100 megs of RAM to do anything useful, where Apple Dylan could build its
frameworks in under 40. It was obvious they were having some painful
struggles with their user interface, although that has improved. I can't
imagine trying to do a sophisticated Windows-API user interface. In Apple
Dylan's case, the great UI came first.
I work primarily with Mac hardware, so I blew a wad of my own money on a
fast PC. Unfortunately my free time has gotten thinner and thinner and there
was no way to use an NT-based environment here at work, although our
tailoring and rule engine tools would benefit ENORMOUSLY if could get away
from Perl and C++ and AppleScript. A more hideous concoction of code I can
scarcely imagine... but it works.
I guess I'm really just venting here... I want to use Dylan. I want to be
able to use Dylan on Apple hardware. For various reasons, I do NOT want to
use Java.
What can be done to save businesses working in advanced language products?
What can be done to make Dylan viable?
I might be able to work with Gwydion, but trying to debug crashing C code
built out of Dylan code does not sound like much fun to me.
Java... C++... Perl... blech.
Paul
--
"ain't you ever seen a disembodied soul before? ain't you ever seen a soul
seeking incarnation?" - Robyn Hitchcock
Paul R. Potts - Technical Group Leader - Health Media Research Lab
Comprehensive Cancer Center - University of Michigan Medical Center
po...@umich.edu - 734.936.0096
Tim Bradshaw
> 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
olef...@my-deja.com
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.
BPer...@computasoft.com
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
Bruce Hoult
<po...@umich.edu> wrote:
> Well, I happened to wear my Apple Cambridge Dylan cancellation t-shirt to
> work today... just on a whim. I rarely wear it.
>
> Now I read Harlequin is bankrupt?
>
> Is Dylan the cursed language? Or are all languages coming out of the Lisp
> tree cursed?
It's T-shirts which are the problem. I wore my official Rotary Rocket
t-shirt to work a few weeks ago and a few days later they unexpectedly
laid off the entire propulsion team. I'm just glad I don't have a Pioneer
Rocketplane shirt to jinx them with as well.
> Why is it that the business model for advanced languages is, for the most
> part, not working?
>
> What would a workable model look like?
Difficult to say. Is anyone making money from development tools now?
Maybe Metrowerks. They're now managing to sucessfully raise prices
without seeming to lose customers and they're available *everywhere* with
the same IDE: Mac, Windows, Solaris, Linux, BeOS, Palm, PlayStation...
I think I'd be willing to pay quite a lot for something that really,
really made my job easier. Metrowerks' C/C++/Pascal/Java product does
that pretty well for those languages. now I just want a better language.
The problem is that I'm not going to pay a lot on the off-chance that the
hype on product M is actually true, when the hype for products A, B, C, D,
E, ... has proved to be false. I need to be able to try it out for myself
very cheaply. Harlequin got *that* much right -- the problem is they don't
make tools for the platforms I actually use (Mac, Linux, Solaris ... and
naturally Rhapsody/Mac OS X).
I'm very, very fussy about my tools. They need to let me do anything I
want to do -- too many "advanced" programming tools try to lock me into
*their* way of thinking. They need to produce fast code. They need to
make it easy to make user interfaces (but there somewhat slow but flexible
code that's fast and easy to write is fine). They need to have great
browsing and editing facilities. They need to interface with existing
stuff.
And I don't want to switch too often. I want to use the same language for
at least 10 years. (Which has been the case if you don't count Java)
> I am very disappointed. I became interested in Dylan when Apple was giving
> out its free book (based on the parenthesized syntax version) to drum up
> interest.
Me too. Got it right here. And the ADTR.
> I was very excited to see Harlequin jump in. I beta-tested Harlequin
> Dylan...
Me too.
> I guess I'm really just venting here... I want to use Dylan.
Me too.
Which is why I jumped on board to try to help out with Gwydion Dylan as
soon as I heard that it was in the hands of Open Source volunteers and I
found a copy to try it out. Maybe it'll take a long time to get it truely
competitive with the commercial offering, but it runs where I want it to
run (or can be made to if I so choose) and it's amazingly good already.
And no company can take it away from me. That's looking even more
important now.
> I might be able to work with Gwydion, but trying to debug crashing C code
> built out of Dylan code does not sound like much fun to me.
It's not that bad. First, your Dylan programs should never be able to
crash -- throwing exceptions should be the worst. Second, there's nothing
stopping source code debugging from working at least as well as it did
with the original CFront C++-to-C compiler. Third, I actually *like*
being able to take a peek at the intermediate C code :-) d2c makes much
more readable code than CFront did, and since it can assume a rather
smarter C compiler backend (i.e. gcc as a minimum), it doesn't have to
fall over itself trying to micro-optomise the generated code like CFront
did.
-- Bruce
Rob Myers
BPer...@computasoft.com wrote:
> 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.
I looked at PowerLisp ( The PC version is Corman Lisp ), which hadn't
been updated in while and isn't Open Source. It had lots of the right
sort of brackets but that's all I could discover... :-)
- Rob.
__________________________________________________________________
__ __ _ __
mailto:ro...@lostwax.com / / ___ ___ / /_ | | /| / /__ ___ __
http://www.lostwax.com/ / /__/ _ \(_-</ __/ | |/ |/ / - `/\ \ /
/____/\___/___/\__/ |__/|__/\_,_//_\_\
Peter Van Eynde
>
>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. | pvan...@debian.org for pleasure,
"God, root, what is difference?" - Pitr| pvan...@inthan.be for more pleasure!
"God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd
Paul R. Potts
discouraging caveats in its release notes. If I can find something to do
that I can actually figure out how to do, maybe I can contribute to the
project too. I'm a pretty decent engineer and good at tracking down bugs,
but I am not a compiler whiz, and I don't really have much practice with
UNIX tools.
If Gwydion works on OSX Server and/or LinuxPPC, I'm interested. Right now,
OSX Server is especially interesting. The lack of a GUI toolkit is a
problem, but maybe I can build some command-line tools that I can drive from
a Java/WebObjects GUI.
The intermediate C code might actually be a selling point... I can tell my
boss that I'm building tools in C! : )
Paul
In article <bruce-07079...@bruce.bgh> , br...@hoult.actrix.gen.nz
(Bruce Hoult) wrote:
> It's not that bad. First, your Dylan programs should never be able to
> crash -- throwing exceptions should be the worst. Second, there's nothing
> stopping source code debugging from working at least as well as it did
> with the original CFront C++-to-C compiler. Third, I actually *like*
> being able to take a peek at the intermediate C code :-) d2c makes much
> more readable code than CFront did, and since it can assume a rather
> smarter C compiler backend (i.e. gcc as a minimum), it doesn't have to
> fall over itself trying to micro-optomise the generated code like CFront
> did.
--
Andreas Bogk
> 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 )
Michael T. Richter
news:m3so70p...@soma.andreas.org...
> 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.
I'd cheerfully contribute to making GD a good compiler if it weren't for the
nagging suspicion, not at all ameliorated by the web page, that the GD
people are intent on doing whatever it takes to make sure that GD is a
Unix-only solution. (I don't work in a Unix environment and I have no
desire to *start* working in a Unix environment.) As a result GD is of
little to no interest to me.
--
Michael T. Richter <m...@ottawa.com> http://www.igs.net/~mtr/
PGP Key: http://www.igs.net/~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8
Andreas Bogk
> I will investigate Gwydion again. The last version I looked at had rather
> discouraging caveats in its release notes. If I can find something to do
This is just to cover our collective asses. If you can tell a compiler
bug from your own bug, and your life doesn't depend on the bug being
fixed within 48 hours, go ahead and use it.
> that I can actually figure out how to do, maybe I can contribute to the
> project too. I'm a pretty decent engineer and good at tracking down bugs,
> but I am not a compiler whiz, and I don't really have much practice with
> UNIX tools.
You don't have to be into compilers to help the project. If you find
bugs, that's helpful, if you write documentation, that helps us, if
you write a library that solves a particular problem and publish it,
that's great.
> If Gwydion works on OSX Server and/or LinuxPPC, I'm interested. Right now,
It works on LinuxPPC, and it should be possible to port it to OSX
server, the garbage collector being the only hard part here.
> OSX Server is especially interesting. The lack of a GUI toolkit is a
> problem, but maybe I can build some command-line tools that I can drive from
> a Java/WebObjects GUI.
We're working on a Gtk binding, although I must admit that work on
that is frozen until pidgin, our C header parser is finished, which in
turn depends on the new C-FFI, which also isn't finished yet, and all
that together will certainly take some time to finish.
Andreas Bogk
> I'd cheerfully contribute to making GD a good compiler if it weren't for the
> nagging suspicion, not at all ameliorated by the web page, that the GD
> people are intent on doing whatever it takes to make sure that GD is a
> Unix-only solution. (I don't work in a Unix environment and I have no
I'm sorry if we generated that impression. It is true that nobody is
maintaining the Windows parts of GD at the moment, but that is not a
political decision or something like that, but simply due to the fact
that nobody volounteered so far. We appreciate any additional platform
Gwydion Dylan works on, and that explicitly includes Windows, MacOS
and BeOS. For the two latter, there are mindy ports available.
GD 2.0 did work on Windows, and I'm sure that 2.3.1 can be made to
work on Windows with little hassle. It won't work out of the box, as
we modified the build process, but I'm not aware of any major
obstacle. It's just that we were not able to test it.
Michael T. Richter
>> I'd cheerfully contribute to making GD a good compiler if it weren't for
the
>> nagging suspicion, not at all ameliorated by the web page, that the GD
>> people are intent on doing whatever it takes to make sure that GD is a
>> Unix-only solution. (I don't work in a Unix environment and I have no
> I'm sorry if we generated that impression. It is true that nobody is
> maintaining the Windows parts of GD at the moment, but that is not a
> political decision or something like that, but simply due to the fact
> that nobody volounteered so far. We appreciate any additional platform
> Gwydion Dylan works on, and that explicitly includes Windows, MacOS
> and BeOS. For the two latter, there are mindy ports available.
> GD 2.0 did work on Windows, and I'm sure that 2.3.1 can be made to
> work on Windows with little hassle. It won't work out of the box, as
> we modified the build process, but I'm not aware of any major
> obstacle. It's just that we were not able to test it.
I don't really consider requiring the use of the Cygwin tools to be a good
Win32 port myself. It has something to do with clashing assumptions about
the underlying environment.
What's the process for coming on-board as a Gwydion observer/commentator
(and, in my Copious Free Time, possibly even developer)?
Right now I'm depressed that, after finding Dylan and falling in love with
it, there is the very real risk of not having a Dylan compiler to work with.
I'm vulnerable. Now's your chance to take advantage of me! :-)
Eric Kidd
On Wed, Jul 07, 1999 at 03:45:37PM +0000, Michael T. Richter wrote:
> What's the process for coming on-board as a Gwydion observer/commentator
> (and, in my Copious Free Time, possibly even developer)?
Join our mailing lists at http://www.gwydiondylan.org/. Say cool things.
Post some patches. We're a very informal bunch. :-)
Cheers,
Eric
Andreas Bogk
> I don't really consider requiring the use of the Cygwin tools to be a good
> Win32 port myself. It has something to do with clashing assumptions about
> the underlying environment.
Well, we will gladly accept your patches to do better ;).
> What's the process for coming on-board as a Gwydion observer/commentator
> (and, in my Copious Free Time, possibly even developer)?
Subscribe to the gd-hackers mailing list[0]. Get familiar with CVS,
and check out the latest development branch[1]. Read the source[2].
Send patches[3].
> Right now I'm depressed that, after finding Dylan and falling in love with
> it, there is the very real risk of not having a Dylan compiler to work with.
> I'm vulnerable. Now's your chance to take advantage of me! :-)
We want you! Subscribe now!
Andreas
[0] http://www.gwydiondylan.org/lists.phtml, or send mail to
majo...@randomhacks.com with "subscribe gd-hackers" in the body.
[1] http://www.cyclic.com,
http://www.gwydiondylan.org/downloading.phtml, [2]
[2] http://www.gwydiondylan.org/gdref/gdmaint/gdmaint.html
[3] To the mailing list. Once you have submitted a working patch, you
become a candidate for core developer, which involves r/w access
to the CVS.
Michael T. Richter
>> I don't really consider requiring the use of the Cygwin tools to be a
good
>> Win32 port myself. It has something to do with clashing assumptions
about
>> the underlying environment.
> Well, we will gladly accept your patches to do better ;).
>> What's the process for coming on-board as a Gwydion observer/commentator
>> (and, in my Copious Free Time, possibly even developer)?
> Subscribe to the gd-hackers mailing list[0]. Get familiar with CVS,
Here's one of the "clashing assumptions about the environment" thing I was
going on about. I've never actually managed to get a working CVS on NT.
This presents a problem for submitting any kind of fixes. (The same applies
to the "patch" utility, likely.)
Andreas Bogk
> > Subscribe to the gd-hackers mailing list[0]. Get familiar with CVS,
> Here's one of the "clashing assumptions about the environment" thing I was
> going on about. I've never actually managed to get a working CVS on NT.
This is the reason I've included the http://www.cyclic.com URL in the
footnote. You can get a CD-ROM with a working version of CVS for
Windows there.
I cannot afford any other version management software, even if it were
available for my platform, which it isn't. So CVS has to do.
> This presents a problem for submitting any kind of fixes.
You can do without CVS, as you can browse the repository online:
http://berlin.ccc.de/cgi-bin/cvsweb/gd
We make a snapshot every night, which you can get at our FTP site:
ftp://berlin.ccc.de/pub/gd/unstable/src/
> (The same applies to the "patch" utility, likely.)
Probably, but it's not unheard of that it works. What would you use in
the Win world for that purpose?
Andreas
Michael T. Richter
>> (The same applies to the "patch" utility, likely.)
> Probably, but it's not unheard of that it works. What would you use in
> the Win world for that purpose?
I'd use a group-oriented code control system that worked on Windows. :-)
Tom Emerson
On Wed, 07 Jul 1999 15:45:37 GMT, "Michael T. Richter" <m...@ottawa.com> said:
> I don't really consider requiring the use of the Cygwin tools to be
> a good Win32 port myself. It has something to do with clashing
> assumptions about the underlying environment.
So do you want a working compiler or a working development
environment? I know several people who used the Harlequin command-line
compiler because they were more comfortable in Emacs and various CLI
tools.
What, explicitly, are you looking for?
-tre
--
Tom Emerson, tr...@tiac.net
http://www.tiac.net/users/tree
Tom Emerson
On Wed, 07 Jul 1999 17:32:02 GMT, "Michael T. Richter" <m...@ottawa.com> said:
> Here's one of the "clashing assumptions about the environment" thing
> I was going on about. I've never actually managed to get a working
> fixes. (The same applies to the "patch" utility, likely.)
Odd --- the CLI version of the CVS client worked without a hitch under
NT for me. I have not had any luck with the GUI wrappers, however, so
YMMV.
We use Unix context diffs and Larry Wall's 'patch', both of which are
part of the cygwin toolset and work fine on NT.
The (unfortunate) fact of the matter right now is that none of the
current volunteers is a heavy Windows developer (AFAIK) who could
tackle the task of getting 2.3.1 working on NT. If this is something
you are interested in doing, then the first step is to bootstrap
within the Cygwin environment. Once you have that working you can move
out to other targets.
Tim Bradshaw
>> Probably, but it's not unheard of that it works. What would you use in
>> the Win world for that purpose?
> I'd use a group-oriented code control system that worked on Windows. :-)
A free one that works on Unix too? I'd be very interested in that, do
you have pointers? I've only ever found CVS to be portable enough,
and it's not very satisfactory on NT as you say.
Similarly if, as you suggest (?) there is a better, free, way to go
for multiplatform Unix/NT solutions than the usual cygwin stuff that
most people seem do I'd be interested in that.
Thanks
--tim
Michael T. Richter
news:comp.lang.dylan.19...@haneda.basistech.com...
>> I don't really consider requiring the use of the Cygwin tools to be
>> a good Win32 port myself. It has something to do with clashing
>> assumptions about the underlying environment.
> So do you want a working compiler or a working development
> environment? I know several people who used the Harlequin command-line
> compiler because they were more comfortable in Emacs and various CLI
> tools.
> What, explicitly, are you looking for?
I can live with a command-line compiler, but I don't want to be forced into
using bash, gnumake, etc.
Michael T. Richter
news:ey3r9mk...@lostwithiel.tfeb.org...
>>> Probably, but it's not unheard of that it works. What would you use in
>>> the Win world for that purpose?
>> I'd use a group-oriented code control system that worked on Windows. :-)
> A free one that works on Unix too? I'd be very interested in that, do
> you have pointers? I've only ever found CVS to be portable enough,
> and it's not very satisfactory on NT as you say.
There was a reason for the smiley at the end. The free tools are, in terms
of user-friendliness at any rate, worth what you pay for them.
> Similarly if, as you suggest (?) there is a better, free, way to go
> for multiplatform Unix/NT solutions than the usual cygwin stuff that
> most people seem do I'd be interested in that.
The better way to do multiplatform solutions is to make the code
multiplatform. Compilers shouldn't output files, for example, which assume
the presence of bash. Or gcc. Or whatever. Revision systems shouldn't
assume a CLI or the standard five streams; the human interaction component
should be platform-specific and use a engine/library to provide the actual
functionality. (Using abstracted I/O facilities would also make porting
easier and allow for efficient implementation by platform, but that's
probably a pipe dream.)
LCD multiplatform is bad multiplatform. Invariably one platform or the
other will suffer for it. As, for example, NT suffers in CVS
implementations. Macs and Unices have much better support.
Tom Emerson
On Wed, 07 Jul 1999 20:19:23 GMT, "Michael T. Richter" <m...@ottawa.com> said:
> I can live with a command-line compiler, but I don't want to be
> forced into using bash, gnumake, etc.
You don't need to use bash: I actually use 4NT, or you could use the
usual DOS box.
You will need to use GNU Make to get things bootstrapped. After that
you can use whatever makefile you want for your own code. It shouldn't
be difficult to get the d2c driver to generate nmake flavored
makefiles if you didn't want to use gmake. But the use of gmake
happens behind the scenes (once your up and running) so the fact that
it is used shouldn't matter much, should it?
knot...@my-deja.com
> > Subscribe to the gd-hackers mailing list[0]. Get familiar with CVS,
>
> I was going on about. I've never actually managed to get a working
> CVS on NT.
I've not used it on NT (one of my compadres does), but I do know cvs
(1.10 at least) works on NT. I looked through the news file and I don't
see that the CVS server works on NT in anything other than local mode.
In my case, one thorny problem I've had with it is the fact that our
firewall closes off port 2401.
> This presents a problem for submitting any kind of fixes. (The same
> applies to the "patch" utility, likely.)
The patch utility is currently distributed with the cvs winzip file.
They are both available from the following URL:
ftp://download.cyclic.com/pub/cvs-1.10/windows/cvs-1.10-win.zip
> Michael T. Richter <m...@ottawa.com> http://www.igs.net/~mtr/
--Brad
Brian Rogoff
> Andreas Bogk <and...@andreas.org> wrote in message
> news:m3r9mkn...@soma.andreas.org...
> >> I don't really consider requiring the use of the Cygwin tools to be a
> good
> >> Win32 port myself. It has something to do with clashing assumptions
> about
> >> the underlying environment.
>
> > Well, we will gladly accept your patches to do better ;).
>
> >> What's the process for coming on-board as a Gwydion observer/commentator
> >> (and, in my Copious Free Time, possibly even developer)?
>
> > Subscribe to the gd-hackers mailing list[0]. Get familiar with CVS,
>
> Here's one of the "clashing assumptions about the environment" thing I was
> going on about. I've never actually managed to get a working CVS on NT.
> This presents a problem for submitting any kind of fixes. (The same applies
> to the "patch" utility, likely.)
WinCVS, www.wincvs.org, worked fine for me, when I was using Windows NT.
I agree that a Windows port of Gwydion should not ultimately rely on the
cygwin tools, and should be a self extracting InstallShield loaded true
blue Windows program, but I bet it will be some time before it reaches
that state. If you want to get it there, you'll probably have to gain
some familiarity with Unix tools.
-- Brian
Bruce Hoult
> Here's one of the "clashing assumptions about the environment" thing I was
> going on about. I've never actually managed to get a working CVS on NT.
> This presents a problem for submitting any kind of fixes. (The same applies
> to the "patch" utility, likely.)
Interesting. There's a good cvs for the Mac -- written by Netscape, if I
recall. How do people like Netscape do source code control on Windows?
The Gwydion Dylan configuration process *is* very heavily tied around the
GNU tools such as autoconf, which is a problem for the Mac too. That
doesn't stop you from running such tools on a Unix machine and
transferring the results over -- you only do such things once in a blue
moon.
There are a couple of other things that provide possible portability
problems. One is that d2c acts as a driver and runs gcc as a child
process. It might be more portable to instead have a script or makefile
that runs d2c and gcc in sucession.
I don't see a problem with it being a bit unix-centric. The Mac has good
free (speech, beer) Unixes available for it (on which d2c is supported).
I understand the PC has too :-)
-- Bruce
Bruce Hoult
<m...@ottawa.com> wrote:
> Andreas Bogk <and...@andreas.org> wrote in message
> news:m3btdon...@soma.andreas.org...
> >> (The same applies to the "patch" utility, likely.)
>
> > Probably, but it's not unheard of that it works. What would you use in
> > the Win world for that purpose?
>
> I'd use a group-oriented code control system that worked on Windows. :-)
Well, cvs doesn't exclude Mac or Windows. It's not proprietory. Unlike,
say, Visual Sourcesafe. Or PCCS. It also happens to be better than
either of those :-)
-- Bruce
Mac programmer
Bruce Hoult
<po...@umich.edu> wrote:
> I will investigate Gwydion again. The last version I looked at had rather
> discouraging caveats in its release notes. If I can find something to do
> that I can actually figure out how to do, maybe I can contribute to the
> project too. I'm a pretty decent engineer and good at tracking down bugs,
> but I am not a compiler whiz, and I don't really have much practice with
> UNIX tools.
There are *lot* of things that we need help with that don't involve
mucking with the internals of the compiler itself!
- the program which reads C header files and emits Dylan glue routines
that interface to them. (Melange)
- documentation, HOWTOs etc
- interfaces to GUI toolkits, databases, and all the other stuff that
makes a language useful.
- tools to make source-code eidting easier. e.g. a "tags" extractor for
vi/emacs, or a GUI code browser, or ...
- lots more...
What we have right now is a compiler that works well. We'd like it to
work a bit *better* but it's already good. It's the surrounding
infrastructure that we most need.
> If Gwydion works on OSX Server and/or LinuxPPC, I'm interested.
It works fine on my G3 PowerBook under LinuxPPC R4. I'm mostly using it
on x86 Linux myself (the PowerBook has better things to do :-), but I've
been doing development on the PowerBook as well. I believe that LinuxPPC
is Andreas Bogk's main development platform.
> The intermediate C code might actually be a selling point... I can tell my
> boss that I'm building tools in C! : )
Say: "it's just a fancy pre-processor that makes it easier to generate
good C code".
-- Bruce
Eric Kidd
On Wed, Jul 07, 1999 at 08:37:05PM +0000, Michael T. Richter wrote:
> The better way to do multiplatform solutions is to make the code
> multiplatform. Compilers shouldn't output files, for example, which
> assume the presence of bash. Or gcc. Or whatever.
The Gwydion code is very modular (with the nasty exception of the
optimizer). Most of the platform-specific configuration gets loaded at
runtime. In fact, d2c even considers "source files" to be a special case of
a much more general architecture.
For a high-level overview of how things work, see the maintainers' guide on
our website at <http://www.gwydiondylan.org/>. In the long run, the Gwydion
core could be adapted to run in some very strange environments. For now,
it's biased towards command-line systems with a copy of GNU Make.
This will only change if somebody cares enough to change it. :-)
Cheers,
Eric
James Beal
>In article <FEHBL...@world.std.com>, d...@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.
Michael T. Richter
news:bruce-08079...@bruce.bgh...
> I don't see a problem with it being a bit unix-centric. The Mac has good
> free (speech, beer) Unixes available for it (on which d2c is supported).
> I understand the PC has too :-)
I don't want to develop for Unix platforms, perhaps?
--
Michael T. Richter <m...@ottawa.com> http://www.igs.net/~mtr/
Michael T. Richter
>> forced into using bash, gnumake, etc.
> You don't need to use bash: I actually use 4NT, or you could use the
> usual DOS box.
> You will need to use GNU Make to get things bootstrapped.
I'd like to change that in the future, but I can live with it for now to
bootstrap myself into position.
> After that
> you can use whatever makefile you want for your own code. It shouldn't
> be difficult to get the d2c driver to generate nmake flavored
> makefiles if you didn't want to use gmake. But the use of gmake
> happens behind the scenes (once your up and running) so the fact that
> it is used shouldn't matter much, should it?
I've seen attempts to do this before. Typically the generated gmake files
contain rules which assume features which either don't exist on all shells
(especially non-UNIX ones) or which are very Unix-specific. Use of a bash
for loop, for example, is quite common. Part and parcel of making a proper
port that is comfortable to native users is to require the minimum amount of
"alien" tools.
And how do you propose to handle systems without command shells at all?
Michael T. Richter
news:comp.lang.dylan.1...@moebius.dartmouth.edu...
>> The better way to do multiplatform solutions is to make the code
>> multiplatform. Compilers shouldn't output files, for example, which
>> assume the presence of bash. Or gcc. Or whatever.
> The Gwydion code is very modular (with the nasty exception of the
> optimizer). Most of the platform-specific configuration gets loaded at
> runtime. In fact, d2c even considers "source files" to be a special case
of
> a much more general architecture.
That sounds good.
> For a high-level overview of how things work, see the maintainers' guide
on
> our website at <http://www.gwydiondylan.org/>. In the long run, the
Gwydion
> core could be adapted to run in some very strange environments. For now,
> it's biased towards command-line systems with a copy of GNU Make.
I'll dig around for that guide. And I'll live temporarily with the
bash/gmake for the bootstrapping effort, although this will be one of my
earliest targets for change. (The next will probably be a proper Win32
installation program....)
> This will only change if somebody cares enough to change it. :-)
That somebody may well be me. By the end of this month I'll be able to
spare some cycles for the project. I may even have time to figure out the
finicky CVS crap. :-)
Michael T. Richter
news:Pine.BSF.4.10.990707...@shell5.ba.best.com...
> WinCVS, www.wincvs.org, worked fine for me, when I was using Windows NT.
I'll look into this.
> I agree that a Windows port of Gwydion should not ultimately rely on the
> cygwin tools, and should be a self extracting InstallShield loaded true
> blue Windows program, but I bet it will be some time before it reaches
> that state. If you want to get it there, you'll probably have to gain
> some familiarity with Unix tools.
I have familiarity with the tools. And as the old adage goes, "familiarity
breeds..." well, you get the drift.
Michael T. Richter
news:Pine.BSF.4.10.990707...@shell5.ba.best.com...
> WinCVS, www.wincvs.org, worked fine for me, when I was using Windows NT.
I just downloaded it and am very impressed. First, it actually worked out
of the box (although the docs stink a bit). Second, the GUI actually works
reasonably nicely *without* emasculating the underlying engine (unlike, say,
ClearCase and its ilk). Finally the scripting interface looks very
interesting.
It's nice to see that someone finally ported the paradigm, not just the CLI
tools.
Eric Kidd
On Thu, Jul 08, 1999 at 04:49:20PM +0000, Michael T. Richter wrote:
> I'll dig around for that guide. And I'll live temporarily with the
> bash/gmake for the bootstrapping effort, although this will be one of my
> earliest targets for change. (The next will probably be a proper Win32
> installation program....)
Native installers are very important--we want people to try out Dylan, and
a native installer makes a good first impression. On Unix, we support
configure scripts, RPMs and FreeBSD ports, all of which are designed to
simplify the installation process for different groups of users. An
InstallShield installer would be an excellent solution for Windows.
As for getting rid of bash and GNU make, this could mean one of three
things:
1) Fixing Gwydion to work with POSIX sh (it may already) and POSIX make.
This is easy and a very high priority.
2) Fixing Gwydion to run a Windows C compiler without any Cygwin tools.
This is probably not a big project.
3) Fixing the Gwydion bootstrap process to get rid of all Unix-like tools.
This is an enormous and messy project. Fortunately, it only affects
maintainers.
My recommendation: install as many Cygwin tools as you need to do a Windows
build. You'll probably want to bootstrap off of the ancient 2.0 binaries
for Windows. This may involve a lot of hackery, pain, suffering, etc. I did
this for Linux over a year ago, but nobody has done it for Windows since
2.0. Along the way, you may fix small parts of (3).
Once you get a working, modern binary, you probably want to forget about
(3). Tackle something easy and obvious like (2) or (1), or make a nice
installer. Things will get much easier for a while. In any event, make sure
you have lots of RAM--128MB would be good for bootstrapping--and a lots of
free hard drive space.
Actually fixing (3) is a major project. The words "screaming
heebie-jeebies" come to mind for some reason. :-)
> > This will only change if somebody cares enough to change it. :-)
>
> That somebody may well be me. By the end of this month I'll be able to
> spare some cycles for the project. I may even have time to figure out
> the finicky CVS crap. :-)
Good! You are, of course, welcome to do whatever you want with the code
(that's the whole point). It would be wonderful, however, to meaningfully
coordinate between Windows and Unix versions of Gwydion.
Cheers,
Eric
(returning to lurker status for another few months...)
Tom Emerson
On Thu, 08 Jul 1999 16:46:57 GMT, "Michael T. Richter" <m...@ottawa.com> said:
> I've seen attempts to do this before. Typically the generated gmake
> files contain rules which assume features which either don't exist
> on all shells (especially non-UNIX ones) or which are very
> Unix-specific. Use of a bash for loop, for example, is quite
> common. Part and parcel of making a proper port that is comfortable
> to native users is to require the minimum amount of "alien" tools.
Yes, these are all good points, and I've been bitten by them several
times in the past when developing cross-platform build systems.
IMHO the use of alient tools isn't so much the issue as the user being
aware that they are using alien tools. Harlequin Dylan makes use of
the gnu linker, behind the scenes. It becomes an installation and
packaging issue at that point.
> And how do you propose to handle systems without command shells at
> all?
This is a general question for any compiler that has multiple passes,
isn't it? The overall driver can be written in another language,
methinks: essentially wrap the command-line tools (including the make
rules) up in a driver that calls through to the system to do the work,
a la Visual Studio.
Alternatively, one can design the system to not need the external step
at all: we have talked about making GD a front-end to GDB: then you
could have a single, huge, monolithic compiler.
However, you will still need to integrate the linker, so it doesn't
solve all of the problems.
Our first order of business is to get GD up-to-stuff with the DRM and
HD. Once we've accomplished that task I think we can attempt to tackle
these other issues.
My US$0.02 worth.
Michael T. Richter
> a native installer makes a good first impression.
Agreed. ZIP files (or, worse, TAR/GZIP files) just don't cut it in this day
and age.
> An InstallShield installer would be an excellent solution for Windows.
I may use Wise instead, but same difference in the end.
> As for getting rid of bash and GNU make, this could mean one of three
> things:
> 1) Fixing Gwydion to work with POSIX sh (it may already) and POSIX make.
> This is easy and a very high priority.
I don't want alien tools on my Windows box at all. This may be nice for
UNIX types, but it is a VERY low priority for me. :-)
> 2) Fixing Gwydion to run a Windows C compiler without any Cygwin tools.
> This is probably not a big project.
This is a necessary step if Gwydion is to be useful outside of the hobby
hacker environment. This will likely be my first real Gwydion project.
> 3) Fixing the Gwydion bootstrap process to get rid of all Unix-like
tools.
> This is an enormous and messy project. Fortunately, it only affects
> maintainers.
Do you really want to alienate potential maintainers, however? I generally
get coloured very unimpressed when I'm told "oh yeah, to make this product
you need to convert your workstation into a Unix workstation". I don't like
Unix. I never did like Unix. I likely never will like Unix given that the
things I dislike about it are considered strengths by Unix's fans. As such
I get turned off when facing what looks like a One True Way-ism.
> My recommendation: install as many Cygwin tools as you need to do a
Windows
> build. You'll probably want to bootstrap off of the ancient 2.0 binaries
> for Windows. This may involve a lot of hackery, pain, suffering, etc. I
did
> this for Linux over a year ago, but nobody has done it for Windows since
> 2.0. Along the way, you may fix small parts of (3).
I'll have to investigate this first.
> Once you get a working, modern binary, you probably want to forget about
> (3). Tackle something easy and obvious like (2) or (1), or make a nice
> installer. Things will get much easier for a while.
I don't really want to forget about (3) though. I'm not a big fan of the
exclusionary way many interesting languages are implemented. There are lots
of cool languages I'd be interested in learning and using -- but not
sufficiently interested to install the Unix blight on my system. I *know*
I'm not the only person who thinks that way. Most of my fellow development
team members here, for example, think this way -- even the guy who is our
Unix guy.
> In any event, make sure
> you have lots of RAM--128MB would be good for bootstrapping--and a lots of
> free hard drive space.
256MB and 20GB free space. I think I'll cope. :-)
> Actually fixing (3) is a major project. The words "screaming
> heebie-jeebies" come to mind for some reason. :-)
It is, nonetheless, an important step IMO.
> Good! You are, of course, welcome to do whatever you want with the code
> (that's the whole point). It would be wonderful, however, to meaningfully
> coordinate between Windows and Unix versions of Gwydion.
We'll talk again at the end of the month.
Eric Kidd
On Thu, Jul 08, 1999 at 05:51:11PM +0000, Michael T. Richter wrote:
> > 2) Fixing Gwydion to run a Windows C compiler without any Cygwin tools.
> > This is probably not a big project.
>
> This is a necessary step if Gwydion is to be useful outside of the hobby
> hacker environment. This will likely be my first real Gwydion project.
Good. It's the right size project to start with. You'll learn about some
compiler internals, but you won't have to go too deep.
> Do you really want to alienate potential maintainers, however? I generally
> get coloured very unimpressed when I'm told "oh yeah, to make this product
> you need to convert your workstation into a Unix workstation". I don't like
> Unix. I never did like Unix. I likely never will like Unix given that the
> things I dislike about it are considered strengths by Unix's fans. As such
> I get turned off when facing what looks like a One True Way-ism.
You can make it work any way you want, of course. :-) I'm just cautioning
you: the build system isn't a strictly declarative system with a pretty
driver. It contains lots of code, complicated tests and some nasty
re-orderings. It handles cross compilation, two kinds of bootstrapping and
several other miscellaneous build scenarios. You could simplify things a
bit in the Windows version, of course. Most of the build system is handled
using Perl and GNU make. Configuration of build parameters is done with GNU
autoconf (on Unix) or by a standard config template (on Windows).
If you can rationalize this whole system, you'll earn everybody's eternal
adoration and gratitude. But approach this problem with caution: here there
be dragons. Eternal gratitude isn't bought cheaply. :-)
> > My recommendation: install as many Cygwin tools as you need to do a
> > Windows build. You'll probably want to bootstrap off of the ancient 2.0
> > binaries for Windows. This may involve a lot of hackery, pain,
> > suffering, etc. I did this for Linux over a year ago, but nobody has
> > done it for Windows since 2.0. Along the way, you may fix small parts
> > of (3).
>
> I'll have to investigate this first.
First step: find a binary of GD 2.0 for Windows. Get it working again. Once
you can build 2.0 from source, port your changes forward, dig out the
bit-rot in the Windows build system and compile 2.3 by any means necessary.
Once you can compile a reasonably clean copy of 2.3 with itself, you're
home free.
Trust me, here--the more your Windows box looks like a Unix system, the
less time you'll spend swearing a blue streak. You can change all this
later, but you've got to start somewhere.
Good luck! The gd-hackers list stands ready to answer your questions and
provide a little moral support.
Cheers,
Eric
Peter S. Housel
Eric Kidd <eric...@pobox.com> wrote:
> First step: find a binary of GD 2.0 for Windows. Get it working again.
Once
> you can build 2.0 from source, port your changes forward, dig out the
> bit-rot in the Windows build system and compile 2.3 by any means
necessary.
> Once you can compile a reasonably clean copy of 2.3 with itself, you're
> home free.
That would involve a lot of wasted work, especially with the table-protocol
change in 2.1.x. Instead, a better way would be to bootstrap parsergen and
d2c using Harlequin Dylan, changing all of our non-portable constructs to
work with common-dylan and portable runtime libraries. This is something we
want to be able to do, so the work would have lasting value. And the
bootstrapping environment appeals much more to the sensibilities of a
unix-hater.
Once that's done, d2c/compiler/main could be changed to run C compiler
passes without gmake. If you don't need to support mindy or automatic
bootstrapping, you could ditch the Makegens and get by with a more static
build system. At which point you're most of the way to where you want to
be.
Wait until the C-heap stuff gets merged back into the main tree. It should
be there by the end of the month.
Cheers,
-Peter-
Andreas Bogk
> I agree that a Windows port of Gwydion should not ultimately rely on the
> cygwin tools, and should be a self extracting InstallShield loaded true
> blue Windows program, but I bet it will be some time before it reaches
> that state. If you want to get it there, you'll probably have to gain
> some familiarity with Unix tools.
Don't get the wrong impression here, while building Gwydion Dylan
itself requires the Cygwin tools, merely using a pre-compiled Gwydion
Dylan doesn't. All you need is either Visual C++ oder gcc.
Chris Double
> My recommendation: install as many Cygwin tools as you need to do a
> Windows build. You'll probably want to bootstrap off of the ancient
> 2.0 binaries for Windows. This may involve a lot of hackery, pain,
> suffering, etc. I did this for Linux over a year ago, but nobody has
> done it for Windows since 2.0. Along the way, you may fix small
> parts of (3).
I spent a couple of days about a month back getting GD to compile
using the Cygwin beta 20 tools. The autoconf and various other things
worked fine and mindy built after a few tweaks to platforms.descr. I
had a few problems with CR/LF translations though. The compiled byte
code was having the CR/LF translated resulted in it not interpreting
correctly.
Once I worked around that Mindy ran without problems. I did have
problems compiling D2C though - I forget what they were as I ran out
of spare time. I was working on the latest build out of CVS at the
time so I wouldn't anticipate too many problems doing a bootstrap
starting from the latest code. I kept all the stuff I had to modify to
get Mindy to build on the off chance I could revisit it some day.
If you are using Cygnus B20 to do it you'll need cygwin versions of
perl and autoconf BTW. I also used WinCVS - nice tool that.
How about bootstrapping D2C using Harlequin Dylan? What effort would
be involved in doing that? I do see a few '#if' type constructs in
parts of the code to deal with differences between Mindy and D2C -
that could be a problem. Any thoughts on how to work around that?
Chris.
Chris Double
> Instead, a better way would be to bootstrap parsergen and
> d2c using Harlequin Dylan, changing all of our non-portable constructs to
> work with common-dylan and portable runtime libraries.
I've been playing around with this and got parsergen and associated
libraries from GD 2.3.1 built and working with Harlequin Dylan 2.0
beta 2. It processes the parser.input file from d2c without a problem
at least.
The changes required weren't great, mainly removing the '#if'
code and moving things to common-dylan, etc. There were a few other
things like <false>, <true> and such that exist in GD but not in HD (I
think - couldn't see any mention of them in HD). I created a wrapper
library to put these in for HD.
The big job will be d2c though...
Chris.
Eugene Zaikonnikov
space their remote agent software based on LispWorks, should they test it
now with another system? It must be terribly expensive...
--
Eugene
Tim Bradshaw
They may well have escrow agreements I expect, big organisations often do.
--tim
Chuck Fry
Eugene Zaikonnikov <vik...@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
chu...@chucko.com (text only please) chuc...@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.
Jeff Dalton
Michael T. Richter wrote:
> I don't like
> Unix. I never did like Unix. I likely never will like Unix given that the
> things I dislike about it are considered strengths by Unix's fans. As such
> I get turned off when facing what looks like a One True Way-ism.
Come on. Just because someone thinks something's a strength doesn't
mean they think it's the One True Way.
So far as I can tell, One True Way-ism is, if anything, far more
prevalent among Mac and Wintel fans than in the Unix world, and
most of the things said by Unix folk that may sound like One True
Way-ism are primarily reactions to the endless sniping from those
other camps.
> There are lots
> of cool languages I'd be interested in learning and using -- but not
> sufficiently interested to install the Unix blight on my system. I *know*
> I'm not the only person who thinks that way. Most of my fellow development
> team members here, for example, think this way -- even the guy who is our
> Unix guy.
Really? The "Unix guy" wouldn't want to install "the Unix blight"
on his system? What kind of "Unix guy" is that?
In any case, I hope Gwydion continues to be availale in a reasonably
Unix-friendly form, even if it's packaged in some different way for
Windows or Macs.
-- jd
Michael T. Richter
news:comp.lang.dylan.19...@todday.aiai.ed.ac.uk...
>> There are lots
>> of cool languages I'd be interested in learning and using -- but not
>> sufficiently interested to install the Unix blight on my system. I
*know*
>> I'm not the only person who thinks that way. Most of my fellow
development
>> team members here, for example, think this way -- even the guy who is our
>> Unix guy.
> Really? The "Unix guy" wouldn't want to install "the Unix blight"
> on his system? What kind of "Unix guy" is that?
One who feels no need to inflict Unix on himself at home just because it is
inflicted upon him at work. (I was probably unclear as to the point that he
didn't want to install Unix on his *home* system.)
> In any case, I hope Gwydion continues to be availale in a reasonably
> Unix-friendly form, even if it's packaged in some different way for
> Windows or Macs.
I have no difficulties with making software friendly across all supported
platforms. Indeed that's what I do for a living right now. As one of the
architects of a large internal library I strive to ensure that library feels
natural to Win32 weenies as well as to Unix weenies. This ranges from not
using compiler features that aren't supported across all platforms (Unix C++
compilers really suck at tracking standards!) to using flexible abstractions
to allow access to powerful, but platform-specific, features on all
platforms to ensuring that packaging works in a fashion which feels native
to all end-users.
My objection is to the plethora of software out there which is built under
the theory that "cross-platform" means converting all other platforms to
Unix.
Eric Kidd
On Fri, Jul 09, 1999 at 05:57:34PM +0000, Michael T. Richter wrote:
> (Unix C++ compilers really suck at tracking standards!)
As a bit of friendly advice: I seriously recommend using the most recent
EGCS release on as many platforms as possible. Vendor C++ compilers are
evil, and should be avoided whenever possible.
All the Linux vendors have been migrating to EGCS over the past year, and
they've been seeing good results. EGCS is essentially GCC 3, and has been
officially approved by the Free Software Foundation.
Cheers,
Eric
Eric Kidd
On Fri, Jul 09, 1999 at 07:28:56PM +1200, Chris Double wrote:
> The changes required weren't great, mainly removing the '#if' code and
> moving things to common-dylan, etc. There were a few other things like
> <false>, <true> and such that exist in GD but not in HD (I think -
> couldn't see any mention of them in HD). I created a wrapper library to
> put these in for HD.
Whenever you see 'type-union(<false>, foo)', change it to 'false-or(foo)'.
The <true> and <false> types are obsolete and deprecated.
Cheers,
Eric
Jeff Dubrule
On Fri, Jul 09, 1999 at 05:57:34PM +0000, Michael T. Richter wrote:
> (Unix C++ compilers really suck at tracking standards!)
From my experience with non-UNIX systems, this is by no means a
UNIX-specific problem...
Perhaps it's merely because the notion of building a program with two
different compilers is a fairly ridiculous proposition under Windows/Mac...
-igor
Tom Emerson
On Fri, 9 Jul 1999 14:50:59 -0400, Eric Kidd <eric...@pobox.com> said:
> As a bit of friendly advice: I seriously recommend using the most
> recent EGCS release on as many platforms as possible. Vendor C++
> compilers are evil, and should be avoided whenever possible.
Sun Workshop C++ 5.x is actually pretty decent: they finally support
standard language features like bool. The code generation of vendor
compilers is often better than gcc as well, especially on some of the
stranger architectures (note that I did not say egcs: I haven't
compared the egcs code gen on sparc and PowerPC to that of Sun's and
IBM's compilers, respectively).
If you work at a company that provides source code libraries to others
then standardizing on egcs isn't necessarily an option since one
cannot force customers to change compilers.
Here at Basis our Rosette library (http://rosette.basistech.com/) is
written in C++, making heavy use of templates and exception handling,
and builds on a variety of Unixen (including AIX, Solaris, DUX
(OSF-1), HPUX, and Linux) as well as Visual C++ 5 and 6, CodeWarrior
on MacOS, and OS/360. The number of work-arounds we've had to go
through to make this work on all these platforms has been surprisingly
small. I finally convinced our CTO to let us switch from vendor makes
to GNU Make: IMHO vendor makes universally suck. 8-)
With all that said, I think egcs and the GNU tool chain is superior to
any vendor toolsuite, hands down. Sometimes one just doesn't have the
option of using the best tools. It is possible to write code that
makes use of advanced language features and is still portable across a
wide range of machines.
Yiorgos Adamopoulos
>My objection is to the plethora of software out there which is built under
>the theory that "cross-platform" means converting all other platforms to
>Unix.
You mean POSIX. It just so happens that Un!x systems are more POSIX than other
systems. There is no such thing today as a ``one true un!x system'' that
everybody uses (I happen to use FreeBSD, Free UnixWare, Solaris) and they are
different between them.
--
ad...@c64.org
KIEp lwWulm ECsEIt0 m9 CPEc B-x Ou LbM Sc++++++++++ T+ A4 H6o b2 D0
Michael T. Richter
At 03:19 PM 7/9/99 , Tom Emerson wrote:
>If you work at a company that provides source code libraries to others
>then standardizing on egcs isn't necessarily an option since one
>cannot force customers to change compilers.
That's the problem we face here.
>Here at Basis our Rosette library (http://rosette.basistech.com/) is
>written in C++, making heavy use of templates and exception handling,
>and builds on a variety of Unixen (including AIX, Solaris, DUX
>(OSF-1), HPUX, and Linux) as well as Visual C++ 5 and 6, CodeWarrior
>on MacOS, and OS/360. The number of work-arounds we've had to go
>through to make this work on all these platforms has been surprisingly
>small. I finally convinced our CTO to let us switch from vendor makes
>to GNU Make: IMHO vendor makes universally suck. 8-)
Namespace support is mostly non-existent on vendor compilers it seems.
This is too bad since we're trying to make a componentized C++ library;
something just SCREAMING for namespaces.
>It is possible to write code that
>makes use of advanced language features and is still portable across a
>wide range of machines.
Possible, but certainly not pretty. I really wish that the camp that
always screams about how standards are the most important thing in the
known universe (including, but not limited to, world hunger) would actually
TRACK the <expletive deleted> C++ standard for a change!
I get very scared when the most standards-compliant compiler of the ones we
have to support is Microsoft's....
Bruce Hoult
m...@igs.net wrote:
> I get very scared when the most standards-compliant compiler of the ones we
> have to support is Microsoft's....
Strange. CodeWarrior was more C++ standard compliant than VC++, last time
I looked, and it's available nearly everywhere (Mac, Windows, Solaris,
Linux probably covers 99% of machines).
-- Bruce
David Combs
Peter Van Eynde <pvan...@inthan.be> wrote:
>On Wed, 07 Jul 1999 10:40:06 GMT, BPer...@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"?
Michael T. Richter
news:bruce-10079...@bruce.bgh...
>> I get very scared when the most standards-compliant compiler of the ones
we
>> have to support is Microsoft's....
> Strange. CodeWarrior was more C++ standard compliant than VC++, last time
> I looked, and it's available nearly everywhere (Mac, Windows, Solaris,
> Linux probably covers 99% of machines).
Did you miss the "of the ones we have to support" portion?
Peter Van Eynde
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. | pvan...@debian.org for pleasure,
"God, root, what is difference?" - Pitr| pvan...@inthan.be for more pleasure!
"God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd
Jeff Dalton
> Jeff Dalton <je...@aiai.ed.ac.uk> wrote in message
> news:comp.lang.dylan.19...@todday.aiai.ed.ac.uk...
> >> There are lots
> >> of cool languages I'd be interested in learning and using -- but not
> >> sufficiently interested to install the Unix blight on my system. I
> *know*
> >> I'm not the only person who thinks that way. Most of my fellow
> development
> >> team members here, for example, think this way -- even the guy who is our
> >> Unix guy.
>
> > Really? The "Unix guy" wouldn't want to install "the Unix blight"
> > on his system? What kind of "Unix guy" is that?
>
> One who feels no need to inflict Unix on himself at home just because it is
> inflicted upon him at work. (I was probably unclear as to the point that he
> didn't want to install Unix on his *home* system.)
I'd still say "What kind of `Unix guy' is that?". You said "even
... our Unix guy". Well, it's not very interesting that a "Unix
guy" who doesn't like Unix, doesn't like Unix; so why the "even"?
> My objection is to the plethora of software out there which is built under
> the theory that "cross-platform" means converting all other platforms to
> Unix.
I do not believe anyone has any such theory about what
"cross-platform" means.
There is, of course, software that that's Unix based and made
available for other platforms in ways that are awkward for
those platforms. But a number of developers are working in
Unix, and often, given time and other constraints, that's the
best that they can reasonably do.
There's also a great deal of software that's for Windows that
they does not work at all under Unix. (At best, some kind of
emulator might be able to handle it -- way of converting the
other platform to Windows.)
In fact, there seems to be more of that software than the other
kind. Moreover, I suspect that making software feel natural
on both Unix and Windows will very often mean making it rather
Windows-like. I am not trying to suggest that *you* will fail
to make software feel equally natural on both platforms -- I
just suspect that often it won't be.
(BTW, re the unnamed Unix C++ compilers that suck at tracking
standards, do you not see the irony of that, coming from the
Windows side?)
A move to make a Unix-based Dylan more Windows-friendly is likely,
I fear, to make it much worse from my point of view.
-- jd
Brian Rogoff
> > Jeff Dalton <je...@aiai.ed.ac.uk> wrote in message
> > news:comp.lang.dylan.19...@todday.aiai.ed.ac.uk...
> > >> There are lots
> > >> of cool languages I'd be interested in learning and using -- but not
> > >> sufficiently interested to install the Unix blight on my system. I
> > *know*
> > >> I'm not the only person who thinks that way. Most of my fellow
> > development
> > >> team members here, for example, think this way -- even the guy who is our
> > >> Unix guy.
> >
> > > Really? The "Unix guy" wouldn't want to install "the Unix blight"
> > > on his system? What kind of "Unix guy" is that?
> >
> > One who feels no need to inflict Unix on himself at home just because it is
> > inflicted upon him at work. (I was probably unclear as to the point that he
> > didn't want to install Unix on his *home* system.)
>
> I'd still say "What kind of `Unix guy' is that?". You said "even
> ... our Unix guy". Well, it's not very interesting that a "Unix
> guy" who doesn't like Unix, doesn't like Unix; so why the "even"?
Yes, I read your comment that way too, and was surprised by Michael's odd
definition of "Unix guy". FWIW, I'll do either.
> > My objection is to the plethora of software out there which is built under
> > the theory that "cross-platform" means converting all other platforms to
> > Unix.
>
> I do not believe anyone has any such theory about what
> "cross-platform" means.
>
> There is, of course, software that that's Unix based and made
> available for other platforms in ways that are awkward for
> those platforms. But a number of developers are working in
> Unix, and often, given time and other constraints, that's the
> best that they can reasonably do.
>
> There's also a great deal of software that's for Windows that
> they does not work at all under Unix. (At best, some kind of
> emulator might be able to handle it -- way of converting the
> other platform to Windows.)
>
> In fact, there seems to be more of that software than the other
> kind. Moreover, I suspect that making software feel natural
> on both Unix and Windows will very often mean making it rather
> Windows-like. I am not trying to suggest that *you* will fail
> to make software feel equally natural on both platforms -- I
> just suspect that often it won't be.
There are several examples of open source development environments
that work OK on Windows and Unix, for varying values of "OK". My short
list includes Python, Icon, Erlang, Objective Caml, and GNAT Ada 95.
Making the build process feel natural is trickier. If you are willing
to limit your options on Unix, and rely solely on Makefiles and a C
compiler, you can create Makefile.{nt, 98} variants which work fine on
Windows. I'd even think this was a good thing if the removed Unix
utilities were replaced by Dylan code in the build process, so that an
early step would build a subset of Dylan interpreter, which is then used
in the later steps as a scripting language and as the language of the
compiler itself.
-- Brian
Eric Kidd
On Mon, Jul 12, 1999 at 06:18:27PM +0100, Jeff Dalton wrote:
> A move to make a Unix-based Dylan more Windows-friendly is likely,
> I fear, to make it much worse from my point of view.
If I were you, I wouldn't worry too much. Gwydion Dylan isn't really a Unix
or a Windows program--it lives in an esoteric and pleasant universe of
modular Dylan, and the Unix support is little more than a build system,
some configuration files and a few subclasses.
Ideally, Gwydion Dylan would run well on any platform that people want to
use it on, no matter how weird.
How do you feel about Python's cross-platform support, by the way?
Cheers,
Eric
Thomas A. Russ
> 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 t...@isi.edu
David Combs
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 <slrn7ok0oi....@mail.inthan.be>,
Peter Van Eynde
>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.
lvi...@cas.org
:Michael T. Richter wrote:
:> things I dislike about it are considered strengths by Unix's fans. As such
:> I get turned off when facing what looks like a One True Way-ism.
I would love to see a machine which doesn't promote "One True Way"ism.
Macs - definitely OTW
Windows - whoa - MS is in COURT over OTW
Unix - you've called it OTW
AppleDOS, CP/M, DOS, IBM MVS, AS/xxx, TRS dos, AmigaDOS, BeOS, NextStep, ....
They all do their best to force a OTW viewpoint on people.
In fact, I've had better luck on Solaris than any other OS to get away from
OTW. For instance, Java appeared there first - write once, run many places.
MAE - a Mac Application Emulator - allowed me (for a while) to run Mac
apps under Solaris. A variety of Windows emulators allowed me to run
those. Linux emulators allow me to run Linux on Solaris. Then there are
the AppleDOS/Nintendo 64/GameBoy/.../PalmOS emulators for small or older
machines.
--
<URL: mailto:lvi...@cas.org> Quote: Saving the world before bedtime.
<*> O- <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
lvi...@cas.org
:On Fri, Jul 09, 1999 at 05:57:34PM +0000, Michael T. Richter wrote:
:> (Unix C++ compilers really suck at tracking standards!)
Sounds like the problems that I hear being screamed about down the hall
from the Windows and Mac developers - apparently THOSE compilers also
'take liberties' with the 'standards', implementing neat little 'features'
that end up breaking all sorts of things...
The bottom line is that most compilers that I have seen suck in one way or
another - regardless of platform or vendor. Of course, I've never worked
for anyone who has valued code development high enough to actually go to
a company whose entire business consisted of _nothing_ but compilers - perhaps
things differ with those products.
lvi...@cas.org
According to Tom Emerson <tr...@tiac.net>:
:Sun Workshop C++ 5.x is actually pretty decent: they finally support
Of course, there are some interesting side effects of the new Sun C++ compiler.
People may find they need to make some changes to their code or headers if
they wrapped any system headers with extern "C" { } wrappings. The latest
compiler comes with C++ compatible headers - resulting in syntax errors
if the application attempted to 'do what was necessary' ...
Dave Berry
Michael T. Richter <m...@ottawa.com> wrote:
>Tom Emerson <tr...@tiac.net> wrote in message
>> You will need to use GNU Make to get things bootstrapped.
>
>I'd like to change that in the future, but I can live with it for now to
>bootstrap myself into position.
You might want to look at JAM. Some parts of Harlequin were moving to
this, because it works well on both Unix and Windows (or so I was told).
I was going to look into using it in the Tools group, but now I'm looking
for new employers instead :-(.
Dave.
Jay Krell
Isn't
extern "C"
{
extern "C"
{
int printf(const char* ...);
}
}
legal? Visual C++ 5 and 6 and gcc accept it. Or did Sun actually provide the
C library with C++ linkage? That would be nice..but not necessarily be a
problem (as long as it is available both ways).
- Jay