reduce-algebra-developers — Discussion of development, administration and support for Reduce

[Reduce-algebra-developers] [reduce-algebra-developers] embedded make command problem

[Nelson H. F. B. <be...@ma...>]

I noticed during build attempts of a reduce-20160429 snapshot on
various FreeBSD versions that there are numerous instances of embedded
explicit make commands in generated Makefiles:

	% find . -name Makefile | xargs fgrep '&& make'
	./csl/new-embedded/Makefile:    cd crlibm && make install
	./csl/new-embedded/Makefile:    cd softfloat && make install
	./csl/new-embedded/Makefile:    cd procedural && make CFLAGS=$(CFLAGS)
	./csl/new-embedded/Makefile:    if test -d crlibm; then cd crlibm && make clean; fi
	./csl/new-embedded/Makefile:    if test -d softfloat; then cd softfloat && make clean; fi
	./csl/new-embedded/Makefile:    cd reduce-image && make clean
	./csl/new-embedded/Makefile:    cd minireduce-image && make clean
	./csl/new-embedded/Makefile:    cd procedural && make clean
	./generic/libreduce/Makefile:   cd $(BUILD) && make clean
	./generic/libreduce/Makefile:   cd $(BUILD) && make distclean
	./generic/redfront/Makefile:    cd $(BUILD)/libedit && make clean
	./generic/redfront/Makefile:    cd $(BUILD)/redfront && make clean
	./generic/redfront/Makefile:    cd src && make -f Makefile.in maintainer-clean

While that happens to work on GNU/Linux systems, it utterly fails on
others, such as the *BSD family, where the native make does not
recognize GNU make extensions.  [I strongly recommend avoidance of
such extensions in software that is expected to run on multiple Unix
platforms.]

In general, no Makefile should ever contain an explicit make command;
it should be written only as $(MAKE).  That way, a top-level make
under a different name, such as gmake or gnumake, will get that name
propagated correctly to all child makes.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: be...@ma...  -
- 155 S 1400 E RM 233                       be...@ac...  be...@co... -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

Re: [Reduce-algebra-developers] more on the 'abort trap'

[Arthur N. <ac...@ca...>]

On Sat, 30 Apr 2016, Kostas Oikonomou wrote:
> Hi Nelson,
> First, thanks for the solution to the
> cd ../redfront & make
> issue.  I had reported the same problem.  My solution was to change 'make' 
> to 'gmake', but yours is better.

I had not spotted why your use of make failed, just that you reported 
redfront building issues - but yes in principle I understand that I should 
be using $(MAKE) and it was an oversight not to us eit when asking that 
redfront needed building. I agree with Nelson that in an ideal world I 
would nopt use bash-isms or gnu-make-isms, but in each case there have 
been some places where I found that hard. Even the work factor of spotting 
where such things creeop in by accident can be quite high. So on that one 
"apologies" and when I next check in stuff it should be sorted, but I do 
not view it as urgent enough to needs a checkin just for that.

>
> Second, with the abort trap, I just discovered the source of the problem!
> In my .reducerc, I have 'load assist'.   If I remove that, I get the same 
> behavior you do.
> So something in that package is creating the issue.
>

If I go "load_package assist; on rounded; -log({3.33/44});"

[on windows] I now see a Memory access violation. So "assist" is not 
living up to its name in this particular case!!!! But that fact that now 
we have something that is reproducible on a range of platforms etc means 
it will be a LOT easier to debug.

Note that very recently it has been arranged that there will be a 
--no-rcfile as a command line option that (I hope) is available for both 
CSL and PSL versions to avoid reading .reducerc (or whatever is equivalent 
on other platforms). YOurs is not the first case of somebody being hurt by 
something they had hidden in there - and as a matter of standard I guess 
it will make sense to avoise people to demonstrate reported bugs with 
--no-rcfile used!

That said, you still have a case where the system aborts in an 
unsatisfactory manner, so there is a bug to be chased down!!!!


>                        Kostas

Re: [Reduce-algebra-developers] more on the 'abort trap'

[Kostas O. <ko...@re...>]

Hi Nelson,

First, thanks for the solution to the

cd ../redfront & make

