- iterate-devel - mailman3.common-lisp.net

[iterate-devel] Seconded: ITER package nickname all caps - breaks readtable-case invert
by Jonathan Johansen 28 Aug '10

28 Aug '10

I think fixing this would be awesome - I like the invert case readtable setting. On Mon, Aug 23, 2010 at 10:08 AM, Vladimir Sedach <vsedach(a)gmail.com> wrote: > Hi, > > Is there a reason why the package nickname ITER is written in all > capital letters in the package definition file? cl-closure-template > uses the ITER nickname but in lowercase, and this breaks when I have > my readtable-case set to invert. Is this a bug in iterate or > cl-closure-template? I've done a search of other packages in my > site-lisp (102 of them), and none of the other ones seem to use the > nickname ITER in upper case. > > Thanks, > Vladimir > > _______________________________________________ > iterate-devel site list > iterate-devel(a)common-lisp.net > http://common-lisp.net/mailman/listinfo/iterate-devel >

1 0

[iterate-devel] ITER package nickname all caps - breaks readtable-case invert
by Vladimir Sedach 23 Aug '10

23 Aug '10

Hi, Is there a reason why the package nickname ITER is written in all capital letters in the package definition file? cl-closure-template uses the ITER nickname but in lowercase, and this breaks when I have my readtable-case set to invert. Is this a bug in iterate or cl-closure-template? I've done a search of other packages in my site-lisp (102 of them), and none of the other ones seem to use the nickname ITER in upper case. Thanks, Vladimir

1 0

[iterate-devel] [Bug] Hashtable traversal code always put at the beginning
by Andrea Taverna 16 Aug '10

16 Aug '10

