matlisp-users — General discussion list.

Re: [Matlisp-users] Matlisp subset in pure CL

[Raymond T. <to...@rt...>]

>>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes:

    Nicolas> Maybe it is also possible with the help of CL vendors and developers to
    Nicolas> reduce the FFI call overhead.

Speculation here, but the FFI call overhead itself is probably quite
low.  The cost currently is turning off GC, extracting the addresses,
putting an unwind-protect around the FFI call, and setting up the FP
modes to what Fortran wants.  If we had immovable foreign vectors and
just set the FP modes to what Fortran wants, then a lot of the
overhead would go away.

    Nicolas> For the more distant future, I dream of a seamless transition between
    Nicolas> Matlisp and CL-Matlisp, e.g. along the following lines:

    Nicolas>   1. Use the CL-implemented version, if there is any, and if the matrices
    Nicolas>      are small.

And the nice thing is we can even get rid of the call overhead if the
function could be inlined.  That's a huge win for small
matrices/vectors. 

Ray

Re: [Matlisp-users] Matlisp subset in pure CL

[Raymond T. <to...@rt...>]

>>>>> "simsek" == simsek  <si...@ee...> writes:

    simsek> But ... there is one thing you may not be aware of.  IIRC, someone
    simsek> correct me if I'm wrong, one of the main reasons why we did matlisp
    simsek> the way it is was to avoid writing such routines in lisp altogether.
    simsek> When I first contacted Ray, he had already worked out the generic
    simsek> foreign wrapper suitable for fortran code.  I then wrote a script
    simsek> to generate the wrapper code automagically from the lapack files.
    simsek> So the idea was not to write basic matrix operatinos at all.


Yes, that was certainly my idea too.  Having said that, let me also
say that I experimented a bit with a full Lisp implementation of some
of the basic routines, and at least with CMUCL, Lisp was no slower
than LAPACK for small matrices.   But why redo the work when someone
had already done it, and better than I would do?

    simsek> Having said that, matlisp has evolved along the way, with contributions
    simsek> from select individuals like yourself.  I think it may be time to
    simsek> consider more drastic functionality of the kind you're suggesting.

I also think this is a good idea.  It would be nice if this approach
could be made seamless with Matlisp, so the user wouldn't have to know
unless he wanted to.  If it also means changing some Matlisp
functions, that would also be ok.  We might want to ask other users
about that, though. :-)

We probably also want to do an official 2.0 release before adding such
features for the "3.0" release.

    simsek> I, unfortunately, personally would not be able to participate in the development
    simsek> but I think there are people out there who might be.

I can help some, but I don't use matlisp that much anymore.

Ray

Re: [Matlisp-users] Matlisp subset in pure CL

[Nicolas N. <Nic...@iw...>]

si...@EE... writes:

> Hi Nicolas;
>
> Wow.  You're doing some impressive work.  I like your ideas.

Thank you very much.

> But ... there is one thing you may not be aware of.  IIRC, someone
> correct me if I'm wrong, one of the main reasons why we did matlisp the
> way it is was to avoid writing such routines in lisp altogether.  When I
> first contacted Ray, he had already worked out the generic foreign
> wrapper suitable for fortran code.  I then wrote a script to generate the
> wrapper code automagically from the lapack files.  So the idea was not to
> write basic matrix operatinos at all.

I think that Matlisp is an important proof of concept, namely that CL
really can take full profit of foreign libraries.  Some time ago, I spoke
with Folkmar Bornemann (a numerical analyst at the Technical University in
Munich) about Femlisp, and he advocated the use of Matlab/Femlab instead.
One of his reasons was that Matlab has access to the high-performance ATLAS
library.  At that time, I did not know that Matlisp could use ATLAS, but
now I feel very comfortable that I can get this speed also from within CL
if I really should need it.

I see the BLAS development in Femlisp as another proof of concept.  My
goals were:

1. It should be sufficient for Femlisp's needs thus making Femlisp more or
   less running with every ANSI CL.  This is possible because Femlisp uses
   iterative solvers, which need only rather few basic operations for full
   matrices.

2. The technique should be extensible to sparse matrices.  In fact, this
   will be the most important step which I plan to tackle in the next
   months.  As much as I know, also for Fortran there is no standard
   library for sparse matrices availableq.  Furthermore, Femlisp has very
   special needs (dynamic modifications of matrix structure, etc.).

3. It should be as concise as possible in source code, and it should
   nevertheless be as fast as you can get with CL.  Especially, at this
   point the dynamic features of CL fit wonderful in the picture.

Point 3 made it necessary that I deviated from Matlisp in several ways.
E.g. I used a different class representation with more general class names,
I removed optional parameters which have a performance drawback for the
method call, etc.  However, the changes are not large and it should be easy
to transfer code between Matlisp and "CL-Matlisp".  The most noticeable
change is that I did not use the [] read macro, but implemented a simpler
one dispatching on #m.  Another one is that I generally use MREF/VREF
instead of MATRIX-REF.

> Having said that, matlisp has evolved along the way, with contributions
> from select individuals like yourself.  I think it may be time to
> consider more drastic functionality of the kind you're suggesting.  I,
> unfortunately, personally would not be able to participate in the
> development but I think there are people out there who might be.
>
>   My two cents, Tunc

In any case, I think that we should be aware of each others development.
Maybe Matlisp can try to improve its method call overhead a little bit
along the lines shown in Femlisp.  For example, you could check matrix
compatibility without a :BEFORE method, or you could remove optional
parameters.
+--
|Example: I have generic functions GEMM-NN!, GEMM-NT!, GEMM-TN!, GEMM-TT!
|and a dispatch function
|
|    (defun gemm! (alpha x y beta z &optional (job :nn))
|      "Dispatches on the optional job argument (member :nn :tn :nt :tt) and
|    calls the corresponding generic function, e.g. GEMM-NN!."
|      (ecase job
|        (:nn (gemm-nn! alpha x y beta z))
|        (:nt (gemm-nt! alpha x y beta z))
|        (:tn (gemm-tn! alpha x y beta z))
|        (:tt (gemm-tt! alpha x y beta z))))
|
|to keep the Matlisp interface.
+--
Maybe it is also possible with the help of CL vendors and developers to
reduce the FFI call overhead.

For the more distant future, I dream of a seamless transition between
Matlisp and CL-Matlisp, e.g. along the following lines:

  1. Use the CL-implemented version, if there is any, and if the matrices
     are small.
  2. Alternatively, use an FFI-call if the external library is available or
     if the matrices are large
  3. Otherwise, throw an error.

However, this development is too early now, at least for me.  While
implementing the BLAS operations sparse matrix, there will probably be
several important changes and I need a code which is as lightweight as
possible for the moment.

Yours, Nicolas.

Re: [Matlisp-users] Matlisp subset in pure CL