issue.  I had reported the same problem.  My solution was to change 
'make' to 'gmake', but yours is better.

Second, with the abort trap, I just discovered the source of the problem!
In my .reducerc, I have 'load assist'.   If I remove that, I get the 
same behavior you do.
So something in that package is creating the issue.

                         Kostas

On 04/30/16 09:45 AM, Nelson H. F. Beebe wrote:
> This morning, I completed the reduce --with-csl build on FreeBSD 11 x86-64,
> and got this result:
>
> % bin/redcsl -w
> REDUCE (3632), 30-Apr-16 ...
>
> 1: on rounded;
>
> 2: -log({1.1/3,2.2/3});
>
>   - log({0.366666666667,0.733333333333})
>
> I used the compiler picked by configure, which is gcc; as my message
> yesterday noted, cc is really clang.
>
> Arthur, there was one glitch in the --with-csl build on that system:
> in cslbuild/x86_64-unknown-freebsd11.0/csl/Makefile, I had to change
>
> 	cd ../redfront && make
> to
>          cd ../redfront && $(MAKE)
>
> As a general rule, I would simply excise all GNU-make syntax from any
> software package Makefiles, so that any standard Unix make utility
> could handle them.
>
> If that is not feasible, then it is critical that one never writes
> "make" in a Makefile, but rather "$(MAKE)", because that propagates
> not only the parent make utility name, but also it applies special
> handling of the -n, -q, and -t options.
>
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
> - University of Utah                    FAX: +1 801 581 4148                  -
> - Department of Mathematics, 110 LCB    Internet e-mail: be...@ma...  -
> - 155 S 1400 E RM 233                       be...@ac...  be...@co... -
> - Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
> -------------------------------------------------------------------------------

Re: [Reduce-algebra-developers] more on the 'abort trap'

[Kostas O. <ko...@re...>]

I forgot to mention that I am building Reduce with FreeBSD's standard 
compiler, which is clang, not gcc:

configure --with-csl  \
      CPPFLAGS=-I/usr/local/include/freetype2 LDFLAGS=-L/usr/local/lib 
CC=clang CXX=clang++

So the issue may be some difference between gcc and clang.

On FreeBSD 10.3 I have clang 3.4.1, and on 11.0 I have clang 3.8.0.

                             Kostas

Re: [Reduce-algebra-developers] more on the 'abort trap'

[Kostas O. <ko...@re...>]

Hi Rainer,

This is FreeBSD 11.0, 64-bit.  I t also happens on FreeBSD 10.3, again 
64 bit, the latest stable release.

I now have an even simpler example:

FreeBSD 10.3:

REDUCE (3592), 20-Apr-16 ...

1: on rounded;

2: -log(3.3/44);
2.59026716545

3: log({3.3/44});
{ - 2.59026716545}

4: -log({3.3/44});
Abort trap

FreeBSD 11.0, with rev. 3636: same behavior.

                             Kostas


On 04/30/16 04:47 AM, Rainer Schöpf wrote:
> Hello Kostas,
>
>   > An even simpler example, showing that 'listvecops' is not the issue:
>   >
>   > REDUCE (3632), 29-Apr-16 ...
>   >
>   > 1: on rounded;
>   >
>   > 2: -log({1.1/3,2.2/3});
>   >
>   > Process REDUCE abort trap
>   >
>   > This happens on FreeBSD, and apparently not on Ubuntu.
>
> Which version of FreeBSD, 32 bit or 64 bit, and on which release?
>
> I have various FreeBSD-VMs here, so I can check if I know a bit more.
>
>    Rainer

Re: [Reduce-algebra-developers] more on the 'abort trap'

[Rainer S. <rai...@gm...>]

Hello Kostas,

 > An even simpler example, showing that 'listvecops' is not the issue:
 > 
 > REDUCE (3632), 29-Apr-16 ...
 > 
 > 1: on rounded;
 > 
 > 2: -log({1.1/3,2.2/3});
 > 
 > Process REDUCE abort trap
 > 
 > This happens on FreeBSD, and apparently not on Ubuntu.

Which version of FreeBSD, 32 bit or 64 bit, and on which release?

I have various FreeBSD-VMs here, so I can check if I know a bit more.

  Rainer

Re: [Reduce-algebra-developers] more on the 'abort trap'

[Raffaele V. <raf...@un...>]

On 30/04/16 01:00, Arthur Norman wrote:
> On Fri, 29 Apr 2016, Kostas Oikonomou wrote:
>> An even simpler example, showing that 'listvecops' is not the issue:
>>
>> REDUCE (3632), 29-Apr-16 ...
>>
>> 1: on rounded;
>>
>> 2: -log({1.1/3,2.2/3});
>>
>> Process REDUCE abort trap
>>
>> This happens on FreeBSD, and apparently not on Ubuntu.
>>
> Thanks Kostas - having really compact examples can help. It does not seem
> to fail for me on Windows either, and not on a Mac... I need to sleep now.
>
> Before I try finding myself a BSD-family system to try this on I want to
> be really certain that it happens for other BSD users or that your
> installation is very fully cleanly build and has no corruption in it. I
> might be keen to know if thos only applies with recent revisions or is
> long-standing even if only just recently observed (it looks simple enough
> that it migh tbe). And given that at the moment it seems BSD-specific I
> would wonder of editing Makefiles to stick in optimisation "-O0" rather
> than "-O2" has an effect in case it is that a recent compiler update on
> that platform is associated with the pain.

In my Debian Testing the result is shown; no "trap" at all.
Maybe updating to a newer BSD would help ... ?

Raf

> Arthur
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
>

Re: [Reduce-algebra-developers] more on the 'abort trap'

[Arthur N. <ac...@ca...>]

On Fri, 29 Apr 2016, Kostas Oikonomou wrote:
> An even simpler example, showing that 'listvecops' is not the issue:
>
> REDUCE (3632), 29-Apr-16 ...
>
> 1: on rounded;
>
> 2: -log({1.1/3,2.2/3});
>
> Process REDUCE abort trap
>
> This happens on FreeBSD, and apparently not on Ubuntu.
>
Thanks Kostas - having really compact examples can help. It does not seem 
to fail for me on Windows either, and not on a Mac... I need to sleep now.

Before I try finding myself a BSD-family system to try this on I want to 
be really certain that it happens for other BSD users or that your 
installation is very fully cleanly build and has no corruption in it. I 
might be keen to know if thos only applies with recent revisions or is 
long-standing even if only just recently observed (it looks simple enough 
that it migh tbe). And given that at the moment it seems BSD-specific I 
would wonder of editing Makefiles to stick in optimisation "-O0" rather 
than "-O2" has an effect in case it is that a recent compiler update on 
that platform is associated with the pain.

Arthur

[Reduce-algebra-developers] more on the 'abort trap'

[Kostas O. <ko...@re...>]

An even simpler example, showing that 'listvecops' is not the issue:

REDUCE (3632), 29-Apr-16 ...

1: on rounded;

2: -log({1.1/3,2.2/3});

Process REDUCE abort trap

This happens on FreeBSD, and apparently not on Ubuntu.

                                     Kostas

Re: [Reduce-algebra-developers] abort trap

[Arthur N. <ac...@ca...>]

On Fri, 29 Apr 2016, Kostas Oikonomou wrote:
> A simpler example:
>
> REDUCE (3607), 20-Apr-16 ...
>
> 1: load listvecops;
> 2: on rounded;
> 3: - log({1.1,2.2,3.3}/6.123);
>
> Process REDUCE abort trap
>
>                                             Kostas
>
What I see on Ubuntu is:

acn1@gauguin ~ $O/bin/redcsl -w
REDUCE (3632), 26-Apr-16 ...

1: load_package listvecops;

2: on rounded;

3: - log({1.1,2.2,3.3}/6.123);

  - log({0.179650498122,0.359300996244,0.538951494366})


Arthur

Re: [Reduce-algebra-developers] abort trap

[Kostas O. <ko...@re...>]

A simpler example:

REDUCE (3607), 20-Apr-16 ...

1: load listvecops;
2: on rounded;
3: - log({1.1,2.2,3.3}/6.123);

Process REDUCE abort trap

                                             Kostas

[Reduce-algebra-developers] abort trap

