Mops FAQ (August) 
Author Message
 Mops FAQ (August)

==============  Mops FAQ - August '95 (current version: 2.6)  ================

G'day.  (I'm Australian, OK?)  Welcome to the Mops FAQ file.

Please read this before emailing me with a problem - answering lots of
individual email messages can take up a lot of time in which I could be
working on improving Mops, and I have to fit all this into the little
spare time I have anyway.

Also make doubly sure you've looked at the section near the end called
"KNOWN BUGS IN 2.6, AND FIXES."  Thanks.

I'll post this list every month or so.

--  Mike.


Q. What is Mops?

A. Mops is a public-domain development system for the Mac.  It's based on
Forth, with extensive OOP extensions, along the lines of Smalltalk.  It comes
with a class library which gives support for all the normal Mac interface
functions.  While not as full-featured as MacApp, say, it's very adequate for
the kind of applications which might be developed by one programmer.

Q. Where did it come from?

A. Mops is derived from Neon, which was one of the first languages for the
Mac that allowed actual development on the Mac itself.  It's a close cousin
to Yerk, which is a more "conservative" development of Neon, basically aimed
at keeping up with later Macs and systems while remaining fully compatible
with Neon.  Mops is more "radical".  It's a complete reimplementation which
compiles native (68K) code instead of the usual Forth threaded variety.  It's
very fast -- about as fast as anything on the Mac in fact.  It has a few
other improvements over the original Neon, such as multiple inheritance,
and temporary (local) objects.

Q. Where can I get it?

A. WWW:   <URL: http://www.*-*-*.com/ ~jayfar/mops.html>
       (thanks to Jayfar (Jay Farrell) for starting this page - please let

   ftp: //

   ftp: //
       (this is the main Forth ftp site)

The Mops files are Mops26s.sea (the system) and Mops26m.sea (the manual).

Mops is also on CompuServe (FORTH forum, library 4).

Some other Mops code is available on the taygeta site, and there are links
in the WWW page.

astro and taygets are the main sites -- I always make sure the latest
version is there.  I can't always ensure this for other places where Mops
might be located.

However at present, the current version (2.6) is also on info-mac in
the /dev directory, with the manual in the /dev/info directory.

Q. Do you have any other sample code available, apart from what's at those

A. Sorry, I can't help much.  I've only written one "real" Mops application
myself, and I'm not free to distribute the source.  Most of my Mops time
has been spent on developing it rather than writing applications in it.

If the above ftp and WWW sites don't have what you want, try posting on
comp.lang.forth and comp.lang.forth.mac - maybe somebody else there can help.

Q. Could I learn Mac programming with Mops?

A. Definitely.  It comes with an on-line manual, which is derived from the
original Neon manual.  This assumes a very basic level of knowledge about
programming, and none about the Mac.

Q. Could I learn OOP with Mops?

A. Definitely! - for the same reason as in the last question.  OOP was
still very new when Neon came out, so the manual explains everything from
a very basic level.

Q. I double-clicked the application "Mops", but just got a window with no

A. You didn't read the Readme.1st file!  To save download time, only the
Mops "nucleus" is included.  You have all the source there, so you have
to compile up the full system from the source by following the instructions
in the Readme.1st file.  It's easy.

Q.  I followed the instructions and started to compile the system, but got
a crash.

A.  This is possibly a conflict with some extension you have running.  We've
had problems with SAM (Symantec Anti-virus for Macintosh) and RamDoubler.
Try it again with extensions off (reboot with the shift key down).  Mops
ought to then compile up OK.  You might also be able to turn your extensions
on again afterwards.  But if the conflict persists with the fully-compiled Mops
system, see if you can isolate which particular extension is causing the
problem, and let me know.

By the way, antivirus software is often not very friendly to compilers,
since compilers do things to resources that the antivirus program might
think is virus activity.  But I use Disinfectant all the time, and have
never had any problems with it.

Q. I compiled up the Mops system OK, but now when I type lines into the Mops
window, nothing happens - the text just sits there.

A. You've probably been using an earlier Mops version, and when you got
2.6 you didn't read the Readme.1st file.  Please do.  The interface isn't
the same.  Now that we have a proper editing window, typing RETURN just starts
a new line.  You have to type ENTER to cause execution (this is what MPW does
as well).  Some applications treat ENTER and RETURN as equivalent, but not
Mops.  Along with the new interface, there's also much more extensive
communication with Quick Edit, which you won't want to miss.

Q. Q. I compiled up the Mops system OK, but when I double-click on Mops.dic,
I get a crash.

A. The most usual cause of this is that you are upgrading from an earlier
version of Mops, and you still have a copy of the earlier Mops nucleus
around.  From the Mac's point of view, "Mops.dic" is a document belonging
to the application "Mops".  When you double-click on "Mops.dic", the Mac
system launches the application "Mops", but if you have two versions of
Mops around, you can't be sure that it will fire up the latest.  In fact,
it probably won't.  As the location of words in the nucleus will be different
between versions, you can't have a new dictionary running on top of an old
nucleus - you'll just get a crash.  So trash the old nucleus (if you're the
cautious type, you can save it onto a floppy first, then eject the floppy).
That way, the Mac is forced to fire up the right version of Mops.

