HDTenEightyP/NetNews huggingface dataset:
From: Mark_Carlotto@b1mac144.read.tasc.com (Mark Carlotto)
Newsgroups: comp.lang.lisp.mcl
Subject: Stack Overflow Error
Date: 21 Jan 93 20:48:27 GMT


                       Subject:                               Time:3:38 PM
  OFFICE MEMO          Stack Overflow Error                   Date:1/21/93
Hi,
I am using the following code to display images stored as PICT resources. By
increasing 
the size of the rectangle, I'm able to effectively roam and zoom the image. My
problem
is that if I make the rectangle too large (i.e., I attempt to zoom the image
too much),
the system crashes (type 28 stack overflow error). Any suggestions/fixes?

P.S. The same thing happens when I use your code for displaying PICT images. 

P.P.S I have tried to increase the sizes of the stack and heap using
make-application
without success.

(defun DISPLAY-IMAGE-RESOURCE (the-window rfile-name-string   pict-num 
                                          left top right bottom)
  (let (string-ptr resrefnum pict-handle)
    (setf string-ptr (#_newptr 256))
    (%put-string string-ptr rfile-name-string 0)
    (setf resrefnum (#_openresfile string-ptr))
    (rlet ((r :rect
              :topleft (make-point left top)
              :bottomright (make-point right bottom)))
      (with-focused-view the-window
        (window-select the-window)
        (#_framerect r)
        (setf pict-handle (#_getpicture pict-num))
        (#_drawpicture pict-handle r)
        (#_closeresfile resrefnum))))
  t)

*******************
From: hsiung@urz.unibas.ch
Newsgroups: comp.lang.lisp.mcl
Subject: MacTCP from menu make problems
Date: 26 Jan 93 12:44:51 MET
Organization: University of Basel, Switzerland

Hi guys,

I have a problem using MacTCP from menu.
When I call open-tcp-stream from menu the function %tcp-control
get stuck in the while-loop?!
I never had this problem when I called open-tcp-stream from the
listener.
I find an ugly solution but I don't really understoog what happend.
If there is a (print "..") and (force-output) in this while-loop
it does work as expected without getting stuck.

Is there someone that understand which interactions are between
menu, listener and other streams??

Alain Hsiung
hsiung@urz.unibas.ch

University of Basel Switzerland.
.

Newsgroups: comp.lang.lisp.mcl
From: westling@starbase.mitre.org (Mark Westling)
Subject: Calling MPW C code: is malloc safe?
Organization: The MITRE Corporation
Date: Mon, 25 Jan 1993 22:10:13 GMT

I'm calling MPW C code using MCL 2.0's foreign function
interface.  My program bombs occasionally (but not
consistently), and I suspect it's due to malloc calls. Is
it safe to use the MPW memory allocation/deallocation
calls in a Lisp environment, or should I create a static
array and manage it all myself?

--Mark Westling
From: grant@pentagon-gw.army.mil (Pete Grant)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Double float woes...
Date: 24 Jan 93 03:30:16 GMT
Organization: U.S. Army Artificial Intelligence Center, The Pentagon

In article <63460@mimsy.umd.edu> waander@cs.umd.edu (Bill Andersen) writes:
>
>  Is there any way to get the integer value of a double-float
>without consing?  I tried (floor x), where x is a double-float
>and I get charged 24 bytes....  Since fixnums are immediate,
>just returning one should not cons and I don't care about the
>remainder..  Any ideas???
>
>  ...Bill

Sure, get a Symbolics.  On my 3650 I get charged 0 bytes. :-)h
Newsgroups: comp.lang.lisp.mcl
From: forbus@ils.nwu.edu (Ken Forbus)
Subject: Porting to MCL: Package problems
Followup-To: comp.lang.lisp.mcl
Keywords: MCL<> CL?,pain 
Organization: The Institute for the Learning Sciences
Date: Wed, 27 Jan 1993 19:56:38 GMT

I am trying to make some Common Lisp code run under MCL.  It runs as is on
every other Common Lisp I've tried: Lucid and Franz on a variety of machines,
KCL and AKCL, Symbolics on their own hardware, and even the Symbolics
CLOE environment under Microsoft Windows.  Overall, quite vanilla code.
Much of it in fact is teaching code, designed to be very
portable.  But it won't run under MCL.

Most of the problems seem to be package related.  MCL can't seem to grok

(in-package 'tms)

for instance, and declaring packages in a Symbolics-style attribute line
appears to make the machine most unhappy.

Presumably others have solved such problems.  Is there a file somewhere which
documents the gotcha's in porting Common Lisp code to MCL?  Thanks.

	Ken

==========================================
Prof. Kenneth D. Forbus
Qualitative Reasoning Group
The Institute for the Learning Sciences
Northwestern University
1890 Maple Avenue
Evanston, Illinois, 60201, USA

email: forbus@ils.nwu.edu
voice: (708) 491-7699
fax: (708) 491-5258
==========================================
From: Espen J. Vestre <espen@coli.uni-sb.de>
Newsgroups: comp.lang.lisp.mcl
Subject: shiftf
Date: 27 Jan 1993 09:34:10 GMT
Organization: Computerlinguistik, Universitaet des Saarlandes
Distribution: world
NNTP-Posting-Host: mp-mac10.coli.uni-sb.de
X-UserAgent: Nuntius v1.1.1d12
X-XXMessage-ID: <A78C0D20C6014453@mp-mac10.coli.uni-sb.de>
X-XXDate: Wed, 27 Jan 93 08:57:52 GMT

MCL's shiftf macro produces unneccesary complicated form in the simple
cases.  The most frequent use of shift, is probably for simple pointer
switching in list structures: Replacing a value while saving the old
value.  (The two-argument (place, newvalue) special case of shiftf used
to have its own name, swapf)

Here's what MCL's shiftf produces:
? (macroexpand '(shiftf (cddr liste) nil))
(LET* ((#:G91 LISTE) 
       (#:G89 (MULTIPLE-VALUE-LIST (CDDR #:G91)))) 
  (DECLARE (DYNAMIC-EXTENT #:G89)) 
  (MULTIPLE-VALUE-BIND (#:G90) NIL 
    (PROGN (CCL::SET-CDDR #:G91 #:G90))) 
  (VALUES-LIST #:G89))

Here's a simpler expansion suggestion (Allegro 4.1 produces something
similar to this):
(LET* ((#:G91 LISTE) 
       (#:G89 (CDDR #:G91))
       (#:G90 NIL))
  (CCL::SET-CDDR #:G91 #:G90)
  #:G89)

The second form has an execution time of appr. 1/3 of the first form,
which may be quite significant for pointer-manipulating programs.

--------------------------------------------------------------
Espen J. Vestre,                          espen@coli.uni-sb.de
Universitaet des Saarlandes,        
Computerlinguistik, Gebaeude 17.2 
Im Stadtwald,                          tel. +49 (681) 302 4501
D-6600 SAARBRUECKEN, Germany           fax. +49 (681) 302 4351
--------------------------------------------------------------
From: kedar@ils.nwu.edu
Newsgroups: comp.lang.lisp.mcl
Subject: Please unsubscribe [end of message]
Date: 26 Jan 93 14:56:06 GMT



==================================================================
Smadar Kedar,
NASA Ames Research Center, Artificial Intelligence Research Branch

currently visiting researcher,
Institute for the Learning Sciences, 
Northwestern University
1890 Maple Ave.
Evanston, IL 60201

phone:  (708)-467-1017  (my office; no voicemail)
        (708)-491-3500  (main number; leave msg)
        (708)-491-5258  (FAX)
email:  kedar@ils.nwu.edu
Newsgroups: comp.lang.lisp,comp.lang.scheme
From: nagle@netcom.com (John Nagle)
Subject: Re: Why Isn't Lisp a Mainstream Language?
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Thu, 28 Jan 1993 07:13:08 GMT

      LISP had its shot at becoming a mainstream language in the mid 1980s,
during the AI boom, and it didn't make it then.  It's unlikely to make
it now.  Smalltalk occupies the market niche for a dynamic language for 
"exploratory programming" at this point in time.

      Scheme is nice, but probably isn't going to take over the world.

					John Nagle
From: desmedt@ruls40.LeidenUniv.nl (Koenraad de Smedt)
Newsgroups: comp.lang.lisp
Subject: CommonORBIT
Date: 21 Jan 93 16:51:14 GMT
Reply-To: desmedt@ruls40.LeidenUniv.nl (Koenraad de Smedt)
Organization: Leiden University, Netherlands

I was a bit overwhelmed by the reaction to my postings about CommonORBIT.
Because I received a lot of requests for the system, I decided to put in
in the CMU Lisp archive.  Today I also added a paper describing the system
to the archive.  Below is an extract from the FAQ file describing how
to obtain it.

   The source code of CommonORBIT is in the
   public domain and available by anonymous ftp from the Lisp
   Utilities Repository,
      ftp.cs.cmu.edu:/afs/cs.cmu.edu/user/mkant/Public/Lisp/
   in the corbit/ subdirectory as the file corbit.tar.Z.

   Documentation is available as the files corbit.msword.hqx, corbit.ps
   or corbit.text. A stripped-down version of CORBIT, known as BOOPS
   (Beginner's Object-Oriented Programming System), is also available
   from the repository as boops.tar.Z. For further information,
   contact the author, Koenraad de Smedt <desmedt@ruls40.LeidenUniv.nl>

Koenraad de Smedt  (Leiden University)
From: sef@sef-pmax.slisp.cs.cmu.edu
Subject: Re: Why Isn't Lisp a Mainstream Language?
Organization: School of Computer Science, Carnegie Mellon
Date: Thu, 28 Jan 1993 03:55:54 GMT


    From: bvrotney@ADS.COM (Bill Vrotney)
    
    Yes "Where to go from here?" I am disappointed that the Lisp leadership is
    not addressing this question. This begs for something like the Common Lisp
    project but aimed at making Lisp smaller and faster in an organized way.  I
    was reading about a KERNEL lisp specification in Lisp and Symbolic
    Computation. Perhaps something along these lines should be hit with force.
    Lisp leadership where are you? Give us something to be hopeful for.
    
Keep an eye on Dylan.

-- Scott

===========================================================================
Scott E. Fahlman			Internet:  sef+@cs.cmu.edu
Senior Research Scientist		Phone:     412 268-2575
School of Computer Science              Fax:       412 681-5739
Carnegie Mellon University		Latitude:  40:26:33 N
5000 Forbes Avenue			Longitude: 79:56:48 W
Pittsburgh, PA 15213
===========================================================================
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: CLOS for AKCL?
Keywords: clos
Date: 21 Jan 93 19:49:55 GMT
Organization: AIAI, University of Edinburgh, Scotland

In article <1993Jan13.140114.115@aiware.in-berlin.de> scm@aiware.in-berlin.de (Harald Schmidt) writes:
>Hallihallo,
>
>I am searching for an object oriented extension for my akcl,
>does anybody knows if there exist one?

Sure, PCL (a CLOS) works in AKCL.  Look at the FAQ positing to see how
to get it.
Newsgroups: comp.lang.lisp,comp.lang.scheme
From: jaffer@zurich.ai.mit.edu (Aubrey Jaffer)
Subject: Re: Why Isn't Lisp a Mainstream Language?
Organization: M.I.T. Artificial Intelligence Lab.
Date: Wed, 27 Jan 1993 19:32:29 GMT

In article <1993Jan27.175935.24272@cc.umontreal.ca> kardank@ERE.UMontreal.CA (Kardan Kaveh) writes:

   In article <1993Jan27.070106.28425@ads.com> bvrotney@ADS.COM (Bill Vrotney) writes:

   ...
   Every once in a while this thread pops up, with people lamenting over the
   size of Common Lisp.  Usually, someone (me, in this instance) will point out
   that there is a small, standardized (IEEE) lisp around: Scheme.

   I am crossposting this to comp.lang.scheme because I feel the point made above
   applies to some extent to scheme as well.

   Although the technical side of scheme has been very well handled, I find the
   lack of scheme in the marketplace quite disturbing.  According to the FAQ,
   there is only _one_ commercial implementation of scheme running on UNIX
   workstations (Chez Scheme).

I sell SCM, which runs on UNIX workstations, on MSDOS floppy disks.
This is as portable a medium as you are likely to find for UNIX
workstations.  However, I am willing to put it on another format.  The
FAQ probably does not mention me as a commercial vendor because SCM is
also availble via FTP.

   There are several free implementations around, but all are either toy
   implementations or are concerned with being an "extestion language" for
   applications written in C.

SCM was written to be the base of a symbolic algebra program written
in R4RS Scheme.

   As a result they have no compilers and no development environments.

If you are working on Unix workstations then there is no problem.
Emacs + psd1.0 provides source code single stepping and breakpointing,
code formatting and send-defun.  SCM (through SLIB) provides trace and
untrace.  I find this a potent combination.

The Hobbit Compiler (by Tanel Tammet) for SCM is in alpha test
and should be ready soon.  However, as SCM runs only 15 times slower
than hand crafted C code (on most machines) and loads very quickly,
the lack of the compiler has not hampered my development efforts.

   No foreign-function interface, for one.

There are directions for adding foreign-functions to SCM in code.doc
in the distribution.  Many people have done so.  So I think it is not
too difficult.

   It can be argued that academia has done its job in presenting us with
   extremely elegant standards (R4RS and IEEE), but the commercial sector has
   dropped the ball.

Perhaps if I charged more, I would be taken more seriously.  But
consider this:  for the price of a "commercial" implementation
(n x $1000) you could hire me or someone else to add a substantial
amount of stuff to SCM.

Some things which could be added to SCM are:
  Profiling (how much time spent in each routine)
  Dynamic Linking (There is a GNU package which does this on Unix
	systems and Carrette has also suggested a fairly portable method)
  Editor (buffers + GNU search + curses)
  String Ports (someone has sent me code for this but I haven't had
	time to integrate it)
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date: 26 Jan 93 19:15:04 GMT
Organization: AIAI, University of Edinburgh, Scotland

In article <1993Jan19.122952.6942@wavehh.hanse.de> cracauer@wavehh.hanse.de (Martin Cracauer) writes:

>I wonder, if it is possible, to change the synatx of LISP without
>loosing it's advantages.

You mean it's other advantages?  For many of us, Lisp's syntax is
an advantage, not a disadvantage.

-- jd
From: bouma@cs.purdue.edu (William J. Bouma)
Newsgroups: comp.lang.lisp
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date: 21 Jan 1993 19:42:21 -0500
Organization: Purdue University Department of Computer Sciences
Distribution: world
NNTP-Posting-Host: melange.cs.purdue.edu


In article <1993Jan21.160702.7978@uk03.bull.co.uk>, bbirch@hemel.bull.co.uk (Bill Birch) writes:
|> But surely Lisp IS a mainstream language!  It has survived the test 
|> of time. Whatever happened to ALGOL, et. al.? Just because a
|> language is not used by Joe Programmer doesn't mean that
|> it is dead. After all, Joe Programmer probably used Lisp
|> at College. He may use Lisp concepts in his 'C' programs.

  I agree with this.  From where I sit (ie. university environment)
  Lisp looks pretty popular.  It is being taught.  Even though we
  disposed of our Lisp machines, people still program in CL.  People
  use Lisp to program Emacs, and use symbolic math pakages such as
  MACSYMA that are written on top of Lisp.

  Other posts in this thread speculate that Lisp is less popular than
  C because of some programming issue such as prefix vs infix math
  notation, or function call notation.  I don't think it has anything
  to do with coding in the languages, as the majority of those who have
  programmed in both is bound to prefer Lisp. ;^)

  The main reason C is preferred over Lisp is the environmental baggage
  Lisp carries.  If I compile a small C program I get a small standalone
  binary.  I type the name of that binary and it runs.  If I compile a
  small CL program I get a small binary, but I have to load that into
  an 8Mb environment in order to run it.  If I want to run a different
  C program, I just type its name.  If I want to run another Lisp 
  program I either have to reload the 8Mb, or make sure there are no
  name clashes with the previous program(s) loaded in.  Then, what if
  I want to run programs in seperate processes?

  With the prevalence of operating systems like UNIX, Lisp would be
  much much more popular if it compiled small standalone binaries.
-- 
Bill <bouma@cs.purdue.edu> 
Newsgroups: comp.lang.lisp
From: hall@aplcenmp.apl.jhu.edu (Marty Hall)
Subject: Re: Why Isn't Lisp a Mainstream Language?
Organization: AAI Corp AI Lab, JHU P/T CS Faculty
Date: Mon, 25 Jan 1993 20:37:38 GMT

In article <19930122162651.0.SWM@SUMMER.SCRC.Symbolics.COM> 
SWM@stony-brook.scrc.symbolics.com (Scott McKay) writes:

I have great respect for Scott's abilities, and agree with his major
points. On the following minor nit, however, I disagree:

>I personally think CAR and CDR could have been flushed from the
>language, since FIRST and REST do the exact same thing.  Note, by the
>way, that you have picked one of the very few things retained in Common
>Lisp for historical purposes.

I agree when one is working with lists. However, occassionally one uses
cons cells for other things (eg trees), and CAR/CDR (or even LEFT-POINTER and
RIGHT-POINTER) are preferable then, IMHO. I'd rather have a meaningless
name in such a case than one like FIRST where the current use contradicts the
meaning. But this is obviously a minor point.

On the real issue of why LISP is not mainstream, most of the comments I've
seen have focused on the user's perspective. However, I think there is also
a commercial reason having to do with the "bundledness" of Common LISP. I've
become convinced that since Common LISP is so big, only a few vendors had 
(have?) the manpower to tackle it. There were good technical reasons against 
going with a small core language with optional libraries for Common LISP, 
but it did make it a lot harder for vendors to break in. If you could buy 
CLOS from one person (and still have it optimized, which is hard, I realize), 
FORMAT from another, LOOP from a third, CLIM from Scott, a development 
environment from yet another, and so on, more small companies could have 
entered the market. Right now it is hard for companies to carve out a
niche; they sort of have to go after the LISP market whole hog.

As a user, I'd rather be able to count on everything being there in any
implementation, and I realize it may be convenient to able to assume CLOS
is built in (when writing the condition system, for instance). But these
conveniences had negative implications in the commercial marketplace.

On an only slightly related note, I'm unaware of the licensing rules, but 
perhaps the availability of CMUCL, WCL, and PCL will provide an avenue for 
smaller vendors to get up and going more quickly. And perhaps CLIM will 
provide a standard so that we can realistically buy (and sell) graphics 
applications that lots of people could use...

					- Marty
(proclaim '(inline skates))
Newsgroups: comp.lang.lisp
From: dfs@doe.carleton.ca (David F. Skoll)
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Organization: Dept. of Electronics, Carleton University
Date: Fri, 22 Jan 1993 19:54:19 GMT

In <1jpi0sINN47q@elroy.jpl.nasa.gov> gat@forsight2.jpl.nasa.gov (Erann
Gat) writes:

>(You seem to be complaining about two orthogonal issues, by
>the way, the syntax of format strings and their functionality.

You are right.  I wrote my article hastily.  But the "format" function
is representative of one aspect of Common Lisp which I believe
prevents it from becoming a "mainstream" language - Common Lisp
attempts to do almost everything, with the result that 90% of the Lisp
image is devoted to functions a small-to-medium program will never use.

And people have been arguing that Lisp is a very good general
purpose language.  A function that prints English names of numbers
is a pretty special-purpose function!

--
David F. Skoll
From: akriger@hamp.hampshire.edu
Newsgroups: comp.lang.lisp
Subject: where's the faq?
Date: 26 Jan 93 22:46:20 EDT
Organization: Hampshire College
NNTP-Posting-Host: hamp.hampshire.edu

hate to ask a silly question, but what happened to the faq for
lisp?

andrew kriger
From: gwilson@majestix.cs.uoregon.edu (Gregory Vance Wilson)
Subject: Re: SCM Wishlist
Organization: University of Oregon Computer and Information Sciences Dept.
Date: Thu, 28 Jan 1993 00:44:01 GMT

> jaffer@zurich.ai.mit.edu (Aubrey Jaffer) writes:
> Some things which could be added to SCM are:

Some other things that might speed its adoption by the rest of us:

* a textbook on software engineering which uses Scheme as a language for its examples
* "   "      "  how to implement Scheme using C (good intro to systems programming)
* "   "      "  operating systems
* "   "      "  computer networks
* "   "      "  graphics
* "   "      "  databases
* "   "      "  physical science
* "   "      "  discrete event simulation
* "   "      "  numerical methods
* "   "      "  computational science (not the same as numerical methods)

My point is that most people who care a lot about language design don't care
(as much) about other aspects of computing.  As a result, language designers
spend their time refining languages, instead of showing the rest of us how
useful they are.  I don't want to be shown how to write a Scheme interpreter
in Scheme; I want to be shown how to implement Runge-Kutta, or an irregular
oct-tree for making my ray-tracing program go faster, or a traffic flow
simulator, or...

I think that C and Pascal (the only two new languages to have gained a
general following since the 1960s) have succeeded precisely because such
books have been, or become, available.  "Give me the child to the age of
seven, and I will give you the man," and all that --- I believe that Scheme
(or ML, or any other language) will not be adopted outside a relatively
narrow segment of academia until (or unless) enough curricular material is
available for it to be the primary language of instruction throughout an
entire undergraduate degree.

Looking forward to the responses,

 ========================================================================
  Gregory V. Wilson                          || Work as though you lived
  Dept. of Computing and Information Science || in the early days
  University of Oregon                       || of a better nation.
  gwilson@cs.uoregon.edu                     || - Alasdair Gray
 ========================================================================