I am sure that some of the .mac files were replaced because at some time
I had the maxima source code for the gamalg package( I hoped I stored it
on disk somewhere ). So, it appears that at least one .mac file was
replaced. dispfun works to get the source code but it would be more
convenient to have the orginal listings.
Dick Fell
Richard Fateman wrote:
>
> richard noel fell wrote:
> >
> > Am I mistaken, or did not earlier versions of many of the programs in
> > the share libraries have files with .mac extensions and were maxima
> > code? Now, there is an abundance of .mc files. It will be more difficult
> > to get any broken programs working if the maxima source code is not
> > available.
>
> I don't know about the recent (post-1982) revisions of the share libraries,
> but the loss of any source files is unfortunate. Could they be
> in some other directory? I hope that none of this was deliberate.
>
> If the source code has been lost, but the untranslated code was
> saved, then the macsyma source, without comments, can be
> reconstructed.
> For example, share/recur.lsp appears to be a "saved" file. reading
> it in and doing dispfun(polyp) should get you the source.
> But in this case we have the source, anyway.
>
> If the code has been translated into lisp programs and saved
> ONLY in that form, it is not possible to automatically
> reconstruct the source. Some of that code may have been
> hand-modified to improve the speed, so even if you had
> the macsyma source, translate() would not produce the same result.
> Sometimes this lisp code is readable, but only if you
> are familiar with lisp.
>
> I was looking at some of the stuff, poorly written and undocumented,
> perhaps wrong or dependent on some accidental properties of
> expressions, and found it discouraging.
>
> Some more specifics:
>
> The unlisp files are log files from a compiler, and I think
> are not necessary, though at one time they might have had some
> use.
>
> The particular files determ and kach look like the lisp files
> were simply the result of translating the mc files, without further
> elaboration.
> Why store both?
> Translating used to take a longer time, and the
> space taken by the source code used to be more significant.
> I think the .lsp files are redundant in these two cases,
> given the current reality of computers that are 500 times
> faster and have 200 times as much RAM, and 2000 times as much
> disk space.
>
> As for why there are dem and mac directories, etc.
> No reason comes to mind, however, realize that on the PDP-10
> ITS timesharing system
> (a) each user had ONE disk directory, not hierarchical.
> (b) there was a limit to how many files could be put in
> that directory.
> share1, share2, ... etc. were probably different USERS.
>
> ITS did not have passwords or protection, so you could
> look at, and write into any other users directories.
>
> It was a different time.
>
> RJF
>
> richard noel fell wrote:
> >
> > Am I mistaken, or did not earlier versions of many of the programs in
> > the share libraries have files with .mac extensions and were maxima
> > code? Now, there is an abundance of .mc files. It will be more difficult
> > to get any broken programs working if the maxima source code is not
> > available.
> > Dick Fell
> >
> > "Vadim V. Zhytnikov" wrote:
> > >
> > > Hello!
> > >
> > > I'm trying to make a few steps further in sorting out Maxima
> > > share directories. Cliff already did quite nice work on it.
> > > Thank you Cliff !
> > > But before presenting results in the form of some script I'd to
> > > discuss several points and ask for some advice.
> > >
> > > 1). File extensions. It seems that we already more or less
> > > implicitly agreed to use following standard extensions
> > > for Maxima files of various types:
> > >
> > > .mac - Maxima source code
> > > .lisp - Lisp source code
> > > .dem - Maxima demo files (maxima code)
> > > .usg - Documentation for packages in share directory
> > >
> > > There are some troubles with renaming all files to such scheme.
> > >
> > > (a) files in share* mostly have extensions .mc and .lsp and
> > > sometimes filenames are hardwired in source code. So renaming
> > > will certainly break something. This is not so important
> > > at present since directory names (share,share1,2,m etc) are also
> > > usually hardwired in source code. If we are going to get rid
> > > of this historical share* scheme and replace it by more logical
> > > one then some extra work on all share files are required
> > > in any case.
> > >
> > > (b) some packages have several demo files and
> > > now the are named
> > > package.dem package.dm1 package.dm2 ...
> > > I suggest to rename them as follows
> > > package.dem package_1.dem package_2.dem ...
> > >
> > > 2). Many packages have two files
> > > package.mc and package.lsp
> > > which are either completely equivalent (both lisp
> > > code actually) or differ just by two-three lines - usually
> > > some declarations or assignments in the very beginning
> > > of file. I'm inclined to remove .lsp and replace it by .mc
> > > renamed to .lisp.
> > >
> > > 3). In many other packages package.lsp is the lisp
> > > equivalent of maxima source package.mc
> > > automatically generated by some translator.
> > > The question is - what is the purpose of these .lsp
> > > files? Do they have any independent value or can be
> > > easily re-created? If so I think we have to drop them.
> > >
> > > Example: determ or kach package in share1
> > >
> > > Richard, could you take a look on them and
> > > return you verdict.?
> > >
> > > In addition a few packages have extra files
> > > package.LISP and package.UNLISP
> > > (sometime they have other extensions).
> > > .LISP also looks like automatically generated
> > > lisp equivalent of .mc but has a bit different
> > > structure.
> > > .UNLISP looks like some log file.
> > > What are they? Do we need them?
> > >
> > > Example: fourie package in share1
> > >
> > > 4). Do anyone know exact purpose
> > > of /demo and /mac directories?
> > > Is /demo directory for some general demo
> > > files which do not belong to any package
> > > in share?
> > > Is /mac directory intended for core Maxima
> > > source files which is not lisp but rather maxima?
> > > It seems that all files in /mac formerly
> > > belonged to /share* but later were moved
> > > into /mac.
> > >
> > > Any comments are greatly appreciated,
> > >
> > > Vadim
> > >
> > > --
> > >
> > > [ Vadim V. Zhytnikov <vvzhy@mail.ru> <vvzhy@td.lpi.ac.ru> ]
> > >
> > > _______________________________________________
> > > Maxima mailing list
> > > Maxima@www.math.utexas.edu
> > > http://www.math.utexas.edu/mailman/listinfo/maxima
>
> One possibility that
> > Dick Fell
> >
> > "Vadim V. Zhytnikov" wrote:
> > >
> > > Hello!
> > >
> > > I'm trying to make a few steps further in sorting out Maxima
> > > share directories. Cliff already did quite nice work on it.
> > > Thank you Cliff !
> > > But before presenting results in the form of some script I'd to
> > > discuss several points and ask for some advice.
> > >
> > > 1). File extensions. It seems that we already more or less
> > > implicitly agreed to use following standard extensions
> > > for Maxima files of various types:
> > >
> > > .mac - Maxima source code
> > > .lisp - Lisp source code
> > > .dem - Maxima demo files (maxima code)
> > > .usg - Documentation for packages in share directory
> > >
> > > There are some troubles with renaming all files to such scheme.
> > >
> > > (a) files in share* mostly have extensions .mc and .lsp and
> > > sometimes filenames are hardwired in source code. So renaming
> > > will certainly break something. This is not so important
> > > at present since directory names (share,share1,2,m etc) are also
> > > usually hardwired in source code. If we are going to get rid
> > > of this historical share* scheme and replace it by more logical
> > > one then some extra work on all share files are required
> > > in any case.
> > >
> > > (b) some packages have several demo files and
> > > now the are named
> > > package.dem package.dm1 package.dm2 ...
> > > I suggest to rename them as follows
> > > package.dem package_1.dem package_2.dem ...
> > >
> > > 2). Many packages have two files
> > > package.mc and package.lsp
> > > which are either completely equivalent (both lisp
> > > code actually) or differ just by two-three lines - usually
> > > some declarations or assignments in the very beginning
> > > of file. I'm inclined to remove .lsp and replace it by .mc
> > > renamed to .lisp.
> > >
> > > 3). In many other packages package.lsp is the lisp
> > > equivalent of maxima source package.mc
> > > automatically generated by some translator.
> > > The question is - what is the purpose of these .lsp
> > > files? Do they have any independent value or can be
> > > easily re-created? If so I think we have to drop them.
> > >
> > > Example: determ or kach package in share1
> > >
> > > Richard, could you take a look on them and
> > > return you verdict.?
> > >
> > > In addition a few packages have extra files
> > > package.LISP and package.UNLISP
> > > (sometime they have other extensions).
> > > .LISP also looks like automatically generated
> > > lisp equivalent of .mc but has a bit different
> > > structure.
> > > .UNLISP looks like some log file.
> > > What are they? Do we need them?
> > >
> > > Example: fourie package in share1
> > >
> > > 4). Do anyone know exact purpose
> > > of /demo and /mac directories?
> > > Is /demo directory for some general demo
> > > files which do not belong to any package
> > > in share?
> > > Is /mac directory intended for core Maxima
> > > source files which is not lisp but rather maxima?
> > > It seems that all files in /mac formerly
> > > belonged to /share* but later were moved
> > > into /mac.
> > >
> > > Any comments are greatly appreciated,
> > >
> > > Vadim
> > >
> > > --
> > >
> > > [ Vadim V. Zhytnikov <vvzhy@mail.ru> <vvzhy@td.lpi.ac.ru> ]
> > >
> > > _______________________________________________
> > > Maxima mailing list
> > > Maxima@www.math.utexas.edu
> > > http://www.math.utexas.edu/mailman/listinfo/maxima