gmane.lisp.gcl.devel

Patch: LaTeX 2.09 -> 2e

Jerry James — 2008-11-26T03:25:25

This gets rid of modern LaTeX complaints about running in compatibility mode when processing xgcl-2/dwdoc.tex. There isn't anything terribly fancy in that document, so the conversion was straightforward. It consisted of the following mappings: - \documentstyle -> \documentclass - {\bf ...} -> \textbf{...} - {\tt ...} -> \texttt{...} - {\em ...} -> \emph{...} I also replaced a few length settings in the preamble with use of the geometry package.

Patch: adapt to newer autoconf versions

Jerry James — 2008-11-20T16:19:18

If autoconf 2.61 is used to process the current configure.in, it produces a script containing illegal shell script syntax, causing a script failure at runtime. This is due to some obsolete autoconf usages within configure.in. This patch fully updates configure.in for use by autoconf 2.61. Let me explain a few bits of the patch. I added AC_PROG_EGREP, because AC_EGREP_HEADER (formerly AC_HEADER_EGREP) now expands to an expression that includes "$(EGREP)", which isn't set unless AC_PROG_EGREP is run. I added AC_GNU_SOURCE and a corresponding #undef in acconfig because some math functions (e.g., isnormal) aren't defined unless _GNU_SOURCE is defined. There was already a workaround in the script for this, but it broke in a couple of cases on my Fedora 9 machine. I reordered a few statements to make the "checking ..." messages and their corresponding results be on the same line. Quite a few obsolete macros were converted to their new forms. There were a number of cases of strings quoted with quote marks

Patch: compile with newer system BFD libraries

Jerry James — 2008-11-20T15:59:09

This patch detects whether a newer system BFD library is being used, specifically one that requires an output BFD. If so, it adds code to set up a dummy output BFD. This lets me compile successfully with the Fedora 9 BFD library. This patch requires regenerating the configure script with autoconf, and also using autoheader to regenerate h/gclincl.h.in. Unfortunately, autoconf 2.61 generates a configure script that will not run successfully, due to some obsolete autoconf usages in the current configure.in. I'll send a patch to fix that in a moment.

LD_COMMAND for Linux

Jerry James — 2008-11-11T22:25:55

I'm struggling to understand the definition of LD_COMMAND in h/linux.h. Currently, it generates a string as follows: ld -d -S -N -x -A %s -T %x %s %s -o %s but Linux uses GNU ld, where: -A sets the architecture -T sets the linker script file Neither of those make any sense in this definition. I suspect these are the BSD linker options, where: -A identifies a symbol file -T specifies the start of the text segment The equivalents in GNU ld are -R and -e, respectively. Also, GNU ld expects a base 10 number as the argument to -e, but BSD's -T expects a hex number; note the %x in the LD_COMMAND definition. So I don't see how this works at all on a Linux system. Shouldn't the definition be: ld -d -S -N -x -R %s -e %d %s %s -o %s ? Is the code that invokes LD_COMMAND never executed on a Linux box?

Build trouble

Nicolas FRANCOIS — 2008-11-09T15:47:14

Hi. I've got a hard time compiling GCL-2.6.7 (Linux (Linux From Scratch), DualCore, Gcc 4.2.3, Glibc 2.7). The build is stuck on a segfault, caused by a buggy malloc, Gentoo bugtracking list dixit : Building symbol table for /sources/gcl-2.6.7/unixport/raw_pre_gcl .. Unrecoverable error: Segmentation violation.. /bin/sh: line 1: 13485 Abandon /sources/gcl-2.6.7/unixport/raw_pre_gcl /sources/gcl-2.6.7/unixport/ -libdir /sources/gcl-2.6.7/ < foo make[1]: *** [saved_pre_gcl] Erreur 134 rm raw_pre_gcl make[1]: quittant le répertoire « /sources/gcl-2.6.7/unixport » make: *** [unixport/saved_pre_gcl] Erreur 2 I don't quite understand all the workarounds provided by the Gentoo list, as they are quite contradictory. Can someone help me compile this package ? I need it badly for Maxima. \bye PS : it used to compile quite fine on my previous installation... But I didn't write down the process, and now the hard drive is gone back to its creator !

Absolut Memory Limit

Heiko Schroeter — 2008-11-06T12:26:46

Hello gcl list, i'am checking large matrices with gcl (GCL (GNU Common Lisp) 2.6.8 CLtL1 Dec 1 2007 20:28:22, on Kubuntu x86_64 2.6.24-21-generic, with 2GB RAM) and found that i cannot allocate more memory to gcl. The snippet works with an array size of 5000 (runtime approx 1.3 seconds). What i see (or how i interpret it) is that the memory footprint for gcl is constantly 262144 pages. I see a lot of GC for the relocatable pages when the array size is 10000 (break into debugger after 4 minutes). Even with various (si:allocate- ) calls when starting the script the total amount of 'maximum pages' stays at 262144. I rechecked this on a Dual Quadcore with 16GB Ram it showes the same amount of 'maximum pages'. What is the recommened way to expand memory for large arrays like this ? Thanks for any pointer to more infos. Rgards Heiko ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Plain gcl -> (room): 434/434 50.7%

