Menu
▾
▴
matlisp-devel — Developers discussion list. Users can request stuff here as well.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(11) |
Nov
(3) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(8) |
Jul
(9) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2004 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2005 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
(1) |
Mar
(7) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(31) |
Apr
(6) |
May
(6) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Raymond T. <toy...@gm...> - 2015-04-11 23:40:13
|
>>>>> "Helmut" == Helmut Jarausch <jar...@sk...> writes:
Helmut> Hi,
Helmut> I have checked out the GIT version of Matlisp. To build the package
Helmut> I've followed the instructions on the GIT web page:
Helmut> autoreconf --install
Helmut> configure --enable-sbcl --with-lisp-exec=/usr/bin/sbcl \
Helmut> --with-atlas=/usr/lib64/libatlas.so --enable-static=no \
Helmut> --libdir=$PWD/lib
Helmut> make
Helmut> This fails:
Helmut> compiling file "/Src/Src/LANG/Lisp/matlisp-9999/packages.lisp" (written 09 MAR 2015 07:38:12 PM):
Helmut> ; compiling (DEFPACKAGE "FORTRAN-FFI-ACCESSORS" ...)
Helmut> debugger invoked on a SB-KERNEL:SIMPLE-PACKAGE-ERROR in thread
Helmut> #<THREAD "main thread" RUNNING {1002D36953}>:
Helmut> The name "CFFI" does not designate any package.
Helmut> I have the cffi package installed here.
Helmut> When I do
Helmut> (require :cffi)
Helmut> (load packages.lisp)
Helmut> it succeeds.
Helmut> I'm using SBCL-1.2.9 here
Thanks for the report and fix! I guess we need to add a dependency on
cffi before we start compiling the FFI accessors.
(I haven't built matlisp in ages, so it will take some time for me to
test and verify the fix.)
--
Ray
|
|
From: Helmut J. <jar...@sk...> - 2015-03-09 19:42:04
|
Hi,
I have checked out the GIT version of Matlisp. To build the package
I've followed the instructions on the GIT web page:
autoreconf --install
configure --enable-sbcl --with-lisp-exec=/usr/bin/sbcl \
--with-atlas=/usr/lib64/libatlas.so --enable-static=no \
--libdir=$PWD/lib
make
This fails:
compiling file "/Src/Src/LANG/Lisp/matlisp-9999/packages.lisp" (written 09 MAR 2015 07:38:12 PM):
; compiling (DEFPACKAGE "FORTRAN-FFI-ACCESSORS" ...)
debugger invoked on a SB-KERNEL:SIMPLE-PACKAGE-ERROR in thread
#<THREAD "main thread" RUNNING {1002D36953}>:
The name "CFFI" does not designate any package.
I have the cffi package installed here.
When I do
(require :cffi)
(load packages.lisp)
it succeeds.
I'm using SBCL-1.2.9 here
Many thanks for a hint,
Helmut
|
|
From: SourceForge.net <no...@so...> - 2013-02-15 02:54:21
|
Bugs item #3604763, was opened at 2013-02-14 15:03 Message generated for change (Comment added) made by akssri You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3604763&group_id=4511 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: compilation bugs Group: None >Status: Closed Resolution: None Priority: 1 Private: No Submitted By: Ilya Perminov (iperminov1) Assigned to: Akshay Srinivasan (akssri) Summary: configure.ac assumes "." is in PATH Initial Comment: There is a type in configure.ac line 380: "if a.out; then" should be "if ./a.out; then". ---------------------------------------------------------------------- >Comment By: Akshay Srinivasan (akssri) Date: 2013-02-14 18:54 Message: Fixed. ---------------------------------------------------------------------- Comment By: Akshay Srinivasan (akssri) Date: 2013-02-14 18:49 Message: This should be a minor fix in configure.ac. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3604763&group_id=4511 |
|
From: SourceForge.net <no...@so...> - 2013-02-15 02:49:35
|
Bugs item #3604763, was opened at 2013-02-14 15:03 Message generated for change (Comment added) made by akssri You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3604763&group_id=4511 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: compilation bugs Group: None Status: Open Resolution: None >Priority: 1 Private: No Submitted By: Ilya Perminov (iperminov1) >Assigned to: Akshay Srinivasan (akssri) Summary: configure.ac assumes "." is in PATH Initial Comment: There is a type in configure.ac line 380: "if a.out; then" should be "if ./a.out; then". ---------------------------------------------------------------------- >Comment By: Akshay Srinivasan (akssri) Date: 2013-02-14 18:49 Message: This should be a minor fix in configure.ac. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3604763&group_id=4511 |
|
From: SourceForge.net <no...@so...> - 2013-02-14 23:03:37
|
Bugs item #3604763, was opened at 2013-02-14 15:03 Message generated for change (Tracker Item Submitted) made by iperminov1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3604763&group_id=4511 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: compilation bugs Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ilya Perminov (iperminov1) Assigned to: Nobody/Anonymous (nobody) Summary: configure.ac assumes "." is in PATH Initial Comment: There is a type in configure.ac line 380: "if a.out; then" should be "if ./a.out; then". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3604763&group_id=4511 |
|
From: Raymond T. <toy...@gm...> - 2012-07-13 15:43:27
|
On Fri, Jul 13, 2012 at 6:48 AM, Akshay Srinivasan < ak...@us...> wrote: > This is an automated email from the git hooks/post-receive script. It was > generated because a ref change was pushed to the repository containing > the project "matlisp". > > The branch, tensor has been updated > via 2b87e86f1392efee853a1807d7c9299fee1f7958 (commit) > from 04ac7f795b17225ad7f942b85bad9508a885ee1e (commit) > > Those revisions listed above that are new to this repository have > not appeared on any other notification email; so we list those > revisions in full, below. > > - Log ----------------------------------------------------------------- > commit 2b87e86f1392efee853a1807d7c9299fee1f7958 > Author: Akshay Srinivasan <aks...@gm...> > Date: Fri Jul 13 11:36:34 2012 +0530 > > o Added fortran-call-lower-bound parameters to scal, dot and swap. > While I think I understand why you want to add this lower bound, it looks like there will eventually be a global for each function. That's just too many. Can't we just have one that is a rough tradeoff? For people who need very specific values, they can always rebind that one global for that one function call. Ray |
|
From: SourceForge.net <no...@so...> - 2012-06-01 03:25:03
|
Bugs item #3527162, was opened at 2012-05-15 23:15 Message generated for change (Settings changed) made by akssri You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3527162&group_id=4511 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Tzaddi (tzaddi) Assigned to: Akshay Srinivasan (akssri) Summary: SVD gives an error: The function (COMMON-LISP:SETF MATLISP:D Initial Comment: It looks like setf (diag ...) is not defined properly or is not in the correct package. When I run svd with job :a I get: The function (COMMON-LISP:SETF MATLISP:DIAG) is undefined. ---------------------------------------------------------------------- Comment By: Akshay Srinivasan (akssri) Date: 2012-05-29 11:12 Message: Fixed in the matlisp-cffi branch. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-05-29 10:59 Message: You should be doing: (copy! s (diag~ s1 0)) I'll add a setf-able method to the branch. We decided to use "~" (like the "!") to refer to functions which give out matrix-slices. ---------------------------------------------------------------------- Comment By: Tzaddi (tzaddi) Date: 2012-05-15 23:28 Message: I found the definition in tensor.lisp, but am not sure why it can't be used in svd.lisp. So, I substituted the expansion in place in the svd method definition and now I get a new error when running svd with job :a Arguments X,Y to COPY! are of different dimensions. Where I substutite I found the definition in tensor.lisp, but am not sure why it can't be used in svd.lisp. So, I substituted the expansion in place in the svd method definition and now I get a new error when running svd with job :a Arguments X,Y to COPY! are of different dimensions. Where I substutite (copy! s (diag s1 0)) for (setf (diag s1) s). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3527162&group_id=4511 |
|
From: SourceForge.net <no...@so...> - 2012-05-29 18:13:28
|
Bugs item #3513323, was opened at 2012-03-30 10:59 Message generated for change (Settings changed) made by akssri You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3513323&group_id=4511 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ilya Perminov (iperminov1) >Assigned to: Akshay Srinivasan (akssri) Summary: SBCL does not like constant definition of +ffi-types+ Initial Comment: SBCL signals "constant is being redefined " errors for +ffi-types+ and +ffi-styles+ in src/ffi-cffi.lisp, because the values of the constants are lists. SBCL documentation explains the problem: http://www.sbcl.org/manual/Defining-Constants.html. Ilya ---------------------------------------------------------------------- Comment By: Akshay Srinivasan (akssri) Date: 2012-05-29 11:10 Message: Yes, this happens to me on SBCL. I've been lazy and keep ignoring this. Will fix this. ---------------------------------------------------------------------- Comment By: Ilya Perminov (iperminov1) Date: 2012-04-23 10:29 Message: The problem happens when ASDF compiles and then loads the file, because SBCL evaluates DEFCONSTANTs in both compile time and load time. ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2012-04-22 21:43 Message: Are you getting this because you are reloading src/ffi-cffi into your lisp? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3513323&group_id=4511 |
|
From: SourceForge.net <no...@so...> - 2012-05-29 18:12:47
|
Bugs item #3527162, was opened at 2012-05-15 23:15 Message generated for change (Comment added) made by akssri You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3527162&group_id=4511 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Tzaddi (tzaddi) >Assigned to: Akshay Srinivasan (akssri) Summary: SVD gives an error: The function (COMMON-LISP:SETF MATLISP:D Initial Comment: It looks like setf (diag ...) is not defined properly or is not in the correct package. When I run svd with job :a I get: The function (COMMON-LISP:SETF MATLISP:DIAG) is undefined. ---------------------------------------------------------------------- >Comment By: Akshay Srinivasan (akssri) Date: 2012-05-29 11:12 Message: Fixed in the matlisp-cffi branch. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-05-29 10:59 Message: You should be doing: (copy! s (diag~ s1 0)) I'll add a setf-able method to the branch. We decided to use "~" (like the "!") to refer to functions which give out matrix-slices. ---------------------------------------------------------------------- Comment By: Tzaddi (tzaddi) Date: 2012-05-15 23:28 Message: I found the definition in tensor.lisp, but am not sure why it can't be used in svd.lisp. So, I substituted the expansion in place in the svd method definition and now I get a new error when running svd with job :a Arguments X,Y to COPY! are of different dimensions. Where I substutite I found the definition in tensor.lisp, but am not sure why it can't be used in svd.lisp. So, I substituted the expansion in place in the svd method definition and now I get a new error when running svd with job :a Arguments X,Y to COPY! are of different dimensions. Where I substutite (copy! s (diag s1 0)) for (setf (diag s1) s). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3527162&group_id=4511 |
|
From: SourceForge.net <no...@so...> - 2012-05-29 18:10:40
|
Bugs item #3513323, was opened at 2012-03-30 10:59 Message generated for change (Comment added) made by akssri You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3513323&group_id=4511 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ilya Perminov (iperminov1) Assigned to: Nobody/Anonymous (nobody) Summary: SBCL does not like constant definition of +ffi-types+ Initial Comment: SBCL signals "constant is being redefined " errors for +ffi-types+ and +ffi-styles+ in src/ffi-cffi.lisp, because the values of the constants are lists. SBCL documentation explains the problem: http://www.sbcl.org/manual/Defining-Constants.html. Ilya ---------------------------------------------------------------------- Comment By: Akshay Srinivasan (akssri) Date: 2012-05-29 11:10 Message: Yes, this happens to me on SBCL. I've been lazy and keep ignoring this. Will fix this. ---------------------------------------------------------------------- Comment By: Ilya Perminov (iperminov1) Date: 2012-04-23 10:29 Message: The problem happens when ASDF compiles and then loads the file, because SBCL evaluates DEFCONSTANTs in both compile time and load time. ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2012-04-22 21:43 Message: Are you getting this because you are reloading src/ffi-cffi into your lisp? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3513323&group_id=4511 |
|
From: SourceForge.net <no...@so...> - 2012-05-29 17:59:44
|
Bugs item #3527162, was opened at 2012-05-15 23:15 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3527162&group_id=4511 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tzaddi (tzaddi) Assigned to: Nobody/Anonymous (nobody) Summary: SVD gives an error: The function (COMMON-LISP:SETF MATLISP:D Initial Comment: It looks like setf (diag ...) is not defined properly or is not in the correct package. When I run svd with job :a I get: The function (COMMON-LISP:SETF MATLISP:DIAG) is undefined. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-05-29 10:59 Message: You should be doing: (copy! s (diag~ s1 0)) I'll add a setf-able method to the branch. We decided to use "~" (like the "!") to refer to functions which give out matrix-slices. ---------------------------------------------------------------------- Comment By: Tzaddi (tzaddi) Date: 2012-05-15 23:28 Message: I found the definition in tensor.lisp, but am not sure why it can't be used in svd.lisp. So, I substituted the expansion in place in the svd method definition and now I get a new error when running svd with job :a Arguments X,Y to COPY! are of different dimensions. Where I substutite I found the definition in tensor.lisp, but am not sure why it can't be used in svd.lisp. So, I substituted the expansion in place in the svd method definition and now I get a new error when running svd with job :a Arguments X,Y to COPY! are of different dimensions. Where I substutite (copy! s (diag s1 0)) for (setf (diag s1) s). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3527162&group_id=4511 |
|
From: SourceForge.net <no...@so...> - 2012-05-16 06:28:35
|
Bugs item #3527162, was opened at 2012-05-15 23:15 Message generated for change (Comment added) made by tzaddi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3527162&group_id=4511 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tzaddi (tzaddi) Assigned to: Nobody/Anonymous (nobody) Summary: SVD gives an error: The function (COMMON-LISP:SETF MATLISP:D Initial Comment: It looks like setf (diag ...) is not defined properly or is not in the correct package. When I run svd with job :a I get: The function (COMMON-LISP:SETF MATLISP:DIAG) is undefined. ---------------------------------------------------------------------- >Comment By: Tzaddi (tzaddi) Date: 2012-05-15 23:28 Message: I found the definition in tensor.lisp, but am not sure why it can't be used in svd.lisp. So, I substituted the expansion in place in the svd method definition and now I get a new error when running svd with job :a Arguments X,Y to COPY! are of different dimensions. Where I substutite I found the definition in tensor.lisp, but am not sure why it can't be used in svd.lisp. So, I substituted the expansion in place in the svd method definition and now I get a new error when running svd with job :a Arguments X,Y to COPY! are of different dimensions. Where I substutite (copy! s (diag s1 0)) for (setf (diag s1) s). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3527162&group_id=4511 |
|
From: SourceForge.net <no...@so...> - 2012-05-16 06:15:08
|
Bugs item #3527162, was opened at 2012-05-15 23:15 Message generated for change (Tracker Item Submitted) made by tzaddi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3527162&group_id=4511 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tzaddi (tzaddi) Assigned to: Nobody/Anonymous (nobody) Summary: SVD gives an error: The function (COMMON-LISP:SETF MATLISP:D Initial Comment: It looks like setf (diag ...) is not defined properly or is not in the correct package. When I run svd with job :a I get: The function (COMMON-LISP:SETF MATLISP:DIAG) is undefined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3527162&group_id=4511 |
|
From: Raymond T. <toy...@gm...> - 2012-04-28 16:13:15
|
Are we in a good enough state that we can merge the matlisp-cffi branch to master? Ray |
|
From: SourceForge.net <no...@so...> - 2012-04-25 03:58:38
|
Bugs item #3514241, was opened at 2012-04-02 12:39 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3514241&group_id=4511 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Ilya Perminov (iperminov1) Assigned to: Nobody/Anonymous (nobody) Summary: config.lisp puts its symbols into CL-USER Initial Comment: config.lisp puts its functions (MATLISP-VERSION and MATLISP-HERALD) into package CL-USER, but these functions are expected to be in MATLISP. ---------------------------------------------------------------------- >Comment By: Raymond Toy (rtoy) Date: 2012-04-24 20:58 Message: Fixed. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3514241&group_id=4511 |
|
From: SourceForge.net <no...@so...> - 2012-04-25 03:18:46
|
Bugs item #3513318, was opened at 2012-03-30 10:42 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3513318&group_id=4511 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Ilya Perminov (iperminov1) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong type declarations in src/quadpack.lisp Initial Comment: Array IWORK is passed to functions that expect an array of F2CL-LIB:INTEGER4, but in initialization its element type is specified as (SIGNED-BYTE 32), In SBCL x64 F2CL-LIB:INTEGER4 and (SIGNED-BYTE 32) are different types. Ilya ---------------------------------------------------------------------- >Comment By: Raymond Toy (rtoy) Date: 2012-04-24 20:18 Message: Fixed. Use f2cl-lib:integer4 in quadpack.lisp and make f2cl-lib:integer4 be the same as (signed-byte 32). ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2012-04-22 21:42 Message: Thanks. That's an oversight in the f2cl macros.l where no one bothered to put in support for sbcl where integer4 should be (signed-byte 32). However, with the upcoming ffi support, we can probably simply things and get rid of the translated quadpack routines. I'll have to think whether we want to do that or not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3513318&group_id=4511 |
|
From: SourceForge.net <no...@so...> - 2012-04-23 04:43:16
|
Bugs item #3513323, was opened at 2012-03-30 10:59 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3513323&group_id=4511 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ilya Perminov (iperminov1) Assigned to: Nobody/Anonymous (nobody) Summary: SBCL does not like constant definition of +ffi-types+ Initial Comment: SBCL signals "constant is being redefined " errors for +ffi-types+ and +ffi-styles+ in src/ffi-cffi.lisp, because the values of the constants are lists. SBCL documentation explains the problem: http://www.sbcl.org/manual/Defining-Constants.html. Ilya ---------------------------------------------------------------------- >Comment By: Raymond Toy (rtoy) Date: 2012-04-22 21:43 Message: Are you getting this because you are reloading src/ffi-cffi into your lisp? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3513323&group_id=4511 |
|
From: SourceForge.net <no...@so...> - 2012-04-23 04:42:17
|
Bugs item #3513318, was opened at 2012-03-30 10:42 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3513318&group_id=4511 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ilya Perminov (iperminov1) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong type declarations in src/quadpack.lisp Initial Comment: Array IWORK is passed to functions that expect an array of F2CL-LIB:INTEGER4, but in initialization its element type is specified as (SIGNED-BYTE 32), In SBCL x64 F2CL-LIB:INTEGER4 and (SIGNED-BYTE 32) are different types. Ilya ---------------------------------------------------------------------- >Comment By: Raymond Toy (rtoy) Date: 2012-04-22 21:42 Message: Thanks. That's an oversight in the f2cl macros.l where no one bothered to put in support for sbcl where integer4 should be (signed-byte 32). However, with the upcoming ffi support, we can probably simply things and get rid of the translated quadpack routines. I'll have to think whether we want to do that or not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3513318&group_id=4511 |
|
From: SourceForge.net <no...@so...> - 2012-04-02 19:39:04
|
Bugs item #3514241, was opened at 2012-04-02 12:39 Message generated for change (Tracker Item Submitted) made by iperminov1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3514241&group_id=4511 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ilya Perminov (iperminov1) Assigned to: Nobody/Anonymous (nobody) Summary: config.lisp puts its symbols into CL-USER Initial Comment: config.lisp puts its functions (MATLISP-VERSION and MATLISP-HERALD) into package CL-USER, but these functions are expected to be in MATLISP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3514241&group_id=4511 |
|
From: SourceForge.net <no...@so...> - 2012-03-30 17:59:22
|
Bugs item #3513323, was opened at 2012-03-30 10:59 Message generated for change (Tracker Item Submitted) made by iperminov1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3513323&group_id=4511 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ilya Perminov (iperminov1) Assigned to: Nobody/Anonymous (nobody) Summary: SBCL does not like constant definition of +ffi-types+ Initial Comment: SBCL signals "constant is being redefined " errors for +ffi-types+ and +ffi-styles+ in src/ffi-cffi.lisp, because the values of the constants are lists. SBCL documentation explains the problem: http://www.sbcl.org/manual/Defining-Constants.html. Ilya ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3513323&group_id=4511 |
|
From: SourceForge.net <no...@so...> - 2012-03-30 17:42:21
|
Bugs item #3513318, was opened at 2012-03-30 10:42 Message generated for change (Tracker Item Submitted) made by iperminov1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3513318&group_id=4511 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ilya Perminov (iperminov1) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong type declarations in src/quadpack.lisp Initial Comment: Array IWORK is passed to functions that expect an array of F2CL-LIB:INTEGER4, but in initialization its element type is specified as (SIGNED-BYTE 32), In SBCL x64 F2CL-LIB:INTEGER4 and (SIGNED-BYTE 32) are different types. Ilya ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104511&aid=3513318&group_id=4511 |
|
From: Raymond T. <toy...@gm...> - 2012-03-27 15:07:44
|
Now that I've used the callback support a little, I'd like to propose
the following to make it a little easier to write callbacks for fortran
routines.
(WITH-FORTRAN-MATRIX (name fv &rest dimensions) &body body)
This makes it easier to access Fortran matrices so you can write
(defun callback (fv)
(with-fortran-matrix (m fv (1 4) (1 5))
(setf (m 1 3) (m 4 5))
The dimensions (1 4) and (1 5) are the lower and upper bounds of the
Fortran matrix m, which is an alias to the actual foreign vector in fv.
Or maybe it should be
(with-fortran-matrices ((m1 fv1 <dims1>)
(m2 fv2 <dims2>))
body)
so that several matrices can be created at once.
Ray
|
|
From: Raymond T. <toy...@gm...> - 2012-03-27 14:59:26
|
On 3/20/12 6:17 AM, Akshay Srinivasan wrote: > Hi, > I was thinking we could just shadow functions like sin, cos, tan.. and > replace them with generic functions and define methods for matrix > classes. I have read something about this being slow runtime-wise, not > sure though. This has been done many times in several packages. I did this for maxima in the bigfloat package. The intent was to be able to take double-float code, through an (in-package "BIGFLOAT") around it, and have it mostly work for Maxima's bigfloat. I never measured it, but I'm quite sure it is significantly slower than the original double-float code. There's the CLOS method lookup overhead and also lots of additional boxing that probably needs to be done. > I can see why this would be a bad idea, because of issues in using > Matlisp classes in other packages. Maybe we can create a package which > overloads things for better user interaction ? > Perhaps. But for me, I've concluded that it's not a good idea to just use a package in another. I prefer to keep the package prefix when referring to other symbols from other packages. Having said that, we should probably separate out the current matlisp package into at least two packages. There's the external matlisp package that exports the exposed matlisp interface, and the internal matlisp-internals package that has all the rest of the cruft for the implementation. Ray |
|
From: Akshay S. <aks...@gm...> - 2012-03-20 13:19:55
|
Hi, I was thinking we could just shadow functions like sin, cos, tan.. and replace them with generic functions and define methods for matrix classes. I have read something about this being slow runtime-wise, not sure though. I can see why this would be a bad idea, because of issues in using Matlisp classes in other packages. Maybe we can create a package which overloads things for better user interaction ? Akshay |
|
From: Akshay S. <aks...@gm...> - 2012-03-20 07:05:31
|
> It seems to me that if I do (make-instance 'real-matrix :nrows
> rows :ncols cols) I shouldn't have to specify the strides unless I
> really want to. There should be some default. Either column-major
> or row-major.
Apparently this is the way it was supposed to work (I take my words
back :)
I think the initarg for {row,col}-stride was changed from zero, which
makes it throw up a unbound error. I've fixed this now.
>
>
>>
>>> ;;Submatrix of d starting at (1, 1) or size (2, 2) (defvar e
>>> (sub! d 1 1 2 2))
>> We should pick a better name than sub!, like maybe sub-matrix!.
>> And what does the ! mean here? The intention for "!" is to mean
>> a destructive operation so does sub! destructively modify d to
>> make a submatrix? And what would that actually mean? If it's
>> not
> destructive,
>> then don't use "!".
>>
> Yes, it is a bad naming convention. Can we pick some other
> character to indicate that the store is shared ? The "!" was meant
> to indicate that the store is essentially the same, but this
> contradicts with the usual Lisp convention.
>
>> It seems that e and d now both refer to the same storage. So if
>> I modify e, d will magically change? That's expected, but once e
>> is created, it becomes very easy to lose track of the fact that
>> it is a submatrix of d, especially at the repl. I think we need
>> to make the relationship more explicit. Maybe create a new class
>> that is a
> subclass
>> of matrix (or whatever) that adds a slot that holds a reference
>> to the matrix. Kind of like how in lisp you can have displaced
>> arrays,
> and you
>> can tell it's displaced and can chase down all the way to the
>> final, non-displaced array if you want to.
> That sounds reasonable, shouldn't be too hard to do.
>
>
> I think if you do this, then you don't need any special naming
> convention. sub-matrix creates a submatrix of the given matrix,
> and the type (submatrix) tells us instantly that something is
> shared. And we can, if we want to, chase down what matrix we're a
> submatrix of. I can imagine submatrices of submatrices of ....
Hmm, but if one would want to copy the submatrix, we'd have to call it
something else. Or we can make sure that we never copy anything by
default, I'm more in favour of this.
Akshay
|
3 messages has been excluded from this view by a project administrator.