[<si...@EE...>]

Hi Nicolas;

Wow.  You're doing some impressive work.  I like your ideas.
But ... there is one thing you may not be aware of.  IIRC, someone
correct me if I'm wrong, one of the main reasons why we did matlisp
the way it is was to avoid writing such routines in lisp altogether.
When I first contacted Ray, he had already worked out the generic
foreign wrapper suitable for fortran code.  I then wrote a script
to generate the wrapper code automagically from the lapack files.
So the idea was not to write basic matrix operatinos at all.

Having said that, matlisp has evolved along the way, with contributions
from select individuals like yourself.  I think it may be time to
consider more drastic functionality of the kind you're suggesting.
I, unfortunately, personally would not be able to participate in the development
but I think there are people out there who might be.

  My two cents, Tunc

----- Original Message -----
From: Nicolas Neuss <Nic...@iw...>
Date: Thursday, May 6, 2004 5:57 am
Subject: [Matlisp-users] Matlisp subset in pure CL

> Hello,
> 
> I have written some CL routines for elementary full matrix arithmetic
> (vector operations, matrix multiplication and inversion).  I need 
> this in
> my PDE toolbox Femlisp (www.femlisp.org) for moderately sized full 
> matricesappearing as subblocks of sparse matrices.  I first used 
> Matlisp but was
> dissatisfied with:
> 
> 1. The overhead of the FFI call which is present in both CMUCL and 
> ACL (we
>   discussed this here).
> 
> 2. The overhead of each call to BLAS operations
> 
> 3. Portability.
> 
> Recently, I replaced Matlisp by my own Common Lisp code.  It uses 
> matrixclasses which are parametrized on the element type and 
> methods which are
> compiled at runtime adapted to the matrix class.  I think this is an
> interesting approach and intend to extend this technique also for 
> sparsematrices in future versions of Femlisp.  I speculate that 
> this development
> should bring my application in a speed range comparable with other FEM
> toolboxes on unstructured grids.
> 
> Example (P4, 2.4GHz), M+!-N adds two NxN-matrices:
> 
> MATLISP (2_0beta-2003-10-14, with ATLAS)
> 
> M+!-1: 0.27 MFLOPS
> M+!-2: 1.25 MFLOPS
> M+!-4: 4.99 MFLOPS
> M+!-8: 15.25 MFLOPS
> M+!-16: 71.39 MFLOPS
> M+!-32: 186.41 MFLOPS
> M+!-64: 353.20 MFLOPS
> M+!-128: 432.96 MFLOPS
> M+!-256: 78.03 MFLOPS
> M+!-512: 72.94 MFLOPS
> 
> FL.MATLISP:
> M+!-1: 13.11 MFLOPS
> M+!-2: 41.94 MFLOPS
> M+!-4: 98.69 MFLOPS
> M+!-8: 167.77 MFLOPS
> M+!-16: 197.38 MFLOPS
> M+!-32: 203.36 MFLOPS
> M+!-64: 203.36 MFLOPS
> M+!-128: 203.36 MFLOPS
> M+!-256: 79.89 MFLOPS
> M+!-512: 79.89 MFLOPS
> 
> We see that the overhead for the M+!-operation has been largely 
> reduced,although the peak performance of ATLAS is twice as large.
> 
> Now, what is the point of this message?  I do not think that Matlisp
> becomes unnecessary because of FL.MATLISP.  In fact, FL.MATLISP 
> comprisesonly a small subset of BLAS/LAPACK now, and I do not 
> intend to implement
> all of it or to achieve the ATLAS performance for BLAS Level 2 
> operationsas GEMM! or GESV!.  But FL.MATLISP achieves a lot with 
> comparatively little
> code.  And, although FL.MATLISP is not yet perfectly implemented, 
> I think
> that there are several things which could be improved in Matlisp 
> in the
> direction which I have taken:
> 
> 1. I like my idea of parametrized matrix classes very much.  I can 
> declare   matrices of uniform element type as e.g. (standard-
> matrix 'double-float)
>   which returns (and maybe generates at runtime) a class named
>   |(STANDARD-MATRIX DOUBLE-FLOAT)| or arbitrary others.  Maybe 
> this would
>   be interesting also for Matlisp, while keeping the alias to 
> REAL-MATRIX.
> 
> 2. My BLAS methods are defined on STANDARD-MATRIX.  When called 
> with a
>   subclass, e.g. |(STANDARD-MATRIX DOUBLE-FLOAT)|, they compile a 
> method   adapted to the subclass.  Probably, Matlisp could be 
> implemented in a
>   similar way by suitably interfacing to DGEMM, ZGEMM, etc.
> 
> It would also be a large advantage if FL.MATLISP and MATLISP could
> interoperate.  This is already possible at a lower level, because 
> I have
> kept the Fortran indexing style.  But it might be reasonable to 
> strive for
> interoperability also on the CLOS level.
> 
> So, if someone has any ideas in which direction one could pursue this
> project I would like to hear them.  My routines can be found in the
> directory "femlisp:src;matlisp" (if you install Femlisp from
> www.femlisp.org) in the FL.MATLISP package.  It would also be 
> relativelyeasy to extract these routines into a separate project, 
> e.g. CL-MATLISP, if
> there is large interest in such a move.
> 
> Thank you for any suggestions,
> 
> Nicolas.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use 
> to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
> 

Re: [Matlisp-users] Matlisp subset in pure CL

[Nicolas N. <Nic...@iw...>]

Nicolas Neuss <Nic...@iw...> writes:

> Example (P4, 2.4GHz), M+!-N adds two NxN-matrices:
> 
> MATLISP (2_0beta-2003-10-14, with ATLAS)
> 
> M+!-1: 0.27 MFLOPS
> M+!-2: 1.25 MFLOPS
> M+!-4: 4.99 MFLOPS
> M+!-8: 15.25 MFLOPS
> M+!-16: 71.39 MFLOPS
> M+!-32: 186.41 MFLOPS
> M+!-64: 353.20 MFLOPS
> M+!-128: 432.96 MFLOPS
> M+!-256: 78.03 MFLOPS
> M+!-512: 72.94 MFLOPS

And these numbers deserve more explanation.  They are measured by doing an
M+!-call repeatedly on matrices of size NxN.  The large values are achieved
if the method call is negligible and the matrices are already in the cache
from the previous call.  If M+! is applied to fresh data which is not in
the cache, the performance should remain below the 70-80 MFLOPS measured for
large matrices above.

Nicolas.

[Matlisp-users] Matlisp subset in pure CL

[Nicolas N. <Nic...@iw...>]

Hello,

I have written some CL routines for elementary full matrix arithmetic
(vector operations, matrix multiplication and inversion).  I need this in
my PDE toolbox Femlisp (www.femlisp.org) for moderately sized full matrices
appearing as subblocks of sparse matrices.  I first used Matlisp but was
dissatisfied with:

1. The overhead of the FFI call which is present in both CMUCL and ACL (we
   discussed this here).

2. The overhead of each call to BLAS operations

3. Portability.

Recently, I replaced Matlisp by my own Common Lisp code.  It uses matrix
classes which are parametrized on the element type and methods which are
compiled at runtime adapted to the matrix class.  I think this is an
interesting approach and intend to extend this technique also for sparse
matrices in future versions of Femlisp.  I speculate that this development
should bring my application in a speed range comparable with other FEM
toolboxes on unstructured grids.

Example (P4, 2.4GHz), M+!-N adds two NxN-matrices:

MATLISP (2_0beta-2003-10-14, with ATLAS)

M+!-1: 0.27 MFLOPS
M+!-2: 1.25 MFLOPS
M+!-4: 4.99 MFLOPS
M+!-8: 15.25 MFLOPS
M+!-16: 71.39 MFLOPS
M+!-32: 186.41 MFLOPS
M+!-64: 353.20 MFLOPS
M+!-128: 432.96 MFLOPS
M+!-256: 78.03 MFLOPS
M+!-512: 72.94 MFLOPS

FL.MATLISP:
M+!-1: 13.11 MFLOPS
M+!-2: 41.94 MFLOPS
M+!-4: 98.69 MFLOPS
M+!-8: 167.77 MFLOPS
M+!-16: 197.38 MFLOPS
M+!-32: 203.36 MFLOPS
M+!-64: 203.36 MFLOPS
M+!-128: 203.36 MFLOPS
M+!-256: 79.89 MFLOPS
M+!-512: 79.89 MFLOPS

We see that the overhead for the M+!-operation has been largely reduced,
although the peak performance of ATLAS is twice as large.

Now, what is the point of this message?  I do not think that Matlisp
becomes unnecessary because of FL.MATLISP.  In fact, FL.MATLISP comprises
only a small subset of BLAS/LAPACK now, and I do not intend to implement
all of it or to achieve the ATLAS performance for BLAS Level 2 operations
as GEMM! or GESV!.  But FL.MATLISP achieves a lot with comparatively little
code.  And, although FL.MATLISP is not yet perfectly implemented, I think
that there are several things which could be improved in Matlisp in the
direction which I have taken:

1. I like my idea of parametrized matrix classes very much.  I can declare
   matrices of uniform element type as e.g. (standard-matrix 'double-float)
   which returns (and maybe generates at runtime) a class named
   |(STANDARD-MATRIX DOUBLE-FLOAT)| or arbitrary others.  Maybe this would
   be interesting also for Matlisp, while keeping the alias to REAL-MATRIX.

2. My BLAS methods are defined on STANDARD-MATRIX.  When called with a
   subclass, e.g. |(STANDARD-MATRIX DOUBLE-FLOAT)|, they compile a method
   adapted to the subclass.  Probably, Matlisp could be implemented in a
   similar way by suitably interfacing to DGEMM, ZGEMM, etc.

It would also be a large advantage if FL.MATLISP and MATLISP could
interoperate.  This is already possible at a lower level, because I have
kept the Fortran indexing style.  But it might be reasonable to strive for
interoperability also on the CLOS level.

So, if someone has any ideas in which direction one could pursue this
project I would like to hear them.  My routines can be found in the
directory "femlisp:src;matlisp" (if you install Femlisp from
www.femlisp.org) in the FL.MATLISP package.  It would also be relatively
easy to extract these routines into a separate project, e.g. CL-MATLISP, if
there is large interest in such a move.

Thank you for any suggestions,

Nicolas.

[Matlisp-users] Re: IFFT! Scaling Error

[Raymond T. <rt...@ea...>]

ma...@ll... wrote:
> All,
> 
> 1.  I noted a 1/N scaling error in IFFT! in the CVS code.  This was
>     not present in my local working copy.  I suspect I caused this
>     some time back and apologize.

Patch applied.  Thanks!

Ray

[Matlisp-users] IFFT! Scaling Error

[<ma...@ll...>]

All,

1.  I noted a 1/N scaling error in IFFT! in the CVS code.  This was
    not present in my local working copy.  I suspect I caused this
    some time back and apologize.

2.  Can someone verify this change and update CVS?  The simple test 
    I used was (m:ifft! (m:fft (m:ones 8 3))) and (m:ifft! (m:fft (m:ones 8 1)))

3.  The diff's are...

*** /home/mak/src/matlisp/src/fft.lisp	2003-02-24 17:30:21.000000000 -0500
--- /usr/local/src/matlisp/src/fft.lisp	2004-04-02 14:07:09.000000000 -0500
***************
*** 395,401 ****
      (if (row-or-col-vector-p x)
  	(progn
  	  (zfftb n (store x) wsave)
! 	  x)
  
        ;; IFFT by column
        (scal! (/ (float n 1d0))
--- 395,401 ----
      (if (row-or-col-vector-p x)
  	(progn
  	  (zfftb n (store x) wsave)
! 	  (scal! (/ (float n 1d0)) x))
  
        ;; IFFT by column
        (scal! (/ (float n 1d0))


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
tnx
mike

Re: [Matlisp-users] matlisp sbcl patch part 2

[Raymond T. <to...@rt...>]

>>>>> "simsek" == simsek  <si...@ee...> writes:

    simsek> Hi Ray,
    simsek> I've been exchanging email with Robbie, who did
    simsek> the sbcl port of matlisp.  I installed sbcl and
    simsek> compiled matlisp.  Sbcl gives 3 errors, but loads
    simsek> the files anyway.

    simsek> These are in the f2cl generated code.  Sbcl doesn't
    simsek> like declarations of this kind:

    simsek> (function (or double-float array-double-float) (values double-float))

    simsek> Robbie's analysis of the situation is below. The main question
    simsek> that I can't answer is: "is this a legit lisp type?"
    simsek> If it is, then note that neither allegro nor cmu have complained.

I think Robbie's analysis is correct.  I'll look into f2cl and fix it
there and generate new versions.  (f2cl has improved a little since
this was done.)

Ray

-- 
--

-- 
Ericsson may automatically add a disclaimer.  Sorry, it's beyond my
control.


 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

[Matlisp-users] Matlisp homepage

[<si...@EE...>]

Dear friends,

I'll update the Matlisp homepage in the coming weeks.
I would like to put a few lines about different places
people have found matlisp useful, and perhaps how, links.

If you would, please send me a few lines that you'd like
to appear on the homepage.

  --Thx! Tunc

Re: [Matlisp-users] matlisp sbcl patch part 2

[<si...@EE...>]

Hi Ray,

I've been exchanging email with Robbie, who did
the sbcl port of matlisp.  I installed sbcl and
compiled matlisp.  Sbcl gives 3 errors, but loads
the files anyway.

These are in the f2cl generated code.  Sbcl doesn't
like declarations of this kind:

(function (or double-float array-double-float) (values double-float))

Robbie's analysis of the situation is below. The main question
that I can't answer is: "is this a legit lisp type?"
If it is, then note that neither allegro nor cmu have complained.

  --Tunc

----- Original Message -----
From: Robbie Sedgewick <rd...@me...>
Date: Thursday, February 12, 2004 3:05 pm
Subject: Re: [Matlisp-users] matlisp sbcl patch part 2

> 
> I think I see the problem.  The example I gave you before didn't have
> the important part.  The types that sbcl doesn't like are all 
> something like
> (function (or double-float array-double-float) (values double-float))
> 
> which sbcl interprets as a function which take 3 arguments, the first
> of type 'or.  As the website you sent me says, by it self 'or is 
> not a
> valid type.
> 
> The declaration was probably supposed to be written as 
> (function ((or double-float array-double-float)) (values double-
> float))which only takes one argument.
> 
> FYI the only affected files are quadpack/dqc25f.lisp, 
> quadpack/dqawfe.lisp,and minpack/r1updt.lisp
> 
> 
> --Robbie
> 
> At Thu, 12 Feb 2004 14:46:55 -0800,
> Tunc Simsek wrote:
> > 
> > It seems legit:
> > 
> > 
> http://www.franz.com/support/documentation/6.2/ansicl/dictentr/or.htm> 
> > It doesn't mean that (or type-foo type-bar) is a useful
> > declaration though.
> > 
> > 
> > 
> > ----- Original Message -----
> > From: Robbie Sedgewick <rd...@me...>
> > Date: Thursday, February 12, 2004 2:18 pm
> > Subject: Re: [Matlisp-users] matlisp sbcl patch part 2
> > 
> > > 
> > > Yeah, sbcl can be very verbose.  I normally run sbcl in a 
> emacs so I
> > > can search back for the errors.
> > > 
> > > Anyway, assuming your three error are the same as the three 
> error I
> > > see, they are all errors about "The symbol OR is not valid as 
> a type
> > > specifier". They occur because at 3 places in the lisp code to 
> minpack> > and quadpack something is declared to have type '(or 
> type-foo
> > > type-bar).  I'm not sure if this is valid lisp or not, but sbcl
> > > doesn't like it.
> > > 
> > > I think that the files gets loaded fine, although I haven't 
> tested the
> > > minpack or the quadpack functionality.  I could patch these 
> files to
> > > fix this, but I don't know if you want to modify these files since
> > > they look automatically generated.
> > > 
> > > We could also probably just ignore them.  Your call.
> > > 
> > > --Robbie
> > > 
> > > 
> > > 
> > > At Thu, 12 Feb 2004 13:51:09 -0800,
> > > Tunc Simsek wrote:
> > > > 
> > > > 
> > > > Hi again.  I installed sbcl 0.8.7 on redhat x86.
> > > > Then I downloaded the matlisp.sbcl.tar file from your
> > > > homepage.  
> > > > 
> > > > 1. sbcl was built fine and passed the automated test
> > > > 2. when I built matlisp, it compiled everything
> > > >  but at the end reported that 3 errors was caught.
> > > >  Unfortunately, sbcl outputs so many messages (warnings, notes)
> > > >   that I can't scroll up the terminal to find what the
> > > >  error messages are.
> > > > 
> > > >  However, the basic matlisp functions seem to work fine.
> > > >  Like eigenvalue, svd and so forth, but I didn't try the
> > > >  complex numbers.  complex numbers is where the bugs usually
> > > >  show up.
> > > > 
> > > > Do you have anyway to find what those error messages were?
> > > > 
> > > > Tunc
> > > > 
> > > > ----- Original Message -----
> > > > From: Robert Sedgewick <rd...@me...>
> > > > Date: Wednesday, February 11, 2004 10:19 pm
> > > > Subject: Re: [Matlisp-users] matlisp sbcl patch part 2
> > > > 
> > > > > 
> > > > > On Feb 12, 2004, at 12:49 AM, si...@EE... wrote:
> > > > > 
> > > > > > Sorry for responding so late by the way.  I'm busy
> > > > > > with my dissertation and looking for a job at the same
> > > > > > time.
> > > > > 
> > > > > Yeah, no kidding, I bet you are swamped.  I had to go 
> through 
> > > that 
> > > > > stuff last year (UCSB physics).  Good luck.
> > > > > 
> > > > > > For someone who doesn't use matlisp you've done
> > > > > > a pretty thorough job with the port!  But give me
> > > > > > some time to go through the modifications to double
> > > > > > check, make sure you didn't miss anything.
> > > > > 
> > > > > Well, I hope to use it more in the future!
> > > > > 
> > > > > Also, I do use a hacked up version of the matlisp ffi to 
> > > interface 
> > > > > to 
> > > > > my c code in a monte carlo program that I work on.
> > > > > 
> > > > > 
> > > > > > So, to try this on sbcl, should I get sbcl from
> > > > > > sourceforge.  I think they have a single release
> > > > > > there.  I only have redhat linux on an x86, I wonder
> > > > > > whether this will make a difference.  Anyway, I'll keep
> > > > > > in touch.
> > > > > 
> > > > > That should work too.  I've tested matlisp with sbcl on 
> debian 
> > > > > linux 
> > > > > x86 and it worked fine.
> > > > > 
> > > > > I dunno why they don't have a rpm of a more recent 
> version, 
> > > but 
> > > > > 0.8.6 
> > > > > isn't all that old.
> > > > > 
> > > > > --Robbie
> > > > > 
> > > > > 
> > > > > >   --Tunc
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: Robbie Sedgewick <rd...@me...>
> > > > > > Date: Wednesday, February 11, 2004 2:44 pm
> > > > > > Subject: Re: [Matlisp-users] matlisp sbcl patch part 2
> > > > > >
> > > > > >>
> > > > > >> Hi Tunc,
> > > > > >>
> > > > > >> Thanks for emailing.  It will be nice to get this patch 
> > > into cvs.
> > > > > >>
> > > > > >> I made the port because (at the time) cmucl was not 
> > > available 
> > > > > for PPC.
> > > > > >> I tend to use sbcl on x86 as well so I can use the same 
> lisp> > > > >> implementation on both my computers.  I have a 
> couple 
> > > projects that
> > > > > >> are numerical in nature that I wanted to use lisp for 
> so I 
> > > > > wanted try
> > > > > >> to matlisp.  I actually haven't had the opportunity to 
> use 
> > > it 
> > > > > all that
> > > > > >> much yet, but I think that will change with my next 
> project.> > > > >>
> > > > > >> I doubt I broke any cmucl stuff.  Most of the changes 
> were 
> > > just 
> > > > > adding>> #+sbcl parts to the existing #+cmu and #+acl.  
> I've 
> > > tried 
> > > > > my changes
> > > > > >> with cmucl (x86 only) and it seemed to work fine, 
> although 
> > > I didn't
> > > > > >> torture test it.  cmucl/ppc is probably still a little 
> too 
> > > > > buggy to
> > > > > >> expect it to work....
> > > > > >>
> > > > > >> You do have the new verison of the patch right?  The 
> one 
> > > that 
> > > > > got sent
> > > > > >> out on the mailing list got corrupted by the sf.net 
> mail server
> > > > > >> because it was too long.  I think the new one was made 
> around> > > > >> 12/15/03.  Also the ffi-sbcl.lisp file on the 
> list got 
> > > truncated.> > >> There are good versions of the patch, the ffi-
> > > sbcl.lisp file 
> > > > > and a
> > > > > >> good tarball at http://mercury.chem.pitt.edu/~rds/
> > > > > >>
> > > > > >> Thanks,
> > > > > >>
> > > > > >> Later,
> > > > > >> Robbie
> > > > > >>
> > > > > >> At Wed, 11 Feb 2004 11:28:57 -0800,
> > > > > >> Tunc Simsek wrote:
> > > > > >>>
> > > > > >>> Hi Robbie,
> > > > > >>>
> > > > > >>> I just got a chance to look at your patches.  It looks 
> really> > > > >> really
> > > > > >>> good.  I have a few questions though.  First, what 
> > > motivated you
> > > > > >> to port
> > > > > >>> matlisp to sbcl?  Second, you've made modifications to 
> > > lots of
> > > > > >> files.> Especially places where complex double-float 
> > > appears.  Did
> > > > > >> you test
> > > > > >>> your changes on cmucl after making them?
> > > > > >>>
> > > > > >>> I will soon try to download and install sbcl and apply 
> > > your 
> > > > > patches.>>> I'll let you know if i need help.
> > > > > >>>
> > > > > >>> Thx again, Tunc
> > > > > >>>
> > > > > >>
> > > > > >
> > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

RE: [Matlisp-users] Matlisp on ACLv6 works here :)

[Ernst v. W. <ev...@in...>]

Well, I didn't go through all the library to find functions for Fourier
transforms -- currently I don't need it.  But a version in Lisp sounds even
better!

BTW, Matlisp2beta feels more stable with ACL6 than Matlisp1.0b with ACL5.

Ernst

   "My understanding it that you will not because the library for Fourier
   "transforms is not supplied on Windows.  Having said that, I do have a
   "simple version in Lisp, so if you need it, I can provide one.  Only
   "supports powers of two, and only complex data, so if it's something
   "else, you might have to do that yourself.
   "
   "Ray

Re: [Matlisp-users] Matlisp on ACLv6 works here :)

[Raymond T. <to...@rt...>]

>>>>> "Ernst" == Ernst van Waning <ev...@in...> writes:

    Ernst> Whenever I need discrete Fourier transforms and succeed to call it form
    Ernst> Lisp, I will inform you.

My understanding it that you will not because the library for Fourier
transforms is not supplied on Windows.  Having said that, I do have a
simple version in Lisp, so if you need it, I can provide one.  Only
supports powers of two, and only complex data, so if it's something
else, you might have to do that yourself.

Ray

-- 
-- 
Ericsson may automatically add a disclaimer.  Sorry, it's beyond my
control.




This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

RE: RE: [Matlisp-users] Matlisp on ACLv6 works here :)

[Ernst v. W. <ev...@in...>]

Hello,

   "Good.  You're not the first user, but there
   "are not too many windows developers using Matlisp.
OK -- had no real choice there :-)
   "
   "I'd be happy to get feedback from you as you encounter
   "problems.  Keep in mind, especially, that some
   "functions will not be available on windows, for
   "example, discrete fourier transforms and some
   "special purpose functions.
Whenever I need discrete Fourier transforms and succeed to call it form
Lisp, I will inform you.

   "
   "What are you doing that so heavily relies on SVD?
Finding orthogonal coordinate systems for non-symmetric, possibly
rectangular matrices derived from data to facilitate application of
geometric algorithms.  I would like to try these algorithms for very large
datasets to join or separate subsets of data and to find patterns on data.
A sort of data mining, if you like, but using classical multivariate
statistics combined with analysis by algorithm.  Some years ago I found out
that this can be done surprisingly well (to get into the algorithmic aspect
I downloaded Matlisp in ACL5), but due to circumstances beyond me I return
to that subject only now.  It is a sort of rainy weekend project, but it
rains a lot here.
Before coming to the decompositions, however, quite a bit of code must be
written that doesn't use Matlisp -- it will be straightforward (I hope)
Lisp.

Of course, there SAS, SPSS, S+ and friends, but these do not have the
functionality that I am looking for.

Kind regards,

Ernst

Re: [Matlisp-users] Matlisp on ACLv6 works here :)

