I applied the diffs below, but found that I needed this further one
before I could run mkpopvision.
--- lib/arraylookup.p- 2018-04-21 09:10:06.000000000 -0400
+++ lib/arraylookup.p 2019-07-11 15:05:25.188191118 -0400
@@ -64,9 +64,9 @@
.arrayvector.issfloatvec
enddefine;
-define lconstant isbytevec(/* v */) /* -> result */ with_nargs 1;
- .datakey.class_spec == 8
-enddefine;
+;;; define lconstant isbytevec(/* v */) /* -> result */ with_nargs 1;
+;;; .datakey.class_spec == 8
+;;; enddefine;
define lconstant isbytearr(/* arr */) /* -> result */ with_nargs 1;
.arrayvector.isbytevec
Steve
On Thu, 11 Jul 2019, Aaron Sloman A.Sloman-at-cs.bham.ac.uk |pop-forum| wrote:
When I set up this location
http://www.cs.bham.ac.uk/research/projects/poplog/amd64/poplog16
with the new 64-bit poplog and installation and use scripts I had forgotten
Waldek's previous warning about the popvision and neural libraries:
$usepop/pop/packages/popvision
$usepop/pop/packages/neural
namely (slightly edited version of Waldek's note):
The packages currently contain 32-bit libraries which will not work on
64-bit machines.
As a quick workaround, to remove/update everything from
'packages/popvision/lib/bin/linux/'
and from
'packages/popvision/lib'
in the lib directory do:
for A in *.c ; do gcc -O2 -fPIC -shared $A -o bin/linux/${A%c}so; done
to create libraries appropriate for the current machine.
A better approach would use per architecture subdirectory like 'arm',
'i386' and 'x86_64', or maybe 'arm-linux', 'i386-linux' and 'x86_64-linux'
if we want support more operationg systems. But that would require some
work to propagate information about the architecture and use it when
needed...
Similarly, 'packages/neural/bin/pclinux' contains 32-bit libraries.
Again one needs to remove them. Then after changing directory
to 'packages/neural/src/c' do the following:
for A in *.c ; do gcc -O2 -fPIC -shared $A -o ../../bin/pclinux/${A%c}so; done
to create libraries for the current machine.
----
He also added:
To load 'mlp' I also needed the diff below (poplog_base defines 'bytevec'
and 'ushortvec'). But results
still look wrong...
--- packages/popvision/lib/array_random.p 1998-08-13 13:46:41.000000000
+0000
+++ packages/popvision/lib/array_random.p 2019-07-06 23:23:38.859218572
+0000
@@ -47,7 +47,7 @@
(seed >> shift) /* -> s3 */;
enddefine;
-defclass lconstant ushortvec :ushort;
+;;; defclass lconstant ushortvec :ushort;
lconstant seedvec = initushortvec(3),
shortbits = 2**SIZEOFTYPE(:ushort,:1) - 1;
--- packages/popvision/lib/mlp.p 2000-03-02 10:50:55.000000000 +0000
+++ packages/popvision/lib/mlp.p 2019-07-06 23:25:32.099069863 +0000
@@ -89,7 +89,7 @@
(seed >> shift) /* -> s3 */;
enddefine;
-defclass lconstant ushortvec :ushort;
+;;; defclass lconstant ushortvec :ushort;
lconstant seedvec = initushortvec(3),
shortbits = 2**SIZEOFTYPE(:ushort,:1) - 1;
--- packages/popvision/lib/newbytearray.p 2003-07-15 08:36:48.000000000
+0000
+++ packages/popvision/lib/newbytearray.p 2019-07-06 23:22:05.831409167
+0000
@@ -12,7 +12,7 @@
uses popvision
uses oldarray
-defclass bytevec :byte;
+;;; defclass bytevec :byte;
define newbytearray = newanyarray(% bytevec_key %); enddefine;
--
====
I shall not have time to do anything about this in the foreseeable future,
but I'll add copies of this note to the information about the packages.
If anyone is willing to try the instructions and/or suggest modifications,
please let me know the outcome.
Thanks
Aaron
http://www.cs.bham.ac.uk/~axs