gmane.lisp.iterate.devel

iterate tests regression on ACL linux 64 (quicklisp2012-04-07 vs 2012-03-07): handler-bind.1

Anton Vodonosov — 2012-05-06T22:35:25

Iterate test suite shows regression between quicklisp 2012-03-07 and  quicklisp 2012-04-07.

acl-8.2a-linux-x64.

Test logs:

quicklisp 2012-03-07: 
http://cl-test-grid.appspot.com/blob?key=AMIfv97pKvcGKmd6_yqeRupJ3ii6PsLmOuUZ0zDuQzUuJQgi_7uJX43ujwQLaaqlRBwTLkipZNoOijXq1ORRPH5fXepLeh-qO0a9Y1O6u1lEOnvDxgKYWuRnS2BWJQqPnRuvsf4xJ5KPwByJXBgamPqGXmoL413eHg
failed tests: bug/walk.2 code-movement.else code-movement.finally code-movement.finally-protected

quicklisp 2012-04-07: 
http://cl-test-grid.appspot.com/blob?key=20006
failed tests: bug/walk.2 code-movement.else code-movement.finally code-movement.finally-protected handler-bind.1

As you see, new failure is handler-bind.1.

iterate tests regression on SBCL 1.0.54 (quicklisp2012-04-07 vs 2012-03-07): handler-bind.1

Anton Vodonosov — 2012-05-06T22:39:32

Iterate test suite shows regression between quicklisp 2012-03-07 and  quicklisp 2012-04-07.

sbcl-1.0.54.84.mswinmt.1137-215bdc8-win-x64.

Test logs:

quicklisp 2012-03-07:
http://cl-test-grid.appspot.com/blob?key=AMIfv94-RAJv0FSm0WjXUTgYha9U7tUSAzwo4V3HxonJSNx5TPSEwRcW2ca7clAc5pJIh5JZjhMS7GZWQih7hViiC7OmZfY1onNIBciD7m6kbVJu9FeiRgeGEtwrPd4YxXx-dB-y6UPs8LFQN5_-st7G9ICpZVRLkA
failed tests: NONE

quicklisp 2012-04-07:
http://cl-test-grid.appspot.com/blob?key=53022
failed tests: bug/walk.2

As you see, new failure is bug/walk.2.

Bug: "collect at beginning" ignores specifiedsequence type

Ilya Perminov — 2012-03-27T22:49:33

Hi,

I reported this bug a few years ago, but it is still there.
If both AT BEGINNING and RESULT-TYPE are specified, RESULT-TYPE is ignored.
Example:
(iter (for i below 2) (collect i at beginning result-type vector))
returns (1 0).

Can someone with write access to the darcs repository fix the bug
please. My previous report includes a patch:
http://www.mail-archive.com/iterate-devel< at >common-lisp.net/msg00142.html

Thanks,
Ilya

ELS 2012, Zadar, Croatia

Marco Antoniotti — 2012-02-01T13:13:50

Apologies for the multiple postings. 

PAPER SUBMISSION DEADLINE EXTENDED 


European Lisp Symposium 2012, Zadar, Croatia, April 30th - May 1st, 2012 

http://european-lisp-symposium.org 

The purpose of the European Lisp Symposium is to provide a forum for 
the discussion and dissemination of all aspects of design, 
implementation and application of any of the Lisp and Lisp-inspired 
dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, 
Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, and so on. We 
encourage everyone interested in Lisp to participate. 


The main theme of the 2012 European Lisp Conference is 
"Interoperability: Systems, Libraries, Workflows".  Lisp based and 
functional-languages based systems have grown a variety of solutions 
to become more and more integrated with the wider world of Information 
and Communication Technologies in current use.  There are several 
dimensions to the scope of the solutions proposed, ranging from 
"embedding" of interpreters in C-based syste

ELS2012 Zadar, Croatia, Call for Papers

Marco Antoniotti — 2012-01-23T11:59:23

Apologies for the multiple postings...

===========================================================================

European Lisp Symposium 2012, Zadar, Croatia, April 30th - May 1st, 2012
http://european-lisp-symposium.org

