Hi,

| For now, I have a (hopefully) simple question about POPC: I want to make a
| standalone version of SIMWORLD, which people can use (without having to
| install the POPLOG).  However, I keep running into problems compiling
| objectclass (have not even gotten to SIMAGENT or SIMWORLD yet...).  This
| is what I get when I try to compile objectclass.p (either alone or when I
| try to compile SIMWORLD):

Unfortunately I wrote ObjectClass prior to POPC being generally
available, even in a preview version.  I guessed as to what the
limitations would be but, alas, I guessed wrongly.  Wildly wrongly.
I have always been under the impression that ObjectClass breaks so
many of the ghastly POPC limits that there was no prospect of getting
it working properly.

| ;;; DECLARING VARIABLE OBJECTCLASS_IN_POPC
|
| ;;; MISHAP - POPC: ILLEGAL ASSIGNMENT TO CONSTANT IDENTIFIER
| ;;; INVOLVING:  1100 pop_oc_version
| ;;; FILE     :  /usr/local/poplog/v15.53/pop/lib/objectclass/objectclass.p
| ;;;       LINE NUMBER:  19

This particular problem looks simple: the command "lib objectclass"
causes a short file to be loaded that establishes a few necessary
facts about the loading environment (mainly so you can establish the
ObjectClass development environment as an alternative to the normal
running mode.)  It should be easy to track down where pop_oc_version
is declared and assigned to in the loading sequence since it will be
in the somewhat casually written short loading file.

| The documentation on objectclass says that it should compile, so I take it
| I must be doing something wrong...  Maybe you have an idea?  Thanks.

This is news to me!  If I had a working copy of Poplog available I
would try to find this documentation myself.  Could someone post me
the relevant snippet - I'd love to see this!

Yes, this is the only general method for delivering Poplog
applications.  This is similar to (although clumsier than) how Perl
and python work, of course, so it is a generally acceptable delivery
method.

It is a _great_ shame that there is no option for dumping saved
images with a leading line "#!/usr/local/poplog/pop/com/run_psv" (or
whatever) so that you can just set "chmod a+x" and avoid the tedium
of having to coordinate the location of script and saved image.  (I
guess you would want to be able to specify the string that is put
after the "#!".)  This would actually make saved images much, much
more useful than they currently are.

In a similar vein, it would be _very_ nice if there was a way to
write standalone "#!" scripts just like Perl or Python.  My feeling
is that we would need a special executable for this because of the
limitations for processing arguments for #! scripts and Poplog has
become rather complicated in its command line requirements.  I
embarked on this work a couple of years ago, got a long way and ran
out of time.  I would be happy to share my documentation and C source
code it with anyone else who is interested.

--
Steve

[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]

The ref file that includes this can be read (without Ved's character
attributes) here:
    http://www.cs.bham.ac.uk/research/poplog/doc/objectclassref/objectclass

The snippet in question is

| -----------------------
| 5  Objectclass and Popc
| -----------------------
| You can compile  an objectclass program  into a stand-alone  application
| with Popc subject to the following restrictions:
|
| (1) Only the  syntax  forms  defined  by  the  objectclass  library  are
|     supported by  Popc.  Run-time operations  such  as  class_construct,
|     create_instance, will_apply_to, and most of the others described  in
|     this file, are  simply not available  in a stand-alone  application.
|     This is because  all objectclass information  is stripped from  keys
|     compiled into the application -- making them indistinguishable  from
|     ordinary Poplog keys -- and generic procedures are frozen into their
|     linked form.
|
| (2) The whole program must be compiled as a single object file. You  can
|     still compile a program from several source files, but only if  they
|     are compiled together into one module using the '-g' option of Popc:
|
|         popc -g program.w \( file1.p file2.p ... \)
|
|     This is because poplink  is unable to  link generic procedures  from
|     method parts defined in  separate modules. An unfortunate  corollary
|     of this restriction  is that you  cannot separately-compile  library
|     modules containing objectclass definitions.
|
| For an objectclass program to be compiled with Popc, it must include the
| line:
|
|     uses-now objectclass;

I assume Matthias followed those instructions (he is usually very
good at getting things to work). The source file that apparently
produced the error message is readable remotely here:

http://www.cs.bham.ac.uk/research/poplog/src/master/C.all/lib/objectc...

It's only 115 lines. The error apparently happened at the last line
in this extract:

| compile_mode:pop11 +strict;
|
| section $-objectclass => pop_oc_version;
|
| ;;; Setup the environment
| #_IF not(DEF objectclass_dir)
| constant objectclass_dir = sys_fname_path(popfilename);
| #_ENDIF
| uses objectclass_help;
|
| constant pop_oc_version = 1100;

I can't see anything wrong with that.

I have not had time to experiment with this.

I presume that it would not be very hard to alter the code that
makes saved images to produce that line, and the code that restores
saved images to ignore it. It should allow use of environment
variables so that portable versions give the user an option
regarding location without having to rebuild the saved image.

There's a small step in this direction that was introduced in 1996.

| Aug 29 (John Gibson)
|    ??? Poplog can now be run with a sequence of layered saved images by
|        specifying just the last one, e.g. instead of
|
|            basepop11 +startup +prolog +foo
|
|        you can now use any of
|
|            basepop11 +foo
|            pop11 +foo
|            prolog +foo

But it has the problem that it breaks if you compile the saved
images in one place for testing, then move them to another place.
(Which is what I do for the generally available local saved images).

A small step in the direction you mention would be a
sys_make_package procedure, that would use a modified version of
sysssave, or sys_lock_system or mkimage. It could be given some
arguments on the basis of which it would create not just a saved
image, but a directory containing a copy of basepop11, a saved image
to be run, a shell script to run the saved image on top of
basepop11, plus any additional files required at run time, e.g.
help, teach, or autoloadable extras.

I don't know if this is already to some extent covered by
pop_ui_projecttool, described here:

    http://www.cs.bham.ac.uk/research/poplog/doc/popxhelp/pop_ui_projecttool

If you have a package you'd like to put in a tar file I could add it
to
    http://www.cs.bham.ac.uk/research/poplog/

for easy access.

Aaron
====
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK

PAPERS: http://www.cs.bham.ac.uk/research/cogaff/ (And free book on Philosophy of AI)
FREE TOOLS: http://www.cs.bham.ac.uk/research/poplog/freepoplog.html