Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
normally I use the pre-built Windows version but now I'd like to run some experiments in a virtual machine running Debian 6 (64bit).
I pulled the current svn trunk (revision 1137) .
In the trunk I ran "./configure -with-csl"
and in trunk/cslbuild/x86_64-unknown-debian6.0 I did "make"
Now I have an executable trunk/cslbuild/x86_64-unknown-debian6.0/csl/reduce. It runs fine in graphical mode but when I try to use it "headless", e.g.
reduce -w input.red
it immediately breaks down with repeated messages saying "Memory access violation detected". But the same input file is processed in graphical mode without problems.
What can I do about it?
And by the way, I decided to build the CSL version of your tool simply because (if I recall correctly) the Windows version is also CSL but what is actually the better choice?
All the best,
Several bits to the question. First I am glad things built as well as they did. Right now I do not know why the system crashes when you try to run headless. There are several suggestions I can make that MAY help us track it down (so that if it is a bug in the sources it could be fixed).
(a) I can build Debian 6 v.m. and install everything and see if I see the same. I am busy at least until the weekend, so if we find another resolution earlier I will not need to
(b) If you go "./configure -with-csl -enable-debug" you should build a version with "gcc -g" debugging options. Then if you start reduce under gdb and run with the "-x" command line flag, the "-x" stops it trying to trap exceptrions so the smash will be noticed directly by gdb. That would show where it happened and might give more clues.
(C) You suggest a test case "reduce -w input.red" - does the crash depend at all on just what the input is? Can you do anything at all? Can you run the various supplies test scripts like …/trunk/packages/alg/alg.tst" OK or does it abort on that for you? If the failure depends on the contents input.tst does that run on other platforms? Would it run for ME?
WRT CSL vs PSL, I need to state that I am the CSL person, so I am not a fully unbiassed witness here. At present there is a ready built CSL pacjage for Windows on sourceforge, but the PSL version runs on Windows too….
OK - the main differences:
The insides of CSL are mainly coded in C, so some people will find it easy to hack and extend. The insides of
PSL are in Lisp and that gives a degree of consistency, but the bootstrap build process is perhaps a little
CSL may fit in slightly less memory, while on some (and sometimes the cases that matter to you!) PSL may be
The CSL version on Windows and X11 has a way to create a window and display maths output in a "fancy" manner.
At present on the Mac the CSL system still does this using X11 which Mac people will mostly view as not counting.
the PSL version is more command-line, but on some platforms has a way of popping up a window.
Having both Lisps helps keep the rest of the code of Reduce more portable and honest and comparing output from the
two gives an extra level of validation or checking of some aspects of your results.
All sorts of individual users will have historical use of one or other version and so have become used to it. The core
parts of the Lisp in PSL and CSL differ, but some errors are easier to detect and debug on one, some on the other
and the two Lisp have different sets of private extensions that can be of value to people who get down that deep.
I think that the selection of which you use may end up a matter of taste. I know of cases where people have had (different sorts) of pain and also (different sorts of) success with each.
OK - I fetched DVD 1 for the 64-bit Debian 6.0 and installed in a VM on Virtual Box (giving it a 12Gb HD and 800M memory). I used synaptic to install subversion, xorg-dev, autoconf, ncurses-dev and other things I would need. I fetched Reduce using subversion, and used scripts/csl-sanity-check.sh to confirm I had the build environment set up.
I could then run "./configure -with-csl" and "make" happily, and from the top level directory bin/redcsl popped up its window as expcted. So I tried "bin/redcsl -w" and from tha I could go in "packages/alg/alg.tst"; with no obvious horrid crash.
That means that from where I sit the most obvious immediate probility os that something in your Reduce input file triggers a bug - are you happy to email that to me off the general list so I can try it here? If that is not the case then somehow your build or environment differs from mine. Are you tight on memory or disc in your virtual machine? If necessary we can exchange detailed build logs or binaries to track down what makes our experience differ…
I just tried this too. If I read in a file from within REDUCE everything goes well.
However, if I do
redcsl -w < packages/alg/alg.tst
I see the same problem as reported with memory access violation also on my Fedora systems.
Thanks very much, Eberhard. When I run with a debug build this is to do with one of the isdigit macro aborting when given a marker that is not properly in the range 0 to 0xff. I will think a bit more before I put in a too-random change - specificaylly I need to understand just why the bad value gets passed to there. But that should be fixed soon.
Thanks a lot for your replies. I did some tests and got the following.
I can start "reduce -w"
then using the command "in" read the alg.tst file and it gets executed just fine.
But I cannot pass this file on the command line directly:
"reduce ../../../packages/alg/alg.tst" does open the GUI but all you see is repeatedly the memory error
"reduce -w ../../../packages/alg/alg.tst" also produces the error as with my own input file
In Windows 7 everything is fine
reduce.com -w alg.tst
both work as expected.
From your last post I see that you have already found a cause by inspecting your own debug info. If you need more input I can send it to you.
I had made the very first start of a move that may eventually let the CSL version of Reduce work in Unicode. This changed the internal treatment of character objects (and in almost all of Reduce one never actually gets one of those, with the sole exception of the end-of-file marker). Your example illustrated that testing ann end-of-file marker to see if it was a letter or a digit led to passing an integer that was outside the range of chars to the C library isdigit() function, and on some but not all platforms that caused a gross clash on reaching the end of the file you read. I have checked in an update that intercepts EOF specifically and should mend this behaviour. Please report if anything remains broken. Apologies. Arthur
Thank you very much!! I appreciate your quick help a lot.
reduce -w alg.tst
runs through just fine now. I do have a question though:
I appears that I am building two different binaries:
which both work but are different (according to diff or md5sum).
~/reduce-algebra/trunk/cslbuild/x86_64-unknown-debian6.0/csl$ diff reduce ../../../bin/redcsl
Binary files reduce and ../../../bin/redcsl differ
So who is who?
The "real" binary is built in cslbuild/<architecture>/csl. But for you to refer to that every time would be very tedious, so there is a rather fixed stub in bin/redcsl (and there cal also be a bin/redpsl to launch the PSL varient when that has been build) that merely invokes the version burried deep down.
If I were clever I would arrange a "make install" that reliably installed Reduce in a standard place… but even that is not without confusion in that people without root access can not put stuff in /usr/bin etc too easily.
In fact in cslbuild/<architecture>/csl the files required are reduce, reduce.img, reduce.fonts and reduce.doc (and in the windows case the gnuplot stuff) - these all find each other by virtue of living in the same directory. So one couple copy them all to somewhere else if that was nicer.