matlisp-users — General discussion list.

Re: [Matlisp-users] (SETF (MATRIX-REF ...) ... ) problem?

[Raymond T. <ray...@er...>]

>>>>> "Michael" == Michael A Koerber <ma...@ll...> writes:

    Michael> When using MATRIX-REF to set sub-matrixes of type COMPLEX-MATRIX  from
    Michael> type COMPLEX-MATRIX I get an error.

Found the bug and checked in the fix.  You can probably just get the
new ref.lisp, if you don't want a new cvs version.

Sorry about that!

Ray

Re: [Matlisp-users] (SETF (MATRIX-REF ...) ... ) problem?

[Raymond T. <ray...@er...>]

>>>>> "Michael" == Michael A Koerber <ma...@ll...> writes:

    Michael> The following code segment shows this.  I'm using
    Michael> matlisp-2.0beta-2003-10-14.tar.gz under FreeBSD 4.9.
    Michael> I suspect the problem is in REF.LISP but haven't tracked it down.  Can
    Michael> anyone help?

What error do you get?  When I try this, I get

* (setf (m:matrix-ref *c* (m:seq 0 4) 0) (m:matrix-ref *d* (m:seq 0 4) 0))

No matching method for the generic function
#<STANDARD-GENERIC-FUNCTION MATLISP:NUMBER-OF-ELEMENTS (1) {400FDCC9}>, when
called with arguments (0).
   [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR]

I think when I refactored set-complex-from-complex-matrix-slice, I
messed up.  I'll look into it.

Ray

[Matlisp-users] (SETF (MATRIX-REF ...) ... ) problem?

[Michael A. K. <ma...@ll...>]

When using MATRIX-REF to set sub-matrixes of type COMPLEX-MATRIX  from 
type COMPLEX-MATRIX I get an error.

Type REAL-MATRIX from REAL-MATRIX is okay.

Type COMPLEX-MATRIX from REAL-MATRIX is okay.

The following code segment shows this.  I'm using 
matlisp-2.0beta-2003-10-14.tar.gz under FreeBSD 4.9.
I suspect the problem is in REF.LISP but haven't tracked it down.  Can 
anyone help?

tnx

mike

(setf *a* (m:zeros 5 2)
       *b* (m:ones  5 2)
       *c* (m:make-complex-matrix 5 2)
       *d* (m:m+ *b* (m:m* (sqrt -1) *b*)))

;; With reals all is well
(m:matrix-ref *a* (m:seq 0 4) 0)
(setf (m:matrix-ref *a* (m:seq 0 4) 0) (m:matrix-ref *b* (m:seq 0 4) 0))

;; With complex set from real all is well
(setf (m:matrix-ref *c* (m:seq 0 4) 1) (m:matrix-ref *b* (m:seq 0 4) 0))

;; With complex set from complex ... error
(m:matrix-ref *c* (m:seq 0 4) 0)
(setf (m:matrix-ref *c* (m:seq 0 4) 0) (m:matrix-ref *d* (m:seq 0 4) 0))

Re: [Matlisp-users] Re: what is #+nil good for?

[Raymond T. <ray...@er...>]

>>>>> "Sam" == Sam Steingold <sd...@gn...> writes:

    >> * Raymond Toy <enl...@re...> [2004-11-22 17:44:23 -0500]:
    >> Since I can never remember if it should be (or) or (and),

    Sam> just hit C-e (or C-j) after the closing paren:
    Sam> (or)
    Sam> nil
    Sam> (and)
    Sam> t

Actually, with slime's reader-conditional highlighting, I don't even
have to do that.  It will be highlighted a certain way if the
conditional doesn't hold.  Of course, this only works if the
conditional is applicable to the lisp that is being run; sometimes,
that's not true.

Ray

[Matlisp-users] Re: what is #+nil good for?

[Sam S. <sd...@gn...>]

> * Raymond Toy <enl...@re...> [2004-11-22 17:44:23 -0500]:
>
> Someone randomly adding stuff to *features* deserves what he gets. :-)

he does, yes.
and you also deserve getting his (misdirected!) wrath too. :-)

>     Sam> plain and simply, "#+nil" is a source code bug
>     Sam> (unless you _do_ support the New Implementation of Lisp).
>
> Since I can never remember if it should be (or) or (and),

just hit C-e (or C-j) after the closing paren:
(or)
nil
(and)
t



-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Only a fool has no doubts.

Re: [Matlisp-users] Re: what is #+nil good for?

[Raymond T. <ray...@er...>]

>>>>> "Sam" == Sam Steingold <sd...@gn...> writes:

    Sam> with all due respect to everyone involved, we all sometimes write lousy
    Sam> code (at least _I_ do, and that makes me think that others sometimes
    Sam> might too), so the fact that Dan Barlow does it, does not prove that the
    Sam> trick is valid.

    >> #+nil (error "The author of this file habitually uses #+nil to comment out
    >> forms.  But don't worry, it was unlikely to work in the New Implementation
    >> of Lisp anyway")

    Sam> if your user uses this #+nil trick and then adds NIL to
    Sam> *features* just to enable some code, you will have a lot of fun
    Sam> explaining to him why matlisp is suddenly broken.

Someone randomly adding stuff to *features* deserves what he gets. :-)

    Sam> plain and simply, "#+nil" is a source code bug
    Sam> (unless you _do_ support the New Implementation of Lisp).

Since I can never remember if it should be (or) or (and), the
probablility of me getting it wrong is much higher then if I use
#+nil.  (Although when I do remember, I do try to use (or) or (and) as
appropriate.) 

Besides, maybe nil means Not-Implemented-Locally?  Or was that
Now-Implemented-Locally?  :-)

Ray

[Matlisp-users] Re: what is #+nil good for?

[Sam S. <sd...@gn...>]

> * Nicolas Neuss <Avp...@vj...> [2004-11-22 19:28:39 +0100]:
>
> Sam Steingold <sd...@gn...> writes:
>
>>> * Marco Antoniotti <zn...@pf...> [2004-11-22 12:16:18 -0500]:
>>>
>>> This is just a conventional way of doing what you'd do in C/C++ with
>>>
>>> #if 0
>>> blah blah bla
>>> #endif

note that it's
     #if 0
not
     #ifdef DISABLED
because it is possible someone will process the file with "gcc -DDISABLED"

>>> Do not add NIL to the features.  When you see #+nil it usually means
>>> that the code is dead and left around for documentation (grin) purposes.
>>
>> "#+nil" is broken by design.
>> use "#+(or)" instead.
>
> Sadly, it is one character more to type...

no, in Emacs, Shift-9 inserts both the opening and the closing paren.
(so, yes, you do have to hit an extra button, and to consume an extra
8 bits of your preciously scarce disk space, but that is not a big price
to pay for correctness.)

> Citing Dan Barlow from asdf.lisp:

with all due respect to everyone involved, we all sometimes write lousy
code (at least _I_ do, and that makes me think that others sometimes
might too), so the fact that Dan Barlow does it, does not prove that the
trick is valid.

> #+nil (error "The author of this file habitually uses #+nil to comment out
> forms.  But don't worry, it was unlikely to work in the New Implementation
> of Lisp anyway")

if your user uses this #+nil trick and then adds NIL to
*features* just to enable some code, you will have a lot of fun
explaining to him why matlisp is suddenly broken.

plain and simply, "#+nil" is a source code bug
(unless you _do_ support the New Implementation of Lisp).

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
If abortion is murder, then oral sex is cannibalism.

Re: [Matlisp-users] Re: what is #+nil good for?

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

Sam Steingold <sd...@gn...> writes:

>> * Marco Antoniotti <zn...@pf...> [2004-11-22 12:16:18 -0500]:
>>
>> This is just a conventional way of doing what you'd do in C/C++ with
>>
>> #if 0
>> blah blah bla
>> #endif
>>
>> Do not add NIL to the features.  When you see #+nil it usually means
>> that the code is dead and left around for documentation (grin) purposes.
>
> "#+nil" is broken by design.
> use "#+(or)" instead.

Sadly, it is one character more to type...

Citing Dan Barlow from asdf.lisp:

#+nil (error "The author of this file habitually uses #+nil to comment out
forms.  But don't worry, it was unlikely to work in the New Implementation
of Lisp anyway")

Nicolas:-)

[Matlisp-users] Re: what is #+nil good for?

[Sam S. <sd...@gn...>]

> * Marco Antoniotti <zn...@pf...> [2004-11-22 12:16:18 -0500]:
>
> This is just a conventional way of doing what you'd do in C/C++ with
>
> #if 0
> blah blah bla
> #endif
>
> Do not add NIL to the features.  When you see #+nil it usually means
> that the code is dead and left around for documentation (grin) purposes.

"#+nil" is broken by design.
use "#+(or)" instead.


-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
What garlic is to food, insanity is to art.

Re: [Matlisp-users] what is #+nil good for?

[Marco A. <ma...@cs...>]

This is just a conventional way of doing what you'd do in C/C++ with

#if 0
blah blah bla
#endif

Do not add NIL to the features.  When you see #+nil it usually means 
that the code is dead and left around for documentation (grin) 
purposes.

Cheers

Marco





On Nov 22, 2004, at 11:44 AM, Rolf Wester wrote:

> Hi,
>
> I have installed Matlisp (great work) and looked a little bit into the 
> sources.
> I found many instances of "#+nil ..." and wonder what this is good 
> for. Is it possible
> to configure the build process by adding :nil to *features*?
>
> Regards
>
> Rolf Wester
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
>
--
Marco Antoniotti					http://bioinformatics.nyu.edu
NYU Courant Bioinformatics Group		tel. +1 - 212 - 998 3488
715 Broadway 10th FL				fax. +1 - 212 - 998 3484
New York, NY, 10003, U.S.A.

[Matlisp-users] what is #+nil good for?

[Rolf W. <rol...@il...>]

Hi,

I have installed Matlisp (great work) and looked a little bit into the 
sources.
I found many instances of "#+nil ..." and wonder what this is good for. 
Is it possible
to configure the build process by adding :nil to *features*?

Regards

Rolf Wester

Re: [Matlisp-users] Compiling Matlisp for freeBSD

[Raymond T. <ray...@er...>]

>>>>> "Michael" == Michael A Koerber <ma...@ll...> writes:

    Michael> I'm in the process of migrating from Linux to FreeBSD...I've poked
    Michael> around a bit, but haven't been able to find out how to compile Matlisp

Out of curiosity, why move from Linux to FreeBSD?

    Michael> under FreeBSD (4.10).  Does someone have a pointer to this?

As long as you have a C compiler, a Fortran compiler, and a supported
Lisp, I don't see this being a major problem.  Are you running into
problems?

Ray

[Matlisp-users] Compiling Matlisp for freeBSD

[Michael A. K. <ma...@ll...>]

I'm in the process of migrating from Linux to FreeBSD...I've poked around a 
bit, but haven't been able to find out how to compile Matlisp under FreeBSD 
(4.10).  Does someone have a pointer to this?

tnx

mike

Re: [Matlisp-users] fix for darwin/sbcl matlisp build

[Robert S. <rd...@me...>]

On Jun 15, 2004, at 5:09 PM, Raymond Toy wrote:
>
>
> I've tried this and it appears to work.  I did use the config.guess
> from Apple's version instead of yours.
>
> However, when I run make, I can't build the Fortran files using g77.
> Should I have used the config.guess from your website?
>

Hmm. That is weird.  I've never had that problem.  I don't think 
changing the config.guess will help, I think all it does is figure out 
that you are running OS X, then it doesn't do much else.

What error does it give out of curiosity?  Does it g77 work if you 
compile something by hand?

I put my matlisp.mk file up on my website.  Maybe you could download it 
and see how it differs from yours?

http://mercury.chem.pitt.edu/~rds

--Robbie

Re: [Matlisp-users] fix for darwin/sbcl matlisp build

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

>>>>> "Robbie" == Robbie Sedgewick <rd...@me...> writes:

    Robbie> Then I tried to fiddle with the configure.in file.  It is only the
    Robbie> "AC_F77_FUNC(f77_name)" command which causes problems on darwin so I
    Robbie> just put that behind a case statement and hardcoded in the correct
    Robbie> answer for darwin.  This function still gets called on non-darwin
    Robbie> platforms.

I've tried this and it appears to work.  I did use the config.guess
from Apple's version instead of yours.

However, when I run make, I can't build the Fortran files using g77.
Should I have used the config.guess from your website?

Ray

[Matlisp-users] fix for darwin/sbcl matlisp build

[Robbie S. <rd...@me...>]

I tryed a more recent version of autoconf (version 2.59) but that didn't 
  help anything.  Same problem as before.

Then I tried to fiddle with the configure.in file.  It is only the 
"AC_F77_FUNC(f77_name)" command which causes problems on darwin so I 
just put that behind a case statement and hardcoded in the correct 
answer for darwin.  This function still gets called on non-darwin platforms.

With this change everything works.  I've attached the patch for 
configure.in.  Public cvs seems to be down so I may have generated the 
patch incorrectly, if I did a full verison of the new configure.in file 
is at
http://mercury.chem.pitt.edu/~rds/

Also newer versions of config.sub and config.guess are needed for 
configure to recognize darwin correctly.  These are in the autoconf 
distribution and I also put copies on my web site.


--Robbie

Re: [Matlisp-users] sbcl on linux/x86

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

Raymond Toy <to...@rt...> writes:

> Probably not since it doesn't come with g77 but does come with gcc.
> Could just be an error in autoconf.  Or perhaps the autoconf from OS X
> is too old.  I think it's 2.52 and we really need 2.58 or later....
> 
> Ray

Maybe you can get such a version via Fink?  A colleague using Mac OS has
autoconf-2.57 from there.

Nicolas.

Re: [Matlisp-users] sbcl on linux/x86

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

>>>>> "Robbie" == Robbie Sedgewick <rd...@me...> writes:

    Robbie> Yeah, well, as it appears to be a bug in configure, what do you think
    Robbie> we should do?  A couple of months ago I generated the files that

Don't know.  Beat up the autconf guys to make it work? :-)

    Robbie> I guess there arn't many projects that run on OS X that use both
    Robbie> fortran and autoconf.....

Probably not since it doesn't come with g77 but does come with gcc.
Could just be an error in autoconf.  Or perhaps the autoconf from OS X
is too old.  I think it's 2.52 and we really need 2.58 or later....

Ray

Re: [Matlisp-users] sbcl on linux/x86

[Robbie S. <rd...@me...>]

Raymond Toy wrote:
> 
> However, configure fails later saying it can't build something with
> Fortran.  I tracked it down to the fact that configure builds a test
> program like
> 
>     int MAIN () { return 1; }
> 
>     int main () { return 0; }
> 
> and expects that to return 1 if MAIN is the correct name for the
> Fortran MAIN subprogram.  Unfortunately on powerpc, the main here
> overrides the main given in -lcrt0 (or wherever it's defined).  If I
> leave out the definition of main, then 1 is returned as expected.
> (Linker errors if MAIN isn't the correct name.)

Yeah, this must be the problem that I had too.  I didn't get as far in 
figuring out exactly what was breaking.

> At this point, I gave up on trying to get configure to work.

Yeah, well, as it appears to be a bug in configure, what do you think we 
should do?  A couple of months ago I generated the files that configure 
is supposed to generate by hand and that lead to a working matlisp, so 
once we get through this problem it should work.

I don't really want to delve into how autoconf works too much to get it 
to work.  Maybe there is some simple change to the configure.in file 
that we can make to skip this check on OS X.  I'll look into that tonight.

I guess there arn't many projects that run on OS X that use both fortran 
and autoconf.....

--Robbie

Re: [Matlisp-users] sbcl on linux/x86

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

>>>>> "Robbie" == Robbie Sedgewick <rd...@me...> writes:

    Robbie> BTW:  The matlisp build process on sbcl/Mac OS X is still not quite
    Robbie> working.  Configure dies with a wierd error.  I'll try to work on it
    Robbie> tonight.

I'm curious to know what you get.  I had to use the config.guess that
comes with Mac OS X instead of the one from matlisp.  This at least
recognizes powerpc now.

However, configure fails later saying it can't build something with
Fortran.  I tracked it down to the fact that configure builds a test
program like

    int MAIN () { return 1; }

    int main () { return 0; }

and expects that to return 1 if MAIN is the correct name for the
Fortran MAIN subprogram.  Unfortunately on powerpc, the main here
overrides the main given in -lcrt0 (or wherever it's defined).  If I
leave out the definition of main, then 1 is returned as expected.
(Linker errors if MAIN isn't the correct name.)

At this point, I gave up on trying to get configure to work.

BTW, this is with g77, that I downloaded via fink.

Ray

[Matlisp-users] sbcl on linux/x86

[Robbie S. <rd...@me...>]

Hi,

I figured out what was going wrong with building matlisp with defsystem 
on linux/x86.  Marco was right, it was a problem with the defsystem 
version.

When I was trying to build it I was on a debian machine which already 
had a copy of defsystem 3 loaded into the sbcl image.  The defsystem 3 
that comes with debian is too old and misses the fix that Marco put in 
to defsystem just for this same problem on cmucl.  If I load the 
defsystem that comes with matlisp before I try compiling matlisp then 
everything works fine.

So, as far as I can tell, matlisp from cvs should work fine with sbcl on 
non-debian linux.  I'll email the maintainer of the debian defsystem 
package and ask him to update it.  Then debian should work fine too...

--Robbie

BTW:  The matlisp build process on sbcl/Mac OS X is still not quite 
working.  Configure dies with a wierd error.  I'll try to work on it 
tonight.

Re: [Matlisp-users] Configuration failure on Linux/SBCL

[Robert S. <rd...@me...>]

On May 26, 2004, at 4:09 PM, Raymond Toy wrote:
>
>
> And since the Fortran code almost never changes, I compile it up once
> and forget it.  Then I just use xemacs + slime + mk:defsystem to
> compile up the Lisp code, which changes a lot more often.

yeah, this is a good point.  I guess it matters a lot less here than in 
other projects where the c/fortran source is changing frequently.....

--Robbie



> Ray
>

Re: [Matlisp-users] Configuration failure on Linux/SBCL

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

>>>>> "Robbie" == Robbie Sedgewick <rd...@me...> writes:

    Robbie> Yeah, I agree with what you are saying.  As much as I don't like
    Robbie> configure, there is really no other portable way to get that
    Robbie> information.  So we are stuck with configure, but is there any reason
    Robbie> not to use your defsystem code to do the compiling of the fortran in
    Robbie> matlisp by default?  And remove the makefile from the picture?

Look at blas.system and lapack.system.  These will compile up the
Fortran code.

However, it's not really very well integrated at this point.  Lisp
doesn't really know how to call the Fortran compiler with the right
arguments to compile the code to make a shared library.  Configure
would need to pass that info on somehow.

This could be added, I suppose, but I don't really see much point
anymore.  By the time you've done the work, you're 99 44/100% of the
way there for making make do it, so let make do it. :-)

Patches would probably be accepted, however.  :-)

And since the Fortran code almost never changes, I compile it up once
and forget it.  Then I just use xemacs + slime + mk:defsystem to
compile up the Lisp code, which changes a lot more often.

Ray

Re: [Matlisp-users] Configuration failure on Linux/SBCL

[Robbie S. <rd...@me...>]

Raymond Toy wrote:
>>>>>>"Robbie" == Robbie Sedgewick <rd...@me...> writes:
> 
> 
>     Robbie> Either way, I think it would be nice to remove the matlisp's build
>     Robbie> dependence on make (to make libmatlisp.so) and replace it with a more
>     Robbie> sophisticated mk:defsystem or asdf system definition.  But that is
>     Robbie> project for another day.
> 
> I had a defsystem definition that could compile all code in matlisp,
> including the Fortran code.  This was easy.  The hard part is figuring
> out the calling conventions and naming conventions of the Fortran
> compiler, which is what configure is used for.  (We don't currently
> check the calling conventions, I think, but we should.)

Yeah, I agree with what you are saying.  As much as I don't like 
configure, there is really no other portable way to get that 
information.  So we are stuck with configure, but is there any reason 
not to use your defsystem code to do the compiling of the fortran in 
matlisp by default?  And remove the makefile from the picture?

--Robbie

Re: [Matlisp-users] Configuration failure on Linux/SBCL

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

>>>>> "Robbie" == Robbie Sedgewick <rd...@me...> writes:

    Robbie> Either way, I think it would be nice to remove the matlisp's build
    Robbie> dependence on make (to make libmatlisp.so) and replace it with a more
    Robbie> sophisticated mk:defsystem or asdf system definition.  But that is
    Robbie> project for another day.

I had a defsystem definition that could compile all code in matlisp,
including the Fortran code.  This was easy.  The hard part is figuring
out the calling conventions and naming conventions of the Fortran
compiler, which is what configure is used for.  (We don't currently
check the calling conventions, I think, but we should.)

Ray