The purpose of the European Lisp Symposium is to provide a forum for
the discussion and dissemination of all aspects of design,
implementation and application of any of the Lisp and Lisp-inspired
dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP,
Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, and so on. We
encourage everyone interested in Lisp to participate.


The main theme of the 2012 European Lisp Conference is
"Interoperabilty: Systems, Libraries, Workflows".  Lisp based and
functional-languages based systems have grown a variety of solutions
to become more and more integrated with the wider world of Information
and Communication Technologies in current use.  There are several
dimensions to the scope of the solutions proposed, ranging from
"embedding" of inte

Proposed patch to ITERATE::FREE-VARS

Robert Goldman — 2012-01-05T21:10:49

Steve Haflich from Franz kindly clarified to me my misunderstanding of
special-operators and macros.

In particular, he pointed out to me that implementations are free to
implement special operators as macros.  Steve writes:

"I assure you that the set of special operators in ACL is _fixed+, and
that there is way for you, the _user_, to extend that set.  But this
requirement of the ANS does not require that the set of cl-package
symbols that return true under spcial-operator-p is not larger than
the required operators in the table you quoted from
http://www.franz.com/support/documentation/current/ansicl/subsubsu/specialf.htm

Now see here:
http://www.franz.com/support/documentation/current/ansicl/subsubsu/macrofor.htm
specifically

  An implementation is free to implement a Common Lisp special operator
  as a macro. An implementation is free to implement any macro operator
  as a special operator, but only if an equivalent definition of the
  macro is also provided."

He goes on to explain how this works in

Differences between lisps

Robert Goldman — 2012-01-05T02:22:11

I find that ACL 8.2 gets 4 failed tests on the latest iterate from darcs:

4 out of 261 total tests failed: ITERATE.TEST::CODE-MOVEMENT.ELSE,
   ITERATE.TEST::CODE-MOVEMENT.FINALLY,
   ITERATE.TEST::CODE-MOVEMENT.FINALLY-PROTECTED,
   ITERATE.TEST::BUG/WALK.2.

where SBCL seems to get only 1.  I say "seems to," since the call to
ASDF:TEST-SYSTEM does not print gracefully in SBCL, probably because of
the compiler being chatty:

1 out of 261 total tests failed: ITERATE.TEST::BUG/WALK.2.

For CODE-MOVEMENT.ELSE, I see a problem on ACL -- the function
local-binding-check does not raise an error on ACL, although it *IS*
invoked.

The bug seems to further be localized to the fact that the following
returns NIL on ACL:

(free-variables form)

looking further, this suggests that something goes wrong in the
code-walker in FREE-VARS.

Looking further, I think I have identified the divergence --- in ACL,
CL:RETURN is a special-operator, and in SBCL, it is not:

Allegro:
CL-USER> (special-operator-p 'return)
#<special o

Darcs problems...

Robert Goldman — 2012-01-05T01:40:21

It seems that the problems were due to a version mismatch.  Darcs 2.2 on
my Mac OS X box was unable to fetch the darcs repo for iterate.  Darcs
2.5 was.  Oddly Darcs 2.2 on Linux was able to fetch it....

Cheers,
r

Proposed patch to ITERATE::FREE-VARS

Robert Goldman — 2012-01-05T21:10:49

Steve Haflich from Franz kindly clarified to me my misunderstanding of
special-operators and macros.

In particular, he pointed out to me that implementations are free to
implement special operators as macros.  Steve writes:

"I assure you that the set of special operators in ACL is _fixed+, and
that there is way for you, the _user_, to extend that set.  But this
requirement of the ANS does not require that the set of cl-package
symbols that return true under spcial-operator-p is not larger than
the required operators in the table you quoted from
http://www.franz.com/support/documentation/current/ansicl/subsubsu/specialf.htm

Now see here:
http://www.franz.com/support/documentation/current/ansicl/subsubsu/macrofor.htm
specifically

  An implementation is free to implement a Common Lisp special operator
  as a macro. An implementation is free to implement any macro operator
  as a special operator, but only if an equivalent definition of the
  macro is also provided."

He goes on to explain how this works in

Differences between lisps

Robert Goldman — 2012-01-05T02:22:11

I find that ACL 8.2 gets 4 failed tests on the latest iterate from darcs:

4 out of 261 total tests failed: ITERATE.TEST::CODE-MOVEMENT.ELSE,
   ITERATE.TEST::CODE-MOVEMENT.FINALLY,
   ITERATE.TEST::CODE-MOVEMENT.FINALLY-PROTECTED,
   ITERATE.TEST::BUG/WALK.2.

where SBCL seems to get only 1.  I say "seems to," since the call to
ASDF:TEST-SYSTEM does not print gracefully in SBCL, probably because of
the compiler being chatty:

1 out of 261 total tests failed: ITERATE.TEST::BUG/WALK.2.

For CODE-MOVEMENT.ELSE, I see a problem on ACL -- the function
local-binding-check does not raise an error on ACL, although it *IS*
invoked.

The bug seems to further be localized to the fact that the following
returns NIL on ACL:

(free-variables form)

looking further, this suggests that something goes wrong in the
code-walker in FREE-VARS.

Looking further, I think I have identified the divergence --- in ACL,
CL:RETURN is a special-operator, and in SBCL, it is not:

Allegro:
CL-USER> (special-operator-p 'return)
#<special o

Darcs problems...

Robert Goldman — 2012-01-05T01:40:21

It seems that the problems were due to a version mismatch.  Darcs 2.2 on
my Mac OS X box was unable to fetch the darcs repo for iterate.  Darcs
2.5 was.  Oddly Darcs 2.2 on Linux was able to fetch it....

Cheers,
r

Proposed patch to ITERATE::FREE-VARS

Robert Goldman — 2012-01-05T21:10:49

Steve Haflich from Franz kindly clarified to me my misunderstanding of
special-operators and macros.

In particular, he pointed out to me that implementations are free to
implement special operators as macros.  Steve writes:

"I assure you that the set of special operators in ACL is _fixed+, and
that there is way for you, the _user_, to extend that set.  But this
requirement of the ANS does not require that the set of cl-package
symbols that return true under spcial-operator-p is not larger than
the required operators in the table you quoted from
http://www.franz.com/support/documentation/current/ansicl/subsubsu/specialf.htm

Now see here:
http://www.franz.com/support/documentation/current/ansicl/subsubsu/macrofor.htm
specifically

  An implementation is free to implement a Common Lisp special operator
  as a macro. An implementation is free to implement any macro operator
  as a special operator, but only if an equivalent definition of the
  macro is also provided."

He goes on to explain how this works in

Differences between lisps

Robert Goldman — 2012-01-05T02:22:11

I find that ACL 8.2 gets 4 failed tests on the latest iterate from darcs:

4 out of 261 total tests failed: ITERATE.TEST::CODE-MOVEMENT.ELSE,
   ITERATE.TEST::CODE-MOVEMENT.FINALLY,
   ITERATE.TEST::CODE-MOVEMENT.FINALLY-PROTECTED,
   ITERATE.TEST::BUG/WALK.2.

where SBCL seems to get only 1.  I say "seems to," since the call to
ASDF:TEST-SYSTEM does not print gracefully in SBCL, probably because of
the compiler being chatty:

1 out of 261 total tests failed: ITERATE.TEST::BUG/WALK.2.

For CODE-MOVEMENT.ELSE, I see a problem on ACL -- the function
local-binding-check does not raise an error on ACL, although it *IS*
invoked.

The bug seems to further be localized to the fact that the following
returns NIL on ACL:

(free-variables form)

looking further, this suggests that something goes wrong in the
code-walker in FREE-VARS.

Looking further, I think I have identified the divergence --- in ACL,
CL:RETURN is a special-operator, and in SBCL, it is not:

Allegro:
CL-USER> (special-operator-p 'return)
#<special o

Darcs problems...

Robert Goldman — 2012-01-05T01:40:21

It seems that the problems were due to a version mismatch.  Darcs 2.2 on
my Mac OS X box was unable to fetch the darcs repo for iterate.  Darcs
2.5 was.  Oddly Darcs 2.2 on Linux was able to fetch it....

Cheers,
r

Noob question about the darcs repo

Robert Goldman — 2012-01-03T16:40:13

Although I have a common-lisp.net account, I find that I cannot clone
the darcs repository:

darcs get rgoldman< at >common-lisp.net:/project/iterate/darcs/iterate
Invalid repository:  rgoldman< at >common-lisp.net:/project/iterate/darcs/iterate

darcs failed:  (scp) failed to fetch:
rgoldman< at >common-lisp.net:/project/iterate/darcs/iterate/_darcs/inventory


Any idea what I'm doing wrong?

Is there some anonymous way to clone this repository for people who
don't have cl.net accounts?

best,
r

test failure: BUG/WALK.2

Anton Vodonosov — 2011-12-28T22:02:10

Hello.

I am running iterate tests (between other often-used CL libraries) on different Lisps.
The results of continuous testing may be found here:
http://common-lisp.net/project/cl-test-grid/pivot_ql-lib_lisp.html.

Currently Iterate has the same failure on all the lisps:

   Test ITERATE.TEST::BUG/WALK.2 failed
   Form: (ITERATE:ITER
           (RETURN
            (IF (ODDP 1)
                (PROGN)
                'ITERATE.TEST::EVEN)))
   Expected value: NIL
   Actual value: ITERATE.TEST::EVEN.

Best regards,
- Anton

Iterate symbol case changes for non-standard lowercase CL implementations.

Douglas Crosher — 2011-11-02T04:30:22

Hi,

The Scieneer CL and ACL have non-standard versions or modes in which the standard symbols are lower case and this can be 
accommodated with some minor changes.

Regards
Douglas Crosher

diff -rc iterate-20111001-darcs/iterate.lisp ../iterate-20111001-darcs/iterate.lisp
*** iterate-20111001-darcs/iterate.lisp2011-10-02 01:17:06.000000000 +1000
--- ../iterate-20111001-darcs/iterate.lisp2011-11-01 22:41:34.000000000 +1100
***************
*** 2324,2342 ****
  (setf (cdr entry) doc-string))
      symbol))
  
! ;;; (INITIALLY &rest)
  (def-special-clause initially (&rest forms)
    "Lisp forms to execute before loop starts"
    (mapc #'local-binding-check forms)
    (return-code :initial (copy-list forms)))
  
! ;;; (AFTER-EACH &rest)
  (def-special-clause after-each (&rest forms)
    "Lisp forms to execute after each iteration"
    (mapc #'local-binding-check forms)
    (return-code :step (walk-list forms)))
  
! ;;; (ELSE &rest)
  (def-special-clause else (&rest forms)
    "Lisp forms to execute if the l

Warning with sbcl atomic-decf

Philipp Marek — 2011-04-27T10:41:39

Using something like
  (for old-val = (atomic-decf ...))
in SBCL gives a warning that (sb-ext:truly-the ...) isn't known.

So perhaps there should be a
    #+sbcl (sb-ext:truly-the . walk-cddr)
just below the "the" handling case.


I've reported that as https://bugs.launchpad.net/sbcl/+bug/771673, too.


Regards,

Phil

defclause-driver with &sequence

Venkatesan S — 2011-01-23T11:14:00

Hi,

I was trying to roll an iterate driver for iterating over dates and I am
stuck with a problem. When using defmacro-driver, I am unable to get the
value passed in from to and other sequence classes. I tried with the example
given in the manual (chapter "Rolling your own"), but hit the same problem.
The manual says:
"We can now refer to parameters from, to, by, etc. which contain either the
values for
the corresponding keyword, or nil if the keyword was not supplied.
Implementing the right
code for these keywords is cumbersome but not difficult; it is left as an
exercise."

But I guess I am one of the dumb few who failed the exercise :)) The
following is my attempt with the example given in the manual:

(defmacro-driver (FOR var IN-WHOLE-VECTOR v &sequence)
      "All the elements of a vector (disregards fill-pointer)"
      (let ((vect (gensym))
              (end (gensym))
              (index (gensym))
              (myfrm (gensym "myfrm"))
              (kwd (if generate 'generate 'for)))

Seconded: ITER package nickname all caps - breaksreadtable-case invert

Jonathan Johansen — 2010-08-28T06:14:29

[Bug] Hashtable traversal code always put at thebeginning

Andrea Taverna — 2010-08-15T12:58:44