gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Re: gcl on ms windows


From: Camm Maguire
Subject: Re: [Gcl-devel] Re: gcl on ms windows
Date: 21 Mar 2002 12:13:25 -0500

Greetings!

"Mike Thomas" <address@hidden> writes:

> This is a multi-part message in MIME format.
> 
> ------=_NextPart_000_0703_01C1C901.4D1497B0
> Content-Type: text/plain;
>       charset="iso-8859-1"
> Content-Transfer-Encoding: 7bit
> 
> Hi Camm.
> 
> I apologise for not going further since my last communication, but I am
> spread rather thin time wise at present and GCL/Maxima is unfortunately not
> near the top of the priorites!
> 

No problem!

> >  Who is Rainer, and where can I
> > find out what he's been doing?
> 
> Rainer Keuchel (address@hidden) - Dan Stanger first mentioned his web
> site some time ago.  His Windows CE software port web page is
> http://www.rainer-keuchel.de/software.html and includes Maxima and GCL.
> 

Thanks for the pointer.  Will try to get a chance to examine the
diffs, though they appear large.

> >
> > > The CVS .data files (for example, "cmpnew/*.data") for GCL are identical
> to
> > > mine (according to "cvs diff") after being rebuilt from scratch here.
> > >
> >
> > Great!!!  Just to clarify, you've built a Mingw32 gcl from cvs,
> 
> Yes, with some mods (after Rainer) re the stack and heap checking macros.
> 

Is this all you had to incorporate from the CE port?

> > and
> > then used that to recompile the gcl lisp files, and got no
> > differences.
> 
> That was the case when last I communicated, but since then some diffs have
> crept in eg "compiler::exit" instead of "lisp::exit" in "cmpblock.data".
> These seem to be minor compared to the issues I refer to below which come up
> during the Maxima build, and which seem to be radical format differences.
> 
> > >    2. My scratch Maxima .data files are substantially different to Dan's
> > > (and the GCL ones) in that they seem to be a completely different
> format.
> > > For example, my new Maxima files lack a leading line of spaces followed
> by
> > > some kind of vector? format header which is present in Mingw32 GCL and
> the
> > > Cygwin builds:
> > >
> > >       #(#! blah blah....
> > >
> >
> > Can you provide a sample?
> 
> Attached are two.  The information in each of these Mingw generated exmples
> seems to be superficially similar to that found in Dan Stanger's examples,
> to the extent that similar, but not identical labels appear eg: in the
> attached "defopt.data", the labels:
> 
>     LISPIN-PACKAGE MAXIMA
>     SYSTEM%INIT
> 
> 
> appear, whereas in Dan's .data file, the spelling is:
> 
>    lisp::in-package "MAXIMA"
>    system::%init
> 
> However, Dan's data files (and my GCL build) have lisp vector syntactic
> sugar surrounding the labels eg:
> 
> #(#!
> (lisp::in-package "MAXIMA")
> #((system::%init . #((system::sputprop (lisp::quote maxima::defopt)
> (lisp::quote maxima::macsyma-module) (lisp::quote (lisp::macro)))
> (system::mm (lisp::quote maxima::defopt) 0))))
> )
> 
> which is absent from my Maxima build files.  It is as though I am generating
> a binary encoding rather than an ascii representation of the data segment
> when building Maxima.
> 
> Once again, I emphasise that when my version of GCL compiles itself, the
> .data files are not mangled, and appear to be exactly the same format as
> those generated by Dan, and which appear in CVS.
> 

OK, this seems to have been superceded by your later progress.  What
was the source of these discrepancies?  Why don't they matter?

> >
> > >    3. They are also upper case, whereas Dan's and the GCL .data files I
> made
> > > (and the CVS GCL ones) are all lower-case!!!
> > >
> >
> > Very odd, but isn't lisp case insensitive?  I wonder if this could
> > also be a system (i.e. Mingw) matter.  Being completely ignorant, but
> > guessing that there is a DOS legacy, perhaps 'printf' statements are
> > compiled to produce upper case?  Try a hello world program in C.
> 
> Yes, Common Lisp is case insensitive, but this is definitely not the
> problem - Mingw32 printf() behaves the same as any other in this case.
> 
> My guess is that for some reason or other, I am producing an internal
> representation of the data when compiling Maxima, and for some further
> unknown reason, this does not happen when building GCL.
> 

OK, has this since become clear?

