\start
Date: Sun, 31 Oct 2010 21:57:22 -0400
From: Camm Maguire
To: Gabriel Dos Reis
Subject: Re: [Gcl-devel] Re: open-axiom builds on mingw32
Cc: Donald Winiecki

My apologies -- one small change required in the open axiom
src/lisp/Makefile -- comment out the cp of rsym.exe, which is now
obsolete.  (Perhaps make it conditional on the file being present, to
interwork with earlier versions.)

fricas builds too, but with the above change, and a manual replacing
of all the /c/ paths in src/lisp/Makefile with c:/.  Tried alias
pwd="pwd -W", but this did not seem to do the trick.

I wish I could figure out a clean resolution to these path issues, as
they also arise with the hol88 I've tried to build.  But I'm taking
your advice and leaving the GCL path system alone in this.  Strangely,
acl2 and maxima don't seem to be affected.

Take care,

Gabriel Dos Reis writes:

> On Fri, Oct 29, 2010 at 8:24 PM, Camm Maguire wr=
ote:
>> Greetings! =C2=A0P.S. =C2=A0Would be great if someone else could confirm=
 before
>> release ....
>
> Hi Camm,
>
>  I did the following:
>
>   1. `make clean' in the local tree
>   2. update local copy of CVS gcl-2.6.8pre
>   3. build GCL
>   4. install GCL
>   5. make clean (GCL directory)
>   6. configure OpenAxiom for build with gcl
>   7. make
>      This step fails (at base-lisp.exe construction) with
>
> Failed to open c:/Docume~1/gdr/Desktop/gcl-2.6.8.cvs/unixport/raw_gcl.exe=
 (2)...
> bailing.
>
>
> I suspect this must be related to GCL trying to figure out what
> si::system-directory
> should be.
>
> I think GCL should be looking to the install directory, but somehow it do=
es not.
> Does that sounds plausible?
>
> -- Gaby
>
>
>
>
>>
>> Gabriel Dos Reis writes:
>>
>>> Camm Maguire writes:
>>>
>>> | Guess I should try fricas.
>>>
>>> Hi Camm,
>>>
>>> That is great news!
>>> Did you have to patch locally GCL or is current trunk (2.6.8pre) all it
>>> takes?
>>>
>>> In principle, you should be able to build FriCAS natively on Windows
>>> because it derives from axiom.build-improvements, but I cannot guarantee
>>> it.

\start
Date: Mon, 01 Nov 2010 09:14:56 -0500
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: [Gcl-devel] Re: open-axiom builds on mingw32
Cc: Donald Winiecki

Camm Maguire writes:

| Greetings!
| 
| My apologies -- one small change required in the open axiom
| src/lisp/Makefile -- comment out the cp of rsym.exe, which is now
| obsolete.  (Perhaps make it conditional on the file being present, to
| interwork with earlier versions.)

Hi Camm,

Thanks for the tip.  I applied the patch below.  I'm not planning on
releasing OpenAxiom-1.4.0 without GCL-2.6.8 fixed so I'm just removing
the rsym hack altogether as implied by the comments :-)

The only issue that remains is for GCL to find its system-directory when
it is installed  Did you get a chance to look at the report?

| fricas builds too, but with the above change, and a manual replacing
| of all the /c/ paths in src/lisp/Makefile with c:/.  Tried alias
| pwd="pwd -W", but this did not seem to do the trick.

Native Windows applications (even when built with msys) should not
hardcode the path with Unix-style pathname.  So, I consider the /c/
issue as a bug in FriCAS's Makefile.

[...]

| >   7. make
| >      This step fails (at base-lisp.exe construction) with
| >
| > Failed to open c:/Docume~1/gdr/Desktop/gcl-2.6.8.cvs/unixport/raw_gcl.exe (2)...
| > bailing.
| >
| >
| > I suspect this must be related to GCL trying to figure out what
| > si::system-directory
| > should be.



*** config/open-axiom.m4	(revision 3828)
--- config/open-axiom.m4	(local)
*************** AC_PROG_CPP
*** 226,252 ****
  OPENAXIOM_CPPFLAGS_FOR_VENDOR_LOCK_INS
  ])
  
- dnl -------------------------
- dnl -- OPENAXIOM_GCL_HACKS --
- dnl -------------------------
- dnl Some auxiliary programs generated by GCL need to be at the
- dnl right place when compiling under mingw32.
- AC_DEFUN([OPENAXIOM_GCL_HACKS],[
- ## The following is a horrible hack to arrange for GCL to successfully
- ## rebuild symbol tables with "rsym" on Windows platform.  It should
- ## go away as soon as GCL upstream is fixed.
- AC_SUBST(axiom_gcl_rsym_hack)
- case $axiom_lisp_flavor,$target in
-     gcl,*mingw*)
-         axiom_gcl_rsym_hack='d=`echo "(format nil \"~a\" si::*system-directory*)" | $(AXIOM_LISP) | grep "/gcl.*/" | sed -e "s,\",,g"`; cp $$d/rsym$(EXEEXT) .'
- 	;;
-     *) 
-         ## Breath.
-         axiom_gcl_rsym_hack=':'
- 	;;
- esac
- ])
- 
  dnl ---------------------------------
  dnl -- OPENAXIOM_SATISFY_GCL_NEEDS --
  dnl ---------------------------------
--- 226,231 ----
*** configure.ac	(revision 3828)
--- configure.ac	(local)
*************** oa_all_prerequisites=
*** 83,89 ****
  AC_SUBST(oa_all_prerequisites)
  
  OPENAXIOM_HOST_COMPILERS
- OPENAXIOM_GCL_HACKS
  OPENAXIOM_HOST_DATA_PROPERTIES
  
  OPENAXIOM_DYNAMIC_MODULE_SUPPORT
--- 83,88 ----
*** src/lisp/Makefile.in	(revision 3828)
--- src/lisp/Makefile.in	(local)
*************** lisp_c_objects = \
*** 92,98 ****
  
  $(OUT)/lisp$(EXEEXT): base-lisp$(EXEEXT)
  ifeq (@axiom_lisp_flavor@,gcl)
- 	@axiom_gcl_rsym_hack@
  	echo '(let* ((sys-cc compiler::*cc*) ' \
  	     '      (sys-ld compiler::*ld*) ' \
  	     '      (compiler::*cc* (concatenate (quote string) ' \
--- 92,97 ----

--=-=-=--


\start
Date: Sat, 13 Nov 2010 16:28:30 +0000
From: Martin Baker
To: Tim Daly,
Subject: Re: Two stage compiler

On Saturday 13 Nov 2010 15:55:08 you wrote:
>   Martin,
> 
> The Spad language is converted into an intermediate lisp
> representations of the form (DEF ... ) and then turned
> into optimized lisp programs and then turned into C and
> then compiled.
> 
> Tim

Thanks very much for the reply.

I somehow got the impression (possibly from daase.lisp.pamphlet I
can't remember now) that the SPAD compiler and the interpreter were
both driven from the database files: (interp.daase, operation.daase,
category.daase, compress.daase, browse.daase) and that this involved a
lot of custom code (different for the compiler and interpreter)
written in a mixture of Lisp and 'boot' code. Have I got this wrong?

It just seemed to me that if, the pattern matching could be separated
out (still driven from the tables), then the rest (Lex, Parse,
Semantic Analysis and so on) could be done by standard tools like
ANTLR.

As I have mentioned before I would really like better error messages
and programming environment and it seemed to me that this might help
with this? I also thought thought it might help you if it made the
code more maintainable?  But, of course, I don't understand all the
practical issues that might stop this working.

\start
Date: Sat, 13 Nov 2010 12:56:16 -0500
From: Tim Daly
To: Martin Baker
Subject: Re: Two stage compiler

  Martin,

I am in the process of tree-shaking (copying only code
that gets referenced) the compiler into literate form
in volume 9.

On 11/13/2010 11:28 AM, Martin Baker wrote:
> On Saturday 13 Nov 2010 15:55:08 you wrote:
>>    Martin,
>>
>> The Spad language is converted into an intermediate lisp
>> representations of the form (DEF ... ) and then turned
>> into optimized lisp programs and then turned into C and
>> then compiled.
>
> Thanks very much for the reply.
>
> I somehow got the impression (possibly from daase.lisp.pamphlet I can't
> remember now) that the SPAD compiler and the interpreter were both driven from
> the database files: (interp.daase, operation.daase, category.daase,
> compress.daase, browse.daase) and that this involved a lot of custom code
> (different for the compiler and interpreter) written in a mixture of Lisp and
> 'boot' code. Have I got this wrong?

The compiler was a mixture of boot and lisp (although boot is just
syntactic sugar over lisp and gets translated to lisp). There is no
boot code in Axiom anymore, it is all common lisp.

Axiom is using a Pratt parser which is very efficient technology.
The Spad compiler parses the top level Spad syntax into a prefix internal
language using "(DEF ...", "(IN ...", "(LEAVE ..." and other forms that
tend to mirror Spad language constructs. These are lisp s-expressions.
 From there these are translated to common lisp. When using GCL, the
common lisp gets translated to C and the C is compiled using GCC.

> It just seemed to me that if, the pattern matching could be
> separated out (still driven from the tables), then the rest (Lex,
> Parse, Semantic Analysis and so on) could be done by standard tools
> like ANTLR.

ANTLR is a java tool. Lisp is so much better suited for doing compiler work
than Java. Once the Spad syntax is translated into s-expressions, these are
the same as AST forms in a compiler. Lisp can easily manipulate these forms
and a lot of optimizations are applied before they get compiled.

Many of these forms can be written as macros and executed
directly. Boot code could not exploit the full power of lisp
macros. It limited you to a Python-like syntax which is somewhat
pointless. Boot code also could not use the structuring functions
(like defstruct, CLOS) properly so a lot of the code relies on global
variables. This will eventually get fixed.

> As I have mentioned before I would really like better error messages and
> programming environment and it seemed to me that this might help with this? I
> also thought thought it might help you if it made the code more maintainable?
> But, of course, I don't understand all the practical issues that might stop
> this working.

The issue of better error messages is a question of keeping context
around. Axiom does tell you exactly what the problem is. It prints the
failed expression in <<...>>, the type of expression it was expecting
and the expression it found. If you understand the internal compiler
s-expressions it is all perfectly obvious :-)

Good error messages require that you keep a trail of where you are in
the original code and how each sub-expression in the original code
relates to the compiled form. This is a matter of careful
book-keeping. It also requires that you related the failure to the
intention of the compiler, a more subtle issue. Even more subtle is
the nuance of the language details. Good error messages are hard.

The Spad compiler was written as a research effort to explore ideas
like encapsulation and dispatching not only on the types of the
arguments but also on the type of the returned value (something very
few languages STILL do not allow). The people who wrote it were also
the only users of it.  So the error messages were perfectly obvious to
us.

One of the eventual goals of the rewrite will be to include this
book-keeping and error messages.

\start
Date: Fri, 19 Nov 2010 11:45:16 +0000 (GMT)
From: Dan Hatton
To: 
Subject: Re: [Maxima] 2.6.8 licensing

On Wed, 27 Oct 2010, Camm Maguire wrote:

> Greetings!  The FSF has requested that we "change the software license
> to GPLv3 or later, and the documentation license FDLv1.3 or later".

(First an assertion of non-authority:  I'm not a copyright holder on
any of the software at issue.  I think I'm listed among the authors of
Axiom, but my contribution really was minimal, and I certainly don't
feel like it gives me any particular right to control the licensing
scheme.  What follows is just a suggestion.)

When I release my own code, I always shy away from using those "or
later" clauses.  We have no idea what might be in a future version of
the GPL or FDL, and therefore no idea what we're signing up to if we
include those clauses.


