From: Pedro F. G. <gif...@tu...> - 2012-04-03 06:13:53
|
Thank you Rainer! --- Lun 2/4/12, Rainer Schöpf <rai...@gm...> ha scritto: > > > > The attached patch just followed the instructions and > > lets me build the CSL version. > > Thanks for pointing this out; please try the changes I > checked in today. > It built on FreeBSD 9.0-amd64 (actually PC-BSD), Thank You! Hmm.. it's very weird but typing "gmake install" brought the system to a busy state and eventually I had to coldboot, I had never happened to me! > > The PSL version gets to here: > > ___ > > > > ... > > configure: Will build this PSL using the unknown > initial binaries > > cp: > /usr/ports/math/reduce/work/reduce-algebra/psl/psl-unknown/*: > No such file or directory > > Yes, FreeBSD is not a known system. By modifying the > script scripts/pslver.sh > (see below) I was able to run the linux port of PSL (see > A yes, the linuxulator is always pretty handy (and fast). Just wondering, you are probably aware of the classic CMU Lisp implementations: http://www.freshports.org/lang/cmucl/ http://www.freshports.org/lang/sbcl/ Is there a chance that REDUCE can work with them? Thanks in advance, Pedro. |
From: Arthur N. <ac...@ca...> - 2012-04-06 14:34:29
|
the reduce people already give some support for CSL and PSL, both of which started specifically to support Reduce. I for one am not keen on a common lisp variant to worry about too. My expectations are that to get Common lisp to excell on benchmarks you need a lot of DECLARE forms. So yes it would be feasible so by all means try. But do not expect a lot of help from me, and probably not from the PSL experts. If you do select a Common Lisp please try to use a BSD licensed one so distribution of reduce remains as consistent as possible. Arthur "Andrey G. Grozin" <A.G...@in...> wrote: >On Tue, 3 Apr 2012, Pedro F. Giffuni wrote: >>> > Just wondering, you are probably aware of the classic >>> > CMU Lisp implementations: >>> > >>> > http://www.freshports.org/lang/cmucl/ >>> > http://www.freshports.org/lang/sbcl/ >>> > >>> > Is there a chance that REDUCE can work with them? >>> >>> I'm know it can. A long time ago, I ported Reduce to >>> MacLisp, one of the precursors of Common Lisp. The >>> Standard Lisp defined as a basis for Reduce is >>> not a Common Lisp, being somewhat older than the Common Lisp >>> Standard - see the doc/misc directory for a description. >>> Therefore, some interface layer is >>> necessary. This is not very difficult, just tedious. >>> >> >> Interesting. I don't know much about Lisp but there are >> a couple of BSD guys very active in CMUCL and SBCL. >> >> It would be even more interesting if it happens to speed >> something up ;). >I know one programmer in Dubna who had ported reduce to cmucl by writing a >thin sl compatibility layer over cl. It ran somewhat slower than in native >sl. The reason is clear: sl is a very small language, cl is very large; >many operations in cl depend on types of operands, leading to numerous >runtime checks. In sl such checks are absent. > >Andrey >------------------------------------------------------------------------------ >Better than sec? Nothing is better than sec when it comes to >monitoring Big Data applications. Try Boundary one-second >resolution app monitoring today. Free. >http://p.sf.net/sfu/Boundary-dev2dev >_______________________________________________ >Reduce-algebra-developers mailing list >Red...@li... >https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers |
From: Rainer S. <rai...@gm...> - 2012-04-03 20:53:36
|
Hello Pedro, On Mon, 2 Apr 2012 at 23:13 -0700, Pedro F. Giffuni wrote: > Thank you Rainer! > > --- Lun 2/4/12, Rainer Schöpf <rai...@gm...> ha scritto: > > > > > > > The attached patch just followed the instructions and > > > lets me build the CSL version. > > > > Thanks for pointing this out; please try the changes I > > checked in today. > > > > It built on FreeBSD 9.0-amd64 (actually PC-BSD), > Thank You! > > Hmm.. it's very weird but typing "gmake install" > brought the system to a busy state and eventually I > had to coldboot, I had never happened to me! It's an infinite recursion of "gmake install" invocations (took me a while to understand why). There is no toplevel "install" target, instead it is passed to a shell script that calls make again. Through some error, the "install" target is passed to each and every sub-make, leading to an infinite recursion. An install target needs extra work; I believe the best way is to build packages for the various operating system. I've already created the necessary files to build a package for Debian or Ubuntu Linux (in subdir debianbuild). Someone familiar with the FreeBSD package building could easily adapt this. > > > > The PSL version gets to here: > > > ___ > > > > > > ... > > > configure: Will build this PSL using the unknown > > initial binaries > > > cp: > > /usr/ports/math/reduce/work/reduce-algebra/psl/psl-unknown/*: > > No such file or directory > > > > Yes, FreeBSD is not a known system. By modifying the > > script scripts/pslver.sh > > (see below) I was able to run the linux port of PSL (see > > > > A yes, the linuxulator is always pretty handy (and fast). But it can only run 32bit Linux. With a little tweaking, I could compile and run the PSL kernel on FreeBSD. This was just a quick and dirty solution; it needs a bit of work to integrate it into the build system. > Just wondering, you are probably aware of the classic > CMU Lisp implementations: > > http://www.freshports.org/lang/cmucl/ > http://www.freshports.org/lang/sbcl/ > > Is there a chance that REDUCE can work with them? I'm know it can. A long time ago, I ported Reduce to MacLisp, one of the precursors of Common Lisp. The Standard Lisp defined as a basis for Reduce is not a Common Lisp, being somewhat older than the Common Lisp Standard - see the doc/misc directory for a description. Therefore, some interface layer is necessary. This is not very difficult, just tedious. Rainer |
From: Pedro F. G. <gif...@tu...> - 2012-04-04 06:00:27
|
Hello Rainer; --- Mar 3/4/12, Rainer Schöpf <rai...@gm...> ha scritto: ... > > An install target needs extra work; I believe the best way > is to build packages > for the various operating system. I've already created > the necessary files to > build a package for Debian or Ubuntu Linux (in subdir > debianbuild). Someone > familiar with the FreeBSD package building could easily > adapt this. > There is a FreeBSD porters handbook: http://www.freebsd.org/doc/en/books/porters-handbook/ But you are lucky as I am an auto-proclaimed expert on such dark arts ;). I will work rather slowly on this though, I don't have much time lately due to a couple of pet projects that keep me busy. We have a hier(7) for the structure. In this case I would install it by default in /usr/local/libexec/reduce and I would add a shell script /usr/local/bin Documentation should go in /usr/local/share/doc/reduce/ (/usr/local is the default PREFIX but it can be changed) I don't know much about Debian or Ubuntu so I will have to figure out a command line to effectively copy the files to a target directory (cp -R or tar will do unless you have an official method). ... > > But it can only run 32bit Linux. With a little tweaking, I > could compile and run the PSL kernel on FreeBSD. This was > just a quick and dirty solution; it needs a > bit of work to integrate it into the build system. > If you do go though the trouble I would add it as an option to the port. > > Just wondering, you are probably aware of the classic > > CMU Lisp implementations: > > > > http://www.freshports.org/lang/cmucl/ > > http://www.freshports.org/lang/sbcl/ > > > > Is there a chance that REDUCE can work with them? > > I'm know it can. A long time ago, I ported Reduce to > MacLisp, one of the precursors of Common Lisp. The > Standard Lisp defined as a basis for Reduce is > not a Common Lisp, being somewhat older than the Common Lisp > Standard - see the doc/misc directory for a description. > Therefore, some interface layer is > necessary. This is not very difficult, just tedious. > Interesting. I don't know much about Lisp but there are a couple of BSD guys very active in CMUCL and SBCL. It would be even more interesting if it happens to speed something up ;). Thanks, Pedro. |
From: Andrey G. G. <A.G...@in...> - 2012-04-04 08:56:35
|
On Tue, 3 Apr 2012, Pedro F. Giffuni wrote: >> > Just wondering, you are probably aware of the classic >> > CMU Lisp implementations: >> > >> > http://www.freshports.org/lang/cmucl/ >> > http://www.freshports.org/lang/sbcl/ >> > >> > Is there a chance that REDUCE can work with them? >> >> I'm know it can. A long time ago, I ported Reduce to >> MacLisp, one of the precursors of Common Lisp. The >> Standard Lisp defined as a basis for Reduce is >> not a Common Lisp, being somewhat older than the Common Lisp >> Standard - see the doc/misc directory for a description. >> Therefore, some interface layer is >> necessary. This is not very difficult, just tedious. >> > > Interesting. I don't know much about Lisp but there are > a couple of BSD guys very active in CMUCL and SBCL. > > It would be even more interesting if it happens to speed > something up ;). I know one programmer in Dubna who had ported reduce to cmucl by writing a thin sl compatibility layer over cl. It ran somewhat slower than in native sl. The reason is clear: sl is a very small language, cl is very large; many operations in cl depend on types of operands, leading to numerous runtime checks. In sl such checks are absent. Andrey |
From: Rainer S. <rai...@gm...> - 2012-04-04 09:02:20
|
Hi Pedro, On Tue, 3 Apr 2012, Pedro F. Giffuni wrote: > Hello Rainer; > --- Mar 3/4/12, Rainer Schöpf <rai...@gm...> ha scritto: > > ... > > > > An install target needs extra work; I believe the best way > > is to build packages > > for the various operating system. I've already created > > the necessary files to > > build a package for Debian or Ubuntu Linux (in subdir > > debianbuild). Someone > > familiar with the FreeBSD package building could easily > > adapt this. > > > > There is a FreeBSD porters handbook: > http://www.freebsd.org/doc/en/books/porters-handbook/ > > But you are lucky as I am an auto-proclaimed expert > on such dark arts ;). I will work rather slowly on > this though, I don't have much time lately due to a > couple of pet projects that keep me busy. > > We have a hier(7) for the structure. In this case I > would install it by default in /usr/local/libexec/reduce > and I would add a shell script /usr/local/bin > Documentation should go in /usr/local/share/doc/reduce/ > (/usr/local is the default PREFIX but it can be changed) > > I don't know much about Debian or Ubuntu so I will > have to figure out a command line to effectively > copy the files to a target directory (cp -R or > tar will do unless you have an official method). Look into the file debianbuild/debian/rules It is a Makefile for the package build process. The interesting bits are the targets configure-stamp override_dh_install When dh_build is run from the debianbuild directory, it generates the tree structure for the package in $(INSTALLDIR), plus some extra files in debianbuild/debian for the package build. > ... > > > > But it can only run 32bit Linux. With a little tweaking, I > > could compile and run the PSL kernel on FreeBSD. This was > > just a quick and dirty solution; it needs a > > bit of work to integrate it into the build system. > > > > If you do go though the trouble I would add it as an option > to the port. I intend to, but it take a bit of time. My quick solution was to take the code of the PSL kernel for Linux and compile it on FreeBSD. This works surprisingly well, but I spotted one bug already. A proper port means a) Writing a Lisp compiler backend for the processor architecture, b) Cross-compiling PSL for the new architecture on an existing system, c) Writing the PSL kernel for the new architecture d) Bootstrapping PSL on the new architecture, with the new PSL kernel and the cross-compiled binaries, e) Building PSL on the new system. Step b can be skipped here, as the processor architecture is already known and the code generator exists. For step c, the PSL kernel for Linux or for Mac OSX can serve as a starting point. Rainer |