Q. My code works fine in the Mops environment, but when I install it as an
application strange things happen.

A. There are a couple of things that could be wrong here.  A common source of
problems can arise if at compile time you're ticking words, and comma-ing the
resulting execution tokens into a table, then at run time executing the words

from another Forth.

In Mops there's no problem with storing an xt at run time then using it later,
but it's highly dangerous to store it at compile time, save it with the
dictionary, then later try to load the dictionary and use the xt.  This is
because in Mops an xt is simply an absolute address, and absolute addresses
of locations in your code will probably change between runs, depending on where
Mops or your application happens to load into the Mac's memory.

The best way to handle this kind of operation is with a DicAddr, X-Addr or
X-Array object.  Please see the section "Addresses--relocatable and absolute"
in Part II of the manual.

Q. I tried to run Mops, but it didn't work.

A. AAUUGGHHHH!!!  Call this a bug report?  I don't.  Yet I actually do
occasionally get messages like this!

Please give me enough information so that at least I might have a fighting
chance of telling what happened.  I probably don't need to know what kind of
Mac or system you're running, since Mops should run on just about anything.
But what I really need to know is:

1. What version of Mops have you got?
2. What did you actually DO to try to run it?  Did you double-click
anything?  What?  Exactly what happened then?  That sort of thing.

Remember, I'm not a mind-reader!

Q. Can I use color in a Mops window?

A. You have to make the window a color window.  The easiest thing to do is
look at the files WindowMod.txt and Window+, and change the NewWindow calls
to NewCWindow, and GetNewWindow to GetNewCWindow, then recompile the system.
I'll probably handle this automatically via an ivar in the next version.

Q. How do I plot an Icon / use the Sound Manager / use an offscreen PixMap
   (insert favorite problem here).

A. Well, if this is a general Mac programming problem rather than something
specifically to do with Mops, I'm not really here to answer this sort of
question.  Try posting on  I have to try
developing the next version of Mops in my spare time, so it's probably not
right for me to be taking time to answer basic Mac programming questions.
I don't have all the answers anyway.  I'm certainly not a substitute for
Inside Mac.  Read the appropriate parts first, and if you're still stuck,
try the newsgroup.  There are plenty of people willing and able to help there.

Q. What's the minimum system I need to run Mops?

A. Mac Plus or 512KE, 2 megs RAM, 4 megs spare hard disk space.

Q. You're joking, surely?

A. No I'm not!

Q. Will a future Mops version compile native code for the Power Mac?

A. I hope so.  I'm working on it, but it's a big job.  It will certainly
take me the rest of this year.

Q. What about a Windows version?

A. A couple of people have contacted me, who thinking about looking at this.
If anybody else is interested, let me know, and I'll pass on contact information

But it will be quite a big job.  It could possibly be built on top of an
existing Windows Forth, but the hard part would be modifying all the classes
to connect to the Windows API instead of the Mac.

