HDTenEightyP/NetNews huggingface dataset:
From: mcdougal@cs.uchicago.edu (Tom McDougal)
Newsgroups: comp.lang.lisp.mcl
Subject: flooding region w/ paint -- how?
Date: 5 Jan 93 21:42:06 GMT
Organization: Univ. of Chicago Computer Science
X-Xxmessage-Id: <A76F5AA3D2011453@tango.uchicago.edu>
X-Xxdate: Tue, 5 Jan 93 21:32:51 GMT
X-Useragent: Nuntius v1.1.1d16

You know how in MacPaint and similar paint programs you can click on a
pixel and fill the surrounding region with paint?  

I need to do this -- i.e., given a graphics window whose contents I
know nothing about, and a pixel, flood the region around that pixel
with paint.  B/W is ok, tho' color would be useful.

I don't suppose there is a primitive quickdraw command for this? :-) 
Suggestions?

Thanks for your kind attention.

-----------------------------------------------------------
Tom McDougal   mcdougal@cs.uchicago.edu   +1 (312) 702-9923

        1929, Old Man River runs off at the mouth.
From: ralex@tigger.cs.colorado.edu (Repenning Alexander)
Newsgroups: comp.lang.lisp.mcl
Subject: Wanted: 2d pop up menus (color palette pop ups)
Date: 9 Jan 93 05:34:01 GMT

I'm looking for ways, no any way really, to implement two dimmensional
pop up menus. I am especially interested in 2D color palette pop ups
like the ones used in many applications dealing with the interactive
change of the pen color, e.g., ResEdit's (cicn editor). Linear menus
are limited when dealing with a large number of items. A linear color
palette pop up with 256 items would be rather tedious for users, so I
believe 2d pop up menus would be a nice extension to MCL.

MCL supports linear menus really great but I don't quite see how I
should implement 2d pop ups. Any pointers and hints are very much
appreciated..

   Alex
From: sharp@newton.apple.com
Newsgroups: comp.lang.lisp.mcl
Subject: remove-view-from-window
Date: 5 Jan 93 19:18:08 GMT

Hiya,

According to both the manual and MCL.help the arguments to
remove-view-from-window are a view and a window.

This is not correct, there are actually no arguments.

My question... is there some alternate method that I can use instead of
remove-view-from-window to perform actions prior to a views removal from a
window or subview?

maurice
-------------------------------------------------------------------------
Maurice Sharp             I #include <std_disclaimer.c>
Apple Computer Inc.       |"Work for?! I don't work *for* anybody.
Intern at Large           | I'm just having fun." -- The Doctor (#4)
From: Jeff_Monroe.METRON#u#CA#u#TC@metron_qmsmtp.metsci.com ("Jeff Monroe")
Newsgroups: comp.lang.lisp.mcl
Subject: None
Date: 11 Jan 93 06:09:26 GMT


                       Subject:                               Time:10:57 AM
  OFFICE MEMO          None                                   Date:1/11/93
>>I have an MCL application that I want to port to an SGI machine with a
>>Franz CLOS/CLIM environment.  Does anyone know if there are portable
>>versions (e.g. CLIM) of MCL's GUI interface functions (e.g. those for
>>window, views, dialogs) available?  This will save me the time of
>>having to rewrite the GUI code in CLIM.
>

>>Another possible solution is "Action!" from Expertelligence, another
>>cross-platform GUI toolkit. You'll find a demo version on your 
>>MCL 2.0 cd-rom.

We currently use "Action!" from Expertelligence to do the user interface for
our application.  While Expertelligence advertises that you can use "Action!"
to port interfaces between platforms, this capability (last time I checked) is
not yet finished.  I would advise that you talk to the Expertelligence people
to find out the status of "Action!" for the various platforms you are
interested in before you get your hopes up too much.

Jeff Monroe
From: UK0392@AppleLink.Apple.COM (EHN & DIJ Oakley,GB,IDV)
Newsgroups: comp.lang.lisp.mcl
Subject: Re3: speed freak buys farm?
Date: 4 Jan 93 19:52:00 GMT

But a few days ago (last year, I think), I said:
>   Funnily enough, I expect to test my first Rocket early in the New Year.
To which came the reply:
>Good luck with this one.  I have a Rocket and am very dissapointed to find
>that MCL is about the only application that I cannot run on it using the new
>RocketShare environment to which you reference.
and Alice Hartley <alice@cambridge.apple.com> said:
>Or from a different perspective, the Radius accelerators are the only
>ones that MCL has problems with. The 25i causes more problems than
>the 33i.
 