[Kostas O. <ko...@re...>]

Can anyone else reproduce this?

                             Kostas


REDUCE (3592), 20-Apr-16 ...

1: load listvecops;

2: xs := {1,2,3};

xs := {1,2,3}

3: ss := for each x in xs sum x;

ss := 6

6: -log(xs/s);

Process REDUCE abort trap

Re: [Reduce-algebra-developers] An entirely predictable message! (Ubuntu 16.04)

[Raffaele V. <raf...@un...>]

On 22/04/16 18:49, Arthur Norman wrote:
> Since Ubuntu 16.04 is now out I fetched and installed a 64-bit copy and
> used scripts/ubuntu-sanity-check.sh to ensure I had all the development
> packages I was liable to need. I fetched fetchreduce.sh and used that to
> grab a copy of the Reduce source code and then did the usual
> configure/make steps - which appeared to go through uneventfully. Then
> scripts/testall.sh runs happily and shows (at least for me) results that
> are just like those on other platforms.
>
> So whew - things still work on the very latest Ubuntu. Well not really a
> big cause for amazement I guess.

I am using Debian testing ("stretch"); I update it almost every week, 
and recompile Reduce from time to time, and everything goes fine at 
least with CSL-Reduce. Debian testing is usually not far from the most 
recent Ubuntu, and building success or problems are more or less parallel.

Raf

>                  Arthur
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
>

[Reduce-algebra-developers] More news that will not astonish!

[Arthur N. <ac...@ca...>]

I just found enough of a 64-bit Fedora image to try my Raspberry Pi 3 in 
64-bit mode. AT present I do not have a native desktop, but I can use ssh 
and X-forwarding and run the CSL version of Reduce on it. I had a small 
trouble in that at least as of today subversion crashes when I try to use 
it to fetch Reduce - so I copied the files across from another machine.

For comparison I also built on a Raspberry Pi 3 using the 32-bit raspbian.
First sizes. compiled in 32-bit mode I have the reduce executable and 
image files with sizes 4755K and 5288K. On the 64-bit system reduce is 
5519K and 5416K

I note that during the build on the 64-bit system gnome-system-monitor 
showed that memory use was always under 40%, so neurosis about the 64-bit 
version being more bulky and that being a worry on a 1Gbyte system should 
not be a sharp concern.

Running scripts/testall.sh --csl on the 32-bit raspbian reports:
      CSL total = 692.88 (seconds)
while the test run had a total elapsed time of 18 minutes with all the 
shall scripting overheads etc etc. On the 64-bit system I see
      CSL total = 1161.74 (seconds)
and the total elapsed time was 28 mins.

Both versions led to valid sets of logs, so apart from the speed 
difference both seem to behave.

All the numbers and comparisons can change as the 64-bit ARM world for 
Raspberry Pi stabilises. Also these tests were run on two separate 
Raspberry Pi 3 machines with different SD cards so the speed of the SD 
cards may have had some impact. AT present I do not know how to run 32-bit 
binaries on the 64-bit platform (or indeed if that is supported yet) but 
when I can I will try an even more direct comparison.

         Arthur

[Reduce-algebra-developers] An entirely predictable message! (Ubuntu 16.04)

[Arthur N. <ac...@ca...>]

Since Ubuntu 16.04 is now out I fetched and installed a 64-bit copy and 
used scripts/ubuntu-sanity-check.sh to ensure I had all the development 
packages I was liable to need. I fetched fetchreduce.sh and used that to 
grab a copy of the Reduce source code and then did the usual 
configure/make steps - which appeared to go through uneventfully. Then 
scripts/testall.sh runs happily and shows (at least for me) results that 
are just like those on other platforms.

So whew - things still work on the very latest Ubuntu. Well not really a 
big cause for amazement I guess.

                Arthur

Re: [Reduce-algebra-developers] arguments to procedures

[Kostas O. <ko...@re...>]

Thanks, I will look into it.

                     Kostas

On 04/20/2016 16:52, Arthur Norman wrote:
> On Wed, 20 Apr 2016, Kostas Oikonomou wrote:
>
>> Is there some way to have Reduce procedures have optional
>> arguments/parameters, or arguments/parameters with default values?
>> Right now I have to declare all such variables global in my user-mode
>> Reduce program.
>>
>>                                  Kostas
>>
> Standard Lisp does not provide optional arguments or default values as a
> capability, so at that level of abstraction the answer is no.
> Apart from the fact that a Lisp-level macro definition can cope...
> But at the level of the algebraic interface that the ordinary user works
> with then observe commands like for instance "plot" or even "df" that can
> take variable numbers or arguments, as can a whole bunch of other things,
> so it how you set up the way that something will get simplified. If you go
>     put('myname, 'simpfn, 'simpmyname)
> then when the user goes myname(... args ...) the function simpmyname gets
> a list of all of the args, so you can check its length and do whatever you
> like...
>
>    Arthur
>

Re: [Reduce-algebra-developers] arguments to procedures

[Arthur N. <ac...@ca...>]

On Wed, 20 Apr 2016, Kostas Oikonomou wrote:

> Is there some way to have Reduce procedures have optional
> arguments/parameters, or arguments/parameters with default values?
> Right now I have to declare all such variables global in my user-mode
> Reduce program.
>
>                                 Kostas
>
Standard Lisp does not provide optional arguments or default values as a 
capability, so at that level of abstraction the answer is no.
Apart from the fact that a Lisp-level macro definition can cope...
But at the level of the algebraic interface that the ordinary user works 
with then observe commands like for instance "plot" or even "df" that can 
take variable numbers or arguments, as can a whole bunch of other things, 
so it how you set up the way that something will get simplified. If you go
   put('myname, 'simpfn, 'simpmyname)
then when the user goes myname(... args ...) the function simpmyname gets 
a list of all of the args, so you can check its length and do whatever you 
like...

  Arthur

[Reduce-algebra-developers] arguments to procedures

[Kostas O. <ko...@re...>]

Is there some way to have Reduce procedures have optional 
arguments/parameters, or arguments/parameters with default values?
Right now I have to declare all such variables global in my user-mode 
Reduce program.

                                 Kostas

[Reduce-algebra-developers] Error with Physop packet

[abpetrov <abp...@uf...>]

Hi,

I tried use Physop packet for some calculations.
The simplified program looks like that

load_package noncom2;
load_package physop;

tensop l(2);
physindex s1,s2;
expr2 := l(s1,s2,x);
expr3 := sum( l(s1,s2,x),x);

Expression expr2 calculates as normal
At calculation of expr3 I got error

Declare l operator?

Why Reduce do it? And how correct it?

Best regards, Petrov Alexander.

[Reduce-algebra-developers] Question about packet cantens

[abpetrov <abp...@uf...>]

Hi,

Can I use tensors from packet CANTENS as noncommutative using
the NONCOM statement from packet PHYSOP ?

Best regards, Petrov Alexander.

Re: [Reduce-algebra-developers] Reduce snapshot 12 April

[Alan B. <ala...@gm...>]

I had no trouble installing the snapshots on Windows 7 and Windows 10. 
They seem to work fine including the Help facility which was broken in 
an earlier snapshot.

On Windows 10, in particular, my virus protection software was rather 
paranoid about the installer issuing dire warnings (twice) about "very 
few users" and "unknown publisher" -- but everything went smoothly after 
clicking (or tapping!)  "Run anyway".

For Norton and PSL-based users it may be necessary to create a security 
exception for bpsl.exe to prevent it being quarantined by the runtime 
protection stuff.

May I take this opportunity of thanking Arthur and Rainer for all their 
work in the last month or so in updating the system/

Alan Barnes

PS I note that in my builds of both the CSL-based and PSL-based versions 
on Ubuntu 14.04 the version numbers are out of sync with each other and 
the version number reported by subversion.  For example the latest 
builds report 3562 and 3473 respectively compared with 3584 on subversion?

Re: [Reduce-algebra-developers] Reduce snapshot 12 April

[Raymond R. <ray...@gm...>]

"You don't tell us whether you installed the .deb package, the .rpm 
package or one of the tarballs."

Well that's embarrassing.  I downloaded realpath and everything now 
works.  I checked on the libxft and  synaptic reads "libxft2 version 
2.3.1-2" as the latest and the actual file name is "libXft.so.2.3.1"  
which is where ldd reduce links to with:
/usr/lib/reduce/cslbuild/csl$ ldd reduce

I installed from the .deb package.  I would have thought that realpath 
would have been in the dependencies although I realize it's a script.
The downloaded installation files were.
reduce-common_20160412_all.deb
reduce-psl_20160412_amd64.deb
reduce-addons_20160412_amd64.deb
reduce-csl_20160412_amd64.deb
I realize that I probably didn't need them all; but I had a conflict 
circle with GDebi package installer so I removed the old version.  I 
probably could have forced the installation but sometimes that results 
in unpleasantness.

And since I neglected it before here is sysinfo output.
  SYSTEM INFORMATION
     Running Ubuntu Linux, the Ubuntu 14.04 (trusty) release.
     GNOME: 3.8.4 (Ubuntu 2015-12-02)
     Kernel version: 4.2.0-35-generic (#40~14.04.1-Ubuntu SMP Fri Mar 18 
16:37:35 UTC 2016)
     GCC: 4.8 (x86_64-linux-gnu)
     Xorg: 1.17.2 (15 January 2016  10:17:33PM) (15 January 2016 
10:17:33PM) (15 January 2016  10:17:33PM)
     Hostname: rrogers-desktop
     Uptime: 7 days 4 h 5 min


I realize that I probably didn't need them all; but I had a conflict 
circle with GDebi package installer so I had to remove the old version.  
I probably could have forced the installation but sometimes that results 
in unpleasantness.

Ray



On 04/12/2016 12:39 PM, Rainer Schöpf wrote:
> On Tue, 12 Apr 2016 at 11:04 -0400, Raymond Rogers wrote:
>
>   > The problems seem minor in Ubuntu 14.xxxx
>   >
>   > redcsl: the script file in /usr/bin/  doesn't point to the correct place.
>   > The script is:
>   > ----------
>   > #! /bin/sh
>   >
>   > MYDIR=`dirname $0`
>   > CSLBUILDDIR=`realpath $MYDIR/../lib/reduce/cslbuild`
>   > exec $CSLBUILDDIR/csl/reduce $*
>   >
>   > ----------------------------
>   > Whereas the real binary location is:
>   > /usr/lib/reduce/cslbuild/csl
>   > ---------------------------------
>   >
>   > Almost hit the target but not quite :)
>   > Although when I do:
>   >   /usr/lib/reduce/cslbuild/csl/reduce
>   > everything seems to work but I get:
>   > "Expected Xft library version 20302 or greater; was 20301"
>   > I will look into this.
>   >
>   >
>   > redpsl has different problems; but a core one is that bpsl  can not
>   > allocate memory on my system.  In addition the script in /usr/bin refers
>   > to the variable "realpath" without defining it.
>
> You don't tell us whether you installed the .deb package, the .rpm package or
> one of the tarballs.
>
> Do you have the realpath command available on your Linux?
>
>   Regards,
>     Rainer

Re: [Reduce-algebra-developers] Reduce snapshot 12 April

[Arthur N. <ac...@ca...>]

OK - a quick check at this end by several of us. I fired up an Ubuntu 
14.04 in  a VM. After I go "sudo apt-get install realpath" I can run both 
redcsl and redpsl and on my VM I do not see the complaint about Xft 
versions that you report. IN parallel with me checking that you will 
observe thatr Rainer has checked in changes that will (when we make the 
next snapshot) mean that things do not try to use "realpath" ans so shoudl 
be safe for people.
But could you please try installing realpath - and/or see the fix that 
Rainer just checke din and hand-edit that into your /usr/bin/red?sl 
scripts and check again.
  Arthur

On Tue, 12 Apr 2016, Arthur Norman wrote:

> Thank you. Your prompt report will really help. We will not try again until 
> we have both had a chance to investigate these issues and see what other 
> ones others raise. If there are going to be serious delicacies about just 
> which versions of various shared libraries different versions of Linux use 
> that is going to be HORRID. So any investigation and advice you can give 
> will be useful. The Linux versions were built on an Ubuntu 15.10 that had 
> used "apt-get upgrade" to get it thoroughly current.
>
>  Arthur
>
> On Tue, 12 Apr 2016, Raymond Rogers wrote:
>
>> The problems seem minor in Ubuntu 14.xxxx
>> 
>> redcsl: the script file in /usr/bin/  doesn't point to the correct place.
>> The script is:
>> ----------
>> #! /bin/sh
>> 
>> MYDIR=`dirname $0`
>> CSLBUILDDIR=`realpath $MYDIR/../lib/reduce/cslbuild`
>> exec $CSLBUILDDIR/csl/reduce $*
>> 
>> ----------------------------
>> Whereas the real binary location is:
>> /usr/lib/reduce/cslbuild/csl
>> ---------------------------------
>> 
>> Almost hit the target but not quite :)
>> Although when I do:
>>  /usr/lib/reduce/cslbuild/csl/reduce
>> everything seems to work but I get:
>> "Expected Xft library version 20302 or greater; was 20301"
>> I will look into this.
>> 
>> 
>> redpsl has different problems; but a core one is that bpsl  can not
>> allocate memory on my system.  In addition the script in /usr/bin refers
>> to the variable "realpath" without defining it.
>> 
>> Ray
>> 
>

Re: [Reduce-algebra-developers] Reduce snapshot 12 April

[Rainer S. <rai...@gm...>]

On Tue, 12 Apr 2016 at 11:04 -0400, Raymond Rogers wrote:

 > The problems seem minor in Ubuntu 14.xxxx
 > 
 > redcsl: the script file in /usr/bin/  doesn't point to the correct place.
 > The script is:
 > ----------
 > #! /bin/sh
 > 
 > MYDIR=`dirname $0`
 > CSLBUILDDIR=`realpath $MYDIR/../lib/reduce/cslbuild`
 > exec $CSLBUILDDIR/csl/reduce $*
 > 
 > ----------------------------
 > Whereas the real binary location is:
 > /usr/lib/reduce/cslbuild/csl
 > ---------------------------------
 > 
 > Almost hit the target but not quite :)
 > Although when I do:
 >   /usr/lib/reduce/cslbuild/csl/reduce
 > everything seems to work but I get:
 > "Expected Xft library version 20302 or greater; was 20301"
 > I will look into this.
 > 
 > 
 > redpsl has different problems; but a core one is that bpsl  can not 
 > allocate memory on my system.  In addition the script in /usr/bin refers 
 > to the variable "realpath" without defining it.

You don't tell us whether you installed the .deb package, the .rpm package or 
one of the tarballs. 

