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

You can subscribe to this list here.

 2009 2010 2011 2012 2013 2014 2015 2016 2017 Jan (2) Feb (5) Mar Apr May (2) Jun (8) Jul (4) Aug Sep Oct (2) Nov (6) Dec Jan (1) Feb (1) Mar (3) Apr (2) May (2) Jun (2) Jul (18) Aug (13) Sep (7) Oct Nov Dec (2) Jan Feb (11) Mar Apr (4) May Jun (1) Jul (18) Aug (16) Sep (12) Oct (12) Nov (19) Dec (42) Jan (16) Feb (3) Mar (8) Apr (14) May (30) Jun (5) Jul (7) Aug (3) Sep (10) Oct (4) Nov (10) Dec (1) Jan (14) Feb (8) Mar (5) Apr (3) May (9) Jun (19) Jul Aug (27) Sep (5) Oct (18) Nov (12) Dec (8) Jan (5) Feb (8) Mar (20) Apr (22) May (28) Jun (9) Jul (6) Aug (46) Sep (40) Oct (15) Nov (8) Dec (34) Jan (20) Feb (15) Mar (18) Apr (20) May (3) Jun (13) Jul (10) Aug (19) Sep (8) Oct (31) Nov (26) Dec (13) Jan (13) Feb (4) Mar (14) Apr (28) May (19) Jun (7) Jul (1) Aug Sep (19) Oct (5) Nov (4) Dec (9) Jan (4) Feb (30) Mar Apr (5) May (1) Jun (1) Jul (3) Aug (2) Sep Oct Nov Dec
S M T W T F S

1

2

3

4
(2)
5

6
(3)
7

8

9

10

11
(6)
12
(1)
13

14

15

16
(1)
17
(2)
18

19

20
(1)
21

22

23
(2)
24

25
(1)
26

27
(1)
28

29

30

31