Well, today the Rocket 33 arrived, was duly installed, and tested under MCL
(amongst other things).  My preliminary impression is that *without* using
RocketShare, there are no compatibility problems between MCL 2.0p2 (pre-release
patch 2) and the currently shipping Rocket 33.  However, I was meticulous to:
1.  Remove ptable from the System Folder (which is not needed for 040s
anyway??)
2.  Remove other INITs and CDEVs of dubious parentage
3.  Use 80ns & 70 ns RAM, totalling 20 Mbyte.
 
And the end result?  Arguably as fast as a Quadra 700, but with the added
potential of (maybe one day) running RocketShare too, and a rather cheaper and
more versatile upgrade than the IIci->Q700 one.  I still have reservations
about the future, though, and it will be interesting to see if RocketShare gets
fixed with respect to MCL.  Fortunately in this case, it was not my money that
I was committing.
 
Howard.
From: language@skdad.usask.ca
Newsgroups: comp.lang.lisp.mcl
Subject: Re: MCL support for MOP
Date: 10 Jan 93 08:36:49 GMT

Bill:
> Feedback please. Do you need these facilities? Other ideas?
> The MCL development team has decided that MCL's size is not the
> most important thing we have to work on right now, but it's
> still important to us.
you may have your reasons for _not_ being interested in the size
of applications generated by MCL,  however,  this is the primary
reason why I am not using MCL to develop any applications programs,
and I can't see myself doing so until that get's fixed.  Why?  well,
it looks stupid to deliver a simple program that takes up 1.4 megs.
especially when the same task can be done with a 20k application.
for example,  BinHex (the application) takes up something like 8k
on disk,  while the MCL BinHex application (which appears to do
the same thing,  although slower) occupies well over 1 meg of disk
space,  and it doesn't run well with less than two!

perhaps this is petty compared to the obvious advantages of using
MCL for development,  but I feel these things are important.  Generally,
I'd prefer to use MCL for everything,  including the tasks normally
done by the finder,  and for my own personal use it's great;  but,
I'd find it difficult trying to explain to a client why a program
with the functionality of TeachText more than 1meg of disk space, and
runs with 2 or more megs in ram...

    -john
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: MCL support for MOP
Date: 8 Jan 93 21:56:58 GMT

>bill@cambridge.apple.com (Bill St. Clair) writes:
>
>> Adding more MOP support to MCL is on my list of
>> things to do, but it's not very near the top of the list so I'm not
>> likely to do it soon.
>
>I wonder how high the need for MOP support is on the list of typical
>MCL users. Some users are worried about the lack of MCL/MOP features.
>Others, however, (including me) don't really use MOP and, therefore,
>are worried about making trade offs regarding performance and/or
>memory.
>
>Questions:
>
>- what impacts would a full MOP implementation have to MCL in terms of
>  performance or memory?
>  
>- could a full MOP implementation be packaged into a separate module 
>  (sort of like PCL minus MCL)

Top of my head estimates follow. Take with a grain of salt.

I doubt that a MOP implementation will require much extra space.
MCL's entire CLOS implementation is only about 270K of source code
which compiles to less than 100K of fasl files (fasl file size is
usually close to in-memory size) The MOP will probably add another
50 to 100K to the source, so it's likely to increase MCL's in-memory
size by 20 to 50K. Some of this will be swappable, so it will only
take up disk space if you don't use it.

>
>One of the many nice things about MCL is its size compared to other
>Common Lisp implementations. It allows developers to create
>applications able to run on low-end machines. However, If more and
>more functionality is creeping into MCL (maybe partly due to the
>ANSIfication of the Common Lisp clean up process) I wonder how much
>longer this is going to be true.

There are a couple of reasons that MCL 2.0 is bigger than 1.3.
The pretty printer and inspector are included in 2.0, they were
provided as fasl files in 1.3. 2.0's CLOS generic functions cost a
little more space than 1.3's Object Lisp obfuns. We'll probably be
looking into a few ways to reduce the size of MCL (though probably
not for 2.1). Some ideas are:

1) A tree shaker to automagically remove parts of MCL that are
   not used by your application.

2) Make the development environment be optional, or distribute 2
   MCL applications: with & without development environment. Maybe
   even a third application that has just Common Lisp with no
   application framework.

3) One or more shared libraries for the different pieces of MCL.
   This will allow small MCL applications at the expense of some
   large inits.

Feedback please. Do you need these facilities? Other ideas?
The MCL development team has decided that MCL's size is not the
most important thing we have to work on right now, but it's
still important to us.


-----
Bill St. Clair
bill@cambridge.apple.com
From: garvey@ai.sri.com (Tom Garvey)
Newsgroups: comp.lang.lisp.mcl
Subject: CLIM query
Date: 6 Jan 93 17:21:14 GMT

I have been very pleasantly impressed with MCL 2.0; it makes my Mac
behave like a real computer!  CLIM offers the promise of being able to
develop applications that will run on our Suns, Lispms, and Macs
(unbelievable! -- maybe).

However, I wish to develop a graphical user interface that can
directly display the logical combination of multiple sensor
footprints.  For this purpose, ALUs (or logical drawing functions)
would have been perfect for my application, but they seem not to exist
in CLIM.  Is this really true, or have I not yet figured out the right
string to apropos in order to find them?  It seems that the only
concession to anything like an ALU is +flipping-ink+, which gives me
XOR, but not AND (which I would like a lot).  Is there any support for
such things?  If not, has anyone put together a (portable) extension
that supports ALUs?

Along the same lines, the ability to bitblt directly to a window's bit
array would be nice.  I found the file bitblt.lisp in the "contrib"
subdirectory of clim (down a ways on info-mcl), which appears to
provide bitblt'ing for X windows and Genera, but nothing for
Quickdraw.  Has anyone gone to the trouble to create the same
functionality for the Mac?

Thanks for any pointers on these issues,
Tom
From: cfry@MIT.EDU (Christopher Fry)
Newsgroups: comp.lang.lisp.mcl
Subject: print-db & *error-output*
Date: 12 Jan 93 00:04:07 GMT

Print-db prints to *error-output* which automatically causes the
listener to become the front window before it prints into it.

Especially when debugging window system code using print-db you want the
current front window to remain the front window throughout the 
print-db call. Semanitically I think of print-db more 
like a user-injected trace, rather than a program error.
Trace-output does not pop the listener to the front.

One way around these problems is to define your own macro:

(defmacro print-db-fry (&rest args)
  `(let ((*error-output* *trace-output*))
     (print-db ,@args)))

but I propose the MCL print-db be changed to use *trace-output* in place
of *error-output*. The most flexibile would be to have it use
*print-db-output* stream and let the hacker set it to what they want.
I'd vote for the default being *trace-output*, though this extra hair
is unnecessary for most uses I can think of at the moment.

I'm guilty of introducing this function to CCL so, if it hasn't been changed
since then, I guess I'm to blame for the current behavior.
From: Espen J. Vestre <espen@coli.uni-sb.de>
Newsgroups: comp.lang.lisp.mcl
Subject: problems with multiple volumes with equal names
Date: 8 Jan 1993 14:56:27 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: <A77353E262014453@mp-mac10.coli.uni-sb.de>
X-XXDate: Fri, 8 Jan 93 14:53:06 GMT

Because I started to use file sharing on my mac before I had figured out
a good name for its HD, it's now doomed to have the name "Macintosh HD". 
I often mount the whole HD from other macs which also have "Macintosh
HD"s.  Now this seems to confuse MCL, probably because MCL doesn't work
with the full zone:machine:volume:path name for the file, but only with
the volume name and the path.  What happens is that if I try to open a
FRED window for editing a file on my (remotely mounted) HD, MCL lets me
use the standard file choosing dialog, but then tries to open a file with
the same pathname on the local volume.

Is there a workaround for this bug?

In any case:  Does anyone know of a hack to change my HDs name into
something more interesting (I know that it's possible to do it by booting
from Sys. 6, but that won't work on a Quadra)

  -espen.
--------------------------------------------------------------
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: language@skdad.usask.ca
Newsgroups: comp.lang.lisp.mcl
Subject: Re:  flooding region w/ paint -- how?
Date: 6 Jan 93 19:26:44 GMT

> You know how in MacPaint and similar paint programs you can
> click on a pixel and fill the surrounding region with paint?

as a matter of fact,  there are quickdraw primitives for both
the paint bucket tool,  and the laso tool found in macpaint.
Check the docs for the SeedFill and CalcMask routines,  and their
colour counterparts SeedCFill and CalcCMask.

    -john montbriand
From: hmadorf@eso.org
Newsgroups: comp.lang.lisp.mcl
Subject: information-sifitng front ends to data bases
Date: 12 Jan 93 12:39:08 GMT

Hi MCLers,

has anyone out there written applications for information retrieval
or information filtering? I am interested in extensible,
programmable high-level DB interfaces which 
- implement spreadsheet functionality or
- can be used for personal bibliographical databases or
- perform fuzzy matching or
- carry out statistical classification or
- serve as user-friendly database client to an SQL (Sybase)
RDBMS on a Unix box accessible via TCP/IP.

Any pointers, also to the published literature, are welcome.

Thanks.

Hans-Martin Adorf
ST-ECF/ESO
adorf@eso.org
Newsgroups: comp.lang.lisp.mcl
From: wlim@gdstech.GRUMMAN.COM (Willie Lim)
Subject: Portable versions of Windows and Views
Organization: Grumman Corporation, Bethpage, New York, USA.
Date: Mon, 11 Jan 1993 14:56:00 GMT

I have an MCL application that I want to port to an SGI machine with a
Franz CLOS/CLIM environment.  Does anyone know if there are portable
versions (e.g. CLIM) of MCL's GUI interface functions (e.g. those for
window, views, dialogs) available?  This will save me the time of
having to rewrite the GUI code in CLIM.



Willie
From: lynch@ils.nwu.edu
Newsgroups: comp.lang.lisp.mcl
Subject: Re: MCL size/distribution (was: MCL support for MOP)
Date: 11 Jan 93 17:20:49 GMT

A tree shaker would definitely be a BIG plus in my mind.

The other ideas sound good, but one little mistake would lead to version
control nightmares; which is not to say don't do them, but take the time to
do them right. :-)
One suggestion I would have is that at any given time, any app should be
able to quickly list what modules have been loaded.  I have already
uploaded one module to the archive, only to find that it used an internal
module that wasn't ready for release.  [Ok, so I'm just an idiot.]  With
shared libraries tucked away in the System folder somewhere, this could
only get worse.

Also, I'm not sure what problem the latter two are intended to solve.  Most
developers have hardware that can handle the size needed by MCL; it's the
end-user that requires a reasonably sized app.
-- 
--
-- "TANSTAAFL" Rich lynch@ils.nwu.edu
From: cfry@MIT.EDU (Christopher Fry)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: CLIM vendor for MCL
Date: 11 Jan 93 17:06:06 GMT

> Someone tell me the vendor (name, address) and price of CLIM for MCL?
Lucid in Menlo Park, CA. I think its about $500 but you should talk to 
them directly. 

>I have an MCL application that I want to port to an SGI machine with a
>Franz CLOS/CLIM environment.  Does anyone know if there are portable
>versions (e.g. CLIM) of MCL's GUI interface functions (e.g. those for
>window, views, dialogs) available?  This will save me the time of
>having to rewrite the GUI code in CLIM.

This is the BIG problem. CLIM 2.0 will have the ability to
support mac-like dialog items, etc though the beta version from
Lucid for the Mac isn't due until spring 93.
Even with 2.0, there's problably a bunch a widget work to do to
support all the MCL window system stuff we know and love.

Even with all of that a port will not be trivial. It will be more like a
total rewrite of the GUI part of your code, but at least a rewrite in a 
language that stands a chance of giving you the support you need.

A dark horse candidate for porting MCL apps is Quorum's  'Equal" product 
that some day is supposed to be able to take any Mac application and 
run it on a variety of Unix machines, unchanged. I'm taking about the 
actual binary application, without recompilation.
My last message from Quarum said they hoped to ship Equal 1st quarter 
93. This is tricky  technology so don't hold your breath. My guess is 
that some extra work will have to be done to get MCL apps to work, just 
because they can't think of everything. Still, that solution would be 
easiest for MCL users. 

Quorum has mentioned SGI Indigo in their literature for their other 
product, "Latitude", so I'd be surprised if they're not planning an
SGI version of Equal.

Quarum is also in Menlo Park, CA, 415 323-3111
From: lafourca@imag.fr (Mathieu Lafourcade)
Newsgroups: comp.lang.lisp.mcl
Subject: Standard object library in CLOS
Date: 12 Jan 93 16:45:57 GMT

Is there currently any project on building a standard, portable object
library for CLOS. And what about the Application Framework project we heard
about some time ago ? Something like MacApp but for and with CLOS...

Any informations ?

---
Lafourcade Mathieu
GETA (Groupe d'Etude pour la Traduction Automatique)
IMAG (Institut de Mathematiques Appliquees de Grenoble)
BP 53X, 38041 GRENOBLE CEDEX, FRANCE

Lafourca@imag.fr
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: remove-view-from-window
Date: 6 Jan 93 17:26:12 GMT

At 21:28 1/5/93 +0000, John R. Gersh wrote:
>In article <9301051918.AA19536@newton.apple.com> Maurice Sharp writes:
>>
>>According to both the manual and MCL.help the arguments to
>>remove-view-from-window are a view and a window.
>>
>>This is not correct, there are actually no arguments.
>>
>
>Well, actually there seem to be three versions:
>        
>        The manual says that the argument to remove-view-from-window
>        is a view.
>
>        The built-in documentation (c-x c-d) says that the arguments
>        are a view and a window.
>
>        If you inspect the function the inspector window says that its
>        arglist is nil.
>
>The manual appears to be correct - the function works as one would
>expect from its description if you give it a view as an argument.

John is correct. The manual has it right; one argument: a view. The other two problems
are bugs in the on-line help file.
From: kab (Kim Barrett)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: call-next-method
Date: 12 Jan 93 13:29:23 GMT

> Is it really correct if a compiler warns in the following code
> 
> (defclass test ()
>   ()
>   )
> 
> (defmethod testmethod ((ich test) foo)
>   (print foo))
> 
> (defclass test-1 (test)
>   ())
> 
> (defmethod testmethod ((ich test-1) foo)
>   (call-next-method))
> 
> (testmethod (make-instance 'test-1) 4)
> 
> with 
> ;Compiler warnings :
> ;   Unused lexical variable Foo, in Testmethod.
> 
> since foo is actually used in testmethod ((ich test) foo)
> because of the call-next-method?

Yes, this is correct behavior.  The call-next-method does not refer to the 
parameter foo, it (conceptually) gets the value that foo is bound to from some 
other place.  Recall that modifying the value of foo (by setq within the method 
body) does not change the set of values that are passed along by 
(call-next-method).

> My problem is that Macintosh Common Lisp 2.0 warns but
> Allegro Cl/PC 1.0 does not and I have to exchange code
> between the two platforms. Even worse, if I change
>  testmethod ((ich test-1) foo) to
> 
> (defmethod testmethod ((ich test-1) foo)
>   (declare (ignore foo))
>   (call-next-method))
> 
> Macintosh Common Lisp 2.0 is satisfied but Allegro Cl/PC 1.0
> complains that foo is actually used and not ignored, so I have to write
> 
> (defmethod testmethod ((ich test-1) foo)
>   #+:ccl-2 (declare (ignore foo))
>   (call-next-method))
> 
> what is quite annoying, since this code is really not platform-dependent

I'd call this a bug in Allegro CL/PC 1.0, and would change that #+ccl-2 to be a 
#-<feature for allegro cl/pc 1.0>.
From: straz@cambridge.apple.com (Steve Strassmann)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: CLIM vendor for MCL
Date: 11 Jan 93 18:30:28 GMT

>Date: Mon, 11 Jan 93 12:06:06 EST
>From: cfry@MIT.EDU (Christopher Fry)
>To: chris@starbase.MITRE.ORG (Chris Elsaesser)
>Subject: Re: CLIM vendor for MCL
>Cc: info-mcl@cambridge.apple.com
>
>>I have an MCL application that I want to port to an SGI machine with a
>>Franz CLOS/CLIM environment.  Does anyone know if there are portable
>>versions (e.g. CLIM) of MCL's GUI interface functions (e.g. those for
>>window, views, dialogs) available?  This will save me the time of
>>having to rewrite the GUI code in CLIM.
>

Another possible solution is "Action!" from Expertelligence, another
cross-platform GUI toolkit. You'll find a demo version on your 
MCL 2.0 cd-rom.
From: gilberte@media.mit.edu (Gilberte Houbart)
Newsgroups: comp.lang.lisp.mcl
Subject: ACTION! (was ECLIM vendor for MCL)
Date: 12 Jan 93 00:31:47 GMT


Just for the record, ACTION! has quite an interesting history. Its
first version was developed by the same person - Jean-Marie Hullot -
who then did the Interface Builder on the NeXT which is an amazingly
elegant and creative tool in terms of developer user interface (I
compared about 3 years ago (already!) several of those tools). In fact
the author got almost hired the day Steve Jobs saw the demo and
realized the potential of this kind of tool. It certainly largely
contributed to increase the productivity of NeXT programmers.

Gilberte