In article <MARCUS.95Aug15151...@sayre.sysc.pdx.edu> mar...@sysc.pdx.edu "Marcus Daniels" writes:
> Second of all, many Unix compilers *can* handle these macros. The few > places GCC extensions are used in CLISP, it is only done if the > feature is available.
Sadly, I don't use Unix, and so I can't use it to cross compiler for Windows.
> Thirdly, and most importantly, there are already programs that process > CLISP source code before it is compiled. It is a simple matter to add > another, namely GNU cpp. GNU cpp is already in the distribution. > Stop fixating on ANSI C. It is ".d"! Get over it!
The C compiler I use was unable to link the GNU preprocessor as a DOSX binary, and the DOS binary ran out of memory. Obviously I was using the wrong compiler, but I was unable to change that. These days it's just too late.
> What has become clear to me is that these individuals are not content to > investigate these simple alternatives for themselves. They do not > understand the nature of free software (or care), and would much rather > whine and spread misinformation.
I'm well aware of the alternatives. Please note that I'm keen to stress that my problems were due to the bugs and limitations of the _commercial C compiler_ that I was using. I'm now using a "fixed" version, and it still has the ## bug that stopped it reading one of the CLISP headers (guess which one).
GNU C has many advantages over the compiler I use for Win32 development, but I'm far more familiar with GNU C, and until Bruno Haible emailed me to let me know that he was porting CLISP himself, I had no idea that it could be used to produce Win32 binaries.
I should add that I received excellent help from Bruno, and my failure to port CLISP was not due to any lack of support from him. In fact, I was very impressed when he mailed the source code to me on floppies, and even more impressed when I _saw_ the source code.
> Ultimately, it isn't about "loss of efficiency", it is about raping the > code without considering perfectly workable alternatives.
I'm not sure what this means, or what it refers to. I didn't find any workable alternatives, and I was certainly motivated to look for them. I also had the time, last year.
In article <412f9a$...@xenon.bt-sys.bt.co.uk> simon.beaum...@bt-sys.bt.co.uk "Simon Beaumont" writes:
> It ain't exactly expensive either... I get the message that you want > a highly sophisticated common lisp development environment fully > supported by a top notch dedicated development team with unlimited > funding stretching way out into the next millenium for FREE!
Not so. Any Common Lisp (even a subset) for Windows, with an FFI and support for callbacks, will suit me. The last version of XLISP that I looked at came close, since it was available as a Win16 binary. However, it had less support for Windows than an OS/2 version of XLISP from a few years earlier. I'll have to look for the latest version of XLISP again, as it well have been updated.
If I'm looking for a Lisp as alternative to C++, then it'll have to produce stand alone binaries, just like a C/C++ compiler. I'd love to program more in Lisp, but sadly, no Common Lisp or subset that I've seen - so far - has been capable of writing Windows apps.
Allegro CL for Windows is a different matter.
> Really how much are you prepared to pay for such a product?
Personally? No more than for a C++ compiler system for Windows. Professionally, I could get someone else to pay for it. Of course, nobody has done this yet.
> What features/facilites would you consider essential?
The option to produce stand alone Win16 or Win32 binaries, so that a user can install (via a typical installer used in almost all Windows apps these days) and run the code without the development enviroment, or knowing - or even caring - which language it was written in.
Support for calling functions in DLLs, via an FFI. Callback support, so that other modules can call Lisp functions, e.g. for enumerating fonts etc.
> Which platforms must it support?
Win16 or Win32. Ideally both, tho not necessarily in the same package. Allegro CL for Windows and Windows NT is a good example, tho buying both versions could be very expensive. If the Win32 version costs the same as the Win16 version, then Allegro CL would be approx 6 times the cost of SC++ (Win16 and Win32 support in one package), or approx 3 times the cost of VC++ (Win16 and Win32 support in two packages).
> How many copies will you buy?
Just one. Ideally, the runtime should be royalty free, and I believe that Allegro CL for Windows is such a product. It's extemely unlikely that I'll be sharing any Lisp development with another programmer, but if that were necessary, then it would be someone else's problem, not mine. Nobody is demanding that I should code in Lisp, not even me. I can only recommend it as a language that I'm familiar and _productive_ with.
> If you can answer these questions realistically I guess the industry > could come up with an answer. Under the definition of free market > economics it already has.
Well, one answer is Allegro CL for Windows. I'll be interested in any alternatives, but as I've no details, never mind reviews, I can't comment on them.
> It really depends on how serious you are, I started out playing > with freeware lisp at home on a vaxstation saved from the crusher.
I have a DOS machine. It can only just run Windows. I can use a number of freeware Lisps, and that's exactly what I've been doing for the last few years. What I can't do is convince anyone that they can be used for Windows development.
> Things are better now and I got to this nirvana by putting my money, > time and career where my mouth was and investing in something > that I believed in. I don't have the gift of direct funding but I use > my rentability, reputation and anything else (duress, screaming > and shouting, foaming at the mouth) to get the message over to > the money people, and make damn sure I deliver if they give me > a shot. In my experience people (managers are people too) are > more impressed by results than rhetoric. Drum up the support/cash to > obtain a single copy of your favourite environment then blow their > socks off with the amazing way you can turn out shit hot applications.
My money is currently going towards a new machine. Then I may have chance of running some of the current development systems, whatever the language may be. Please note that I'm unemployed, which means that most of my money goes on basic necessities.
The costs of development software make me very conservative, just like all the potential employers I find. What they want is C++ developent for Windows. What I'm expected to do is look for work that I'm likely to get, not stuff that is in very little demand. Fortunately, nobody is asking what I'm spending my money on, so all I need is the money...
> Convince others... spread the word... then lean on the poor old > vendors. The only currency that researchers and engineers can > use is hard cash so get it flowing their way and you may have > some influence on what they do with it. It gets harder and harder > for individuals to influence shit these days so now is a good > time (17:30pm on a friday may be stretching my metaphor a tad here > :-) - Good luck.
That's what I'm doing. Of course, most people see no reason to listen to me - they're often too busy arguing over the petty differences between C and Pascal to worry about the advantages of Lisp. For some programmers, it's a religious issue. I get odd looks when I mention Lisp, a little like the looks I got whenever I mentioned MIDI and Windows in the same breath, 5 years ago. Those looks said, "You're crazy!"
Well, so what if I'm a little crazy? I'm using Lisp coz _I can_. What I'm not yet able to do is write Windows apps in Lisp, but in theory (using, say, Allegro CL), I can. The difficulty is of a financial, not a technical, nature.
Meanwhile, I have an idea which I'm using to convince someone that I should use Lisp, as I can use it to implement the software. Perhaps _he'll_ pay for the hardware and software I need... Obviously, we both crazy, but the idea is a good one, and if I get to work on it, it'll someday be possible to say, "Look, here's something done in Lisp, and it works, and more importantly, it works better than the alternative, written by MS in C/C++." -- <URL:http://www.demon.co.uk/community/index.html> <URL:http://www.enrapture.com/cybes/namaste.html> "You can never browse enough."
#>I have been following this thread and I have not yet read which is the #>compiler that does not compile large pieces of code. I want to ask: #> #>1 - what is the compiler (supposedly commercial) which cannot compile #> CLISP and
32 bit Microsoft and WATCOM compilers (I wouldn't even try Borland or Symantic). Keep in mind that these compilers are used by thousands and thousands (millions?) of programmers. They are also used to compile Windows 3.1, Windows NT and thousands (millions?) of applications. I think it is somewhat nieve to call these compilers "brain dead" just because they don't have boundless limitations.
#>2 - does this compiler comply with the published C standards (whatever #> they are)?
Yes. As previously posted, the standards do not allow for arbitrarly large modules (or missing argument macros).
| 32 bit Microsoft and WATCOM compilers (I wouldn't even try Borland or | Symantic).
why wouldn't you "even try" Borland or Symantec (note spelling)?
| Keep in mind that these compilers are used by thousands and thousands | (millions?) of programmers.
a huge number of users do not make anything non-brain-dead, unless you wish to say something about those millions at the same time, in which case it is more likely that something used by millions of _amateurs_ _is_ brain-dead.
which is the brain-dead video tape format: VHS or Betamax? which is used by professionals, and which by millions of casual users?
| They are also used to compile Windows 3.1, Windows NT
now, if true, this would be very interesting. please provide references!
| I think it is somewhat nieve to call these compilers "brain dead" just | because they don't have boundless limitations.
if you mean "naive", then no. from _experience_ and sophistication comes the realization that arbitrary limits is very bad for you and your users. in case you didn't know, "naive" and "experienced" or "sophisticated" are as close as you get to antonyms. it is precisely _naivite_ that invite the unwashed masses to write code with arbitrary limits. just because the unwashed masses outnumber the professionals doesn't mean they're right. in fact, quite the opposite is true in the general case.
| Yes. As previously posted, the standards do not allow for arbitrarly | large modules (or missing argument macros).
look, just because you can't read standards doesn't make them mean what you want them to mean. of _course_ standards "allow for" arbitrarily large anything. what standards do, is to avoid _requiring_ arbitrarily large objects or numbers of things, but instead _require_ that no implementation impose a maximum smaller than some specific limit. the "minixum maximum" rule has two goals: (1) discourage boneheads from implementing standards, and (2) ensure the maximal portability of programs within those limits. in no way does the "minimum maximum" requirements mean that compilers or programs that exceed them are non-conforming.
I can't believe you have managed to lead people on for so long. you're obviously clueless and uncurably so. if you wish to make a shot at changing this impression, make up your mind that you have posted your last guess and that you will make all the effort that is required to ensure that you will never again post wrong information. above all, do not lie.
CS> The C compiler I use was unable to link the GNU preprocessor as a CS> DOSX binary, and the DOS binary ran out of memory. Obviously I was CS> using the wrong compiler, but I was unable to change that. These CS> days it's just too late.
GNU cpp binaries are everywhere, and have been for several years. oak.oakland.edu, for example.
me> Ultimately, it isn't about "loss of efficiency", it is about raping me> the code without considering perfectly workable alternatives.
CS> I'm not sure what this means, or what it refers to.
It only refers to the misguided goal of removing empty macro usages.
CS> I didn't any workable alternatives, and I was certainly motivated to look CS> for them. I also had the time, last year.
It never occured to you to try preprocessing with a EMX or DJGPP GCC? Interesting.
Oh and BTW, the MSWindows work that was done on CLISP was released; it is in the source tree.
Cyber Surfer, you could help me get a win32 binary release out in a timely fashion! If you could provide me with the following information:
1. How do file maps work on win32? Like many people I cannot afford to buy technical manuals for five minutes of use. I understand that WinNT/Windows95 has a tiered division of virtual memory. I heard that filemaps go in the same region as DLLs. What is the maximum VM space I can get my hands on? Code samples would be useful. I'm discouraged to see that mallocs start at 0x20000000. If there is a kernel VM ring, that would basically nukes an ideal singlemap configuration, even for NT.
2. How can I check for available data on a file descriptor? I see no "select" or FIONREAD ioctls. The only thing close I see is a win32 "console" peek. I assume this means only keyboard events. Ideas?
3. Is it realistic to have a single win32 binary. Or are there too many tradeoffs? For example: 8+3 filenames or long filenames. NT private maps vs global '95 maps.
In article <8768jt5dpj....@hrothgar.mindspring.com> rsand...@mindspring.com "Robert Sanders" writes:
> Is it not worth more to you? I would personally find a good CL > development environment much more useful than a C++ environment, and > would be willing to pay a difference commensurate with that increase > in value. Of course, I also understand that I can't pay C++-like > commodity prices for what is, sadly, a niche product.
I agree that a good CL would be more useful than a C++ system. However, I can't use that argument to pay for a CL system. I need the money, and I don't have it. If I don't have it, then I may have to pursuade someone else to pay for it, and that's not as easy as it would be for a C++ system. That's my point.
If it were possible for my to use CL, then I'd be using it. If it becomes possible to use it in the future, then I will. However, it's incredibly easy to get hold of a C++ system, and even easier to justify it. I'm in the position where I have to justify using Lisp, so a $1000 price tag doesn't help.
I'm sure there are many other programmers with the same difficulty. The problem could be summed up like this: never mind what it may be worth _to me_, what counts is what it's worth to an employer. So far, I've found very few employers who are interested in Lisp, and most of them are on the other side of the Atlantic from me. I'm not knocking Lisp (CL, Scheme, whatever), as I love it, but if I want someone to pay me to use it, I may be disappointed. -- <URL:http://www.demon.co.uk/community/index.html> <URL:http://www.enrapture.com/cybes/namaste.html> "You can never browse enough."
In article <MARCUS.95Aug19063...@sayre.sysc.pdx.edu> mar...@sysc.pdx.edu "Marcus Daniels" writes:
> GCC is hosted on win32; no need for Unix.
NT? I can't currently use NT, either. I use Win32s. If GCC is hosted by Win32s, then that may be ok, but I have some doubts, mainly coz the Win16 platform does not support command line tools very well (or all?).
Even if I were to switch to NT now, it would be too late for me to port CLISP to Win32.
> GNU cpp binaries are everywhere, and have been for several years. > oak.oakland.edu, for example.
True, and I had GNU C when I asked Bruno Haible about porting CLISP. However, I had no idea that it was possible to use it to produce Win32 binaries. I had (and still have) no interest in creating a DOS binary of CLISP, as that exists already.
> CS> I didn't any workable alternatives, and I was certainly motivated to look > CS> for them. I also had the time, last year.
> It never occured to you to try preprocessing with a EMX or DJGPP GCC? > Interesting.
As I've explained already, I tried that. It _failed_. The DOSX binary of the preprocessor failed, and I've no idea why. ISTR there may have been a link problem. The 16bit DOS binary also failed, coz it ran out of memory.
> Oh and BTW, the MSWindows work that was done on CLISP was released; it is > in the source tree.
Really? When I asked recently Bruno how the Win32 port was doing, he didn't mention this.
> Cyber Surfer, you could help me get a win32 binary > release out in a timely fashion! If you could provide me with the > following information:
Only if I had the time, which I no longer have. I'm too busy doing Win16 development - in C. This frustrates me, as you might imagine!
> 1. How do file maps work on win32? Like many people I cannot afford > to buy technical manuals for five minutes of use. I understand > that WinNT/Windows95 has a tiered division of virtual > memory. I heard that filemaps go in the same region as DLLs.
File mapping? That's an NT/Win95 feature. As I understand it, NT maps code into memory. I'm not too familier with it, as all my Win32 development is done with Win32s, which is a subsystem for Win16 that allows it to run Win32 software usign a subset of the full Win32 API. File mapping is not supported.
> What is the maximum VM space I can get my hands on? Code samples > would be useful. I'm discouraged to see that mallocs start > at 0x20000000. If there is a kernel VM ring, that would basically > nukes an ideal singlemap configuration, even for NT.
As I've said, I don't use NT. I have no docs for that kind of info.
> 2. How can I check for available data on a file descriptor? > I see no "select" or FIONREAD ioctls. The only thing > close I see is a win32 "console" peek. I assume this > means only keyboard events. Ideas?
See above. The console API is not supported under Win32s, as Win16 works very differently. MS appear to have assumed that no command line apps will be needed for 16bit Windows.
> 3. Is it realistic to have a single win32 binary. Or are > there too many tradeoffs? For example: 8+3 filenames or long filenames. > NT private maps vs global '95 maps.
There are a lot of tradeoffs. You lose most of the really tasty Win32 featues if you use Win32s. However, this shouldn't be a problem for CLISP, unless it needs file mapping, threads, pipes, etc. One solution might be to produce Win32 and Win32s versions, but that could create more problems. It's certainly more work, which could be why some developers don't bother doing it that way. I've no idea if it would be useful, necessary, or even worth the trouble.
Of course, if CLISP can use features such as pipes, then supporting them would certainly be worth the effort! It could be done in such a way that if CLISP were run under Win32s, where pipes are unavailable, then those features would simply fail. Win32s would "fail" to create the pipe, and the CLISP function to create it could indicate this failure. Such a Win32 CLISP would run under Win32s, but not every feature would be supported.
On the other hand, if a Win32 CLISP were to use the console functions as the main interface with the user, then it would not work with Win32s at all. I've no idea if this would be a reasonable tradeoff, but if Win95 supports console apps, then it might be reasonable to think of Win95 as the minimum Win32 platform for CLISP. -- <URL:http://www.demon.co.uk/community/index.html> <URL:http://www.enrapture.com/cybes/namaste.html> "You can never browse enough."
On Sat, 19 Aug 95 09:41:51 GMT, Cyber Surfer <cyber_sur...@wildcard.demon.co.uk> said:
>> Really how much are you prepared to pay for such a product? > Personally? No more than for a C++ compiler system for Windows.
Is it not worth more to you? I would personally find a good CL development environment much more useful than a C++ environment, and would be willing to pay a difference commensurate with that increase in value. Of course, I also understand that I can't pay C++-like commodity prices for what is, sadly, a niche product.
In article <8768jt5dpj....@hrothgar.mindspring.com> Robert Sanders <rsand...@mindspring.com> writes:
From: Robert Sanders <rsand...@mindspring.com> Newsgroups: comp.lang.lisp Date: 20 Aug 1995 01:47:03 -0400 Organization: MindSpring Enterprises, Inc. Lines: 13 Sender: rsand...@hrothgar.mindspring.com NNTP-Posting-Host: hrothgar.mindspring.com X-Newsreader: (ding) Gnus v0.99.11
On Sat, 19 Aug 95 09:41:51 GMT, Cyber Surfer <cyber_sur...@wildcard.demon.co.uk> said:
>> Really how much are you prepared to pay for such a product? > Personally? No more than for a C++ compiler system for Windows.
Is it not worth more to you? I would personally find a good CL development environment much more useful than a C++ environment, and would be willing to pay a difference commensurate with that increase in value. Of course, I also understand that I can't pay C++-like commodity prices for what is, sadly, a niche product.
This is actually a problem for the (lisp) vendors. It affect me, but that is just unfortunate. The question is for the vendors: do you want to increase you market share and win (with all the ambiguities that the verb "win" has) in the long run?
Once again, wouldn't we all be using Macs, if Apple had not kept their prices up for so long wrt the "average" PC running MSDOS?
Of course, "tombs are filled with afterthoughts". See you in four days, as Microsoft would say. :)
Happy Lisping
-- Marco G. Antoniotti - Resistente Umano --------------------------------------------------------------------------- ---- Robotics Lab | room: 1220 - tel. #: (212) 998 3370 Courant Institute NYU | e-mail: marc...@cs.nyu.edu | WWW: http://found.cs.nyu.edu/marcoxa
...e` la semplicita` che e` difficile a farsi. ...it is simplicity that is difficult to make. Bertholdt Brecht
In article <808903603...@wildcard.demon.co.uk> Cyber Surfer <cyber_sur...@wildcard.demon.co.uk> writes:
me> It never occured to you to try preprocessing with a EMX or DJGPP me> GCC? Interesting.
CS> As I've explained already, I tried that. It _failed_. The DOSX CS> binary of the preprocessor failed, and I've no idea why.
What does DOSX have to do with using the EMX or GO32 extenders? The binary EMX/CLISP DOS distribution is an existence proof.
me> Oh and BTW, the MSWindows work that was done on CLISP was released; me> it is in the source tree.
CS> Really? When I asked recently Bruno how the Win32 port was doing, CS> he didn't mention this.
You have been intimating that work is being withheld or was promised and was not forthcoming; neither is true.
Where are the letters `3' or `2' in my previous sentence? How did they find their way into yours? It is difficult to see why you would be so interested in "the Win32" port when you say things like:
CS> NT? I can't currently use NT, either. I use Win32s. If GCC is hosted CS> by Win32s, then that may be ok, but I have some doubts, mainly coz CS> the Win16 platform does not support command line tools very well CS> (or all?).
I guess what we in the Lisp "community" really need in order to leverage your programming skills is win32s support, not 3.1 support, and not NT or Win95 support.
In article <MARCUS.95Aug21035...@sayre.sysc.pdx.edu> mar...@sysc.pdx.edu "Marcus Daniels" writes:
> CS> As I've explained already, I tried that. It _failed_. The DOSX > CS> binary of the preprocessor failed, and I've no idea why.
> What does DOSX have to do with using the EMX or GO32 extenders?
Well, I wasn't using GNU C to compile and link the preprocessor, I was using Symantec C. DOSX is the Symantec DOS extender.
> CS> Really? When I asked recently Bruno how the Win32 port was doing, > CS> he didn't mention this.
> You have been intimating that work is being withheld or was > promised and was not forthcoming; neither is true.
Wrong. Bruno has explained to me that he's no longer working on CLISP. I've no idea what the current status of the Win32 port is.
> Where are the letters `3' or `2' in my previous sentence? How did they > find their way into yours? It is difficult to see why you would be so > interested in "the Win32" port when you say things like:
> CS> NT? I can't currently use NT, either. I use Win32s. If GCC is hosted > CS> by Win32s, then that may be ok, but I have some doubts, mainly coz > CS> the Win16 platform does not support command line tools very well > CS> (or all?).
The Win32s API is a subset of the full Win32 API used by NT. The Win95 API used to be called Win32c, for similar reasons. I think this is getting a little off-topic for comp.lang.lisp, BTW. I'll be happy to continue this by email, of course.
> I guess what we in the Lisp "community" really need in order to > leverage your programming skills is win32s support, not 3.1 support, > and not NT or Win95 support.
I'm not sure I understand that. Is it a question? What does the phrase, "leverage your programming skills", mean? Win32s is subsystem that runs on top of Win16, providing a subset of the Win32 API. If CLISP can run under DOS, using a DOS extender, then I guess it can run under Windows using Win32s.
When I had offered to port CLISP to Windows, a year ago, it was after assuming that this was possible. I offered my time and Windows programming skills to Bruno Haible because nobody else was using them. I no longer have that free time, and I'm still using the same bug-ridden tools - which are for a commercial C/C++ compiler, by the way - which prevented me from compiling the CLISP source code. When Bruno emailed me to say that he was porting CLISP himself, there little point in continuing with my own port.
Anyway, I'm not demanding a Win32 port of CLISP. I'm not demanding _anything_. Asking Symantec for a compiler without a bug in the preprocessor that left a space when you used ## didn't produce much of a result, altho I did get a new version. Perhaps they didn't get around to fixing such a "minor" bug? I dunno.
As someone who is unemployed, I have bigger problems to worry about, and some of them demanded my attention. Ultimately, _that_ is the real reason why I didn't port CLISP. I've never suggested that it was coz of any lack of support from Bruno, Symantec, or anyone else. I'm more than satisfied with the help I received.
If you have any more questions, please ask by email, as I'm not sure that anyone else is interested in this matter. If they are, then perhaps they should also email me.
I think you actually mean `the people involved in writing free / academic lisp systems' here. Well, yes, those people are indeed interested in academic uses of Lisp: they are generally academics, it's what they're paid to do.
Exactly. Originally, as designed and implemented by two mathematics students, CLISP should be the basis for a computer algebra system. A better bignum calculator for the mathematician's every day use.
It is not surprising that academics don't pay much attention to possible commercial success, unless their funds depend on it.
Bruno
Bruno Haible email: <hai...@ilog.fr> Software Engineer phone: +33-1-49083585
I'll port any of them so long as I don't have to fight the thing.
Any port of a big piece of software is a fight. Since the ports of CLISP and GCL are usually doable within a couple of days or (at most) weeks, I guess you were actually fighting your environment, notably your C compilers, not "the thing".
Bruno Haible email: <hai...@ilog.fr> Software Engineer phone: +33-1-49083585
GCC doesn't really support Windows 3.1, NT 3.x or '95. It's just good for command line utilities.
That's not true. Even the statement "GCC doesn't support Windows 3.1" is not true. There is a package named `rsxwdk' (Windows development kit with RSX) available via ftp which, together with emx+gcc, lets you build Windows 3.1 32-bit binaries. The package is certainly not beta software, but with some fighting (yes!) it is possible to build CLISP binaries which run under MS-Windows 3.1 (not DOS box).
Bruno Haible email: <hai...@ilog.fr> Software Engineer phone: +33-1-49083585
I don't know or really care which compiler you use but I can assure you they use macros with missing arguments in many, many places. This is not ANSI C. I can not speak about what compilers do or do not support this *feature*. If the thing works on your machine than obviously your compiler definitly supports the feature, period.
Yes, the CLISP source use this kind of C feature. For those C compilers which don't support it, the Makefile gets a little bit more complicated by the use of "sed -e 's/,)/,__EMPTY_MACRO_ARGUMENT__)/g'" commands. It is not worth talking about.
Oh, I don't doubt that they will insert an ifdef or two. That's not the problem. The problem has to do with fundemental design issues which were chosen not out of necessity, but out of disregard for anything but academic environments (although I understand that they certainly have this right).
You are alluding to three design decisions in CLISP:
- To write half of CLISP in C, and rely on existing C compilers (ANSI C or C++ compilers are not required). Some other Lisp's ability to be widely used is suffering from the fact they are written in 8086 or 68k assembly language.
- To write the entire bytecode interpreter as a single C function. This is your "functions so large" complaint. It did hurt me with Turbo C 2.0 three years ago because this compiler could not compile functions with more than 32 KB object code. Please tell us, did you encounter a similar limitation with Microsoft C?
- To implement the arithmetic and number system as a single compilation unit, about 950 KB C code. This was done because a lot of subroutines are realized as macros (similar to inline functions), for efficiency. When this is compiled using WATCOM C (9.5 or 10.0) the C compiler reports an "internal table overflow" because it cannot handle more than 108 KB object code per compilation, and suggests splitting the module.
And, no, the CLISP maintainers will not revise these design decisions.
I don't like speculating, but it is starting to sound like you wanted Bruno to split the source into smaller modules and functions and he refused. Maybe I'm wrong, and I suspect there is more to it, but if not, then I repeat - get a decent compiler.
That's exactly what Blake McBride wanted me to do, and I refused and suggested complaining at WATCOM.
Similarly, when your text editor says it cannot handle text files larger than 64 KB, will you split your files or will you choose another text editor? I would choose another text editor.
Bruno
Bruno Haible email: <hai...@ilog.fr> Software Engineer phone: +33-1-49083585
One thing which have elisp clisp and gcl sources in common is the heavy use of large macros and (maybe due to this?) extremely large binaries. Is the win in efficiency really noticeable?
The partial Windows 3.1 work that was done is in the distribution, but you obviously didn't bother to check. Or for that matter even pay attention to the CLISP mailing list.
me> I guess what we in the Lisp "community" really need in order to me> leverage your programming skills is win32s support, not 3.1 me> support, and not NT or Win95 support.
CS> I'm not sure I understand that. Is it a question? What does the CS> phrase, "leverage your programming skills", mean? Win32s is CS> subsystem that runs on top of Win16, providing a subset of the CS> Win32 API. If CLISP can run under DOS, using a DOS extender, then CS> I guess it can run under Windows using Win32s.
Correct! You can use the rsx GCC system for Windows 3.1, or write NT/Win95 applications with GCC. So, what is the problem?
CS> As someone who is unemployed, I have bigger problems to worry CS> about, and some of them demanded my attention. Ultimately, _that_ CS> is the real reason why I didn't port CLISP. I've never suggested CS> that it was coz of any lack of support from Bruno, Symantec, or CS> anyone else. I'm more than satisfied with the help I received.
I don't know where you got this notion that this discussion is about you porting CLISP to win32. Who cares?? This discussion about "Why is not Lisp widely used". I submit the reason has absolutely nothing to do with the efforts, or the attitude of the people involved in free software. CLISP is one example.
>>>>> "Johann" == Johann Friedrich Heinrichmeyer <jfh@ES-sun2> writes:
Johann> One thing which have elisp clisp and gcl sources in common Johann> is the heavy use of large macros and (maybe due to this?) Johann> extremely large binaries. Is the win in efficiency really Johann> noticeable?
On a sparc, lisp.run for clisp is only 1MB, and the lispinit.mem is about 800K. While running, the size is about 1 MB. The X11R6 server is 2 MB or so. XEmacs takes 4 MB or more while running. I don't find this to be extremely large.
>>>>> "Johann" == Johann Friedrich Heinrichmeyer <jfh@ES-sun2> writes:
In article <JFH.95Aug23091834@ES-sun2> jfh@ES-sun2 (Johann Friedrich Heinrichmeyer) writes:
Johann> One thing which have elisp clisp and gcl sources in common is Johann> the heavy use of large macros and (maybe due to this?) Johann> extremely large binaries. Is the win in efficiency really Johann> noticeable?
750K is a large executable for a Common Lisp implementation?
> The partial Windows 3.1 work that was done is in the distribution, > but you obviously didn't bother to check. Or for that matter > even pay attention to the CLISP mailing list.
I prefer not to read CLISP mailing list, as I have more than enough to read already. Instead, tend to look for things on FTP or WWW sites.
Which distributions are you refering to, BTW? I looked on the ma2s2.mathematik.uni-karlsruhe.de FTP site.
> Correct! You can use the rsx GCC system for Windows 3.1, or write NT/Win95 > applications with GCC. So, what is the problem?
As I've explain severla times before, I don't have the time to port CLISP myself. In case you've missed it _in this article_, I'll repeat it: I don't have the time to port CLISP myself.
Please note (in case this is something else that you've missed) my name is not Blake McBride. I have no problem with the freeware Lisps available. If I had a problem, I'd have mentioned it. All I've said is that I don't have a Lisp that I can use to write Windows apps in.
Of course, I don't _need_ to write Windows apps in Lisp, but if I did, I could probably acquire a commercial Common Lisp system. It's just a matter of convincing someone that such a system is needed to develop an app, instead of C++.
> CS> As someone who is unemployed, I have bigger problems to worry > CS> about, and some of them demanded my attention. Ultimately, _that_ > CS> is the real reason why I didn't port CLISP. I've never suggested > CS> that it was coz of any lack of support from Bruno, Symantec, or > CS> anyone else. I'm more than satisfied with the help I received.
> I don't know where you got this notion that this discussion is about > you porting CLISP to win32. Who cares?? This discussion about > "Why is not Lisp widely used". I submit the reason has absolutely > nothing to do with the efforts, or the attitude of the people involved > in free software. CLISP is one example.
You asked me about the difficulties I've had, and I answered. I'm more interested in discussing why Lisp is not more widely used, as I'd prefer to be developing software in Lisp than in C/C++. I recall that it was Blake McBride who mentioned CLISP before I did. I was simply pointing out that I've not yet found a CLISP for Win32, which may help explain why Lisp isn't used by many Windows developers.
I think of it as a matter of education. It's not an issue of whether CLISP, for example, is a commercial Lisp or not, but the fact that it is freely available may make it easier for anyone curious about Lisp to try at. There's almost no risk at all, and it's far from a "toy" Lisp. However, the old myths about Lisp (too slow, too big, unrealistic etc) are perpetuated by the smaller systems, like XLISP, which are interpreted.
I can remember how only 5 years ago, it was possible to get an odd look from a MIDI user if you mentioned MIDI and Windows in the same sentence. These days, I expect to get those same looks if I use Lisp and Windows in the same sentence!
Perhaps they think Lisp is dead? I wish I could show that this wasn't true. A Lisp for DOS won't help, coz DOS = Dead Operating System. A Lisp for Win32 would be at the front of the race, where the top runners are.
What I'm talking about is how Lisp is perceived by developers. That's determined by marketing, and the marketing of Lisp for the Windows market is not as strong as it the marketing for C++, which may explain why C++ is used so much more widely, at least for Windows.
Do you see now why I mentioned CLISP (and the lack of a Win32 version) 9 days ago? It could be too late to help me, but then, I'm already convinced. Sadly, this doesn't help me use Lisp, instead of C++, to develop software.
We could probably be just as easily talking about GNU CL, of course, or any other freely available Common Lisp system, as long as such a system would be available to developers who might want to try Lisp, and see for themselves how good it is. Without a real system to play with, it's a lot easier to believe the myths.
This also applies to Smalltalk, Prolog, and any other language for which implementations are not sold in vast quantities or advertised as heavily as, let's say, VC++. I said it was a marketing problem over a week ago. At the very least, it's the reason why I've yet to meet a Windows developer using Lisp for commercial software.
: >>>>> "Johann" == Johann Friedrich Heinrichmeyer <jfh@ES-sun2> writes:
: Johann> One thing which have elisp clisp and gcl sources in common : Johann> is the heavy use of large macros and (maybe due to this?) : Johann> extremely large binaries. Is the win in efficiency really : Johann> noticeable?
: On a sparc, lisp.run for clisp is only 1MB, and the lispinit.mem is : about 800K. While running, the size is about 1 MB. The X11R6 server : is 2 MB or so. XEmacs takes 4 MB or more while running. I don't find : this to be extremely large.
I read through the long thread on "Why is Lisp not more widely used" and I was surprised that noone mentioned WCL, which is listed in the Free Common Lisp Implementations section of the FAQ. With the binary distribution comes a paper "WCL: Delivering Efficient Common Lisp Applications under Unix", by Wade Hennessey, discussing size and portability issues. The highlight of WCL seems to be that an additional Lisp program compiles to a very small executable (40 Kbyte for a minimal program). This executable uses a large shared library (4 Mbytes), which can be shared by all Lisp applications running on the machine. It seems to me like a quite elegant solution of one aspect of the size problem.
I should add that my practical experience with WCL is very small so far. On the plus side: It was very easy to install and try a small example. On the minus side: There seems to be a problem when using it with gcc 2.6.3 (described in another posting to this group).
>Without a real system to play with, it's a lot easier to believe >the myths.
>This also applies to Smalltalk, Prolog, and any other language >for which implementations are not sold in vast quantities or >advertised as heavily as, let's say, VC++. I said it was a >marketing problem over a week ago. At the very least, it's the >reason why I've yet to meet a Windows developer using Lisp for >commercial software.
Sorry to jump into the middle of this thread, but I was curious about this issue. I still remember my disappointment when Borland introduced Delphi based on (of all languages) Pascal!
Is there a market for Lisp in a VC++/Delphi-like product? Would it have to be watered down to the point of being nothing more than a toy?
In article <809267808...@wildcard.demon.co.uk> Cyber Surfer <cyber_sur...@wildcard.demon.co.uk> writes:
CS> I think of it as a matter of education. It's not an issue of CS> whether CLISP, for example, is a commercial Lisp or not, but the CS> fact that it is freely available may make it easier for anyone CS> curious about Lisp to try at. There's almost no risk at all, and CS> it's far from a "toy" Lisp. However, the old myths about Lisp (too CS> slow, too big, unrealistic etc) are perpetuated by the smaller CS> systems, like XLISP, which are interpreted.
What will encourage people try Lisp is the belief that it gives them a competitive advantage. Experienced Lisp *programmers* may give them this, novices will not. It is impossible to make money on Common Lisp unless you are able to direct some mental energy to practicing a mature skill. If you can't come up with money for a commercial Lisp (which does seem to be what you want), or finish a fairly simple port, one has to wonder why you think you have the depth to win with Lisp.
Anyone who would generalize Lisp from XLISP is not in the category of individuals capable of critical thought. I can't imagine how someone could have such a pretense. No prejudice about Lisp exists due to XLISP or xlispstat. You'd get more sympathy if you made accusations about CMU Lisp or Emacs (and a lot more flames, too).
CS> Perhaps they think Lisp is dead? I wish I could show that this CS> wasn't true.
It is time to let Lisp die. Just bring Lisp back with a new name like Dylan, GUILE, or generically as "dynamic language" -- some of us know better and can ignore the vast stupidity of it all.
CS> A Lisp for DOS won't help, coz DOS = Dead Operating CS> System. A Lisp for Win32 would be at the front of the race, where CS> the top runners are.
Where is the race going?
CS> What I'm talking about is how Lisp is perceived by developers. CS> That's determined by marketing, and the marketing of Lisp for the CS> Windows market is not as strong as it the marketing for C++, which CS> may explain why C++ is used so much more widely, at least for CS> Windows.
The moral of the story: Truth is a vote; we should all try very hard to win the attention of fools.
CS> Do you see now why I mentioned CLISP (and the lack of CS> a Win32 version) 9 days ago?
I have some ideas.
CS> It could be too late to help me, but then, I'm already convinced.
>>>>> "Martin" == Martin Brundage <mar...@ix.netcom.com> writes: In article <41s1a0$...@ixnews7.ix.netcom.com> mar...@ix.netcom.com (Martin Brundage) writes:
Martin> Is there a market for Lisp in a VC++/Delphi-like product?
In the Free software world, GNU is interested in it (from the `tasks' list)
* An interface-builder program to make it easy to design graphical interfaces for applications. This could work with the dynamic linker DLD and C++, loading in the same class definitions that will be used by the application program.
Otherwise, before starting on a make-money scheme, check out the offerings of the Lisp and Lisp-integration vendors.
Martin> Would it have to be watered down to the point of being nothing Martin> more than a toy?
In article <41s1a0$...@ixnews7.ix.netcom.com> mar...@ix.netcom.com "Martin Brundage" writes:
> Is there a market for Lisp in a VC++/Delphi-like product? Would it have > to be watered down to the point of being nothing more than a toy?
The only Lisp for Windows with support for the Windows API that I've personally seen was an early beta, so it wouldn't be fair to discuss it (not that I would, anyway).
What exactly what make a Lisp system qualify as "VC++/Delphi-like", in your opinion? Would VBX support and a forms designer be necessary, or would a framework for the Windows API be good enough? VC++ and Delphi offer _both_ of these. -- <URL:http://www.demon.co.uk/community/index.html> <URL:http://www.enrapture.com/cybes/namaste.html> "You can never browse enough."