I can't really give any further help, since I don't have time, and in any
case I've never programmed for Windows.

Q. Will you continue to support Mops for some time to come?

A. I've been doing it for 6 years now, and don't plan to stop!

Q. Why an oddball language that isn't C++?

A. Try it and see how quickly you can get things done.  The most popular
way isn't always the best way.  After all, you're using a Mac, aren't you?

----------------------- KNOWN BUGS IN 2.6, AND FIXES -------------------------

1.  This is actually an old bug, but it's only just been reported.  It can bite
you if you close all your windows.  I keep a value actW, which is a pointer to
the frontmost Mops window, or is zero otherwise.  I was forgetting to clear it
when I closed a window.  This usually didn't matter, since whenever another
Mops window got an activate event, actW was set correctly by the activate: metho
But if there was only one Mops window open, and it got closed, actW was left
pointing to outer space.  This could cause a phantom white rectangle to get draw
somewhere when I attempted to erase the grow icon on the nonexistent window - or

you could simply crash.

To fix it, look in the file WindowMod.txt, find the CLOSE: method, and replace
it with this:

    get: alive  0EXIT
    ^base  call CloseWindow
    ^base actW = IF  0 -> actW  THEN    \ If this was the active window, it
                                        \  isn't any more
    clear: alive   exec: close  ;m

You don't need to recompile the Mops system.  Just do
compile: windowmod

then quit Mops (so it doesn't get confused about which version of WindowMod is
running).  When you start up Mops again, everything should be OK.

2.  This bug can cause occasional crashes, and most particularly, spurious
"dictionary overflow" errors.  If you're getting anything like this, the fix
below will probably cure it.

In the file Class, in the definition RUNREF, look for the lines

    selID compRef        \ compile the binding
    postpone (exit)        \ and an exit, so we return to interpretation
    svState -> state        \ restore state

Then straight after that, add the line
    0 -> hiDP            \ don't need it any more and could cause problems

I'll put the whole definition here, so you can cut and paste:

: RUNREF  { selID \ svDP svBufPtr svState -- }
    DP -> svDP                \ save DP
    DP hiDP umax -> hiDP    \ so we can reset DP to right place on an error

    bufPtr NIF  runRefBuf  ELSE  bufPtr  THEN
    dup -> DP  -> svBufPtr    \ now we'll compile in runRefBuf
    state -> svState        \ save state
 postpone ]            \ need compile state so this compilation works properly
    selID compRef        \ compile the binding
    postpone (exit)        \ and an exit, so we return to interpretation
    svState -> state    \ restore state
    0 -> hiDP            \ don't need it any more and could cause problems
    DP -> bufPtr        \ new bufPtr value
    svDP -> DP            \ restore DP since the code might compile something
    patches_done        \ we're about to execute what we just compiled
    svBufPtr execute    \ execute at old bufPtr location
    svBufPtr -> bufPtr    \ then restore old bufPtr

I'll add to this list if (when?) new bugs are discovered.


                     (no longer on Compuserve)                  /      \
It is not possible for everybody to be right,                         v
but it is perfectly possible for everybody to be wrong. (ancient proverb)

Fri, 16 Jan 1998 03:00:00 GMT  
 [ 1 post ] 

 Relevant Pages 

1. Mops FAQ (March 98)

2. Mops FAQ (May)

3. Mops FAQ

4. Mops FAQ

5. Mops FAQ

6. The Mops FAQ

7. draft FAQ for comp.lang.logo, August, 1993

8. FAQ: comp.lang.tcl Frequently Asked Questions (3/5) (Last updated: August 19, 1994)

9. FAQ: comp.lang.tcl Frequently Asked Questions (1/5) (Last updated: August 10, 1993)

10. FAQ: comp.lang.tcl Frequently Asked Questions (2/5) (Last updated: August 10, 1993)

11. FAQ: comp.lang.tcl Frequently Asked Questions (5/5) (Last updated: August 10, 1993)

12. FAQ: comp.lang.tcl Frequently Asked Questions (1/5) (Last updated: August 10, 1993)


Powered by phpBB® Forum Software