> > Agreed, this would be great!
> 
> Sure would!  Once again apologies on the delay, probably more to go.
> 
> > "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
> 
> My sentiment exactly although it would be nice if we could all treat our
> neighbours nicely.  Let's hope that free software helps break down some of
> the barriers.
> 
> Mike Thomas.
> 
> 
> ------=_NextPart_000_0703_01C1C901.4D1497B0
> Content-Type: application/octet-stream;
>       name="defcal.data"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
>       filename="defcal.data"
> 
> HAIbAAAAFQ0EVVNFUgEIDwohFQ0ETElTUElOLVBBQ0tBR0UNBk1BWElNQRpEAAAAAA8FLCZSRVNU
> DwksJk9QVElPTkFMDwYhFQ0GTUFYSU1BJlJFU1RWDwYtJlFVT1RFDRp3aXRob3V0IGFueSBzcGVj
> aWFsIGFjdGlvbg0qQ2FuJ3QgREVGLVBST1BMLUNBTEwgd2l0aCBub24tc3ViciBhcmdsaXN0IQ8M
> LVVTRS1TVUJSQ0FMTA8FLS1TVUJSDwUsUFJPR04IIQ8FLFFVT1RFIQ8HLENPTVBJTEUPCCxERUZN
> QUNSTw8ELURFRi0PBi0tRVFVSVYIIQ8CLU9QIQ8FLUVRVUlWIQ8ELExJU1QILw8HLVBVVFBST1AJ
> MwgvLzEJMwgvDwgsRlVOQ1RJT04yCC8vLw8GLS1QUk9QTA8ELS1GVU4GIQ8HLU9QLU5BTUUhDwQt
> T1AtTAUhDwQtQk9EWQ8FLExJU1QqCC8PCi1ERUZVTi1QUk9QNAg1Ng8FLERFRlVODwUtLUNBTEwP
> Ay1MRVQPAyxBTkQPByxTWU1CT0xQDwQtR0VUTA8CLUlGDwQsTlVMTA8CLEVRDwMsQ0FSDwgtU1VC
> UkNBTEwPBCxDQURSDwcsRlVOQ0FMTAgvMA8NLUlOSEVSSVQtUFJPUEwhDw8tU1lNQk9MUy1ERUZJ
> TkVEIQ8RLU1BQ1NZTUEtT1BFUkFUT1JTCC8wCA8LLURFQ0xBUkUtVE9QCQ8HLFNQRUNJQUw3OCEP
> BCxTRVRRDwksQ09QWS1MSVNUDwUsU1VCU1QPAS0kCCEPAy1BTlMAOg8ELU1FTVEPBixDRVJST1IP
> Ci1TWU1CT0xDT05DIQ8PLUNIRUNLLVNVQlItQVJHTCEPEy1NQUtFLVBBUlNFUi1GVU4tREVGDwQs
> U09SVAAhDwktQ1NUUlNFVFVQIQ8XLSpERUZJTkUtSU5JVElBTC1TWU1CT0xTDwQtREVMUQ8LLVNU
> UklQRE9MTEFSIQ8ILUFERDJDU1RSIQ8JLUFERDJDU1RSMQ8ILUVYUExPREVODwUtRkxBVEMEDwUh
> FQ0GU1lTVEVNJUlOSVQaEwAAAAAJDwVBU0VUVlYOOgkPAkFNQwAOCgoPCEFTUFVUUFJPUAgvDwYt
> REVGQ0FMCC8PDi1NQUNTWU1BLU1PRFVMRQgvBw8FLE1BQ1JPCiEPBkFNRlNGVU4ILzsOAA4BCCEP
> DUEqTUFLRS1TUEVDSUFMCC8uCSEPAixPUgghDwYsQk9VTkRQCC8uCTkuAAkhDwJBTU0ILw8OLURF
> Ri1QUk9QTC1DQUxMDgEKQggvPA4CDgQIQwgvNwoPB0FQVVRQUk9QCC83DRFGb3Igc2FmZSBrZWVw
> aW5nLggvDxZBVkFSSUFCTEUtRE9DVU1FTlRBVElPTglECEUILzcJOTcACEMILzgJRAhFCC84CTk4
> AApCCC8+DgMOAQlGCC8PFi1ERUZJTkUtSU5JVElBTC1TWU1CT0xTDgQKQggvDw8tVU5ERUZJTkUt
> U1lNQk9MDgUOAQpCCC8PDS1ERUZJTkUtU1lNQk9MDgYOAQpCCC89DgcOAQpCCC8/DggOAwpCCC9A
> DgkOAhg=
> 
> ------=_NextPart_000_0703_01C1C901.4D1497B0
> Content-Type: application/octet-stream;
>       name="defopt.data"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
>       filename="defopt.data"
> 
> HAIFAAAAFQ0EVVNFUgEIDwohFQ0ETElTUElOLVBBQ0tBR0UNBk1BWElNQRoBAAAAAAQPBSEVDQZT
> WVNURU0lSU5JVBoCAAAAAAoPCC1TUFVUUFJPUAghDwUsUVVPVEUhDwYhFQ0GTUFYSU1BREVGT1BU
> CC4PDjBNQUNTWU1BLU1PRFVMRQguBw8FLE1BQ1JPCQ8CLU1NCC4vDgAY
> 
> ------=_NextPart_000_0703_01C1C901.4D1497B0--
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



reply via email to

[Prev in Thread] Current Thread [Next in Thread]