[Gcl-devel] Re: more gcl info

[Camm Maguire]

Greetings!

address@hidden writes:

> All my results were produced using the pre59 version of maxima, using the new
> build system.  The dates correspond to when I extracted from cvs.
> > OK, I have these.  I understand these to be the solaris lisp compiled
> > files which you then c compiled on cygwin.
> No, these files were built under linux.

OK

> > 
> > > I redid the build under linux, after resetting the value stack size
> > 
> > Or maybe these files were produced under Linux?
> > 
> > > to 32768, which allowed error free compilation of maxima with
> > > the required compilation options.  There still remains more work
> > 
> > Where is the failure without resetting the stack size?
> The error is value stack overflow, which occurs when compiling bessel.lisp.
> I had reset the value to 16384, which worked on bessel, but failed on the 
> ellipt.lisp
> with the same error.

OK, Just committed two fixes which I believe will address both issues
(prototypes and value stack) you've had with these files.  Please
confirm.

vssize is now 32768 by default, with a configure option
--enable-vssize to set it as one wishes (like maxpage, along with
which vssize is mentioned in the readme).

math.h is searched for, and included if found.  Should eliminate the
compiler warnings for sqrt et. al.  Please let me know if this means
that the tests now pass!

> > 
> > In general, if you could give me build logs as well, that would help
> > greatly. 
> I think I did, look at the files one (stdout) and two (stderr).

Are these separate on your website?  Don't seem to be in the tar
files.  ????


> > 
> > > to do:
> > > 
> > > 1) Fix the gcl compiler to generate warning free code for ellipt
> > > and bessel.
> > 
> > OK, my guess is that with maxima-pre59, these files need the stack
> > size increase.  Or is there some other warning?  Does the
> > destructuring-bind not work?
> The problems were the value stack overflow on lisp to c, and some warnings 
> from
> the c compiler about types on sqrt.  I think that if you compile the c code 
> on linux,
> you would get the same warnings.

OK should hopefully be fixed now.

> > 
> > I've been doing all my regression tests with maxima-5.6, as this is
> > the last stable release.  Should I be using pre-59?  I don't really
> > have time to investigate errors which could be resulting from maxima
> > code as opposed to gcl.  But if its near stable, then maybe that is
> > best. 
> > 
> In general, the pre59 code can be tested with 3 different free lisps on 
> linux, clisp, cmucl and gcl.
> They should all give the same results.
> > 

Indeed :-)

> > > 2) Update the gcl value stack size.
> > 
> > Specifically, why?  Where is the failure?
> Discussed above.
> > 
> > > 3) Remove functionality in unexnt which is duplicated by cygwin.
> > 
> > Such as?
> Sbrk for one.  I think I may have ifdefed out the code that is duplicated, 
> but I will try to check
> later.
> > 

OK, when you do, please forward.  (i.e., ifdef's from you don't seem
to be in the unexnt.c version in your gcl-cvs tarball)


> > > 4) Fix my filename hack in unexnt t o find saved_gcl.
> > 
> > Patch?
> The code is in the gcl tar file, and I think it works on my system only, 
> based on the way that
> the filenames are set up.  I think there is a cygwin function that will get a 
> windows path
> that could be used, but if you want to check unexnt in now, with a big fixme 
> on it, you could.
> Basicly, the build process on windows is pretty complex anyway, so getting by 
> this is not
> a big deal.  If I get a chance, I will revisit it.

OK, I take it it is this patch:
--- gcl/o/unexnt.c      Mon Jan 14 19:16:20 2002
+++ unexnt.c    Fri Feb 15 16:13:00 2002
@@ -326,16 +326,27 @@
   int changed =0;
   HANDLE file_mapping;
   void  *file_base;
+  char newfilename[100];
   DWORD size, upper_size;
   /* fix for cygnus pathnames */
+  /* this is the old cygnus path style
   if (filename[0]=='/' && filename[1]=='/' ) {
     filename[1]=filename[2];
     filename[2]=':';
     filename ++;
     changed = 1;
   }
-
-  file = CreateFile (filename, GENERIC_READ, FILE_SHARE_READ, NULL,
+  */
+  if(filename[0]=='/') {
+  strcpy(newfilename,"e:/cygwin");
+  strcat(newfilename,filename);
+  }
+  else
+  {
+    strcpy(newfilename, filename);
+  }
+printf("newfilename %s\n",newfilename);
+  file = CreateFile (newfilename, GENERIC_READ, FILE_SHARE_READ, NULL,
                     OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
   if (changed) {
     filename --;

I agree that its not ready for cvs, due to the hard-coding of the
path.  Do you have a more general suggestion?


> > 
> > > 5) Replace the hardcoded DBEGIN with a value from sbrk.
> > 
> > Don't know why you need this, but it might be a good idea anyway.
> > There may be an issue, though, with raw_gcl having a different value
> > from saved_gcl.  Have you looked at this?  Can I see where you put in
> > your patch as an example?
> I will post a tar when I get a chance, the changes were pretty minimal.

OK, Thanks!  Still, what is your goal here?  Do you think this might
clear up problems?  From my reading of the comments, it may not, as
Schelter said it would not matter if it were 10-20MB too low!  I do
think it *must* be the same in raw and any saved gcl, though.

> > 
> > > 6) Fix solve.
> > 
> > What's wrong with solve?  Is this pre-59 only?  5.6 passes all tests
> > for me when built under Linux, which is what I think you are doing.
> > 

???

> > > 
> > > I suspect that after changing the value stack size on solaris,
> > > I will be able to repeat building there as the tests seem to
> > > have succeeded, as well as they did on linux.
> > 
> > I'd love to hear confirmation of this.  If you get the 5.6 tests to
> > pass successfully using solaris only for all builds, please let me
> > know.
> I may be able to try this with pre59, when I do I will let you know.

Thanks!

> > 
> > In any case, I *really want* to see the configure output for solaris,
> > as I think it can help me fix Linux sparc.
> It should be in gcl.tar.bz2.

Will check it out!

> > 
> > > Also, I had been able to build gcl with Doug Lea's malloc, however
> > > I was unable to dump, and had to load the objects at startup.
> > > 
> > 
> > Don't know why you want to do this.  What advantage are you looking
> > for?
> I was trying to test for memory allocation problems.  Dougs malloc has all 
> these asserts
> that I enabled.
> > 

Good idea.

Thanks again,

> Dan
> 
> 

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