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

[Reduce-algebra-developers] File format .b?

[Douglas G. D. <dan...@gr...>]

Hello,
What is a ".b" file?
Its not a dll.  I don't believe it is a "basic" file.
So, what generates .b files?
Are they something very specific to Reduce?

-Doug Danforth

[Reduce-algebra-developers] Cygwin compilation (minor?) problems

[René G. <dos...@gm...>]

I managed to get CSL Reduce 3684 compiled under Cygwin but with some
(minor?) problems.

[1] the shell script *cygwin-sanity-check.sh* told me that:


To build Reduce you should install texlive-collection-fonts-recommended
To build Reduce you should install texlive-collection-fonts-extra


However my Cygwin mirror has

 texlive-collection-fontsrecommended
 texlive-collection-fontsextra


with no extra hyphen.


 [2] again the generated file *machineid-2.cpp* and thus *machineid.cpp*
has an added but this time rather peculiar ^M (*highlighted* when the filed
is viewed with *less*) and the compiler failed because it causes zillions
of unmatched " pairs.

I had that problem before but it was easy to kill that spurious ^M and
simply resume the compilation.

This time neither grep nor sed (or any other editor I tried for that
matter!) would recognise this peculiar character by any of the standard
ways the notorious Windows CR LF pair is known as regular expression.

In answer to a *stackexchange* query (not mine!) it was said to use: CTRL v
CTRL m, which indeed printed as the peculiar ^M.

Thus I was tempted to add after the *cslbuild/i686-pc-cygwin/csl Makefile*
line

cat machineid-1.cpp machineid-2.cpp > machineid.cpp

the line

sed -i 's/<CTRL v CTRL m>//g' machineid.cpp


which worked.

This command line *prints* indeed as


sed -i 's/^M//g' machineid.cpp


but cannot be reused as such later on without explicitly inserting CTRL v
CTRL m instead of te printed ^M.

Thus I left the Makefile alone and did the correction with the sed command
before resuming the compilation.

The *make csl* could be resumed again and the operation must be repeated
twice with the *i686-pc-windows *and *x86_64-pc-windows* compilations.

I could not figure out where and when the faulty *machineid.cpp *was copied
in the relevant directories. After each failure, *find *could only find the
initial faulty copy or a new one responsible for each of the compilation
failures in turn.

*The final redscl seems to be fine *and thus I reported the problem here
only in the hope that it might help correcting it. I cannot understand
myself how the spurious CTRL v CTRL m was inserted and thus cannot be of
further help in the matter.

Regards and thanks to Arthur,

René.

Re: [Reduce-algebra-developers] ubuntu 16.04 LTS

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

Thank you!!! I will interleave responses.

On Wed, 11 May 2016, René Grognard wrote:

> I am happy to report that after upgrading from ubuntu 15.10 to 16.04 LTS
> the compilation of redcsl and redpsl went without a hitch right to the
> testall.sh
>
Hoorah. That is of course what we HOPE for so it ois nice to hear a report 
when it does.

> I was somewhat surprised by the huge amount of download/install required by
> the new ubuntu-sanity-check.sh.
>
Some of that is that ubuntu_sanity check fetches all the Ubuntu packages 
needed to build documentation, and that includes not just LaTeX but some 
font packages relevant for it... and the result is that if you do not 
already have them installed you get a big fetch.

> Also redcsl and redpsl reported version 3648 whereas svn update reported
> revision 3660. Any reason for the difference?
>
There can be revisions in the subversion repository that do not change 
enough of the key Reduce sources to trigger to version number that gets 
built into Reduce itself to be updated. For instance recently there have 
been checkins relating to work in redfront abd others that may have an 
effect on just some PSL target architectures. those changes do not impact 
Reduce itself or only on limited architectures and so do not lead to an 
update on the revision number it reports. When that revision number is 
changes it may lead to many people finding they need to recompile all of 
Reduce and if the only file that had changed was the one storing a revison 
number that would seem wasteful and unnecessary...

> René.
>
> (Dr R J M Grognard, Sydney,Australia)
>
Arthur

[Reduce-algebra-developers] ubuntu 16.04 LTS

