gmane.lisp.iterate.devel

Re: Active?

Attila Lendvai — 2012-05-11T23:57:33

no worries, i didn't read it that way, and sorry if i sounded like
suggesting that.

re commit bits, i guess for handing some out first we need people to
step up and volunteer... ;)

i support anyone who deals with the codebase responsively (doesn't
experiment with revolutionary refactorings in the official repo).

Re: Active?

Robert Goldman — 2012-05-11T23:23:24

I certainly don't mean to criticize what you are doing: I am grateful
for it.  I just think it would be nice to get some more people with the
commit bit.  I'm probably not the ideal person myself, but perhaps we
can get a volunteer or two.  I imagine as the most active person on the
project now, it would probably be up to you to authorize such a person,
so that the cl.net admins will convey the sacred privilege.

Cheers,
r

Re: Active?

Attila Lendvai — 2012-05-11T17:58:26

well, this decision is in no way my responsibility, or is iterate "my"
project in any sense. it was just dormant when i had several patches,
so i asked for the commit bit.

but with that in mind i support that more people get commit bits, and
especially so when it comes to you Robert.

Re: Active?

Robert Goldman — 2012-05-10T00:47:55

Would you consider getting someone else into the group, then?  I am not
really in a position to volunteer for much upkeep right now, but perhaps
could help scrounge someone up.

Iterate has moved in to be one of the libraries that's used in pretty
much all of our projects, so I'm motivated to help keep it shiny.

Cheers,
r

Re: Bug: "collect at beginning" ignores specified sequence type

Attila Lendvai — 2012-05-09T22:57:58

pushed, thanks!

and sorry for the delay...

Re: Active?

Attila Lendvai — 2012-05-09T22:50:29

i'm "active", and reading the list every once in a while, and i even
have all pending issues starred, but i don't have ACL.

and also, many of the iterate bugs are due to its walker
implementation, and when i darcs initialized the hu.dwim.reiterate
repo, i kinda gave up on fixing iterate itself.

(i haven't switched to reiterate myself in my projects yet, and i'm
not planning to make it 100.00% compatible drop-in replacement,
although providing a separate package with a few clause expanders
should be simple)

Re: Active?

Robert Goldman — 2012-05-07T15:25:55

This is what I see at common-lisp.net:

iterate:x:1506:afuchs,mbaringer,alendvai,jhoehle

Perhaps it would be a good thing to give some additional people the
commit bit; I am not sure if anyone other than Attila is currently
active (apologies if I am wrong about that).

Cheers,
r

Re: Active?

Vladimir Sedach — 2012-05-07T15:09:51

I think the problem is that Attila does not read iterate-devel. There
are quite a lot of patches and bug reports submitted here in the past
2 years that haven't made it into the code.

I've CC'ed Attila. I guess another question would be is there anyone
else with access to the Iterate repository right now?

Vladimir

On Mon, May 7, 2012 at 9:48 AM, Robert Goldman <rpgoldman< at >sift.info> wrote:

Active?

Robert Goldman — 2012-05-07T13:48:53

Is this mailing list (and the iterate library) still active?

I made some patches to iterate to address issues on ACL, but I don't
believe that they are moving forward to incorporation in the library.

The last email on this list that seems to show anything like forward
motion (and that's debatable), seems to be from 2010.

There is a patch from 7 months ago from attila, though.

Cheers,
r

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

Re: Differences between lisps

Robert Goldman — 2012-01-05T02:30:19

...snip...


Oh, dear.  Looking further into the hyperspec, I see that this seems to
be a case where ACL collides with the ANSI spec....

I will report this to Franz as a bug.

Best,
r

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

Re: Differences between lisps

Robert Goldman — 2012-01-05T02:30:19

...snip...


Oh, dear.  Looking further into the hyperspec, I see that this seems to
be a case where ACL collides with the ANSI spec....

I will report this to Franz as a bug.

Best,
r

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