Do you have the realpath command available on your Linux?

 Regards,
   Rainer 

Re: [Reduce-algebra-developers] Reduce snapshot 12 April

[Arthur N. <ac...@ca...>]

Thank you. Your prompt report will really help. We will not try again 
until we have both had a chance to investigate these issues and see what 
other ones others raise. If there are going to be serious delicacies about 
just which versions of various shared libraries different versions of 
Linux use that is going to be HORRID. So any investigation and advice you 
can give will be useful. The Linux versions were built on an Ubuntu 15.10 
that had used "apt-get upgrade" to get it thoroughly current.

   Arthur

On Tue, 12 Apr 2016, Raymond Rogers wrote:

> The problems seem minor in Ubuntu 14.xxxx
>
> redcsl: the script file in /usr/bin/  doesn't point to the correct place.
> The script is:
> ----------
> #! /bin/sh
>
> MYDIR=`dirname $0`
> CSLBUILDDIR=`realpath $MYDIR/../lib/reduce/cslbuild`
> exec $CSLBUILDDIR/csl/reduce $*
>
> ----------------------------
> Whereas the real binary location is:
> /usr/lib/reduce/cslbuild/csl
> ---------------------------------
>
> Almost hit the target but not quite :)
> Although when I do:
>  /usr/lib/reduce/cslbuild/csl/reduce
> everything seems to work but I get:
> "Expected Xft library version 20302 or greater; was 20301"
> I will look into this.
>
>
> redpsl has different problems; but a core one is that bpsl  can not
> allocate memory on my system.  In addition the script in /usr/bin refers
> to the variable "realpath" without defining it.
>
> Ray
>