[<si...@EE...>]

Exactly.  I don't have a windows fortran compiler
either.  If I had one I could compile them.

Tunc

----- Original Message -----
From: Raymond Toy <to...@rt...>
Date: Tuesday, February 3, 2004 3:04 pm
Subject: Re: [Matlisp-users] Matlisp on ACLv6 works here :)

> >>>>> "Tunc" == simsek  <si...@ee...> writes:
> 
>    Tunc> Good.  You're not the first user, but there
>    Tunc> are not too many windows developers using Matlisp.
> 
>    Tunc> I'd be happy to get feedback from you as you encounter
>    Tunc> problems.  Keep in mind, especially, that some 
>    Tunc> functions will not be available on windows, for 
>    Tunc> example, discrete fourier transforms and some
>    Tunc> special purpose functions.
> 
> Is that because the windows version doesn't have the FFT libraries
> supplied, unlike BLAS and LAPACK?  Would be nice to be able to supply
> that.  (But I can't, since I don't have a Fortran compiler on windows,
> and rarely use windows for this, anyway.)
> 
> Ray
> 
> 
> 
> This communication is confidential and intended solely for the 
> addressee(s). Any unauthorized review, use, disclosure or 
> distribution is prohibited. If you believe this message has been 
> sent to you in error, please notify the sender by replying to this 
> transmission and delete the message without disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data corruption, 
> interruption, unauthorized amendment, tampering and viruses, and 
> we only send and receive e-mails on the basis that we are not 
> liable for any such corruption, interception, amendment, tampering 
> or viruses or any consequences thereof.
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
> 