SYSTEM DESCRIPTION > Iterate version: latest from darcs repository and 1.4.3 Lisp implementation: SBCL 1.0.33 BUG DESCRIPTION> when using FOR..IN-HASHTABLE the code generated for hash-table traversing is always put at the beginning of generate code, with the result that the hash-table to be traversed must be in scope since the beginning of the ITER form. EXAMPLE > (macroexpand-1 '(iter:iter (iter:with table = (make-hash-table)) (iter:for (k v) in-hashtable table) (format t "~A ~A ~%" k v))) ==> (WITH-HASH-TABLE-ITERATOR (#:HASH-TABLE-ITERATOR-810 TABLE) ; <-- 'TABLE used before being bound (LET* ((TABLE (MAKE-HASH-TABLE)) (#:G811 NIL) (K NIL) (V NIL)) (BLOCK NIL (TAGBODY (PROGN) LOOP-TOP-NIL (PROGN (MULTIPLE-VALUE-SETQ (#:G811 K V) (#:HASH-TABLE-ITERATOR-810)) (IF (NOT #:G811) (GO LOOP-END-NIL)) (FORMAT T "~A ~A ~%" K V)) (PROGN) (GO LOOP-TOP-NIL) LOOP-END-NIL (PROGN)) NIL))) thank you, Andrea

2 1

[iterate-devel] Fix for broken progn
by Olof-Joachim Frahm 03 Jun '10

03 Jun '10

Hi, the attached patch fixes a nasty bug in iterate: Without it, forms like (iterate (leave (if T (progn) 3))) evaluate to 3, because walk-progn simply strips empty progn forms. Regards, Olof -- The world is burning. Run.

2 2

[iterate-devel] Iteration on multiple lists sequentially
by William Halliburton 28 May '10

28 May '10

Hello all, Does anyone have a generator that allows for iteration on multiple lists sequentially without creating a single list. I'm doing this alot: (iter (for el in (append list1 list2 list3))) when the APPEND is really not necessary with a sufficiently smart generator like: (iter (for el in list then list2 then list3))) ? Thank you, Will

2 2

[iterate-devel] Bad superiority example
by Eivind Midtgård 11 Apr '10

11 Apr '10

The document at http://common-lisp.net/project/iterate/ uses this as an example of the superiority of iterate over loop: Finding the longest list in a list of lists: (iterate (for elt in list-of-lists) (finding elt maximizing (length elt))) whereas the example of how it can be done in loop is long and contorted. But loop can do (loop for elt in list-of-lists maximizing (length elt)) The example in 3.2 Named blocks may be better as a selling point: (iter outer (for i below (array-dimension ar 0)) (iter (for j below (array-dimension ar 1)) (in outer (collect (aref ar i j))))) showing that the outer loop can easily collect data produced in the inner loop. Eivind

2 1

[iterate-devel] compile failed on allegro 8.2
by Michael Pheasant 07 Apr '10

07 Apr '10

Hi trying to install iterate with (asdf-install:install :iterate) I get the following error: .... ;;; Compiling file /Users/m.pheasant/.asdf-install-dir/site/iterate-1.4.3/iterate.lisp Error: Unsyntactic ! syntax: "1" It refers to the first time the !1 is seen, in defun walk: (t ;; Lisp function call (return-code-modifying-body #'walk-arglist (cdr form) #L(list (cons (car form) !1)))))) any help appreciated. I was using sbcl and appreciated iterate over loop, and would like to use it from allegro. Cheers Mike -- Michael Pheasant Software Engineer Queensland Facility for Advanced Bioinformatics Level 6, QBP University of Queensland, QLD 4072 T: +61 (0)7 3346 2070 F: +61 (0)7 3346 2101 www.qfab.org

2 1

[iterate-devel] Proposal for manual modification re defclause-sequence
by Mirko Vukovic 12 Feb '10

12 Feb '10

Hello, I recently had an issue of saving iterate extension code in sbcl fasl files. Several folks have commented that the documentation on defclause-sequency could be more explicit on that topic. Thus this email. You can find the whole email thread here: http://common-lisp.net/pipermail/iterate-devel/2010-February/000654.html (the first email in that thread has an attachment with the original problem file). Basically the problem was the following defclause-sequence definition: (defclause-sequence matrix-row matrix-row-index :access-fn (lambda (grid index) (assert (and (grid:gridp grid) (eql (grid:grid-rank grid) 2)) (grid)) (grid:row grid index)) :size-fn (lambda (grid) (assert (and (grid:gridp grid) (eql (grid:grid-rank grid) 2)) (grid)) ... etc. In an interpreted list, such as clisp, there were no problems with this form. But in a compiled list, such as sbcl, the form could be evaluated, but could not be saved in a fasl. Thus compile file and asdf loading did not work. The solution was to quote the lambda forms: (defclause-sequence matrix-row matrix-row-index :access-fn '(lambda (grid index) (assert (and (grid:gridp grid) (eql (grid:grid-rank grid) 2)) (grid)) (grid:row grid index)) :size-fn '(lambda (grid) (assert (and (grid:gridp grid) (eql (grid:grid-rank grid) 2)) (grid)) ... etc. Important to note, sharp-quoting -- #' -- such as in the example code in the manual, did not work. My (very incomplete understanding) is that storing lists (such as '(lambda ...) in fasl's is OK, and iter can figure out what to do with them once read back in. But not storing compiled objects (which a #'(lambda ...) cannot be stored in fasl's. I propose that the documentation be changed, with perhaps a few additional examples. I would be glad to work with one of the developers/maintainers off-line on this issue. Regards, Mirko

1 0

[iterate-devel] Fwd: iterate form evaluates but does not load into sbcl fasl
by Mirko Vukovic 09 Feb '10

09 Feb '10

Hello, (A copy of this email was recently sent to the gsll and sbcl mailing lists). The package gsd <http://repo.or.cz/w/gsd.git>, part of gsll<http://common-lisp.net/project/gsll/>uses iterate to loop over elements of vectors and matrices. I have attached the part of the package that extends iterate to this email. I am having the following issue on sbcl1.034 on RHEL5 64-bit linux, via slime. The following form evaluates OK at the REPL. (iter:iter (iter:for c :matrix-row grid::*array-3-4-double-float* ) (print c)) But, if I embed it into a function: (defun foo () (iter:iter (iter:for c :matrix-row grid::*array-3-4-double-float*) (print c))) it will evaluate OK in slime (C-x C-e), but will not compile (C-c C-c). The returned error is: >>> post-processing/xpdp-post-processing.lisp:75:3: error: Objects of type FUNCTION can't be dumped into fasl files. --> LET* BLOCK TAGBODY PROGN SETQ THE FUNCALL SB-C::%FUNCALL THE --> SB-KERNEL:%COERCE-CALLABLE-TO-FUN ==> #<FUNCTION (LAMBDA #) {1002DD7AD9}> note: The first argument never returns a value. --> LET* BLOCK TAGBODY PROGN SETQ THE FUNCALL SB-C::%FUNCALL THE ==> (SB-KERNEL:%COERCE-CALLABLE-TO-FUN #<FUNCTION # {1002DD7AD9}>) ... more stuff >>> So, it seems that sbcl can digest it, but for some reason cannot write it to a fasl. The macroexpansion of the code above is: (LET* ((#:SEQUENCE120 NIL) (#:LIMIT121 NIL) (C NIL) (#:INDEX119 NIL)) (BLOCK NIL (TAGBODY (PROGN (SETQ #:SEQUENCE120 GRID::*ARRAY-3-4-DOUBLE-FLOAT*) (SETQ #:LIMIT121 (FUNCALL # #:SEQUENCE120)) (SETQ #:INDEX119 -1)) LOOP-TOP-NIL (PROGN (SETQ #:INDEX119 (+ #:INDEX119 1)) (IF (>= #:INDEX119 #:LIMIT121) (GO LOOP-END-NIL)) (SETQ C (FUNCALL # #:SEQUENCE120 #:INDEX119)) (PRINT C)) (PROGN) (GO LOOP-TOP-NIL) LOOP-END-NIL (PROGN)) NIL)) Is this issue due to a malformed extension of iterate, or some misalignment between iterate and sbcl? Thank you, Mirko

4 7

[iterate-devel] Problem with iterate and fare-matcher
by Olof-Joachim Frahm 05 Feb '10

05 Feb '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've got a problem using iterate with the fare-matcher library (both current versions). In the following code fragment, the function FOO does as it should, matching for the symbol QUIT from the current package. The function BAR however only wraps it inside the iterate macro and then apparently produces slightly wrong code: > (use-package '(#:fare-matcher #:iterate)) > > (defun foo (msg) > (match msg > ('quit 42) > (_ 'else))) > > (foo 'quit) > ;; 42 > > (defun bar (msg) > (iterate > (leave (match msg > ('quit 42) > (_ 'else))))) > > (bar 'quit) > ;; ELSE > (bar 'fare-matcher::quit) > ;; 42 Even with macroexpanding the two definitions I couldn't figure out where this goes wrong, so maybe you have an idea about this. Cheers, Olof - -- Es liegt in der menschlichen Natur, unvenrüntfig zu denken und zu handeln. -- nach Anatole France -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAktsY3kACgkQEiTh585nXwB3jgCeNh5pUyV5D2g5f41z6iA5zJoc lkIAn3ULA6Jy0JKDjKWLi3Q1wXsAzvag =4EaR -----END PGP SIGNATURE-----

1 0