[René G. <dos...@gm...>]

I am happy to report that after upgrading from ubuntu 15.10 to 16.04 LTS
the compilation of redcsl and redpsl went without a hitch right to the
testall.sh

I was somewhat surprised by the huge amount of download/install required by
the new ubuntu-sanity-check.sh.

Also redcsl and redpsl reported version 3648 whereas svn update reported
revision 3660. Any reason for the difference?

René.

(Dr R J M Grognard, Sydney,Australia)

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

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

Rainer,

Thanks very much for the fix!

                     Kostas

On 05/05/2016 03:58, Rainer Schöpf wrote:
> Now fixed.
>
> The reason was indeed that a rounded domain element is not correctly handled
> in the form functions.
>
> The bug manifested itself only when the rounded number was passed as argument to
> the procedure, since such an argeumnt is evaluated and simplified to internal
> form before passing.
>
>   Rainer
>
>
> On Sun, 1 May 2016 at 10:12 -0400, Kostas Oikonomou wrote:
>
>   > I, unfortunately, found another problem.  I wonder if it is related.
>   >
>   > Consider the following file "bug.red":
>   >
>   > ------------------------------------------------------------------------
>   > on rounded$
>   > procedure ab(eps);
>   > %procedure ab();
>   >    begin;
>   >       ierr := mat((2.11),(1.18),(0.004));
>   >       select(ierr(~i,1) <= eps, for i := 1:3 collect i);
>   >       % select(ierr(~i,1) <= 1e-5, for i := 1:3 collect i);
>   >    end$
>   > end;
>   > ------------------------------------------------------------------------
>   >
>   > Now we have:
>   >
>   > [ko@wiley ]$ redcsl -w --no-rcfile
>   > REDUCE (3632), 29-Apr-16 ...
>   >
>   > 1: in "bug.red"$
>   >
>   > 2: ab(1e-5);
>   > Abort trap
>   > [ko@wiley ]$
>   >
>   > However, if the commented out lines are substituted, the problem disappears.
>   > So it seems to have something to do with the argument to the procedure call.
>   > I assume this is reproducible ...
>   >
>   >                                         Kostas
>   >
>
>     Rainer Schöpf

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

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

On Mon, 2 May 2016 at 06:36 -0600, Nelson H. F. Beebe wrote:

 > >From the reduce-20160429 snapshot on my FreeBSD 11 x86-64 system,
 > here is what I see with Kosta's short bug.red program:

For the record: I made a couple of improvements to the FreeBSD (64bit) port of 
PSL, one of them printing out the name of the lisp function where the bus error 
or segmentation violation occurs. I'll update the 32bit FreeBSD version soon.

Also, PSL Reduce understands the --no-rcfile command line option from now on.

 Rainer

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

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

Now fixed. 

The reason was indeed that a rounded domain element is not correctly handled 
in the form functions.

The bug manifested itself only when the rounded number was passed as argument to 
the procedure, since such an argeumnt is evaluated and simplified to internal 
form before passing. 

 Rainer


On Sun, 1 May 2016 at 10:12 -0400, Kostas Oikonomou wrote:

 > I, unfortunately, found another problem.  I wonder if it is related.
 > 
 > Consider the following file "bug.red":
 > 
 > ------------------------------------------------------------------------
 > on rounded$
 > procedure ab(eps);
 > %procedure ab();
 >    begin;
 >       ierr := mat((2.11),(1.18),(0.004));
 >       select(ierr(~i,1) <= eps, for i := 1:3 collect i);
 >       % select(ierr(~i,1) <= 1e-5, for i := 1:3 collect i);
 >    end$
 > end;
 > ------------------------------------------------------------------------
 > 
 > Now we have:
 > 
 > [ko@wiley ]$ redcsl -w --no-rcfile
 > REDUCE (3632), 29-Apr-16 ...
 > 
 > 1: in "bug.red"$
 > 
 > 2: ab(1e-5);
 > Abort trap
 > [ko@wiley ]$
 > 
 > However, if the commented out lines are substituted, the problem disappears.
 > So it seems to have something to do with the argument to the procedure call.
 > I assume this is reproducible ...
 > 
 >                                         Kostas
 > 

   Rainer Schöpf

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

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

>From the reduce-20160429 snapshot on my FreeBSD 11 x86-64 system,
here is what I see with Kosta's short bug.red program:

%  redcsl -w --no-rcfile
REDUCE (3632), 30-Apr-16 ...

1: in "bug.red"$

2: ab(1e-5);
terminate called after throwing an instance of 'char const*'
Abort

%  redpsl -w --no-rcfile
Loading image file:
/usr/uumath/ashare/reduce/reduce-20160429/scripts/../pslbuild/x86_64-unknown-freebsd11.0/red/reduce.img 
Reduce (Free PSL version, revision 3632), 30-Apr-2016 ...

1: in "bug.red"$

2: ab(1e-5);
***** Bus Error

3: ^D
4: quit;

Quitting

On GNU/Linux x86-64 CentOS 7, the first gives

2: ab(1e-5);

Memory access violation detected

and the second reports

2: ab(1e-5);
***** Segmentation Violation in formlis

Running it under valgrind does not produce any further info from valgrind
about pointer violations or other issues. 

Arthur suggested this alternative tracing:

% bootstrapreduce -w
REDUCE (3632), 29-Apr-16 ...

1: in "bug.red"$

2: on backtrace;

3: ab(1e-5);

+++ Error attempt to take car of an atom: 1.0e-05
Inside: form1
Arg1: (!:rd!: . 1.0e-05)
Arg2: nil
Arg3: algebraic
Inside: convertmode
Arg1: (!:rd!: . 1.0e-05)
Arg2: nil
Arg3: symbolic
Arg4: algebraic
Inside: formc
Arg1: (!:rd!: . 1.0e-05)
Arg2: nil
Arg3: algebraic
Inside: formclis
Arg1: ((!:rd!: . 1.0e-05))
Arg2: nil
Arg3: algebraic
Inside: formbool
Arg1: (leq (ierr (!~ i) 1) (!:rd!: . 1.0e-05))
Arg2: nil
Arg3: algebraic
Inside: select!-eval
Arg1: ((leq (ierr (!~ i) 1) (!:rd!: . 1.0e-05)) (list 1 2 3))
apply: select!-eval
Inside: reval1
Arg1: (select (leq (ierr (!~ i) 1) (!:rd!: . 1.0e-05)) (list 1 2 3))