Re: [Matlisp-users] Matlisp on ACLv6 works here :)

[Raymond T. <to...@rt...>]

>>>>> "Tunc" == simsek  <si...@ee...> writes:

    Tunc> Good.  You're not the first user, but there
    Tunc> are not too many windows developers using Matlisp.

    Tunc> I'd be happy to get feedback from you as you encounter
    Tunc> problems.  Keep in mind, especially, that some 
    Tunc> functions will not be available on windows, for 
    Tunc> example, discrete fourier transforms and some
    Tunc> special purpose functions.

Is that because the windows version doesn't have the FFT libraries
supplied, unlike BLAS and LAPACK?  Would be nice to be able to supply
that.  (But I can't, since I don't have a Fortran compiler on windows,
and rarely use windows for this, anyway.)

Ray



This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

Re: RE: [Matlisp-users] Matlisp on ACLv6 works here :)

[<si...@EE...>]

Good.  You're not the first user, but there
are not too many windows developers using Matlisp.

I'd be happy to get feedback from you as you encounter
problems.  Keep in mind, especially, that some 
functions will not be available on windows, for 
example, discrete fourier transforms and some
special purpose functions.

What are you doing that so heavily relies on SVD?

Tunc


----- Original Message -----
From: Ernst van Waning <ev...@in...>
Date: Tuesday, February 3, 2004 1:59 pm
Subject: RE: [Matlisp-users] Matlisp on ACLv6 works here :)

> Hello!
> 
> Found what was wrong -- pretty trivial: (user::current-directory) was
> correct, but *default-pathname-defaults* was pointing one 
> directory higher.
> After setting *default-pathname-defaults* to (user::current-directory)
> Matlisp (the version Tunc referred to in the message quoted below) 
> compiledand loaded, seemingly as expected.
> 
> Is it true that I am one of the first Matlisp-users on windows?  
> In that
> case I will be glad to send you a transcript of the compilation.  
> There are
> lots of messages that may be more meaningful to you than they are 
> currentlyto me :)
> 
> Tried some things (multiplication and SVD), which appeared to work as
> expected.  So, my problem is over.
> 
> OTOH, I understand it is a lot of work to make Matlisp and keep it 
> working,so if you need a bit of help from my side, just say so & 
> I'll see what I can
> do.  I plan to make a system that uses large non-sparse matrices, 
> whichrelies heavily on the SVD.
> 
> Again, I hope to hear from you soon.
> 
> Kind regards,
> 
> Ernst
> 
> PS  Totally off-topic, but very curious where the name Tunc Simsek
> originates from:)
> 
>   "-----Original Message-----
>   "From: mat...@li...
>   "[mat...@li...]On Behalf Of
>   "si...@EE...
>   "Sent: 02 February 2004 23:28
>   "To: Raymond Toy
>   "Cc: ev...@in...; Matlisp Users
>   "Subject: Re: [Matlisp-users] Matlisp and ACLv6
>   "
>   "
>   "Hi again.
>   "
>   "Two point here.
>   "
>   "First, Ernst,  I insist that you infact not loading
>   "the distribution from the link I sent you.
>   "I just checked and f77-mangling.lisp exists in
>   "the right place.  I think you're trying to load
>   "the distribution you got from matlisp.sourceforge.net.
>   "My suspicions were first arised when I say matlisp-1.0b
>   "in the command line in your dribble.
>   "Please try just one more time.  Make sure to get
>   "the zip file from
>   "
>   "http://robotics.eecs.berkeley.edu/~simsek/matlisp-allegro-v6.2.zip
>   "
>   "Then unzip it to say c:/  (this will create a directory
>   "called c:/matlisp).  Then, from within allegro, do:
>   "
>   ":cd c:/matlisp
>   ":ld start
>   "
>   "
>   "The second point.  Ray.  You're right.  On unix you
>   "need to run configure.  To avoid that, I manually configured
>   "for windows and produced the f77-mangling.lisp from the
>   "f77-mangling.lisp.in
>   "file.  It exists in the link I gave above.
>   "
>   "Thanks again,
>   "Tunc
>   "
>   "
>   "----- Original Message -----
>   "From: Raymond Toy <to...@rt...>
>   "Date: Monday, February 2, 2004 2:01 pm
>   "Subject: Re: [Matlisp-users] Matlisp and ACLv6
>   "
>   "> >>>>> "Ernst" == Ernst van Waning <ev...@in...> writes:
>   ">
>   ">    Ernst> Yes, ok, let me be patient :)
>   ">    Ernst> I have tried to install from Tunc's URL again and 
> below   "> you will find what
>   ">    Ernst> my ACL62 wrote.  Apparently some fasl files are
>   "> missing.  In fact, bin as
>   ">    Ernst> downloaded only has one lisp source and one file 
> called   "> copyright and
>   ">    Ernst> another called f77-mangling.lisp.in.  The file 
> src\f77-
>   "> mangling.lisp is
>   ">    Ernst> present in bin.  So, I am a bit puzzled.
>   ">
>   ">    Ernst> In case you want to look into it, I have attached a
>   "> dribble-bug, so you know
>   ">    Ernst> my configuration.
>   ">
>   "> Did you run configure?  If you don't, f77-mangling.lisp 
> won't exist;
>   "> configure creates it.  I guess this makes it somewhat 
> difficult to run
>   "> on Windows if you don't have cygwin installed.
>   ">
>   "> But I've never tried building on Windows, so there might be 
> some other
>   "> way of doing it.
>   ">
>   "> Ray
>   ">
>   "> P.S.  Please reply to all so the discussion gets archived to the
>   "> matlisp-users mailing list.
>   ">
>   ">
>   "> Ericsson automatically adds the following disclaimer.  I 
> didn't do it.
>   ">    "
>   ">
>   ">
>   ">
>   "> This communication is confidential and intended solely for the
>   "> addressee(s). Any unauthorized review, use, disclosure or
>   "> distribution is prohibited. If you believe this message has been
>   "> sent to you in error, please notify the sender by replying 
> to this
>   "> transmission and delete the message without disclosing it. 
> Thank you.
>   ">
>   "> E-mail including attachments is susceptible to data corruption,
>   "> interruption, unauthorized amendment, tampering and viruses, and
>   "> we only send and receive e-mails on the basis that we are not
>   "> liable for any such corruption, interception, amendment, 
> tampering   "> or viruses or any consequences thereof.
>   ">
>   ">
>   "> -------------------------------------------------------
>   "> The SF.Net email is sponsored by EclipseCon 2004
>   "> Premiere Conference on Open Tools Development and Integration
>   "> See the breadth of Eclipse activity. February 3-5 in 
> Anaheim, CA.
>   "> http://www.eclipsecon.org/osdn
>   "> _______________________________________________
>   "> Matlisp-users mailing list
>   "> Mat...@li...
>   "> https://lists.sourceforge.net/lists/listinfo/matlisp-users
>   ">
>   "
>   "
>   "
>   "-------------------------------------------------------
>   "The SF.Net email is sponsored by EclipseCon 2004
>   "Premiere Conference on Open Tools Development and Integration
>   "See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>   "http://www.eclipsecon.org/osdn
>   "_______________________________________________
>   "Matlisp-users mailing list
>   "Mat...@li...
>   "https://lists.sourceforge.net/lists/listinfo/matlisp-users
>   "
>   "
> 
> 

RE: [Matlisp-users] Matlisp on ACLv6 works here :)

[Ernst v. W. <ev...@in...>]

Hello!

Found what was wrong -- pretty trivial: (user::current-directory) was
correct, but *default-pathname-defaults* was pointing one directory higher.
After setting *default-pathname-defaults* to (user::current-directory)
Matlisp (the version Tunc referred to in the message quoted below) compiled
and loaded, seemingly as expected.

Is it true that I am one of the first Matlisp-users on windows?  In that
case I will be glad to send you a transcript of the compilation.  There are
lots of messages that may be more meaningful to you than they are currently
to me :)

Tried some things (multiplication and SVD), which appeared to work as
expected.  So, my problem is over.

OTOH, I understand it is a lot of work to make Matlisp and keep it working,
so if you need a bit of help from my side, just say so & I'll see what I can
do.  I plan to make a system that uses large non-sparse matrices, which
relies heavily on the SVD.

Again, I hope to hear from you soon.

Kind regards,

Ernst

PS  Totally off-topic, but very curious where the name Tunc Simsek
originates from:)

   "-----Original Message-----
   "From: mat...@li...
   "[mailto:mat...@li...]On Behalf Of
   "si...@EE...
   "Sent: 02 February 2004 23:28
   "To: Raymond Toy
   "Cc: ev...@in...; Matlisp Users
   "Subject: Re: [Matlisp-users] Matlisp and ACLv6
   "
   "
   "Hi again.
   "
   "Two point here.
   "
   "First, Ernst,  I insist that you infact not loading
   "the distribution from the link I sent you.
   "I just checked and f77-mangling.lisp exists in
   "the right place.  I think you're trying to load
   "the distribution you got from matlisp.sourceforge.net.
   "My suspicions were first arised when I say matlisp-1.0b
   "in the command line in your dribble.
   "Please try just one more time.  Make sure to get
   "the zip file from
   "
   "http://robotics.eecs.berkeley.edu/~simsek/matlisp-allegro-v6.2.zip
   "
   "Then unzip it to say c:/  (this will create a directory
   "called c:/matlisp).  Then, from within allegro, do:
   "
   ":cd c:/matlisp
   ":ld start
   "
   "
   "The second point.  Ray.  You're right.  On unix you
   "need to run configure.  To avoid that, I manually configured
   "for windows and produced the f77-mangling.lisp from the
   "f77-mangling.lisp.in
   "file.  It exists in the link I gave above.
   "
   "Thanks again,
   "Tunc
   "
   "
   "----- Original Message -----
   "From: Raymond Toy <to...@rt...>
   "Date: Monday, February 2, 2004 2:01 pm
   "Subject: Re: [Matlisp-users] Matlisp and ACLv6
   "
   "> >>>>> "Ernst" == Ernst van Waning <ev...@in...> writes:
   ">
   ">    Ernst> Yes, ok, let me be patient :)
   ">    Ernst> I have tried to install from Tunc's URL again and below
   "> you will find what
   ">    Ernst> my ACL62 wrote.  Apparently some fasl files are
   "> missing.  In fact, bin as
   ">    Ernst> downloaded only has one lisp source and one file called
   "> copyright and
   ">    Ernst> another called f77-mangling.lisp.in.  The file src\f77-
   "> mangling.lisp is
   ">    Ernst> present in bin.  So, I am a bit puzzled.
   ">
   ">    Ernst> In case you want to look into it, I have attached a
   "> dribble-bug, so you know
   ">    Ernst> my configuration.
   ">
   "> Did you run configure?  If you don't, f77-mangling.lisp won't exist;
   "> configure creates it.  I guess this makes it somewhat difficult to run
   "> on Windows if you don't have cygwin installed.
   ">
   "> But I've never tried building on Windows, so there might be some other
   "> way of doing it.
   ">
   "> Ray
   ">
   "> P.S.  Please reply to all so the discussion gets archived to the
   "> matlisp-users mailing list.
   ">
   ">
   "> Ericsson automatically adds the following disclaimer.  I didn't do it.
   ">    "
   ">
   ">
   ">
   "> This communication is confidential and intended solely for the
   "> addressee(s). Any unauthorized review, use, disclosure or
   "> distribution is prohibited. If you believe this message has been
   "> sent to you in error, please notify the sender by replying to this
   "> transmission and delete the message without disclosing it. Thank you.
   ">
   "> E-mail including attachments is susceptible to data corruption,
   "> interruption, unauthorized amendment, tampering and viruses, and
   "> we only send and receive e-mails on the basis that we are not
   "> liable for any such corruption, interception, amendment, tampering
   "> or viruses or any consequences thereof.
   ">
   ">
   "> -------------------------------------------------------
   "> The SF.Net email is sponsored by EclipseCon 2004
   "> Premiere Conference on Open Tools Development and Integration
   "> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
   "> http://www.eclipsecon.org/osdn
   "> _______________________________________________
   "> Matlisp-users mailing list
   "> Mat...@li...
   "> https://lists.sourceforge.net/lists/listinfo/matlisp-users
   ">
   "
   "
   "
   "-------------------------------------------------------
   "The SF.Net email is sponsored by EclipseCon 2004
   "Premiere Conference on Open Tools Development and Integration
   "See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
   "http://www.eclipsecon.org/osdn
   "_______________________________________________
   "Matlisp-users mailing list
   "Mat...@li...
   "https://lists.sourceforge.net/lists/listinfo/matlisp-users
   "
   "

Re: [Matlisp-users] Matlisp and ACLv6

[<si...@EE...>]

Yes.  Also lib/lazy-loader.lisp is created by hand.
And there is a precompiled version of the foreign
libraries called clawrap-win.

Tunc

----- Original Message -----
From: Raymond Toy <to...@rt...>
Date: Monday, February 2, 2004 2:50 pm
Subject: Re: [Matlisp-users] Matlisp and ACLv6

> >>>>> "Tunc" == simsek  <si...@ee...> writes:
> 
>    Tunc> The second point.  Ray.  You're right.  On unix you 
>    Tunc> need to run configure.  To avoid that, I manually configured
>    Tunc> for windows and produced the f77-mangling.lisp from the 
> f77-mangling.lisp.in
>    Tunc> file.  It exists in the link I gave above.
> 
> Thanks for setting me straight.  So to build on windows, you basically
> just need to create f77-mangling.lisp and lazy-loader.lisp by hand?
> 
> Ray
> 
> 
> 
> This communication is confidential and intended solely for the 
> addressee(s). Any unauthorized review, use, disclosure or 
> distribution is prohibited. If you believe this message has been 
> sent to you in error, please notify the sender by replying to this 
> transmission and delete the message without disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data corruption, 
> interruption, unauthorized amendment, tampering and viruses, and 
> we only send and receive e-mails on the basis that we are not 
> liable for any such corruption, interception, amendment, tampering 
> or viruses or any consequences thereof.
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
> 

Re: [Matlisp-users] Matlisp and ACLv6

[Raymond T. <to...@rt...>]

>>>>> "Tunc" == simsek  <si...@ee...> writes:

    Tunc> The second point.  Ray.  You're right.  On unix you 
    Tunc> need to run configure.  To avoid that, I manually configured
    Tunc> for windows and produced the f77-mangling.lisp from the f77-mangling.lisp.in
    Tunc> file.  It exists in the link I gave above.

Thanks for setting me straight.  So to build on windows, you basically
just need to create f77-mangling.lisp and lazy-loader.lisp by hand?

Ray



This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

Re: [Matlisp-users] Matlisp and ACLv6

[<si...@EE...>]

Hi again.

Two point here. 

First, Ernst,  I insist that you infact not loading
the distribution from the link I sent you.
I just checked and f77-mangling.lisp exists in
the right place.  I think you're trying to load
the distribution you got from matlisp.sourceforge.net.
My suspicions were first arised when I say matlisp-1.0b
in the command line in your dribble.
Please try just one more time.  Make sure to get
the zip file from 

http://robotics.eecs.berkeley.edu/~simsek/matlisp-allegro-v6.2.zip

Then unzip it to say c:/  (this will create a directory 
called c:/matlisp).  Then, from within allegro, do:

:cd c:/matlisp
:ld start


The second point.  Ray.  You're right.  On unix you 
need to run configure.  To avoid that, I manually configured
for windows and produced the f77-mangling.lisp from the f77-mangling.lisp.in
file.  It exists in the link I gave above.

Thanks again,
Tunc


----- Original Message -----
From: Raymond Toy <to...@rt...>
Date: Monday, February 2, 2004 2:01 pm
Subject: Re: [Matlisp-users] Matlisp and ACLv6

> >>>>> "Ernst" == Ernst van Waning <ev...@in...> writes:
> 
>    Ernst> Yes, ok, let me be patient :)
>    Ernst> I have tried to install from Tunc's URL again and below 
> you will find what
>    Ernst> my ACL62 wrote.  Apparently some fasl files are 
> missing.  In fact, bin as
>    Ernst> downloaded only has one lisp source and one file called 
> copyright and
>    Ernst> another called f77-mangling.lisp.in.  The file src\f77-
> mangling.lisp is
>    Ernst> present in bin.  So, I am a bit puzzled.
> 
>    Ernst> In case you want to look into it, I have attached a 
> dribble-bug, so you know
>    Ernst> my configuration.
> 
> Did you run configure?  If you don't, f77-mangling.lisp won't exist;
> configure creates it.  I guess this makes it somewhat difficult to run
> on Windows if you don't have cygwin installed.
> 
> But I've never tried building on Windows, so there might be some other
> way of doing it.
> 
> Ray
> 
> P.S.  Please reply to all so the discussion gets archived to the
> matlisp-users mailing list.
> 
> 
> Ericsson automatically adds the following disclaimer.  I didn't do it.
> 
> 
> 
> 
> This communication is confidential and intended solely for the 
> addressee(s). Any unauthorized review, use, disclosure or 
> distribution is prohibited. If you believe this message has been 
> sent to you in error, please notify the sender by replying to this 
> transmission and delete the message without disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data corruption, 
> interruption, unauthorized amendment, tampering and viruses, and 
> we only send and receive e-mails on the basis that we are not 
> liable for any such corruption, interception, amendment, tampering 
> or viruses or any consequences thereof.
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
>  

Re: [Matlisp-users] Matlisp and ACLv6

[Raymond T. <to...@rt...>]

>>>>> "Ernst" == Ernst van Waning <ev...@in...> writes:

    Ernst> Yes, ok, let me be patient :)
    Ernst> I have tried to install from Tunc's URL again and below you will find what
    Ernst> my ACL62 wrote.  Apparently some fasl files are missing.  In fact, bin as
    Ernst> downloaded only has one lisp source and one file called copyright and
    Ernst> another called f77-mangling.lisp.in.  The file src\f77-mangling.lisp is
    Ernst> present in bin.  So, I am a bit puzzled.

    Ernst> In case you want to look into it, I have attached a dribble-bug, so you know
    Ernst> my configuration.

Did you run configure?  If you don't, f77-mangling.lisp won't exist;
configure creates it.  I guess this makes it somewhat difficult to run
on Windows if you don't have cygwin installed.

But I've never tried building on Windows, so there might be some other
way of doing it.

Ray

P.S.  Please reply to all so the discussion gets archived to the
matlisp-users mailing list.


Ericsson automatically adds the following disclaimer.  I didn't do it.




This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

[Matlisp-users] Lists available on gmane.

[Raymond T. <to...@rt...>]

Gentlepeople,

In case you haven't noticed, the matlisp lists are now available on
gmane (http://gmane.org).

See the groups gmane.lisp.matlisp.devel and gmane.lisp.matlisp.users
on news.gmane.org.

All archived messages have been incorporated as well.

Many thanks to gmane for providing this service,

Ray



This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

Re: [Matlisp-users] Matlisp and ACLv6

[Raymond T. <to...@rt...>]

>>>>> "Ernst" == Ernst van Waning <ev...@in...> writes:

    Ernst> Hello Raymond,
    Ernst> thanks for your offer.  Tunc Simsek sent me a URL, I installed the software,
    Ernst> unpacked it, but when loading it into ACLv62, it went astray very quickly.
    Ernst> Where is the snapshot you refer to?  BTW, what do you mean by a snapshot :)

Look at http://sourceforge.net/project/showfiles.php?group_id=4511

You'll find a 2.0 beta from 2003-10-14.

If you still have problems, I'll look into it when I get a chance.
I'm pretty sure this worked, but perhaps something has been broken
since then.

Ray



This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

Re: [Matlisp-users] Matlisp and ACLv6

[Raymond T. <to...@rt...>]

>>>>> "Ernst" == Ernst van Waning <ev...@in...> writes:

    Ernst> ACLv501 cannot fins translation rule for #p"matlisp:;code;packages.fasl"
    Ernst> either, so it may be best to ask someone with more matlisp knowledge than I
    Ernst> have.  I have looked and found Matlisp-1.0b to be the newest version, so I
    Ernst> don't think a new download will do the trick.

There is a snapshot which contains a more recent version.  Can you try
this please?

If that doesn't work, please let us know.  I'll look into it.  The
snapshot did work with ACL6.2 when I tried it a year ago or so.

Ray