June 2005 - PPL-devel - BUGSENG Mailman

ppl/interfaces/Prolog/SWI Makefile.am
by Matthew Mundell 09 Jun '05

09 Jun '05

CVSROOT: /cvs/ppl Module name: ppl Branch: grids Changes by: mundell(a)cs.unipr.it 2005-06-09 17:29:18 Modified files: interfaces/Prolog/SWI: Makefile.am Log message: Revert last change. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/Prolog/SWI/Makefil…

1 0

Strange behavior of `pl -dump-runtime-variables' on SWI-Prolog 5.4.7
by Roberto Bagnara 09 Jun '05

09 Jun '05

On a system where SWI-Prolog 5.4.7 has been configured with a simple `configure', this gives $ /usr/local/bin/pl -dump-runtime-variables CC="gcc"; PLBASE="/usr/local/lib/pl-5.4.7"; PLARCH="i686-linux"; PLLIBS="-ldl -lreadline -lncurses -lm -lrt "; PLLIB="-lpl"; PLLDFLAGS="-export-dynamic -O3 -pthread"; PLSOEXT="so"; PLVERSION="50407"; PLSHARED="yes"; PLTHREADS="yes"; Instead, on a system where SWI-Prolog 5.4.7 has been configured with `./configure --disable-mt', the same command gives $ /tmp/junk/bin/pl -dump-runtime-variables CC="gcc"; PLBASE="/tmp/junk/lib/pl-5.4.7"; PLARCH="i686-linux"; PLLIBS="-ldl -lreadline -lncurses -lm "; PLLIB=""; PLLDFLAGS="-export-dynamic -O3"; PLSOEXT="so"; PLVERSION="50407"; PLSHARED="yes"; PLTHREADS="no"; For some reason, PLLIB is now assigned the empty string. This makes `plld' fail miserably and, since I don't see any connection between multithreading and the observed behavior, I wonder if this is a bug. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

1 0

Re: [SWIPL] Suggestion for the DarwinPorts version of SWI-Prolog
by Richard A. O'Keefe 09 Jun '05

09 Jun '05

Roberto Bagnara <bagnara(a)cs.unipr.it> wrote: I may well be missing something, but it seems the life of people interfacing C/C++ and Prolog programs on MacOS would be simplified if SWI-Prolog.h and the other interface header file could be installed in some fixed place, such as /opt/local/include, as well as in /opt/local/lib/swipl-x.y.zz/include. Yes, you are missing something, and no, my life would not be simplified. If a package installs things in a fixed place, then I cannot install it. Nohow. Let me explain why. This university has a policy that if a machine is connected to the University net, then it MUST be administered ONLY by an approved system administrator who is basically responsible for keeping antivirus stuff up to date, installing the approved e-mail software, and basically ensuring that bad stuff doesn't happen. ONLY the approved system administrator is allowed to know the root password. It doesn't matter who *owns* the machine. I have an old Sun-3/50 and a 486 PC in my office which *could* be connected to the net, and I'm about to get a past-its-wow-gosh-date Windows NT box ditto. But if I want them connected to the University net, I will NOT be allowed to know what the root password is, even though they're my machines. The G4 Mac running MacOS X and the SunBlade100 running Solaris 2.9 that sit side-by-side on my desk, on which I do my real work, belong to the University, and there is no way that they are ever going to let me have the root password on those machines as long as they are connected to the University net. This means that I *cannot* install software that puts things in /usr or /opt or *anywhere* except my own directory or /tmp. If I want such software to be installed, I have to ask the appropriate system administrator nicely (different sysadmins for the Solaris box and the MacOS X box, by the way), and wait for them to fetch the software, check it out for unrighteousness, and install it, in their own good time. (These are busy people.) I had to wait months for one such package. P.S. BTW, why /opt/local instead of /usr/local? >From my Solaris box: % man -s 5 filesystem /opt Root of a subtree for add-on application packages. The file system mounted on /usr contains platform-dependent and platform-independent sharable files. On the MacOS X box it's "man 7 hier" instead of "man -s 5 filesystem" and there isn't any /opt.

2 1

ppl/src Grid_conversion.cc Grid.defs.hh
by Matthew Mundell 09 Jun '05

09 Jun '05

CVSROOT: /cvs/ppl Module name: ppl Branch: grids Changes by: mundell(a)cs.unipr.it 2005-06-09 12:12:59 Modified files: src : Grid_conversion.cc Grid.defs.hh Log message: Move the grid multiplying code into two inline functions called multiply_grid. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/src/Grid_conversion.cc.diff?c… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/src/Grid.defs.hh.diff?cvsroot…

1 0

Suggestion for the DarwinPorts version of SWI-Prolog
by Roberto Bagnara 09 Jun '05

09 Jun '05

Hi there, I may well be missing something, but it seems the life of people interfacing C/C++ and Prolog programs on MacOS would be simplified if SWI-Prolog.h and the other interface header file could be installed in some fixed place, such as /opt/local/include, as well as in /opt/local/lib/swipl-x.y.zz/include. This would match what happens on, e.g., the Linux version where these header files are installed in, say, /usr/local/include as well as in /usr/local/lib/swipl-x.y.zz/include. Please note that I know _nothing_ about MacOS: I am only trying to support users of the Parma Polyhedra Library, yet minimizing the number of special cases I have to take into account. All the best, Roberto P.S. BTW, why /opt/local instead of /usr/local? -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

2 3

ppl/tests/Grid grid1.cc
by Matthew Mundell 08 Jun '05

08 Jun '05

CVSROOT: /cvs/ppl Module name: ppl Branch: grids Changes by: mundell(a)cs.unipr.it 2005-06-08 17:00:23 Modified files: tests/Grid : grid1.cc Log message: Add test20, which constructs from a generator system containing a ray. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/tests/Grid/grid1.cc.diff?cvsr…

1 0

ppl/src Grid_nonpublic.cc
by Matthew Mundell 08 Jun '05

08 Jun '05

CVSROOT: /cvs/ppl Module name: ppl Branch: grids Changes by: mundell(a)cs.unipr.it 2005-06-08 16:59:02 Modified files: src : Grid_nonpublic.cc Log message: In method construct convert rays to lines. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/src/Grid_nonpublic.cc.diff?cv…

1 0

ppl/src Grid_chdims.cc
by Matthew Mundell 08 Jun '05

08 Jun '05

CVSROOT: /cvs/ppl Module name: ppl Branch: grids Changes by: mundell(a)cs.unipr.it 2005-06-08 16:58:18 Modified files: src : Grid_chdims.cc Log message: Use a temporary variable in add_space_dimensions. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/src/Grid_chdims.cc.diff?cvsro…

1 0

XSB and the PPL
by Roberto Bagnara 08 Jun '05

08 Jun '05

The last version of XSB (2.7.1, nicknamed Kinryo) incorporates a number of ISO standard features that were not present in previous releases. In addition, it seems to provide support for unbounded integers, something that is of vital importance for applications using the PPL. I am thus in the process of trying to do the port to this version of XSB. The major problem I am having is an apparent infinite loop that may indicate a problem in that version of XSB, or in GCC, or (but I doubt it) in our own code. Cheers, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

1 0

Re: [PPL-devel] Re: Problems with SWI-Prolog interface
by Matthew Mundell 08 Jun '05

08 Jun '05

P M Hill <hill(a)comp.leeds.ac.uk> writes: > On Wed, 8 Jun 2005, Matthew Mundell wrote: > >> Roberto Bagnara <bagnara(a)cs.unipr.it> writes: >> >>> Matthew Mundell wrote: >>>> So any idea why plld only finds libpl when -lpl is given explicitly? >>> >>> Because the installation of SWI-Prolog you are using is broken. >>> If you try the following command on your machine you will get >>> >>> $ pl -dump-runtime-variables >>> CC="/usr/local/gcc-3.4.3/bin/gcc"; >>> PLBASE="/usr/local/pl/lib/pl-5.4.7"; >>> PLARCH="i686-linux"; >>> PLLIBS="-ldl -lreadline -lncurses -lm "; >>> PLLIB=""; >>> PLLDFLAGS="-export-dynamic -O3"; >>> PLSOEXT="so"; >>> PLVERSION="50407"; >>> PLSHARED="yes"; >>> PLTHREADS="no"; >>> >>> If you do the same on any machine with a decently installed >>> version of SWI-Prolog, you will get, instead >>> >>> $ pl -dump-runtime-variables >>> CC="gcc"; >>> PLBASE="/usr/local/lib/pl-5.4.7"; >>> PLARCH="i686-linux"; >>> PLLIBS="-ldl -lreadline -lncurses -lm -lrt "; >>> PLLIB="-lpl"; >>> PLLDFLAGS="-export-dynamic -O3 -pthread"; >>> PLSOEXT="so"; >>> PLVERSION="50407"; >>> PLSHARED="yes"; >>> PLTHREADS="yes"; >>> >>> Notice the difference concerning the value of `PLLIB'. >>> My advice is to erase your installation of SWI-Prolog completely >>> and then re-install it again from the sources with a standard >>> ./configure ; make ; sudo make install >> >> Thanks Roberto. I've rebuilt SWI in /usr/not-backed-up and PLLIB only >> contains -lpl if --enable-mt is passed to configure. So I think that >> if the existing SWI installation is rebuilt with multi-threading then >> the PPL interface will compile. I doubt that a standard ./configure >> will work, even from a fresh set of source. > > On cspcx97 (my new notebook) > > $ pl -dump-runtime-variables > CC="gcc"; > PLBASE="/usr/local/lib/pl-5.4.7"; > PLARCH="i686-linux"; > PLLIBS="-ldl -lreadline -lncurses -lm -lrt "; > PLLIB="-lpl"; > PLLDFLAGS="-export-dynamic -O3 -pthread"; > PLSOEXT="so"; > PLVERSION="50407"; > PLSHARED="yes"; > PLTHREADS="yes"; > > is ok with the standard ./configure ; make ; sudo make install ! Yes, sorry, the top-level configure script forces --enable-mt onto the src directory's configure script, and I'd originally asked Graham to prevent this (with --disable-mt). > > Pat

1 0