[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]
Quote:
> Date: Fri, 14 Jun 2002 07:07:18 +0000 (UTC)
> ....
> | ;;; 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!
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.
Quote:
> >I guess another option is to produce a package made of two files
> > executable(basepop11)+saved image,
> >(plus a shell script to run them) which has been used for some
> >commercial packages.
> 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.
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
Quote:
> 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.
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