Showing 20 results of 20

 Re: [Reduce-algebra-developers] Question about df. From: abpetrov - 2014-03-27 17:21:30 ```I want to clarify the question. Can I redefine standard behaviour of DF for function asum, defined below? Or I have to define my own differentiate operator and rewrite many rules of DF to it? Best regards, Petrov Alexander. 25.03.2014 23:52, abpetrov пишет: > I am sorry, I did not have to ask a general question. > More precisely the situation is next. > I want define a new function named asum (abstract summation). > It is means a symbol Sum, used in mathematical expressions. > But it doesn't involve any really summations. It is just symbol, > which operates with some rules. > So I defined this finction in module as > > module asum; > > % asum( f(i1,i2,...,iN), {i1,l1,h1},{i2,l2,h2},...,{iN,lN,hN}); > > put('asum,'simpfn,'simp!-asum); > and so on. > > Respectively, I suppose, that I cann't use solution b). > Moreover, because some series can not be rearranged like > df(asum..., x) = asum(df(...,x),..) > > I don't want use solution a). > > I see one solution my problem like new function > transform_asum( asum(...), 'df); > > but it will require a lot of work. > I hope may be exists more simple solution, which I can not see > because of my short knowledge of Reduce. > > > > 23.03.2014 19:20, Rainer Schöpf пишет: >> On Sun, 23 Mar 2014 at 23:50 -0000, abpetrov wrote: >> >> > >> > Hi, >> > >> > I try define a new operator f, and, respectively, a new derivation for it. >> > But there is an question. >> > >> > 1) >> > operator f\$ >> > operator x\$ >> > >> > df(f(x(i)),x(i)); >> > >> > This expression is not 0, it is right. >> > >> > 2) >> > operator f\$ >> > operator x\$ >> > >> > df(f(x(i)),x(k)); >> > >> > This expression is 0, it is not right. >> >> x(i) and x(k) are different, so there is no dependency between them. >> >> > I want have some unevaluated derivation, it is not 0. >> > >> > 3) I can define a rule, But it doesn't help. The result is 0. >> > operator f\$ >> > operator x\$ >> > operator Delta\$ >> > Deriv_by_ind := { df (x(~j), x(~j1)) => Delta(j-j1) }\$ >> > let Deriv_by_ind\$ >> > >> > df(f(x(i)),x(k)); >> > >> > How can I get unevaluated form df(f(x(i)),x(k)), which is not 0? >> >> Two possiblities: >> >> (a) define a rule for f: >> >> let { df(f(x(~j)),x(~k)) => df(f(x(j)),x(j)) * Delta(j-k) when j neq k}; >> >> >> (b) Use the dfpart package: >> >> load_package dfpart; >> >> generic_function f(u); >> >> operator Delta,x; >> Deriv_by_ind := { df (x(~j), x(~j1)) => Delta(j-j1) }; >> let Deriv_by_ind; >> >> >> Regards, >> Rainer >> ```
 Re: [Reduce-algebra-developers] Question about df. From: abpetrov - 2014-03-25 17:51:08 ```I am sorry, I did not have to ask a general question. More precisely the situation is next. I want define a new function named asum (abstract summation). It is means a symbol Sum, used in mathematical expressions. But it doesn't involve any really summations. It is just symbol, which operates with some rules. So I defined this finction in module as module asum; % asum( f(i1,i2,...,iN), {i1,l1,h1},{i2,l2,h2},...,{iN,lN,hN}); put('asum,'simpfn,'simp!-asum); and so on. Respectively, I suppose, that I cann't use solution b). Moreover, because some series can not be rearranged like df(asum..., x) = asum(df(...,x),..) I don't want use solution a). I see one solution my problem like new function transform_asum( asum(...), 'df); but it will require a lot of work. I hope may be exists more simple solution, which I can not see because of my short knowledge of Reduce. 23.03.2014 19:20, Rainer Schöpf пишет: > On Sun, 23 Mar 2014 at 23:50 -0000, abpetrov wrote: > > > > > Hi, > > > > I try define a new operator f, and, respectively, a new derivation for it. > > But there is an question. > > > > 1) > > operator f\$ > > operator x\$ > > > > df(f(x(i)),x(i)); > > > > This expression is not 0, it is right. > > > > 2) > > operator f\$ > > operator x\$ > > > > df(f(x(i)),x(k)); > > > > This expression is 0, it is not right. > > x(i) and x(k) are different, so there is no dependency between them. > > > I want have some unevaluated derivation, it is not 0. > > > > 3) I can define a rule, But it doesn't help. The result is 0. > > operator f\$ > > operator x\$ > > operator Delta\$ > > Deriv_by_ind := { df (x(~j), x(~j1)) => Delta(j-j1) }\$ > > let Deriv_by_ind\$ > > > > df(f(x(i)),x(k)); > > > > How can I get unevaluated form df(f(x(i)),x(k)), which is not 0? > > Two possiblities: > > (a) define a rule for f: > > let { df(f(x(~j)),x(~k)) => df(f(x(j)),x(j)) * Delta(j-k) when j neq k}; > > > (b) Use the dfpart package: > > load_package dfpart; > > generic_function f(u); > > operator Delta,x; > Deriv_by_ind := { df (x(~j), x(~j1)) => Delta(j-j1) }; > let Deriv_by_ind; > > > Regards, > Rainer > ```
 Re: [Reduce-algebra-developers] Question about df. From: Rainer Schöpf - 2014-03-23 19:20:21 ```On Sun, 23 Mar 2014 at 23:50 -0000, abpetrov wrote: > > Hi, > > I try define a new operator f, and, respectively, a new derivation for it. > But there is an question. > > 1) > operator f\$ > operator x\$ > > df(f(x(i)),x(i)); > > This expression is not 0, it is right. > > 2) > operator f\$ > operator x\$ > > df(f(x(i)),x(k)); > > This expression is 0, it is not right. x(i) and x(k) are different, so there is no dependency between them. > I want have some unevaluated derivation, it is not 0. > > 3) I can define a rule, But it doesn't help. The result is 0. > operator f\$ > operator x\$ > operator Delta\$ > Deriv_by_ind := { df (x(~j), x(~j1)) => Delta(j-j1) }\$ > let Deriv_by_ind\$ > > df(f(x(i)),x(k)); > > How can I get unevaluated form df(f(x(i)),x(k)), which is not 0? Two possiblities: (a) define a rule for f: let { df(f(x(~j)),x(~k)) => df(f(x(j)),x(j)) * Delta(j-k) when j neq k}; (b) Use the dfpart package: load_package dfpart; generic_function f(u); operator Delta,x; Deriv_by_ind := { df (x(~j), x(~j1)) => Delta(j-j1) }; let Deriv_by_ind; Regards, Rainer ```
 [Reduce-algebra-developers] Question about df. From: abpetrov - 2014-03-23 17:49:06 ```Hi, I try define a new operator f, and, respectively, a new derivation for it. But there is an question. 1) operator f\$ operator x\$ df(f(x(i)),x(i)); This expression is not 0, it is right. 2) operator f\$ operator x\$ df(f(x(i)),x(k)); This expression is 0, it is not right. I want have some unevaluated derivation, it is not 0. 3) I can define a rule, But it doesn't help. The result is 0. operator f\$ operator x\$ operator Delta\$ Deriv_by_ind := { df (x(~j), x(~j1)) => Delta(j-j1) }\$ let Deriv_by_ind\$ df(f(x(i)),x(k)); How can I get unevaluated form df(f(x(i)),x(k)), which is not 0? Best regards, Petrov Alexander. ```
 [Reduce-algebra-developers] Reduce and characters outside simple ASCII From: Arthur Norman - 2014-03-20 12:16:22 ```I just checked in a bunch of updates that I believe work on both the PSL and CSL version and provide what is at present limited support for use of characters outside simple ASCII. Source files should still all be in simple ASCII and for a while should not contain characters whose codes are over 0x7f. Ie accented characters, currency marks etc. However there is now a notation #word; (word is an HTML5 name for an entity) or #hexdigits; or #Udecimaldigits; that lets you express a reasonable range of Unicode characters. The code packs these in utf-8 and they then go into Lisp-level strings and symbol names that way. When items are displayed via a terminal that supports utf-8 and that has a suitable font in use you get nice displays. As a concrete example I can go (#alpha; + #beta;)^3; One thing to be aware of is that the above special treatment of "#" happens ahead of use of "!" as an escape character, so !#alpha; is an escaped alpha character not an escaped hash followed by the word alpha. The code in packages/rlisp/tok.red has rather more commentary. There are a lot of very substantial limitations and dangers in trying to use this at present - but people who do not put anything that goes "#" then characters that is a recognised word or a hex or decimal number and then a ";" should never be hurt. So in particular in case of worry please put whitespace next to the "#" or before the ";" to avoid this. Here are some of the special problems, in no particular order. Some of them can only be fixed by work within the Lisp systems... (1) PSL just plain crashes is you use EXPLODE on a symbol or string that contains characters whose codes are too large. There are functions like id2list and wideid2list (in tok.red) that may sometimes be useful alternatives. (2) if you use prin2 on an item with utf-8 encoded data all is well, but print may insert exclamation marks before each byte of a multibyte utf-8 sequence thus messing things up. (3) position across tle line (posn and linelength) can be messed up by utf-8 sequences by counting bytes not characters, so output will end up badly formatted. (4) the CSL gui does not understand utf-8 at all so will bot display things at all nicely. The same goes for parts of reduce that try to generate TeX. (5) As well as EXPLODE being an issue COMPRESS will be. All uses of it will really need review. (6) utf-8 input from files is not supported. ====== Right now I have tested this at least a little with CSL on Windows (using a cygwin terminal), Linux and Mac. I have tried PSL on Windows and and Linux but for reasons that at present look impossible the build on a mac fails. Specifically if I trace id2string I see *** Function `token' has been redefined *** (token): base 16#100351970, length 10#21 bytes token< id2string being entered a1: ! >< id2string = 4295002707 and id2string hands back something that is not a string. Its argument ought to be either a letter "s" or a newline I think! ====== An issue this all introduces is that strings (and by extension the names of identifiers) become things that can either be considered as sequences of bytes or as sequences of characters. Everything that looks inside them may need two variants to cope with the two interpretations! Arthur ```
 Re: [Reduce-algebra-developers] Changes wrt the character "#" From: Arthur Norman - 2014-03-17 07:10:38 ```On Mon, 17 Mar 2014, Andrey G. Grozin wrote: > On Sun, 16 Mar 2014, Arthur Norman wrote: >> I have just checked in a bunch of updates that alter the exact treatment >> of "#". > Is this treatment identical in csl- and psl-reduce? > > Andrey > The code at present is all in rlisp/tok.red and it behaves just the same under PSL and CSL. As much as I can I will keep everything compatible across the two versions of Lisp, and when and if things reach a stage where Lisp-level changes would help I will try to keep them as small as possible. But use of characters outside the range of 7-bit ascii will always depend on the terminal you use to display it and the fonts that it has available. Arthur ```
 Re: [Reduce-algebra-developers] Changes wrt the character "#" From: Andrey G. Grozin - 2014-03-17 03:52:52 ```On Sun, 16 Mar 2014, Arthur Norman wrote: > I have just checked in a bunch of updates that alter the exact treatment > of "#". Is this treatment identical in csl- and psl-reduce? Andrey ```
 [Reduce-algebra-developers] Changes wrt the character "#" From: Arthur Norman - 2014-03-16 22:53:46 ```I have just checked in a bunch of updates that alter the exact treatment of "#". Firstly the preprocessor-like directives #if, #else, #elif, #endif, #eval and #define may now be written without a preceeding exclamation mark... but note that they are NOT recognised within quoted items (even if those items spread across several lines), so '!#if still needs the "!" and does not try to trigger conditional inclusion, and a := '( one #if nil two #endif three); does not have the #if and #endif processed (because the quote mark protects them). Secondly # can be used to notate characters that might otherwise be hard to express. So far the follow-through that uses these is not in place, but I hope to address that sometime! #name; where name is one of the entity names from HTML5 will stand for one of teh about 2000 symbols available there. RIGHT NOW you might only use things that stand for characters with codes up to 255, and if you try larger values they can crask the Lisp system maybe. So eg "#amp;" for "&" is OK. Sometime later I hope that this will extend to #alpha; etc. #hhh; or #xhhh; where hhh are hex digits (and the x can be in upper or lower case) will be for a Unicode code-point specified in hexadecimal. #uddd; or #Uddd; will be a Unicode code point specified is decimal. There are a few HTML5 names made up just of letters a-f which could look like hex specifications. The name takes precedence and you can use X or a leading 0 to forcibly indicate numeric input. If the number you specify is over 0x0010ffff then what you gave could not be valud Unicode and it will be rejected. Unrecognised names, overlarge numbers, missing semicolons and the like should just cause the characters to go through to Reduce unaltered. A way you can try this today (and this WILL CHANGE soon I hope) is to just go lisp "#xc2;#xa3;"; which gives the two byte utf-8 sequence for a a pounds-sterling sign, and if you have a utf-8 enabled terminal you should see that. There are a few places where this change is not 100% upwards compatible (and I needed to alter a few source files scattered through Reduce to survive). Mainly a sequence of characters "#d;" where d is any string of hex digits suddently means something special. I found two places where this arise naturally. In susy2 there was a line operator !#a,!#b,!#c; where the final #c; hurt. I could fix that by just putting an apparently frivolous blank before the semicolon. In the factoriser some names like !#a were used with the intent that they would never clash with normal sensible names. By altering them to use !#z I could remove the clash with hex-specfied characters. Any code that uses "#" as an infix operator could find itself writing a#b; but if instead it speced things out as a # b; it will be safe. Arthur ```
 [Reduce-algebra-developers] Tracing and the CSL version From: Arthur Norman - 2014-03-12 21:02:33 ```I have just checked in an update that is intended to arrange that if you trace a function using bootstrapreduce (not reduce) the message will show what function called the traced thing. For instance 1: tr addsq; (addsq) 2: (x-1)^3; Tail calling addsq (2 args) from simpdiff Arg1: ((((x . 1) . 1)) . 1) Arg2: (-1 . 1) Entering addsq (2 args) from subs2f1 Arg1: ((((x . 1) . 1)) . 1) Arg2: (nil . 1) addsq = ((((x . 1) . 1)) . 1) Entering addsq (2 args) from subs2f1 Arg1: ((((x . 1) . 1)) . 1) Arg2: (-1 . 1) addsq = ((((x . 1) . 1) . -1) . 1) ... ... ... where "from xxx" indicates the caller of addsq. This is only activated when using bootstrapreduce not reduce partly because it costs (not very much but a bit) and partly because the productiion system's scheme of compilation into C hurts it. The motivation here is that if you have a misbehaving function you can trace it - and see who calls it. You can then trace the caller and in that way work back to find a context for the call where you see trouble. I hope that this will help developers, but as always I may have botched something and there can easily be circumstances that cause it to los etrack of where it is... reports of issues can help me get it better. But of course since it is intended for use when debugging maybe ANYTHING is better than nothing so many sorts of mess over it perhaps do not matter too much... Arthur ```
 Re: [Reduce-algebra-developers] downloads and snapshots From: Nelson H. F. Beebe - 2014-03-11 20:35:25 ```Thanks, Rainer, for the clarification on the sourceforge projects; we've been calling Reduce by that name at Utah for 40+ years, so I didn't think to try a name "reduce-algebra"! >> http://reduce-algebra.sf.net >> which is up to date, except for the .tar.gz file. That tar file is dated 20101007, which is 3 years and 4 months ago. Would it be feasible to automate deposit of say, a weekly or monthly, snapshot in sourceforge? ------------------------------------------------------------------------------- - 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: beebe@... - - 155 S 1400 E RM 233 beebe@... beebe@... - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- ```
 Re: [Reduce-algebra-developers] downloads and snapshots From: Arthur Norman - 2014-03-11 20:20:28 ```On Tue, 11 Mar 2014, Francis Wright wrote: > If you are referring to http://reduce-algebra.sourceforge.net/ then I'll be > happy to try to fix it, but I'm not sure that you are. For me, > http://reduce.sf.net redirects to a different SF project. Can you clarify > what web site needs fixing, please? > > Thanks, Francis > Whe all that whil ago I set up the project at sourceforge the name "reduce" had already been used by somebody else for some rather different project, so the Reduce Algebra System lives as "reduce-algera" and it seems that reduce-algebra.sf.net and reduce-algebra.sourceforge.net are both OK, and from those you can find https://sourceforge.net/projects/reduce-algebra/ which is the bit that I generally want to look at... It is now an unreasonably long time since we uploaded a simple set of binary snapshots into the sourceforge release area https://sourceforge.net/projects/reduce-algebra/files/?source=navbar and I think that perhaps we really need to get to do that since not everybody will be willing to fetch from subversion and build for themselves. As has been the case for some time that needs some level of agreemet that we can pick on one revision and declare it stable enough to be worth freezing. We might also need to agree on a naming for it. And the work of packing Reduce with installers is in a MUCH better state than it was several years ago, but I am not 100% confident that we can press a simple button and make a set of versions that will suit the majoe platforms reliably. Perhaps old style tarball binary versions of just a random snapshot might be better than nothing! Arthur ```
 Re: [Reduce-algebra-developers] downloads and snapshots From: Francis Wright - 2014-03-11 19:34:43 ```If you are referring to http://reduce-algebra.sourceforge.net/ then I'll be happy to try to fix it, but I'm not sure that you are. For me, http://reduce.sf.net redirects to a different SF project. Can you clarify what web site needs fixing, please? Thanks, Francis > -----Original Message----- > From: Nelson H. F. Beebe [mailto:beebe@...] > Sent: 11 March 2014 2:23 pm > To: reduce-algebra-developers@... > Cc: beebe@... > Subject: [Reduce-algebra-developers] downloads and snapshots > > The site > > http://reduce.sf.net > > has only reduce-0.1.tar.gz, which seems old, with 2007-vintage file dates. > > When I try (according to an old recipe recorded here): > > svn co https://reduce-algebra.svn.sourceforge.net/svnroot/reduce- > algebra reduce-20120504 > > I get > > svn: E175011: Repository moved permanently to > 'https://svn.code.sf.net/p/reduce-algebra/code/!svn/vcc/default';; > please relocate > > However, that URL is problematic because of the exclamation point, which > various shells treat as a metacharacter, and with or without it, I get > > svn: E170000: URL 'https://svn.code.sf.net/p/reduce- > algebra/code/!svn/vcc/default' doesn't exist > > I then went back through the mailing list archives and found a solution that > works: > > svn checkout http://svn.code.sf.net/p/reduce-algebra/code/trunk > reduce-20140311 > > So, can someone with sourceforge access please update the master Web page to > have > > (a) a pointer to a .tar.gz file that is reasonably current, and > > (b) instructions on how to use svn to checkout a current > development snapshot. > > The reason for my activity today is that yesterday, I got onto a new Red Hat 7 > beta system for which I'm building scores of packages. That beta release > currently has no Lisp systems whatever in its yum system, but I got clisp and > maxima installed, and reduce is next on the list. > > ---------------------------------------------------------------------------- --- > - 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: beebe@... > - > - 155 S 1400 E RM 233 beebe@... beebe@... - > - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ > - > ---------------------------------------------------------------------------- --- > > ---------------------------------------------------------------------------- -- > Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the > definitive new guide to graph databases and their applications. Written by three > acclaimed leaders in the field, this first edition is now available. Download your > free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Reduce-algebra-developers mailing list > Reduce-algebra-developers@... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers ```
 Re: [Reduce-algebra-developers] downloads and snapshots From: Rainer Schöpf - 2014-03-11 19:29:15 ```Hello Nelson, > The site > > http://reduce.sf.net > > has only reduce-0.1.tar.gz, which seems old, with 2007-vintage file dates. This is a different project, our site is http://reduce-algebra.sf.net which is up to date, except for the .tar.gz file. Rainer ```
 [Reduce-algebra-developers] [reduce-algebra-developers] reduce-20140311 on Red Hat 7 beta x86-64: success! From: Nelson H. F. Beebe - 2014-03-11 16:22:37 ```I can now report a successful first build of the reduce-20140311 svn snapshot taken earlier today, on the newly released Red Hat 7 beta on x86-64 with PSL: % reduce Loading image file: /usr/local/ashare/reduce/reduce-20140311/scripts/../pslbuild/x86_64-unknown-linux-gnu/red/reduce.img Reduce (Free PSL version), 11-Mar-2014 ... 1: int(exp(x),x); x e 2: quit; Quitting There were, however, a few glitches: (1) My initial configure attempt looked like this: env CFLAGS=-I/usr/include/freetype2 CXXFLAGS=-I/usr/include/freetype2 \ LDFLAGS='-Wl,-rpath,/usr/local/lib64 -L/usr/local/lib64' \ ./configure --with-csl (2) the automake versioning problem discussed recently on this list has not been properly fixed yet: % make /bin/sh scripts/make.sh all MFLAGS=<> MKFLAGS=<> MAKECMDGOALS=<> args= par=no PSLMFLAGS=<> Current machine tag is x86_64-unknown-linux-gnu About to build in cslbuild/x86_64-unknown-linux-gnu /usr/bin/gmake all MYFLAGS= --no-print-directory cd /usr/local/ashare/reduce/reduce-20140311 && /bin/sh /usr/local/ashare/reduce/reduce-20140311/missing automake-1.13 --foreign configure.ac:631: error: version mismatch. This is Automake 1.13.4, configure.ac:631: but the definition used by this AM_INIT_AUTOMAKE configure.ac:631: comes from Automake 1.13.3. You should recreate configure.ac:631: aclocal.m4 with aclocal and run automake again. WARNING: 'automake-1.13' is probably too old. ... I fixed that problem like this: % /usr/bin/automake --version automake (GNU automake) 1.13.4 % find . -name Makefile.in | xargs touch (3) Retry, and then get this failure: configure: WARNING: unrecognized options: --with-csl, --with-build, --with-pslbuild (4) Retry, omitting the --with-csl option: configure: error: you must specify either --with-csl or --with-psl to select a Lisp (5) Retry, adding --with-psl Success! This version built without any X11 support (the Red Hat 5 and 6 versions have it), so some more build experimentation is required. However, I'm going to delay that for now, while I build more packages for Red Hat 7. ------------------------------------------------------------------------------- - 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: beebe@... - - 155 S 1400 E RM 233 beebe@... beebe@... - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- ```
 [Reduce-algebra-developers] downloads and snapshots From: Nelson H. F. Beebe - 2014-03-11 15:32:25 ```The site http://reduce.sf.net has only reduce-0.1.tar.gz, which seems old, with 2007-vintage file dates. When I try (according to an old recipe recorded here): svn co https://reduce-algebra.svn.sourceforge.net/svnroot/reduce-algebra reduce-20120504 I get svn: E175011: Repository moved permanently to 'https://svn.code.sf.net/p/reduce-algebra/code/!svn/vcc/default';; please relocate However, that URL is problematic because of the exclamation point, which various shells treat as a metacharacter, and with or without it, I get svn: E170000: URL 'https://svn.code.sf.net/p/reduce-algebra/code/!svn/vcc/default'; doesn't exist I then went back through the mailing list archives and found a solution that works: svn checkout http://svn.code.sf.net/p/reduce-algebra/code/trunk reduce-20140311 So, can someone with sourceforge access please update the master Web page to have (a) a pointer to a .tar.gz file that is reasonably current, and (b) instructions on how to use svn to checkout a current development snapshot. The reason for my activity today is that yesterday, I got onto a new Red Hat 7 beta system for which I'm building scores of packages. That beta release currently has no Lisp systems whatever in its yum system, but I got clisp and maxima installed, and reduce is next on the list. ------------------------------------------------------------------------------- - 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: beebe@... - - 155 S 1400 E RM 233 beebe@... beebe@... - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- ```
 [Reduce-algebra-developers] autoconf/automake adjustments From: Arthur Norman - 2014-03-06 22:56:32 ```I have just checked in adjustments to the various Makefile.am files in the CSL side of the Reduce tree so that if they detect autoconf-related files are apparently not up to date they SHOULD not call the autogen.sh script in the top-level of the tree. If autoconf (etc) is installed that should use it to remake all relevant files. If it is NOT available then the script merely resets time-stamps into order. I hope I have this so it behaves well but there could be typos etc. I HOPE it really makes everything fairly seriously robust aginst whatever (even vaguely modern) versions of autoconf/automake you have installed or for people who do not have them installed at all. I HOPE. Improvements to what I have done or reports of mistakes will be welcome. Arthur ```
 Re: [Reduce-algebra-developers] About Reduce IDE. From: abpetrov - 2014-03-06 18:44:26 Attachments: lreduce.zip ```I am sorry, I have to send to reduce-algebra-developers@... You may try to build LReduce. My sourceforge account name is alex_bp 27.02.2014 20:37, Arthur Norman пишет: > That looks interesting. I think we should put that in the "generic" > directory for Reduce (alongside redfront & qreduce etc) so that > everybody who wants can build and try it. I have never tried Lazarus > but I see it asserts that it can be used on Linux and Win32 (and > more). You might like to consider what set of files could by put as say > .../trunk/generic/petrov_ide/... > (or you might consider what name you wanted this to have) then put the > licese terms in all files so that that is explicit (obviously ensuring > that you are entitled to!) and send me a .zip or .tar file so I can > install it there. It would be good if there was a document (eg in > LaTeX or a plain text file) that explains how to fetch Lazarus and > build your stuff, and enough instructions for setting it up and using > it that reasonably ordinary people could try it.... and if you ensure > that you have a sourceforge user identity you can probably be added to > the lists so you can then update and maybe even support it! > > Arthur > > On Fri, 28 Feb 2014, abpetrov wrote: > >> >> Hi, >> >> I decide to make simple Reduce IDE for myself. Now it is works fine for >> me. Of course I will try improve it, but it is depends from free time. >> And it is not my priority, I prefer mathematical part Reduce. >> >> If you think, that this program may be useful for somebody except me, I >> offer you distribute it sources with the same free license as Reduce. >> >> About program. It is written in free pascal in Lazarus and used >> interface with Reduce over pipe. I use console mode Reduce. >> It looks like multitab editor, like gedit or Kate, but it has some >> additional menu items. It allows edit many files at the same time. It >> has syntax highlighting. It can execute single line, selection or whole >> file from active tab. It remembers last session. >> >> Possible it has next big disadvantages now: >> 1) no nice graphic mathematical output >> 2) no internalization, English only >> 3) no makefile, I build it in Lazarus directly >> >> >> Screenshot is attached. >> >> Best regards, Petrov Alexander. >> >> > ```
 Re: [Reduce-algebra-developers] can not build reduce From: Andrey Krutov - 2014-03-06 17:01:02 ```Dear Arthur, Trick with scripts/stamp.sh works. Thank you! -- Best regards, Andrey On 04.03.2014 11:56, Arthur Norman wrote: > Thank you for reporting this - and in fact you are not the first who has > suffered here - however at present I do not quite understand how to get a > generic nice fix! When I doi discover I will put it in - and if anybody > here understands autoconf/automake well enough to advise me that would be > good. I will try to explain the issue and give several ways to move ahead > that should fix it. > > The Makefiles created using autoconf/automake carefully and properly put > in dependencies so that if one of the upstream configuration files like > configure.ac or Makefile.am is updated they will re-generate everything > properly be re-running autoconf/automake.configure etc. This is a good > thing. For reasons that the authors there understand but I can only > speculate about they check which version of automake (etc) you have > installed and everything goes messy (but only sometimes?) if the version > you have differes from the one used centrally. Well I can imagine that > autoconf etc may not be compatible version to version and so them > demanding version matches is way safest. > > Certainly in the past and probably still now some people do not have > autoconf etc installed at all. To help them survive the Reduce subversion > has files like configure and Makefile.in that are derived from the master > ones. > > When you update using subversion that brings all local files until step > with the master copies. SO they end up textually perfect - however > subversion does not guarantee to keep the timestamp ordering as it was in > the original. Thus after a "svn update" you can have updates versions of > (eg) Makefile.am and Makefile.in and if configure.ac and configure which > are in fact fully proper and OK, but where the timestamps suggest that the > dervived versions are out of date. That can trigger the automated attempt > to rebuild them which in turn can cause the pain you now observe. > > OK, so now how can you get this sorted out? Well I have two scripts there > that are intended to help. The first is > scripts/stamp.sh > and if you invoke that after a "svn update" it resets datestamps on > autoconf-related files so that they are in the "correct" order and "make" > will not try to recreate any of them. If at some stage you have autoremade > some of those files you may need to go "svn revert" to bring them into > step with the master versions since otherwise subversion carefully > preserves your local changes. You can observe any changes you have made > locally by going > scripts/status.sh > If you have not made any changes to the Reduce source files yourself then > the easiest recipe goes > svn -R revert . ; scripts/stamp.sh > BUT PLEASE NOTE that if you had made changes to Reduce that were your > private improvements or upgrades or whatever the global revert there would > lose them! > > The other idea is to remake all the autoconf files that exist using your > locally installed release and version of autoconf/automake and the script > ./autogen.sh > tries to do that. There are potential pains there not in re-autoconfing > bits of CSL and Reduce itself but in some of the third party packages that > are included. Some of them lead to warning messages such as "warning: > 'INCLUDES' is the old name for 'AM_CPPFLAGS'" and at present I have chosen > not to alter the master files there since they are imported. For wxWidgets > on MY system I get moans along the lines of " warning: macro > 'AM_PATH_GTK' not found in library" and "possibly undefined macro: > AC_BAKEFILE_PROG_CC" where again I could fix things up locally for myself > but I might expect that others would suffer the same way. So I think I > believe that using scripts/stamp.sh is maybe safer??? > > Anyway if some wise person can advise me of a general, portable and safe > way to deal with this that makes if easy for both people with no autoconf > installed, ones with a very old version, one with a slightly old and even > one with a newer version that used centrally... gosh it would be goot to > be told what can be done! > > Arthur > > > On Tue, 4 Mar 2014, Andrey Krutov wrote: > >> Dear reduce developers, >> >> After last update for svn up I can not build reduce. >> >> >> make 2>&1 | tee rebuild.log >> /bin/sh scripts/make.sh >> MFLAGS=<> MKFLAGS=<> MAKECMDGOALS=<> args=<> >> par=no PSLMFLAGS=<> >> Current machine tag is x86_64-unknown-ubuntu13.10 >> About to build in cslbuild/x86_64-unknown-ubuntu13.10 >> make MYFLAGS= --no-print-directory >> cd /home/hedin/tmp/reduce-algebra/trunk && /bin/sh >> /home/hedin/tmp/reduce-algebra/trunk/missing automake-1.14 --foreign >> configure.ac:631: error: version mismatch. This is Automake 1.14.1, >> configure.ac:631: but the definition used by this AM_INIT_AUTOMAKE >> configure.ac:631: comes from Automake 1.14. You should recreate >> configure.ac:631: aclocal.m4 with aclocal and run automake again. >> WARNING: 'automake-1.14' is probably too old. >> You should only need it if you modified 'Makefile.am' or >> 'configure.ac' or m4 files included by 'configure.ac'. >> The 'automake' program is part of the GNU Automake package: >> ; >> It also requires GNU Autoconf, GNU m4 and Perl in order to run: >> ; >> ; >> ; >> make[1]: *** [/home/hedin/tmp/reduce-algebra/trunk/Makefile.in] Ошибка 1 >> Building failed with return code 2 for version >> cslbuild/x86_64-unknown-ubuntu13.10 >> make: *** [all] Ошибка 2 >> >> # end of rebuild.sh >> >> >> But I have right version of automake >> >> hedin@...:~/tmp/reduce-algebra/trunk\$ automake --version >> automake (GNU automake) 1.14.1 >> Copyright (C) 2013 Free Software Foundation, Inc. >> License GPLv2+: GNU GPL version 2 or later >> ; >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. >> >> Written by Tom Tromey >> and Alexandre Duret-Lutz . >> >> >> -- >> Best regards, >> Andrey >> >> ------------------------------------------------------------------------------ >> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. >> With Perforce, you get hassle-free workflows. Merge that actually works. >> Faster operations. Version large binaries. Built-in WAN optimization and the >> freedom to use Git, Perforce or both. Make the move to Perforce. >> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk >> _______________________________________________ >> Reduce-algebra-developers mailing list >> Reduce-algebra-developers@... >> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers ```
 Re: [Reduce-algebra-developers] can not build reduce From: Arthur Norman - 2014-03-04 10:56:51 ```Thank you for reporting this - and in fact you are not the first who has suffered here - however at present I do not quite understand how to get a generic nice fix! When I doi discover I will put it in - and if anybody here understands autoconf/automake well enough to advise me that would be good. I will try to explain the issue and give several ways to move ahead that should fix it. The Makefiles created using autoconf/automake carefully and properly put in dependencies so that if one of the upstream configuration files like configure.ac or Makefile.am is updated they will re-generate everything properly be re-running autoconf/automake.configure etc. This is a good thing. For reasons that the authors there understand but I can only speculate about they check which version of automake (etc) you have installed and everything goes messy (but only sometimes?) if the version you have differes from the one used centrally. Well I can imagine that autoconf etc may not be compatible version to version and so them demanding version matches is way safest. Certainly in the past and probably still now some people do not have autoconf etc installed at all. To help them survive the Reduce subversion has files like configure and Makefile.in that are derived from the master ones. When you update using subversion that brings all local files until step with the master copies. SO they end up textually perfect - however subversion does not guarantee to keep the timestamp ordering as it was in the original. Thus after a "svn update" you can have updates versions of (eg) Makefile.am and Makefile.in and if configure.ac and configure which are in fact fully proper and OK, but where the timestamps suggest that the dervived versions are out of date. That can trigger the automated attempt to rebuild them which in turn can cause the pain you now observe. OK, so now how can you get this sorted out? Well I have two scripts there that are intended to help. The first is scripts/stamp.sh and if you invoke that after a "svn update" it resets datestamps on autoconf-related files so that they are in the "correct" order and "make" will not try to recreate any of them. If at some stage you have autoremade some of those files you may need to go "svn revert" to bring them into step with the master versions since otherwise subversion carefully preserves your local changes. You can observe any changes you have made locally by going scripts/status.sh If you have not made any changes to the Reduce source files yourself then the easiest recipe goes svn -R revert . ; scripts/stamp.sh BUT PLEASE NOTE that if you had made changes to Reduce that were your private improvements or upgrades or whatever the global revert there would lose them! The other idea is to remake all the autoconf files that exist using your locally installed release and version of autoconf/automake and the script ./autogen.sh tries to do that. There are potential pains there not in re-autoconfing bits of CSL and Reduce itself but in some of the third party packages that are included. Some of them lead to warning messages such as "warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS'" and at present I have chosen not to alter the master files there since they are imported. For wxWidgets on MY system I get moans along the lines of " warning: macro 'AM_PATH_GTK' not found in library" and "possibly undefined macro: AC_BAKEFILE_PROG_CC" where again I could fix things up locally for myself but I might expect that others would suffer the same way. So I think I believe that using scripts/stamp.sh is maybe safer??? Anyway if some wise person can advise me of a general, portable and safe way to deal with this that makes if easy for both people with no autoconf installed, ones with a very old version, one with a slightly old and even one with a newer version that used centrally... gosh it would be goot to be told what can be done! Arthur On Tue, 4 Mar 2014, Andrey Krutov wrote: > Dear reduce developers, > > After last update for svn up I can not build reduce. > > > make 2>&1 | tee rebuild.log > /bin/sh scripts/make.sh > MFLAGS=<> MKFLAGS=<> MAKECMDGOALS=<> args=<> > par=no PSLMFLAGS=<> > Current machine tag is x86_64-unknown-ubuntu13.10 > About to build in cslbuild/x86_64-unknown-ubuntu13.10 > make MYFLAGS= --no-print-directory > cd /home/hedin/tmp/reduce-algebra/trunk && /bin/sh > /home/hedin/tmp/reduce-algebra/trunk/missing automake-1.14 --foreign > configure.ac:631: error: version mismatch. This is Automake 1.14.1, > configure.ac:631: but the definition used by this AM_INIT_AUTOMAKE > configure.ac:631: comes from Automake 1.14. You should recreate > configure.ac:631: aclocal.m4 with aclocal and run automake again. > WARNING: 'automake-1.14' is probably too old. > You should only need it if you modified 'Makefile.am' or > 'configure.ac' or m4 files included by 'configure.ac'. > The 'automake' program is part of the GNU Automake package: > ; > It also requires GNU Autoconf, GNU m4 and Perl in order to run: > ; > ; > ; > make[1]: *** [/home/hedin/tmp/reduce-algebra/trunk/Makefile.in] Ошибка 1 > Building failed with return code 2 for version > cslbuild/x86_64-unknown-ubuntu13.10 > make: *** [all] Ошибка 2 > > # end of rebuild.sh > > > But I have right version of automake > > hedin@...:~/tmp/reduce-algebra/trunk\$ automake --version > automake (GNU automake) 1.14.1 > Copyright (C) 2013 Free Software Foundation, Inc. > License GPLv2+: GNU GPL version 2 or later > ; > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Written by Tom Tromey > and Alexandre Duret-Lutz . > > > -- > Best regards, > Andrey > > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and the > freedom to use Git, Perforce or both. Make the move to Perforce. > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > _______________________________________________ > Reduce-algebra-developers mailing list > Reduce-algebra-developers@... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers```
 [Reduce-algebra-developers] can not build reduce From: Andrey Krutov - 2014-03-04 10:22:28 ```Dear reduce developers, After last update for svn up I can not build reduce. make 2>&1 | tee rebuild.log /bin/sh scripts/make.sh MFLAGS=<> MKFLAGS=<> MAKECMDGOALS=<> args=<> par=no PSLMFLAGS=<> Current machine tag is x86_64-unknown-ubuntu13.10 About to build in cslbuild/x86_64-unknown-ubuntu13.10 make MYFLAGS= --no-print-directory cd /home/hedin/tmp/reduce-algebra/trunk && /bin/sh /home/hedin/tmp/reduce-algebra/trunk/missing automake-1.14 --foreign configure.ac:631: error: version mismatch. This is Automake 1.14.1, configure.ac:631: but the definition used by this AM_INIT_AUTOMAKE configure.ac:631: comes from Automake 1.14. You should recreate configure.ac:631: aclocal.m4 with aclocal and run automake again. WARNING: 'automake-1.14' is probably too old. You should only need it if you modified 'Makefile.am' or 'configure.ac' or m4 files included by 'configure.ac'. The 'automake' program is part of the GNU Automake package: ; It also requires GNU Autoconf, GNU m4 and Perl in order to run: ; ; ; make[1]: *** [/home/hedin/tmp/reduce-algebra/trunk/Makefile.in] Ошибка 1 Building failed with return code 2 for version cslbuild/x86_64-unknown-ubuntu13.10 make: *** [all] Ошибка 2 # end of rebuild.sh But I have right version of automake hedin@...:~/tmp/reduce-algebra/trunk\$ automake --version automake (GNU automake) 1.14.1 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv2+: GNU GPL version 2 or later ; This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Tom Tromey and Alexandre Duret-Lutz . -- Best regards, Andrey ```

Showing 20 results of 20