Menu
▾
▴
reduce-algebra-developers
|
From: Kostas O. <k.o...@at...> - 2014-04-27 16:59:21
|
Hello,
I am having some problems with building reduce from svn on FreeBSD 10.
Here is what I do:
[ko@wiley <javascript:return> ~/build/reduce]$ configure
--prefix=/opt/reduce --with-psl
configure: Absolute path to source directory = /usr/home/ko/build/reduce
checking build system type... amd64-unknown-freebsd10.0
checking host system type... amd64-unknown-freebsd10.0
configure: with_crlibm = yes
in-place build attempt = yes
configure: host=amd64-unknown-freebsd10.0 args= '--prefix=/opt/reduce'
'--with-psl'
configure: Will build in the x86_64-unknown-freebsd10.0 subdirectory
configure: +++ Will build in
/usr/home/ko/build/reduce/pslbuild/x86_64-unknown-freebsd10.0
checking build system type... amd64-unknown-freebsd10.0
checking host system type... amd64-unknown-freebsd10.0
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p...
/usr/home/ko/build/reduce/psl/../install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for cygpath... no
configure: Build platform specified as x86_64-unknown-freebsd10.0
configure: Will build this PSL using the unknown initial binaries
cp: ../../psl/dist/nonkernel/unknown/lap/*: No such file or directory
cp: ../../psl/dist/lap/unknown/*.b: No such file or directory
cp: ../../psl/dist/kernel/unknown/bpsl*: No such file or directory
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
[ko@wiley <javascript:return> ~/build/reduce]$
This doesn't seem like a successful configure! Anyhow, the next step
fails:
[ko@wiley <javascript:return> ~/build/reduce]$ make psl
/bin/sh scripts/make.sh psl
MFLAGS=<> MKFLAGS=<> MAKECMDGOALS=<> args=<psl>
par=no PSLMFLAGS=<>
Current machine tag is x86_64-unknown-freebsd10.0
About to build in pslbuild/x86_64-unknown-freebsd10.0
/usr/local/bin/gmake MYFLAGS= --no-print-directory
if ! test -f red/bootstrap.img; \
then /usr/local/bin/gmake red/bootstrap.img; \
if test -f red/bootstrap.img; then /usr/local/bin/gmake reduce; fi; \
else touch red/bootstrap.img; touch red/hugo; /usr/local/bin/gmake
reduce; fi
/usr/home/ko/build/reduce/psl/bootstrap.sh x86_64-unknown-freebsd10.0
/usr/home/ko/build/reduce/pslbuild/x86_64-unknown-freebsd10.0
++++++ Build initial bootstrap system ++++++
Bus error
Bus error
Bootstrap reduce built
[ko@wiley <javascript:return> ~/build/reduce]$
I would appreciate any help. Thanks in advance.
Kostas
|
|
From: Rainer S. <rai...@gm...> - 2014-04-27 18:06:42
|
On Sun, 27 Apr 2014 at 13:00 -0400, Kostas Oikonomou wrote: > I am having some problems with building reduce from svn on FreeBSD 10. > Here is what I do: > > > [ko@wiley <javascript:return> ~/build/reduce]$ configure > --prefix=/opt/reduce --with-psl > configure: Absolute path to source directory = /usr/home/ko/build/reduce > checking build system type... amd64-unknown-freebsd10.0 > checking host system type... amd64-unknown-freebsd10.0 This is probably the reason: previously the build system type was x86_64-unknown-freebsd<version> Maybe this is a change in uname or in autoconf. Could you please supply the output of the following commands: uname -m uname -p uname -r uname -s ./config.guess ./scripts/findhost `./config.guess` ./scripts/pslver.sh Thank you Rainer |
|
From: Kostas O. <k.o...@at...> - 2014-04-27 18:11:48
|
Hello Rainer,
Here are the results:
[ko@wiley ~/build/reduce]$ uname -m
amd64
[ko@wiley ~/build/reduce]$ uname -p
amd64
[ko@wiley ~/build/reduce]$ uname -r
10.0-RELEASE-p9
[ko@wiley ~/build/reduce]$ uname -s
FreeBSD
[ko@wiley ~/build/reduce]$ ./config.guess
amd64-unknown-freebsd10.0
[ko@wiley ~/build/reduce]$ ./scripts/findhost `./config.guess`
bash: ./scripts/findhost: No such file or directory
[ko@wiley ~/build/reduce]$ ./scripts/pslver.sh
unknown
[ko@wiley ~/build/reduce]$
Kostas
On 04/27/2014 14:04, Rainer Schöpf wrote:
> On Sun, 27 Apr 2014 at 13:00 -0400, Kostas Oikonomou wrote:
>
> > I am having some problems with building reduce from svn on FreeBSD 10.
> > Here is what I do:
> >
> >
> > [ko@wiley <javascript:return> ~/build/reduce]$ configure
> > --prefix=/opt/reduce --with-psl
> > configure: Absolute path to source directory = /usr/home/ko/build/reduce
> > checking build system type... amd64-unknown-freebsd10.0
> > checking host system type... amd64-unknown-freebsd10.0
>
> This is probably the reason: previously the build system type was
>
> x86_64-unknown-freebsd<version>
>
> Maybe this is a change in uname or in autoconf.
>
> Could you please supply the output of the following commands:
>
> uname -m
> uname -p
> uname -r
> uname -s
> ./config.guess
> ./scripts/findhost `./config.guess`
> ./scripts/pslver.sh
>
> Thank you
> Rainer
>
|
|
From: Rainer S. <rai...@gm...> - 2014-04-27 18:24:02
|
Hello Kostas, it looks like autoconf / config.guess do behave differently at your end. I've updated a couple of files. Please update your wubversion working copy (to revision 2513) and try again. Rainer |
|
From: Kostas O. <k.o...@at...> - 2014-04-27 18:35:19
|
Ok, here is what happens now. The "configure" step has improved, but the "make" still has problems. On 04/27/2014 14:23, Rainer Schöpf wrote: > Hello Kostas, > > it looks like autoconf / config.guess do behave differently at your end. > I've updated a couple of files. Please update your wubversion working copy (to revision 2513) and try again. > > Rainer > > [ko@wiley ~/build/reduce]$ configure --prefix=/opt/reduce --with-psl configure: Absolute path to source directory = /usr/home/ko/build/reduce checking build system type... amd64-unknown-freebsd10.0 checking host system type... amd64-unknown-freebsd10.0 configure: with_crlibm = yes in-place build attempt = yes configure: host=amd64-unknown-freebsd10.0 args= '--prefix=/opt/reduce' '--with-psl' configure: Will build in the x86_64-unknown-freebsd10.0 subdirectory configure: +++ Will build in /usr/home/ko/build/reduce/pslbuild/x86_64-unknown-freebsd10.0 checking build system type... amd64-unknown-freebsd10.0 checking host system type... amd64-unknown-freebsd10.0 checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/home/ko/build/reduce/psl/../install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking for cygpath... no configure: Build platform specified as x86_64-unknown-freebsd10.0 configure: Will build this PSL using the freeBSD64 initial binaries checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile [ko@wiley ~/build/reduce]$ [ko@wiley ~/build/reduce]$ make psl /bin/sh scripts/make.sh psl MFLAGS=<> MKFLAGS=<> MAKECMDGOALS=<> args=<psl> par=no PSLMFLAGS=<> Current machine tag is x86_64-unknown-freebsd10.0 About to build in pslbuild/x86_64-unknown-freebsd10.0 /usr/local/bin/gmake MYFLAGS= --no-print-directory if ! test -d deps; then mkdir deps; fi touch deps/noncore-packages.psl-depend if ! test -d deps; then mkdir deps; fi touch deps/noncore-packages.psl-make if ! test -d deps; then mkdir deps; fi touch deps/core-packages.psl-depend if ! test -d deps; then mkdir deps; fi touch deps/core-packages.psl-make Makefile:557: TRACE: /usr/home/ko/build/reduce/psl/aclocal.m4 :: /usr/home/ko/build/reduce/psl/configure.ac autoreconf command available for use. ============================================================ Updating autoconf files in /usr/home/ko/build/reduce/psl: /usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of AM_PATH_SMPEG /usr/local/share/aclocal/smpeg.m4:13: run info Automake 'Extending aclocal' /usr/local/share/aclocal/smpeg.m4:13: or see http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal ============================================================ Updating autoconf files in /usr/home/ko/build/reduce/psl/support-packages/xport-2.05: /usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of AM_PATH_SMPEG /usr/local/share/aclocal/smpeg.m4:13: run info Automake 'Extending aclocal' /usr/local/share/aclocal/smpeg.m4:13: or see http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal Now reset all date-stamps... Step 1 of 5: configure.ac, configure.in and Makefile.am: Step 2 of 5: aclocal.m4: Step 3 of 5: configure: Step 4 of 5: config.h.in: Step 5 of 5: Makefile.in: Date-stamps should now be in the proper sequence. Makefile:573: TRACE: /usr/home/ko/build/reduce/psl/Makefile.in :: /usr/home/ko/build/reduce/psl/configure.ac /usr/home/ko/build/reduce/psl/aclocal.m4 /usr/home/ko/build/reduce/psl/configure Redundant attempt to remake Makefile.in /bin/sh ./config.status --recheck running CONFIG_SHELL=/bin/sh /bin/sh /usr/home/ko/build/reduce/psl/configure --prefix=/opt/reduce --with-psl --with-build=x86_64-unknown-freebsd10.0 --no-create --no-recursion checking build system type... amd64-unknown-freebsd10.0 checking host system type... amd64-unknown-freebsd10.0 checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/home/ko/build/reduce/psl/../install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether /usr/local/bin/gmake sets $(MAKE)... yes checking whether /usr/local/bin/gmake supports nested variables... yes checking for cygpath... no configure: Build platform specified as x86_64-unknown-freebsd10.0 configure: Will build this PSL using the freeBSD64 initial binaries checking that generated files are newer than configure... done configure: creating ./config.status /bin/sh ./config.status config.status: creating Makefile if ! test -f red/bootstrap.img; \ then /usr/local/bin/gmake red/bootstrap.img; \ if test -f red/bootstrap.img; then /usr/local/bin/gmake reduce; fi; \ else touch red/bootstrap.img; touch red/hugo; /usr/local/bin/gmake reduce; fi /usr/home/ko/build/reduce/psl/bootstrap.sh x86_64-unknown-freebsd10.0 /usr/home/ko/build/reduce/pslbuild/x86_64-unknown-freebsd10.0 ++++++ Build initial bootstrap system ++++++ Bus error Bus error Bootstrap reduce built [ko@wiley ~/build/reduce]$ |
|
From: Rainer S. <rai...@gm...> - 2014-04-27 19:11:46
|
On Sun, 27 Apr 2014 at 14:36 -0400, Kostas Oikonomou wrote: > Ok, here is what happens now. The "configure" step has improved, but the > "make" still has problems. Interesting. The PSL port was build on FreeBSD 8.3, so it is probably necessary to recompile on 10.0. I don't have 10.0 readily available, so this will take a bit of time. If you're feeling adventorous, you might try for yourself: cd psl/dist/kernel/freeBSD64 ./cclnk Remove the pslbuild/x86_64-unknown-freebsd10.0 directory and run configure again. Rainer |
|
From: Kostas O. <k.o...@at...> - 2014-04-27 20:37:46
|
[ko@wiley ~/build/reduce]$ cd psl/dist/kernel/freeBSD64
[ko@wiley ~/build/reduce/psl/dist/kernel/freeBSD64]$ ./cclnk
pslextras.c:170:9: error: non-void function 'setenv' should return a
value [-Wreturn-type]
return;
^
1 error generated.
[ko@wiley ~/build/reduce/psl/dist/kernel/freeBSD64]$
I see that "cclnk" invokes "cc". This prompts me to ask: does the
build need gcc? The default C compiler on FreeBSD 10 is clang. It was
gcc up to FreeBSD 9.2. gcc is still available, but I would need to
specify CC=gcc on the "configure" line.
On 04/27/2014 15:09, Rainer Schöpf wrote:
> On Sun, 27 Apr 2014 at 14:36 -0400, Kostas Oikonomou wrote:
>
> > Ok, here is what happens now. The "configure" step has improved, but the
> > "make" still has problems.
>
> Interesting. The PSL port was build on FreeBSD 8.3, so it is probably necessary
> to recompile on 10.0. I don't have 10.0 readily available, so this will take a
> bit of time.
>
> If you're feeling adventorous, you might try for yourself:
>
> cd psl/dist/kernel/freeBSD64
> ./cclnk
>
> Remove the
>
> pslbuild/x86_64-unknown-freebsd10.0
>
> directory and run configure again.
>
> Rainer
>
|
|
From: Pedro G. <pfg@FreeBSD.org> - 2014-04-27 21:01:13
|
El 27/04/2014 15:39, Kostas Oikonomou escribió: > [ko@wiley ~/build/reduce]$ cd psl/dist/kernel/freeBSD64 > [ko@wiley ~/build/reduce/psl/dist/kernel/freeBSD64]$ ./cclnk > pslextras.c:170:9: error: non-void function 'setenv' should return a > value [-Wreturn-type] > return; > ^ > 1 error generated. > [ko@wiley ~/build/reduce/psl/dist/kernel/freeBSD64]$ > This is just clang being more picky than gcc. You can probably disable the warnings but it looks like a good chance to clean the code. Building on other platforms with clang should reveal the same issues. > I see that "cclnk" invokes "cc". This prompts me to ask: does the > build need gcc? The default C compiler on FreeBSD 10 is clang. It was > gcc up to FreeBSD 9.2. gcc is still available, but I would need to > specify CC=gcc on the "configure" line. > In FreeBSD's 10 port, the older version of reduce-csl is being built with clang by default. Pedro. > On 04/27/2014 15:09, Rainer Schöpf wrote: >> On Sun, 27 Apr 2014 at 14:36 -0400, Kostas Oikonomou wrote: >> >> > Ok, here is what happens now. The "configure" step has improved, but the >> > "make" still has problems. >> >> Interesting. The PSL port was build on FreeBSD 8.3, so it is probably necessary >> to recompile on 10.0. I don't have 10.0 readily available, so this will take a >> bit of time. >> >> If you're feeling adventorous, you might try for yourself: >> >> cd psl/dist/kernel/freeBSD64 >> ./cclnk >> >> Remove the >> >> pslbuild/x86_64-unknown-freebsd10.0 >> >> directory and run configure again. >> >> Rainer >> > |
|
From: Kostas O. <k.o...@at...> - 2014-04-28 20:51:06
|
I fixed pslextras.c by putting in "return 0" so clang would compile it.
Now we have a new bpsl:
[ko@wiley ~/build/reduce/psl/dist/kernel/freeBSD64]$ file bpsl
bpsl: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD),
dynamically linked (uses shared libs), for FreeBSD 10.0 (1000510), not
stripped
[ko@wiley ~/build/reduce/psl/dist/kernel/freeBSD64]$
Then I did what Rainer suggested. But the problem is the same:
[ko@wiley ~/build/reduce]$ rm -r pslbuild/x86_64-unknown-freebsd10.0
[ko@wiley ~/build/reduce]$ configure --prefix=/opt/reduce --with-psl
configure: Absolute path to source directory = /usr/home/ko/build/reduce
checking build system type... amd64-unknown-freebsd10.0
checking host system type... amd64-unknown-freebsd10.0
configure: with_crlibm = yes
in-place build attempt = yes
configure: host=amd64-unknown-freebsd10.0 args= '--prefix=/opt/reduce'
'--with-psl'
configure: Will build in the x86_64-unknown-freebsd10.0 subdirectory
configure: +++ Will build in
/usr/home/ko/build/reduce/pslbuild/x86_64-unknown-freebsd10.0
checking build system type... amd64-unknown-freebsd10.0
checking host system type... amd64-unknown-freebsd10.0
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p...
/usr/home/ko/build/reduce/psl/../install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for cygpath... no
configure: Build platform specified as x86_64-unknown-freebsd10.0
configure: Will build this PSL using the freeBSD64 initial binaries
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
[ko@wiley ~/build/reduce]$ make psl
/bin/sh scripts/make.sh psl
MFLAGS=<> MKFLAGS=<> MAKECMDGOALS=<> args=<psl>
par=no PSLMFLAGS=<>
Current machine tag is x86_64-unknown-freebsd10.0
About to build in pslbuild/x86_64-unknown-freebsd10.0
/usr/local/bin/gmake MYFLAGS= --no-print-directory
if ! test -d deps; then mkdir deps; fi
touch deps/noncore-packages.psl-depend
if ! test -d deps; then mkdir deps; fi
touch deps/noncore-packages.psl-make
if ! test -d deps; then mkdir deps; fi
touch deps/core-packages.psl-depend
if ! test -d deps; then mkdir deps; fi
touch deps/core-packages.psl-make
if ! test -f red/bootstrap.img; \
then /usr/local/bin/gmake red/bootstrap.img; \
if test -f red/bootstrap.img; then /usr/local/bin/gmake reduce; fi; \
else touch red/bootstrap.img; touch red/hugo; /usr/local/bin/gmake
reduce; fi
/usr/home/ko/build/reduce/psl/bootstrap.sh x86_64-unknown-freebsd10.0
/usr/home/ko/build/reduce/pslbuild/x86_64-unknown-freebsd10.0
++++++ Build initial bootstrap system ++++++
Bus error
Bus error
Bootstrap reduce built
[ko@wiley ~/build/reduce]$
On 04/27/2014 16:46, Pedro Giffuni wrote:
> El 27/04/2014 15:39, Kostas Oikonomou escribió:
>> [ko@wiley ~/build/reduce]$ cd psl/dist/kernel/freeBSD64
>> [ko@wiley ~/build/reduce/psl/dist/kernel/freeBSD64]$ ./cclnk
>> pslextras.c:170:9: error: non-void function 'setenv' should return a
>> value [-Wreturn-type]
>> return;
>> ^
>> 1 error generated.
>> [ko@wiley ~/build/reduce/psl/dist/kernel/freeBSD64]$
>>
>
> This is just clang being more picky than gcc. You can probably disable
> the warnings but it looks like a good chance to clean the code.
> Building on other platforms with clang should reveal the same issues.
>
>> I see that "cclnk" invokes "cc". This prompts me to ask: does the
>> build need gcc? The default C compiler on FreeBSD 10 is clang. It was
>> gcc up to FreeBSD 9.2. gcc is still available, but I would need to
>> specify CC=gcc on the "configure" line.
>>
>
> In FreeBSD's 10 port, the older version of reduce-csl is being built
> with clang by default.
>
> Pedro.
>
>
>> On 04/27/2014 15:09, Rainer Schöpf wrote:
>>> On Sun, 27 Apr 2014 at 14:36 -0400, Kostas Oikonomou wrote:
>>>
>>> > Ok, here is what happens now. The "configure" step has improved,
>>> but the
>>> > "make" still has problems.
>>>
>>> Interesting. The PSL port was build on FreeBSD 8.3, so it is
>>> probably necessary
>>> to recompile on 10.0. I don't have 10.0 readily available, so this
>>> will take a
>>> bit of time.
>>>
>>> If you're feeling adventorous, you might try for yourself:
>>>
>>> cd psl/dist/kernel/freeBSD64
>>> ./cclnk
>>>
>>> Remove the
>>>
>>> pslbuild/x86_64-unknown-freebsd10.0
>>>
>>> directory and run configure again.
>>>
>>> Rainer
>>>
>>
>
|
|
From: Rainer S. <rai...@gm...> - 2014-04-30 17:11:35
|
On Mon, 28 Apr 2014 at 16:52 -0400, Kostas Oikonomou wrote: > I fixed pslextras.c by putting in "return 0" so clang would compile it. > Now we have a new bpsl: > > [...] > ++++++ Build initial bootstrap system ++++++ > Bus error I managed to reproduce the Bus error, but needed a good's night sleep to understand it. We had a very similar problem with 64bit Linux; it turned out that the Standard C library requires a certain alignment of stack frames, probably for the correct use of the SSE instructions. When calling a C function from inside the Lisp interpreter this alignment condition wasn't enforced. I made the necessary changes and rebuilt the PSL kernel for 64bit FreeBSD. Please try again. Rainer |
|
From: Kostas O. <k.o...@at...> - 2014-04-30 18:06:31
|
Rainer,
Thanks very much for all your work! I just tried again, and the build
went flawlessly, and was much faster than the CSL build I had tried.
Further, this PSL build is with clang 3.3, not gcc, so that's an
additional benefit.
I will try the TeXmacs plugin later tonight.
Meanwhile, I have a couple of questions:
1) I configured with --prefix=/opt/reduce. But I read that "make
install" doesn't work. How can I put what I built in /opt/install (by
hand)?
2) Does REDUCE have any facilities for (numerical) nonlinear constrained
optimization? E.g. convex? I don't see anything relevant in the
available packages.
Kostas
On 04/30/2014 13:11, Rainer Schöpf wrote:
> On Mon, 28 Apr 2014 at 16:52 -0400, Kostas Oikonomou wrote:
>
> > I fixed pslextras.c by putting in "return 0" so clang would compile
> it. > Now we have a new bpsl:
> > > [...]
>
> > ++++++ Build initial bootstrap system ++++++
> > Bus error
>
> I managed to reproduce the Bus error, but needed a good's night sleep
> to understand it.
> We had a very similar problem with 64bit Linux; it turned out that the
> Standard C library requires a certain alignment of stack frames,
> probably for the correct use of the SSE instructions. When calling a
> C function from inside the Lisp interpreter this alignment condition
> wasn't enforced.
>
> I made the necessary changes and rebuilt the PSL kernel for 64bit
> FreeBSD.
>
> Please try again.
>
> Rainer
|
|
From: Rainer S. <rai...@gm...> - 2014-05-02 17:00:40
|
On Wed, 30 Apr 2014 at 13:50 -0400, Kostas Oikonomou wrote: > Rainer, > > Thanks very much for all your work! I just tried again, and the build > went flawlessly, and was much faster than the CSL build I had tried. > Further, this PSL build is with clang 3.3, not gcc, so that's an > additional benefit. Actually, no, it isn't. The executable file for the PSL kernel is taken from the subversion repository, and most of it is written in Lisp anyway. Reduce is Lisp code compiled by the PSL compiler. > 1) I configured with --prefix=/opt/reduce. But I read that "make > install" doesn't work. How can I put what I built in /opt/install (by > hand)? Not easily. For PSL, you need to copy the psl and red subdirectories of pslbuild/<system-directory>/ to /opt/reduce, to adjust the pathnames in the lisp loaddirectories!* variable, and to write a new shell script to start Reduce. I did this for Debian Linux, so all the bits are already there; but I need to put them together. > 2) Does REDUCE have any facilities for (numerical) nonlinear constrained > optimization? E.g. convex? I don't see anything relevant in the > available packages. I don't know of such a package, sorry. Rainer |
|
From: Pedro G. <pf...@fr...> - 2014-05-03 03:04:59
|
On 05/02/14 12:00, Rainer Schöpf wrote: > On Wed, 30 Apr 2014 at 13:50 -0400, Kostas Oikonomou wrote: > > > Rainer, > > > > Thanks very much for all your work! I just tried again, and the build > > went flawlessly, and was much faster than the CSL build I had tried. > > Further, this PSL build is with clang 3.3, not gcc, so that's an > > additional benefit. > > Actually, no, it isn't. The executable file for the PSL kernel is taken from the > subversion repository, and most of it is written in Lisp anyway. Reduce is Lisp > code compiled by the PSL compiler. > > > 1) I configured with --prefix=/opt/reduce. But I read that "make > > install" doesn't work. How can I put what I built in /opt/install (by > > hand)? > > Not easily. For PSL, you need to copy the psl and red subdirectories of > pslbuild/<system-directory>/ to /opt/reduce, to adjust the pathnames in the lisp > loaddirectories!* variable, and to write a new shell script to start Reduce. > > I did this for Debian Linux, so all the bits are already there; but I need to > put them together. It should be pretty similar to what I did on the FreeBSD csl port. Just check the packaging list for other platforms and adjust the port Makefile and pkg-plist accordingly. Of course, I wouldn't have objection for a new reduce-psl port in FreeBSD or perhaps we can coordinate to make the package available in sourceforge (?). Pedro. |
|
From: Rainer S. <rai...@gm...> - 2014-05-04 15:46:38
|
On Fri, 2 May 2014 at 21:51 -0500, Pedro Giffuni wrote: > It should be pretty similar to what I did on the FreeBSD csl port. > > Just check the packaging list for other platforms and adjust the port > Makefile and pkg-plist accordingly. > > Of course, I wouldn't have objection for a new reduce-psl port in FreeBSD or > perhaps we can coordinate to make the package available in sourceforge (?). Gladly. Looking at the port you created I see that nearly all files are located directly below %%DATADIR%% == PREFIX/share/reduce. I think we need separate directories for the csl and psl versions. Installing PSL Reduce is slightly more complicated than for CSL Reduce, becuase of the different logic for finding files at runtime. CSL Reduce finds its files relative to the directory from which is it started, whereas PSL Reduce has a lisp variable for the search path (stored in the .img file). Ie. you can simply move the CSL subtree around, but you need to update the search path in the PSL .img file. There may be ways around this: either by setting the search path from the pathname of program, or by using a reference to an environment variable in the PSL search path which will be expanded when looking for files. I'm undecided whether this is the right thing to do (as opposed to always using absolute paths). Rainer |
|
From: Pedro G. <pf...@fr...> - 2014-05-04 16:11:10
|
On 05/04/14 10:46, Rainer Schöpf wrote: > On Fri, 2 May 2014 at 21:51 -0500, Pedro Giffuni wrote: > > > It should be pretty similar to what I did on the FreeBSD csl port. > > > > Just check the packaging list for other platforms and adjust the port > > Makefile and pkg-plist accordingly. > > > > Of course, I wouldn't have objection for a new reduce-psl port in FreeBSD or > > perhaps we can coordinate to make the package available in sourceforge (?). > > Gladly. > > Looking at the port you created I see that nearly all files are located > directly below %%DATADIR%% == PREFIX/share/reduce. I think we need separate > directories for the csl and psl versions. I didn't want to make the path very long. You can use PREFIX/share/reduce/psl/. And PREFIX is usually set to /usr/local/. > > Installing PSL Reduce is slightly more complicated than for CSL Reduce, becuase > of the different logic for finding files at runtime. CSL Reduce finds its files > relative to the directory from which is it started, whereas PSL Reduce has a > lisp variable for the search path (stored in the .img file). Ie. you can simply > move the CSL subtree around, but you need to update the search path in the PSL > .img file. In the ports tree we usually use REINPLACE before building. Perhaps you can use sed(1) or bspatch1) after the image is created. Pedro. |
|
From: Rainer S. <rai...@gm...> - 2014-05-04 18:06:09
|
On Sun, 4 May 2014 at 11:11 -0500, Pedro Giffuni wrote: > In the ports tree we usually use REINPLACE before building. > Perhaps you can use sed(1) or bspatch1) after the image is created. There is a script psl/saveimage.sh for Creating the image with different search paths. I'll look into that and come back to you. Rainer |
|
From: Kostas O. <k.o...@at...> - 2014-05-05 17:19:34
|
While we are on the subject of the port, another thing I think would be
useful is to make the manual in doc/help
with hyperlinks. I tried to do that, by inserting in redhelp.tex
\usepackage[pdftex,colorlinks=true,linkcolor=blue,extension=pdf]{hyperref}
but I get lots of errors, apparently due to the commands \name{} and
\nameref{}. I even tried commenting out their definitions in
redindex.sty and putting
\newcommand{\nameref}[1]{\texttt{#1}}
\newcommand{\name}[1]{\texttt{#1}}
in redhelp.tex, but that resulted in more or less the same errors.
Kostas
On 05/04/2014 14:06, Rainer Schöpf wrote:
> On Sun, 4 May 2014 at 11:11 -0500, Pedro Giffuni wrote:
>
> > In the ports tree we usually use REINPLACE before building.
> > Perhaps you can use sed(1) or bspatch1) after the image is created.
>
> There is a script psl/saveimage.sh for Creating the image with different search
> paths.
>
> I'll look into that and come back to you.
>
> Rainer
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
|
|
From: Rainer S. <rai...@gm...> - 2014-05-05 17:46:27
|
On Mon, 5 May 2014 at 13:15 -0400, Kostas Oikonomou wrote: > While we are on the subject of the port, another thing I think would be > useful is to make the manual in doc/help That directory contains the sources for the (obsolete) help system for windows. An upd-to-date version of the manual is in doc/manual, with scripts mkpdf.sh and mkhtml.sh. You need tex4ht to generate the html version. Rainer |
|
From: Kostas O. <k.o...@at...> - 2014-05-07 13:48:54
|
I am trying to understand how big of a job it would be to interface Reduce with a package for doing numerical optimization. Specifically NLopt: http://ab-initio.mit.edu/wiki/index.php/NLopt. NLopt has interfaces to many programming languages, one of them being GNU Guile (Scheme). Would that interface make the task easier? Also, does it matter whether Reduce is built with PSL or CSL? Is interfacing to external software documented anywhere? Thanks for any advice. Kostas |
|
From: Arthur N. <ac...@ca...> - 2014-05-07 14:58:20
|
On Wed, 7 May 2014, Kostas Oikonomou wrote: > I am trying to understand how big of a job it would be to interface > Reduce with a package for doing numerical optimization. > Specifically NLopt: http://ab-initio.mit.edu/wiki/index.php/NLopt. > NLopt has interfaces to many programming languages, one of them being > GNU Guile (Scheme). > Would that interface make the task easier? Also, does it matter whether > Reduce is built with PSL or CSL? > Is interfacing to external software documented anywhere? > Thanks for any advice. > Kostas > ------------------------------------------------------------------------------ "Interfacing" can mean a load of different things, but one of the top issues is which side of the interface is in control. Ie in your case do you want to have Reduce code that generates formulae and you then devolve solving them to NLopt, or do you imagine NLopt having some problem it is trying to solve and somehow invoking Reduce to do a bit of algebra for it as a useful step along the way? I will for a start imagine you wish to invoke NLopt from within Reduce (and that way round is probably going to be the easier way - but at some level either can be managed). The next issue is how much experience you have (eg with Reduce or general programming) and how confident you are hacking things. If you are very nervous then what you do is just write output from Reduce using off nat; out "file"; write something; out t; and then decode the file you created as input to a program that drives NLopt. You may wish to experiment that way to start to see how well things work and to discover where the pinch points might be. But if you want something a bit equivalent to that but "more automatic" I first suggest you look in the Reduce sources in trunk/packages/foreign where there are modules that interface to the "gurobi" and "z3" external theorem provers/solvers. If you investigate those you can see if it is doing something at all analogous to what you have in mind and it may then provide a model to build on. You could also look in packages/plot at the code that lets Reduce interface to gnuplot (which it does basically by invoking gnuplot via a pipe so it can then send stuff out to be plotted). You note that NLopt is C callable, so at a higher level of effort (but with the potential to be smoother??) you could add C calls to it into the source code of a customised version of CSL - you can find stuff that might give you a sort of prototype and feeling for what could be involved by looking in trunk/csl/cslbase/nag_d.c where at some stage (now well in the past) there had been an interface to parts of the NAG numerical library. That has not been tested or maintained at all recently but remains in the code precisely in case it is a helpful model for people like you. Interfacing to external software can run from being as easy as writing to a file and then using "system" to spawn a process to do something through in wiring new stuff into one or other of the Lisps. Where one ends up depends on skill and ambition! And the wide range means that while there are sort of examples that you can trace there is (and I suspect there can not be) a single comprehensive general set of instructions. But I hope that if you are doing interesting stuff and putting effort in on your side that people on this list might join in and help exploain issues bit by bit if you get stuck. But there are of course no guarantees! Arthur |
|
From: Kostas O. <k.o...@at...> - 2014-05-12 23:17:28
|
Dear Arthur,
Thank you for the detailed reply.
As you surmised, what I had in mind is invoking an NLopt routine from
within Reduce, e.g. to solve an optimization problem numerically, after
formulating the equations, functions, etc. in Reduce. Now having looked
at trunk/packages/foreign, I conclude that it would take a significant
amount of time and effort (for me, anyway) to develop a C interface.
And even if that were done, it would work only with the CSL version.
An additional consideration is that I am greatly favoring the PSL
version because I like using the TeXmacs interface to Reduce.
Unfortunately, that interface only works for PSL.
Kostas
On 05/07/2014 10:58, Arthur Norman wrote:
> On Wed, 7 May 2014, Kostas Oikonomou wrote:
>> I am trying to understand how big of a job it would be to interface
>> Reduce with a package for doing numerical optimization.
>> Specifically NLopt: http://ab-initio.mit.edu/wiki/index.php/NLopt.
>> NLopt has interfaces to many programming languages, one of them being
>> GNU Guile (Scheme).
>> Would that interface make the task easier? Also, does it matter whether
>> Reduce is built with PSL or CSL?
>> Is interfacing to external software documented anywhere?
>> Thanks for any advice.
>> Kostas
>> ------------------------------------------------------------------------------
>>
>
>
> "Interfacing" can mean a load of different things, but one of the top
> issues is which side of the interface is in control. Ie in your case
> do you want to have Reduce code that generates formulae and you then
> devolve solving them to NLopt, or do you imagine NLopt having some
> problem it is trying to solve and somehow invoking Reduce to do a bit
> of algebra for it as a useful step along the way?
>
> I will for a start imagine you wish to invoke NLopt from within Reduce
> (and that way round is probably going to be the easier way - but at
> some level either can be managed).
>
> The next issue is how much experience you have (eg with Reduce or
> general programming) and how confident you are hacking things. If you
> are very nervous then what you do is just write output from Reduce using
> off nat; out "file"; write something; out t;
> and then decode the file you created as input to a program that drives
> NLopt. You may wish to experiment that way to start to see how well
> things work and to discover where the pinch points might be.
>
> But if you want something a bit equivalent to that but "more
> automatic" I first suggest you look in the Reduce sources in
> trunk/packages/foreign where there are modules that interface to the
> "gurobi" and "z3" external theorem provers/solvers. If you investigate
> those you can see if it is doing something at all analogous to what
> you have in mind and it may then provide a model to build on. You
> could also look in packages/plot at the code that lets Reduce
> interface to gnuplot (which it does basically by
> invoking gnuplot via a pipe so it can then send stuff out to be plotted).
>
> You note that NLopt is C callable, so at a higher level of effort (but
> with the potential to be smoother??) you could add C calls to it into
> the source code of a customised version of CSL - you can find stuff
> that might give you a sort of prototype and feeling for what could be
> involved by looking in trunk/csl/cslbase/nag_d.c where at some stage
> (now well in the past) there had been an interface to parts of the NAG
> numerical library. That has not been tested or maintained at all
> recently but remains in the code precisely in case it is a helpful
> model for people like you.
>
> Interfacing to external software can run from being as easy as writing
> to a file and then using "system" to spawn a process to do something
> through in wiring new stuff into one or other of the Lisps. Where one
> ends up depends on skill and ambition! And the wide range means that
> while there are sort of examples that you can trace there is (and I
> suspect there can not be) a single comprehensive general set of
> instructions. But I hope that if you are doing interesting stuff and
> putting effort in on your side that people on this list might join in
> and help exploain issues bit by bit if you get stuck. But there are of
> course no guarantees!
>
> Arthur
>
>
>
|
|
From: Arthur N. <ac...@ca...> - 2014-05-13 07:20:51
|
Thank you. At least you can see that things are possible if at some stage
in the future you or somebody else reaches a stage where investing the
time becomes a balanced choice of what to do.
You can also potentially look at the gentran and scope packages in Reduce
that are intended to let you generate fragments of program that you then
carry away, compile and use.
At various stage in the past TeXmacs has worked with the CSL version too
but I have never got in to using it - and sorting that out would need a
TeXmacs enthusiast not me to cope. But basically I believe that TeXmacs
merely opens the system it embeds around via a pipe and then sends and
receives pretty much whatever character strings the algebra system would
normally generate, and the TeX-format-output capabilities of Reduce do not
depend on which Lisp is in use. I do not know who the current active
expert on that is.
Arthur
On Mon, 12 May 2014, Kostas Oikonomou wrote:
> Dear Arthur,
>
> Thank you for the detailed reply.
>
> As you surmised, what I had in mind is invoking an NLopt routine from
> within Reduce, e.g. to solve an optimization problem numerically, after
> formulating the equations, functions, etc. in Reduce. Now having looked
> at trunk/packages/foreign, I conclude that it would take a significant
> amount of time and effort (for me, anyway) to develop a C interface.
> And even if that were done, it would work only with the CSL version.
>
> An additional consideration is that I am greatly favoring the PSL
> version because I like using the TeXmacs interface to Reduce.
> Unfortunately, that interface only works for PSL.
>
> Kostas
>
|
|
From: Eberhard S. <esc...@ca...> - 2014-05-13 10:38:45
|
I just commited a TeXmacs plugin that works with CSL and PSL to the
repository in the generic directory.
Please check it out.
Eberhard
On 13/05/14 01:19, Kostas Oikonomou wrote:
> Dear Arthur,
>
> Thank you for the detailed reply.
>
> As you surmised, what I had in mind is invoking an NLopt routine from
> within Reduce, e.g. to solve an optimization problem numerically, after
> formulating the equations, functions, etc. in Reduce. Now having looked
> at trunk/packages/foreign, I conclude that it would take a significant
> amount of time and effort (for me, anyway) to develop a C interface.
> And even if that were done, it would work only with the CSL version.
>
> An additional consideration is that I am greatly favoring the PSL
> version because I like using the TeXmacs interface to Reduce.
> Unfortunately, that interface only works for PSL.
>
> Kostas
>
> On 05/07/2014 10:58, Arthur Norman wrote:
>> On Wed, 7 May 2014, Kostas Oikonomou wrote:
>>> I am trying to understand how big of a job it would be to interface
>>> Reduce with a package for doing numerical optimization.
>>> Specifically NLopt: http://ab-initio.mit.edu/wiki/index.php/NLopt.
>>> NLopt has interfaces to many programming languages, one of them being
>>> GNU Guile (Scheme).
>>> Would that interface make the task easier? Also, does it matter whether
>>> Reduce is built with PSL or CSL?
>>> Is interfacing to external software documented anywhere?
>>> Thanks for any advice.
>>> Kostas
>>> ------------------------------------------------------------------------------
>>>
>>
>> "Interfacing" can mean a load of different things, but one of the top
>> issues is which side of the interface is in control. Ie in your case
>> do you want to have Reduce code that generates formulae and you then
>> devolve solving them to NLopt, or do you imagine NLopt having some
>> problem it is trying to solve and somehow invoking Reduce to do a bit
>> of algebra for it as a useful step along the way?
>>
>> I will for a start imagine you wish to invoke NLopt from within Reduce
>> (and that way round is probably going to be the easier way - but at
>> some level either can be managed).
>>
>> The next issue is how much experience you have (eg with Reduce or
>> general programming) and how confident you are hacking things. If you
>> are very nervous then what you do is just write output from Reduce using
>> off nat; out "file"; write something; out t;
>> and then decode the file you created as input to a program that drives
>> NLopt. You may wish to experiment that way to start to see how well
>> things work and to discover where the pinch points might be.
>>
>> But if you want something a bit equivalent to that but "more
>> automatic" I first suggest you look in the Reduce sources in
>> trunk/packages/foreign where there are modules that interface to the
>> "gurobi" and "z3" external theorem provers/solvers. If you investigate
>> those you can see if it is doing something at all analogous to what
>> you have in mind and it may then provide a model to build on. You
>> could also look in packages/plot at the code that lets Reduce
>> interface to gnuplot (which it does basically by
>> invoking gnuplot via a pipe so it can then send stuff out to be plotted).
>>
>> You note that NLopt is C callable, so at a higher level of effort (but
>> with the potential to be smoother??) you could add C calls to it into
>> the source code of a customised version of CSL - you can find stuff
>> that might give you a sort of prototype and feeling for what could be
>> involved by looking in trunk/csl/cslbase/nag_d.c where at some stage
>> (now well in the past) there had been an interface to parts of the NAG
>> numerical library. That has not been tested or maintained at all
>> recently but remains in the code precisely in case it is a helpful
>> model for people like you.
>>
>> Interfacing to external software can run from being as easy as writing
>> to a file and then using "system" to spawn a process to do something
>> through in wiring new stuff into one or other of the Lisps. Where one
>> ends up depends on skill and ambition! And the wide range means that
>> while there are sort of examples that you can trace there is (and I
>> suspect there can not be) a single comprehensive general set of
>> instructions. But I hope that if you are doing interesting stuff and
>> putting effort in on your side that people on this list might join in
>> and help exploain issues bit by bit if you get stuck. But there are of
>> course no guarantees!
>>
>> Arthur
>>
>>
>>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
|
|
From: Kostas O. <k.o...@at...> - 2014-05-14 14:56:46
|
Hello Eberhard,
This is what I did with the plugin.
1) By looking at the plugin's code, it seems that the plugin does not
need ~/.reducerc, so I did not install that file.
2) I did the installation of the CSL version of reduce by hand:
#!/bin/sh
REDUCECSL=cslbuild/x86_64-unknown-freebsd10.0-nogui/csl
PREFIX=/opt/reduce-csl
mkdir -p ${PREFIX}/bin
cp ${REDUCECSL}/reduce ${PREFIX}/bin
cp ${REDUCECSL}/reduce.img ${PREFIX}/bin
cp -r ${REDUCECSL}/reduce.doc ${PREFIX}
cp -r packages ${PREFIX}
3) Then I have a link:
/opt/bin/redcsl -> /opt/reduce-csl/bin/reduce.
4) What happens with this setup is that the "Reduce" menu shows up in
TeXmacs, but the initialization doesn't finish. This is likely due to
the fact that running by hand
/opt/reduce-csl/bin/reduce --texmacs
does not wrap output in LaTeX, I don't know why. But if I explicitly
load the tmprint package, it does.
5) Another issue is that the symbolic link makes
(get-reduce-doc-dir reduce-bin-path)
get the wrong path for the docs.
Kostas
On 05/13/2014 05:57, Eberhard Schruefer wrote:
> I just commited a TeXmacs plugin that works with CSL and PSL to the
> repository in the generic directory.
> Please check it out.
>
> Eberhard
>
> On 13/05/14 01:19, Kostas Oikonomou wrote:
>> Dear Arthur,
>>
>> Thank you for the detailed reply.
>>
>> A
|
|
From: Eberhard S. <esc...@ca...> - 2014-05-14 21:40:19
|
Please try with this in your .reducerc
lisp$
if getenv("TEXMACS_REDUCE_PATH") then load tmprint$
if getenv("TEXMACS_REDUCE_PATH") or memq('texmacs,lispsystem!*) then
<<prin2 int2id 2;prin2 "command:(toggle-session-math-input)";prin2
int2id 5>>$
algebraic$
end$
Eberhard
On 14/05/14 16:54, Kostas Oikonomou wrote:
> Hello Eberhard,
>
> This is what I did with the plugin.
>
> 1) By looking at the plugin's code, it seems that the plugin does not
> need ~/.reducerc, so I did not install that file.
>
> 2) I did the installation of the CSL version of reduce by hand:
>
> #!/bin/sh
> REDUCECSL=cslbuild/x86_64-unknown-freebsd10.0-nogui/csl
> PREFIX=/opt/reduce-csl
> mkdir -p ${PREFIX}/bin
> cp ${REDUCECSL}/reduce ${PREFIX}/bin
> cp ${REDUCECSL}/reduce.img ${PREFIX}/bin
> cp -r ${REDUCECSL}/reduce.doc ${PREFIX}
> cp -r packages ${PREFIX}
>
> 3) Then I have a link:
>
> /opt/bin/redcsl -> /opt/reduce-csl/bin/reduce.
>
> 4) What happens with this setup is that the "Reduce" menu shows up in
> TeXmacs, but the initialization doesn't finish. This is likely due to
> the fact that running by hand
>
> /opt/reduce-csl/bin/reduce --texmacs
>
> does not wrap output in LaTeX, I don't know why. But if I explicitly
> load the tmprint package, it does.
>
> 5) Another issue is that the symbolic link makes
>
> (get-reduce-doc-dir reduce-bin-path)
>
> get the wrong path for the docs.
>
> Kostas
>
> On 05/13/2014 05:57, Eberhard Schruefer wrote:
>> I just commited a TeXmacs plugin that works with CSL and PSL to the
>> repository in the generic directory.
>> Please check it out.
>>
>> Eberhard
>>
>> On 13/05/14 01:19, Kostas Oikonomou wrote:
>>> Dear Arthur,
>>>
>>> Thank you for the detailed reply.
>>>
>>> A
|
Thanks for helping keep SourceForge clean.
X