gsll-devel February 2009

gsll-devel@common-lisp.net

6 participants
15 discussions

[Gsll-devel] inverse of cl-array
by Niitsuma Hirotaka 11 Feb '09

11 Feb '09

I can not find convert function #A(...) -> #m(...) ( cl-array is conversion #m -> #a ) Thus I write the following ,but that looks slow. -------------- (defun coerce-array-to-list (in-array) (map 'list #'identity (make-array (array-total-size in-array) :element-type (array-element-type in-array) :displaced-to in-array))) ;borrow from http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/a925ca60… (defun appropriate-name (element-type ar) (make-marray element-type :dimensions (array-dimensions ar) :initial-contents (coerce-array-to-list ar)) ) --------------- usage: ( appropriate-name 'double-float #2A((1.0d0 2.0d0) (2.0d0 5.0d0))) -> #m((1.0d0 2.0d0) (2.0d0 5.0d0)))

3 4

[Gsll-devel] Fwd: [clisp-list] Is this a bug, or does it violate the standard?
by Mirko Vukovic 01 Feb '09

01 Feb '09

See below for words of wisdom regarding loop and macros. I have seen that mentioned before. ---------- Forwarded message ---------- From: Pascal J. Bourguignon <pjb(a)informatimago.com> Date: Sun, Feb 1, 2009 at 9:59 PM Subject: Re: [clisp-list] Is this a bug, or does it violate the standard? To: clisp-list <clisp-list(a)lists.sourceforge.net> Cc: Mirko Vukovic <mirko.vukovic(a)gmail.com> On Feb 2, 2009, at 3:20 AM, Mirko Vukovic wrote: > > Indeed, the style "looked" bad, having a simple form in the middle of > compound forms.. The example was a distillation of a code from a > package that was compiling OK on SBCL, but failed on CLISP. > > I like the idea of macrolet. And I will remember the (progn ...) trick as well. Which reminds me to mention that LOOP shouldn't be used in the expansion of macros because of this kind of problems... When writting macros, it's safer to use DO, DO*, DOLIST, DOTIMES or even TAGBODY/GO in the expansion. -- __Pascal Bourguignon__ http://www.informatimago.com

1 1

Re: [Gsll-devel] with-ode-integration macro problem on clisp
by Liam Healy 01 Feb '09

01 Feb '09

On Sun, Feb 1, 2009 at 9:17 PM, Mirko Vukovic <mirko.vukovic(a)gmail.com> wrote: > According to folks on the clisp mailing list and hyperspec > (http://www.lispworks.com/documentation/HyperSpec/Body/06_aaaa.htm), > the bodies of simple loops can contain only *compound forms*. So, the > original code was out of spec. Live and learn :-) So it is. Who knew. If you have a git patch you can email, go ahead and send it, I will apply it (I've never applied a git patch from email, but I'll figure it out) and check it in. While you're chasing down CLISP problems, I noticed a bunch of them when running the tests. If those problems turn out to be in GSLL we should try to patch them up. Liam

1 0

Re: [Gsll-devel] with-ode-integration macro problem on clisp
by Liam Healy 01 Feb '09

01 Feb '09

On Sun, Feb 1, 2009 at 7:26 PM, Mirko Vukovic <mirko.vukovic(a)gmail.com> wrote: > On Sat, Jan 31, 2009 at 10:23 PM, Liam Healy <lhealy(a)common-lisp.net> wrote: >> Mirko, >> >> It looks like there is a bug there in CLISP; symbol-macrolet is a part >> of the standard and it should work. I have given up on testing in >> CLISP because I encounter so many errors that seem to be a problem on >> their side. If you can get a useful answer out of CLISP, that's >> great, but you should switch to SBCL or CCL if you can because I do >> test on these. > > Liam, I use SBCL at work on my linux box. But at home I have a > windows laptop where I use clisp on cygwin. I have not ventured yet > into using the windows version of SBCL -- if you have heard of user > stories about that I would love to hear them. > > If I do find `fixable' problems on CLISP, do you want me to post them here? If the problem is not due to a bug in CLISP, by all means, post it here. If it is some grey area where CLISP has a problem with some arguably-acceptable construct in GSLL, I will consider changing it if it reasonably straightforward to do so. Maybe using a flet or labels is a workaround for the present problem, but from your description symbol-macrolet is being incorrectly compiled in CLISP. By the way, I put in the :cygwin feature switch in init.lisp for you. Does that work OK? > > >> >> As to whether it should be a symbol-macro or a function call I think >> it is a style issue. I'm not terribly happy with the macro as it is, >> I think it requires rethinking anyway, I just hacked through it to get >> something out that would get rid of the with-c-double. I'll return to >> it at some point but I have other things I'm working on first. > > I may need to use it in the next few weeks. If I come up with > something more `elegant', I will post it. > > Maybe something like > > (with-ode-stepper (stepper ...) > ... > (do-ode-steps (stopping-test) > (post-step-form)) > ... > ) That looks OK. > > I will post the offending example code on the clisp group to get their feedback. OK. > Mirko > Liam

1 0

[Gsll-devel] with-ode-integration macro problem on clisp
by Mirko Vukovic 31 Jan '09

31 Jan '09

Liam, The file `ode-example.lisp' could not compile on clisp+cygwin+windows. The error occurred in `integrate-vanderpol', which uses the `with-ode-integration' macro. I traced the problem to the symbol-macrolet generated macro `make-next-step'. It looks like the loop body cannot digest symbols created with symbol-macrolet (again clisp only, not sbcl). I was able to fix the problem by changing make-next-step into a function via labels. I am attaching a file that illustrates the problem, fix and verification. It has has several items: 1) illustration with a simple code on where clisp fails when loop uses a symbol-macrolet based symbol 2) the modified with-ode-integration macro 3) a version of integrate-vanderpol based on the modified macro 4) an example of a test-suite where I compared the outputs of your macro with the modified macro, using your examples of integrating vanderpol. This issue is not a major show-stopper for me, since I have a working version now. I can see why make-next-step should be defined as a symbol-macro -- it is so simple. On the other hand, strictly visually, its appearance as a symbol in the body of the loop between two forms is a bit jarring. Also, make-next-step is an `internal' symbol to the with-ode-integration macro, and maybe should not be visible to the user. But all of the above are really, minor, minor points, because the user is free to write their own version of `with-ode-integration' :-) The major point is really that sooner or later someone else will try to compile on clisp and hit the same problem. Mirko

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

gsll-devel February 2009