Evaluating: (aeval (list (quote select) (list (quote leq) (list (quote ierr) (
list (quote !~) (quote i)) 1) eps) (prog (i forall!-result forall!-endptr) (setq
 i 1) (cond (#1=(minusp (difference 3 i)) (return (makelist nil)))) (setq 
forall!-result (setq forall!-endptr (cons i nil))) looplabel (setq i (plus2 i 1)
) (cond (#1# (return (cons (quote list) forall!-result)))) (rplacd 
forall!-endptr (cons i nil)) (setq forall!-endptr (cdr forall!-endptr)) (go 
looplabel))))
Evaluating: (nil (setk (quote ierr) (aeval (list (quote mat) (list (quote (
!:dn!: 211 . -2))) (list (quote (!:dn!: 118 . -2))) (list (quote (!:dn!: 4 . -3)
))))) (aeval (list (quote select) (list (quote leq) (list (quote ierr) (list (
quote !~) (quote i)) 1) eps) (prog (i forall!-result forall!-endptr) (setq i 1) 
(cond (#1=(minusp (difference 3 i)) (return (makelist nil)))) (setq 
forall!-result (setq forall!-endptr (cons i nil))) looplabel (setq i (plus2 i 1)
) (cond (#1# (return (cons (quote list) forall!-result)))) (rplacd 
forall!-endptr (cons i nil)) (setq forall!-endptr (cdr forall!-endptr)) (go 
looplabel)))))Arg1: (!:rd!: . 1.0e-05)
Inside: reval1
Arg1: (ab (!:dn!: 1 . -5))

I get that output on both FreeBSD and CentOS.

-------------------------------------------------------------------------------
- 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...>]

Rainer,

Thanks.   But if I understand you correctly, the following should also 
exhibit the problem:

[ko@wiley ]$ redcsl -w --no-rcfile
REDUCE (3632), 29-Apr-16 ...

1: on rounded$

2: ierr := mat((2.11),(1.18),(0.004))$

3: select(ierr(~i,1) <= 1e-5, for i := 1:3 collect i);

{}

4: bye;

On 05/ 1/16 10:59 AM, Rainer Schöpf wrote:
> select(ierr(~i,1) <= 1e-5, for i := 1:3 collect i);

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

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

On Sun, 1 May 2016 at 10:12 -0400, Kostas Oikonomou wrote:

 > I, unfortunately, found another problem.  I wonder if it is related.

No, it something else entirely.

Problem is that the select operator calls formbool on its first argument. 
Formbool is part of the parser and doesn't handle rounded numbers.

A stopgap solution would be

lisp put('!:rd!:,'formfn,'mkquote);

but this needs more analysis first.

  Rainer

 > Consider the following file "bug.red":
 > 
 > ------------------------------------------------------------------------
 > on rounded$
 > procedure ab(eps);
 > %procedure ab();
 >    begin;
 >       ierr := mat((2.11),(1.18),(0.004));
 >       select(ierr(~i,1) <= eps, for i := 1:3 collect i);
 >       % select(ierr(~i,1) <= 1e-5, for i := 1:3 collect i);
 >    end$
 > end;
 > ------------------------------------------------------------------------
 > 
 > Now we have:
 > 
 > [ko@wiley ]$ redcsl -w --no-rcfile
 > REDUCE (3632), 29-Apr-16 ...
 > 
 > 1: in "bug.red"$
 > 
 > 2: ab(1e-5);
 > Abort trap
 > [ko@wiley ]$
 > 
 > However, if the commented out lines are substituted, the problem disappears.
 > So it seems to have something to do with the argument to the procedure call.
 > I assume this is reproducible ...
 > 
 >                                         Kostas
 > 

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

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

If you are looking for bugs that show up at this level using the CSL 
version then please test using bootstrapreduce rather than redcsl, and 
with "on backtrace" because that way more information may be available.
  Arthur

On Sun, 1 May 2016, Kostas Oikonomou wrote:

> I, unfortunately, found another problem.  I wonder if it is related.
>
> Consider the following file "bug.red":
>
> ------------------------------------------------------------------------
> on rounded$
> procedure ab(eps);
> %procedure ab();
>   begin;
>      ierr := mat((2.11),(1.18),(0.004));
>      select(ierr(~i,1) <= eps, for i := 1:3 collect i);
>      % select(ierr(~i,1) <= 1e-5, for i := 1:3 collect i);
>   end$
> end;
> ------------------------------------------------------------------------
>
> Now we have:
>
> [ko@wiley ]$ redcsl -w --no-rcfile
> REDUCE (3632), 29-Apr-16 ...
>
> 1: in "bug.red"$
>
> 2: ab(1e-5);
> Abort trap
> [ko@wiley ]$
>
> However, if the commented out lines are substituted, the problem 
> disappears.   So it seems to have something to do with the argument to the 
> procedure call.   I assume this is reproducible ...
>
>                                        Kostas
>

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

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

I, unfortunately, found another problem.  I wonder if it is related.

Consider the following file "bug.red":

------------------------------------------------------------------------
on rounded$
procedure ab(eps);
%procedure ab();
    begin;
       ierr := mat((2.11),(1.18),(0.004));
       select(ierr(~i,1) <= eps, for i := 1:3 collect i);
       % select(ierr(~i,1) <= 1e-5, for i := 1:3 collect i);
    end$
end;
------------------------------------------------------------------------

Now we have:

[ko@wiley ]$ redcsl -w --no-rcfile
REDUCE (3632), 29-Apr-16 ...

1: in "bug.red"$

2: ab(1e-5);
Abort trap
[ko@wiley ]$

However, if the commented out lines are substituted, the problem 
disappears.   So it seems to have something to do with the argument to 
the procedure call.   I assume this is reproducible ...

                                         Kostas

[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
>