Patch for ~username code

Jerry James — 2008-11-05T14:12:26

This is another patch against 2.6.7 + the current Debian patch. This one does a couple of minor cleanups to the code that handles filenames starting with "~username". First, such names may be greater than 20 characters long, so this code may overflow its buffer. On Fedora, they can be 256 characters long. The patch uses LOGIN_NAME_MAX instead. Second, the variable "q" is initialized twice with the same value, so this patch removes the second initialization. Finally, since we already know that q[0] == '~', there is no point in starting the loop at index 0. Starting it at index 1 also gets gcc to stop whining about a possibly negative array index when setting name[n - 1] to zero. Regards,

Patch: minor Linux changes

Jerry James — 2008-11-04T22:08:34

Here is a patch against 2.6.7 + the current Debian patch. The first hunk, against h/linux.h, makes the code use sigprocmask instead of sigblock. The sigprocmask interface has been available since Linux kernel version 2.2 (current version is 2.6). The sigblock interface is currently deprecated. The second hunk, against o/run_process.c, does two things. First, it uses dup2 instead of dup. There's no particular problem here, it just makes me nervous not to ask for the file descriptor we assume we got later. Second, it closes the fdin and fdout file descriptors, which are no longer needed. The next two hunks, against o/unixfsys.c, fixes a problem I am having on Fedora 9, where at high optimization levels, the glibc headers specify inline versions of some functions. I'm getting calls made to getwd() somehow, even though getcwd() is available. I don't understand it, but this part of the patch fixes the problem for me. Also note that the getcwd prototype (in the #ifndef _WIN32 block) is unnecessary, since

Patch: don't #include inside a function

Jerry James — 2008-11-04T16:04:46

I'm taking over maintainership of the Fedora GCL package, effective today. I've grabbed the current Debian patch. Even with that patch, I'm getting a build failure, due to h/unrandomize.h. Essentially, it is not possible to #include inside a function when compiling with both optimization and -D_FORTIFY_SOURCE. When I complained about this to the glibc maintainers, they replied: Then GCL is buggy. Standard headers are never meant to be included inside of a function. E.g. ISO C99 says in 7.1.2/4: ... "If used, a header shall be included outside of any external declaration or definition, and it shall first be included before the first reference to any of the functions or objects it declares, or to any of the types or macros it defines."... So here is a patch to move the #include statements out of functions. After applying this patch, configure will need to be regenerated. diff -dur gcl-2.6.7.ORIG/configure.in gcl-2.6.7/configure.in --- gcl-2.6.7.ORIG/configure.in2008-11-03 16:58

Signaling floating-point overflow?

Raymond Toy — 2008-10-31T04:42:10

Does gcl signal an arithmetic-error on floating-point overflow? I vaguely remember that it did, but my gcl 2.6.8 build (solaris) does something and produces an error about printing a non-number. I guess that means an infinity was generated? Can I make gcl produce an arithmetic-error on FP overflow? Ray

Compiling on Windows

Russell Wallace — 2008-10-29T18:53:34

I have a GCL install on Windows that works fine in interpreter mode, and I'm trying to get it to compile a program, i.e. via GCC. Google finds the following suggested methods: (compile-file "main.lisp":system-p t) (compiler::link '("main.o" "libuser32.a") "main.exe") Result: Compiling main.lisp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling main.lisp. '.' is not recognized as an internal or external command, operable program or batch file. C:\ayane>dir *.exe Volume in drive C is OS Volume Serial Number is 0422-C2D0 Directory of C:\ayane 29/10/2008 09:43 454,232 raw_main_map.exe 1 File(s) 454,232 bytes 0 Dir(s) 67,711,852,544 bytes free C:\ayane>raw_main_map.exe Program too big to fit in memory The other suggested method: C:\ayane>\PROGRA~1\GCL-2.6.6-ANSI\lib\gcl-2.6.6\unixport \saved_ansi_gcl -compile main.lisp Compiling main.lisp. End of Pass 1. End of Pass 2. OPTIMIZE leve

wrong value for (float-sign -0.0)

Gabriel Dos Reis — 2008-09-28T05:25:17

Camm -- On IEEE-754 platforms, GCL reports a wrong value the sign of -0.0 >*features* (:COMPILER :NUMLIB :SDEBUG :DEFPACKAGE :GNU-LD :UNEXEC :BFD :NATIVE-RELOC :READLINE :TRUNCATE_USE_C :CLX-LITTLE-ENDIAN :BSD :GNU :LINUX :X86_64 :SGC :IEEE-FLOATING-POINT :UNIX :GMP :GCL :AKCL :COMMON :KCL) >(float-sign -0.0) 1.0 The correct value is -1.0. This affects both GCL-2.6.8pre and GCL-2.7.0.

[CfPart] Lisp50< at >OOPSLA

Pascal Costanza — 2008-09-18T18:53:54

Lisp50< at >OOPSLA ...celebrating the 50th birthday of Lisp at OOPSLA 2008 Monday, October 20, 2008 Nashville, Tennessee, USA co-located with OOPSLA 2008 participation is free for all OOPSLA participants registration for at least one conference day at OOPSLA is required URL: http:www.lisp50.org Feed: http://lisp50.blogspot.com Invited Speakers + William Clinger, Northeastern University, USA + Pascal Costanza, Vrije Universiteit Brussel, Belgium + Richard Gabriel, IBM Research, USA + Rich Hickey, Independent Consultant, USA + Alan Kay, Viewpoints Research Institute, USA + Fritz Kunze, USA + Ora Lassila, Nokia Research Center, USA + John McCarthy, USA + Kent Pitman, PTC, USA + Guy Steele, Sun Microsystems Laboratories, USA + Herbert Stoyan, University of Erlangen, Germany + Warren Teitelman, Google Inc., USA + JonL White, USA Titles, abstracts, biographies and schedule will be announced at the Lisp50 webpage and blog in the coming days and weeks. Abstract In October 1958, John McCarthy published one in a s

_gp_disp vs __gnu_local_gp

Camm Maguire — 2008-08-01T18:20:45

Greetings! gcc-4.3 outputs the latter in place of the former. Are they equivalent, i.e. is this a simple renaming? Why the change? Take care,

Can't build GCL on regular Linux box

Blake McBride — 2008-07-31T22:26:24

_______________________________________________ Gcl-devel mailing list Gcl-devel< at >gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel

ansi tests

Sam Steingold — 2008-07-21T15:50:28

Hi, Paul Dietz does not answer, so, presumably, he stopped maintaining the ansi tests. is anyone working on them? who do I report bugs? Thanks Sam

Updated directions for setting up MinGW and MSYS onMS-Vista (and other stuff)

Donald Winiecki — 2008-07-06T20:20:28

The following (and attached) is my update on the installation and setup directions for TortoiseCVS, MinGW, MSYS and GCC for building GCL. It would be terrific if anyone using Vista could check this out for me and let me know if it works for them. Just something to add * I've now verified this with both GCL-2.6.7 and GCL-2.6.8pre (ANSI). Though I should _also_ say that the process is somewhat flaky on Vista; sometimes I have to checkout from the CVS several times before I can successfully build the .exe. There may be something unusual going on in the checkout process with TortoiseCVS. I suspect this because, on installation, TortoiseCVS reports that it is not fully compatible with MS-Vista. Since I'm using the most recent update of TortoiseCVS, I'll have to keep attentive of any developments in that tool. Best regards from under the beautiful and cloudless blue skies of Boise, Idaho! _don winiecki *----------- the updated setup directions follow *----------- =====================================

Building GCL on MS-Vista

Donald Winiecki — 2008-07-06T02:52:24

Just to make an early announcement, I've managed to root out a few disconnected sources that allowed me to successfully setup MinGW, MSYS and GCC so I can build GCL on my new Vista box. I've built gcl-2.6.8pre in both ANSI and CLtL1 form under Vista and both seem to operate properly through a few simple tests. I'll be writing up the details in an update to the procedure I prepared a few months ago and send that on to the list. At that point it would be good if anyone else with a Vista machine could try it out to make sure it works more generally. When I can, I'll get up to speed on how to insert it into the CVS for broader distribution. Best, _don winiecki

Compiling GCL for Win32 under Vista

Donald Winiecki — 2008-07-02T23:49:56

I've just been handed a new computer running MS-Vista and have been working today to get things set up to see if I could build GCL on it. While I still have a few things in mind to try, it appears that the same MSYS and MinGW configurations that allowed GCC to function under XPsp2 won't work under Vista. It appears to be a memory allocation thing, which if the case, would be well beyond my ability to address. If anyone has succeeded in setting up MinGW, MSYS and GCC, and gotten GCL to compile under Vista I would be very happy to hear how you installed and configured things! Best, _don winiecki

custom lisp code after save-system and GPL

Mykhaylo Sorochan — 2008-04-17T14:44:44

_______________________________________________ Gcl-devel mailing list Gcl-devel< at >gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel

is run-process working?

Mykhaylo Sorochan — 2008-04-17T14:41:17

_______________________________________________ Gcl-devel mailing list Gcl-devel< at >gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel