From coffeemug at gmail.com  Fri Aug 15 22:02:40 2008
From: coffeemug at gmail.com (Vyacheslav Akhmechet)
Date: Fri, 15 Aug 2008 18:02:40 -0400
Subject: [lift-devel] Dynamic Variables?
Message-ID: <b381ea40808151502t38100a06k24db9420bab3bb65@mail.gmail.com>

Hello,

I have the latest asdf-installable version of Lift. I am trying the
following example:

(deftestsuite my-test-suite ()
  ()
  (:dynamic-variables
   (*foo* t)))

(defun foo ()
  (declare (special *foo*))
  *foo*)

(addtest (my-test-suite)
  some-test
  (ensure-same (foo) t))

When I run the test with (describe (run-test)) I get the following result:

Test Report for MY-TEST-SUITE: 1 test run, 1 Error.

ERROR  : my-test-suite : some-test
  Condition: The variable *FOO* is unbound.
  Code     : "
  ((ENSURE-SAME (FOO) T))"

Test Report for MY-TEST-SUITE: 1 test run, 1 Error.; No value

Why is *foo* unbound? Am I doing something wrong?


From gwking at metabang.com  Sat Aug 16 22:33:37 2008
From: gwking at metabang.com (Gary King)
Date: Sat, 16 Aug 2008 18:33:37 -0400
Subject: [lift-devel] Dynamic Variables?
In-Reply-To: <b381ea40808151502t38100a06k24db9420bab3bb65@mail.gmail.com>
References: <b381ea40808151502t38100a06k24db9420bab3bb65@mail.gmail.com>
Message-ID: <D9AEA17D-B75D-4D26-9A1B-32A8CA889EEE@metabang.com>

Hi Vyacheslav,

You're not doing anything wrong; you are doing something I didn't  
anticipate!

LIFT assumes that all the variables listed in the :dynamic-variables  
clause will have been previously defined via defvar or defparameter.  
Adding

(defvar *foo*)

will make things work the way you expect. I'm not sure whether to  
think of this as a bug or a feature. What do you think?


On Aug 15, 2008, at 6:02 PM, Vyacheslav Akhmechet wrote:

> Hello,
>
> I have the latest asdf-installable version of Lift. I am trying the
> following example:
>
> (deftestsuite my-test-suite ()
>  ()
>  (:dynamic-variables
>   (*foo* t)))
>
> (defun foo ()
>  (declare (special *foo*))
>  *foo*)
>
> (addtest (my-test-suite)
>  some-test
>  (ensure-same (foo) t))
>
> When I run the test with (describe (run-test)) I get the following  
> result:
>
> Test Report for MY-TEST-SUITE: 1 test run, 1 Error.
>
> ERROR  : my-test-suite : some-test
>  Condition: The variable *FOO* is unbound.
>  Code     : "
>  ((ENSURE-SAME (FOO) T))"
>
> Test Report for MY-TEST-SUITE: 1 test run, 1 Error.; No value
>
> Why is *foo* unbound? Am I doing something wrong?
> _______________________________________________
> lift-devel mailing list
> lift-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/lift-devel

--
Gary Warren King, metabang.com
Cell: (413) 559 8738
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM






From coffeemug at gmail.com  Sun Aug 17 00:23:23 2008
From: coffeemug at gmail.com (Vyacheslav Akhmechet)
Date: Sat, 16 Aug 2008 20:23:23 -0400
Subject: [lift-devel] Dynamic Variables?
In-Reply-To: <D9AEA17D-B75D-4D26-9A1B-32A8CA889EEE@metabang.com>
References: <b381ea40808151502t38100a06k24db9420bab3bb65@mail.gmail.com>
	<D9AEA17D-B75D-4D26-9A1B-32A8CA889EEE@metabang.com>
Message-ID: <b381ea40808161723s6f09a581lda3b7c24a1dbe268@mail.gmail.com>

On Sat, Aug 16, 2008 at 6:33 PM, Gary King <gwking at metabang.com> wrote:
> LIFT assumes that all the variables listed in the :dynamic-variables clause
> will have been previously defined via defvar or defparameter.
Ah, of course. Somehow when I saw :dynamic-variables feature I assumed
it's implemented with progv and the association was too strong in my
mind.

> I'm not sure whether to think of this as a bug or a feature. What do you think?
One way to think of it is that this behavior exposes potential bugs
and issues in the code. I don't agree with this personally because CL
specifically allows to declare variables as special using (declare
(special ...)) form, so not all special variables have to be declared
globally. I guess I use this feature of CL more often than you do :)

It would probably more in the spirit of CL to automatically declare
:dynamic-variables as special, and it wouldn't 'cause UI surprises.
However, now that I know what the workaround is, the issue doesn't
bother me much and I suppose other people would feel the same way.

Thanks,
- Slava


From coffeemug at gmail.com  Sun Aug 17 00:29:36 2008
From: coffeemug at gmail.com (Vyacheslav Akhmechet)
Date: Sat, 16 Aug 2008 20:29:36 -0400
Subject: [lift-devel] Slime warnings
Message-ID: <b381ea40808161729h233e809dl7d12fae7b004e756@mail.gmail.com>

Hello,

Compiling (and recompiling) tests defined with Lift cause Slime to
show high level warnings (so that it opens another window). It's
rather difficult to develop with these windows showing up. Is there a
way to fix this other than muffling Slime warnings? The CL testing
frameworks review article[1] also brings up this issue with Lift.
Considering that Slime chooses the warnings of this level to pop up
warning windows by default, should Lift macros compile to code that
doesn't produce such warnings, if possible?

Thanks,
- Slava

[1] http://aperiodic.net/phil/archives/Geekery/notes-on-lisp-testing-frameworks.html


From coffeemug at gmail.com  Thu Aug 21 17:36:02 2008
From: coffeemug at gmail.com (Vyacheslav Akhmechet)
Date: Thu, 21 Aug 2008 13:36:02 -0400
Subject: [lift-devel] Environment mixup
Message-ID: <b381ea40808211036k19097216tdc50e55d90bc14f7@mail.gmail.com>

Hello,

I ran into the following issue:

(deftestsuite foo () ()
  (:dynamic-variables *some-var*))

(deftestsuite bar (foo)
  ((some-slot *some-var*)))

(addtest some-test
  (+ 1 2))

The test SOME-TEST fails because the variable *some-var* isn't bound
at the time some-slot is defined. However, if I were to change the
definition of BAR, things would work:

(deftestsuite bar (foo)
  (some-slot)
  (:setup (setf some-slot *some-var*)))

Should the environment set up by FOO be available to BAR at the time
of slot initialization? Is this a bug or a feature?


From gwking at metabang.com  Thu Aug 21 22:00:42 2008
From: gwking at metabang.com (Gary King)
Date: Thu, 21 Aug 2008 18:00:42 -0400
Subject: [lift-devel] Environment mixup
In-Reply-To: <b381ea40808211036k19097216tdc50e55d90bc14f7@mail.gmail.com>
References: <b381ea40808211036k19097216tdc50e55d90bc14f7@mail.gmail.com>
Message-ID: <294B7793-2E1A-4591-B089-EBD8D2582322@metabang.com>

> The test SOME-TEST fails because the variable *some-var* isn't bound
> at the time some-slot is defined. However, if I were to change the
> definition of BAR, things would work:
>
> (deftestsuite bar (foo)
>  (some-slot)
>  (:setup (setf some-slot *some-var*)))
>
> Should the environment set up by FOO be available to BAR at the time
> of slot initialization? Is this a bug or a feature?

This feels like a bug to me; there is an order to the way things are  
supposed to happen (now if I could just find where I wrote it down)  
and it certainly should be the case that the superclass gets to do its  
work _before_ the subclass does anything. I've logged a bug and will  
try to get to it soon.

(On the positive side, I have a whole bunch of features that I need to  
add to LIFT for my own work so it's more likely that I'll be able to  
look into this at the same time...).


--
Gary Warren King, metabang.com
Cell: (413) 559 8738
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM