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

[iterate-devel] Auto-nag: iterate link verifier failed
by root＠common-lisp.net 23 Jan '06

23 Jan '06

You are being nagged on because your project's name showed up in the nightly Checkbot run. Checkbot checks for broken links etc. This probably means that you are either pointing to a broken link or that someone is pointing to a broken link on your site. Or something else, it check's a bunch of stuff. Update your webpages or you shall be nagged again next week. To find out what's wrong with your webpages, please consult: http://common-lisp.net/checkbot/checkbot-common-lisp.net.html Any questions? You can reach the author of this cronjob at clo-devel(a)common-lisp.net Thanks!

1 0

[iterate-devel] Auto-nag: iterate link verifier failed
by root＠common-lisp.net 18 Jan '06

18 Jan '06

You are being nagged on because your project's name showed up in the nightly Checkbot run. Checkbot checks for broken links etc. This probably means that you are either pointing to a broken link or that someone is pointing to a broken link on your site. Or something else, it check's a bunch of stuff. Update your webpages or you shall be nagged again next week. To find out what's wrong with your webpages, please consult: http://common-lisp.net/checkbot/checkbot-common-lisp.net.html Any questions? You can reach the author of this cronjob at admin(a)common-lisp.net Thanks!

1 0

Re: [iterate-devel] Fwd: if-first-iteration, a little better vers ion as an arch patch
by Hoehle, Joerg-Cyril 18 Jan '06

18 Jan '06

Peter Van Eynde wrote: >> am i right when i assume there's no source control for iterate >> currently and the arch/tla source tree (at >> iterate-devel(a)common-lisp.net--2004/iterate--main--1.4) >This seem to be the case, this and the lack of a version bump in the >'newest' tar.gz's asd file makes life difficult for this debian >maintainer. Hm, I'm not sure I understand. You seem to miss two things: o one is some update at common-lisp.net, in the main-1.4 branch. I can't help with that, only people with write access can. o the other is some means to see whether there's something new in the .tgz which I send out? That I can answer. + I didn't feel like changing (defconst version "1.4" "Current version of Iterate") into "1.4.x" for every patch that I send. I fount it ok to have only major.minor, not x.y.z. And what I sent out last year are mostly bugfixes, so there wasn't a need to update minor. Anyway, my idea about how things work is that whoever puts my stuff into Arch(a)common-lisp.net will automatically cause a new Arch number to be generated, so my own numbering schemes are moot anyway. I thought I understood that only what is in common-lisp.net HEAD counts for the Debian source (and thus Peter), so my RCS numbering is of no interest to others. What would you like to have + change (defconst version to "1.4.23"), in sync with my own internal RCS numbers? + change it according to some other numbering, i.e. e.g. "1.4.5" when it's the fifth time I send out the archive publicly? + not change this Lisp variable, until I really change the API or functionality? + name the .tgz archives differently than e.g. iterate-jch.tgz? + none of the above, you were not talking about that at all. Would you please clarify? Jörg Höhle.

2 1

Re: [iterate-devel] Fwd: if-first-iteration, a little better vers ion as an arch patch
by Hoehle, Joerg-Cyril 13 Jan '06

13 Jan '06

Attila Lendvai writes: >this entire stuff is probably a few minutes for you probably :) Never. I'm used to double check the code, double-check the macro output (with and without multiple uses etc.). And I did not mention the need to add testcases, nor update the TeX documentation... Nor use of RCS/darcs/you-name-it. OTOH, answering e-mails always seems to take little time and little care :-) >I think a first-iteration-p would be more useful then an entire if-... >construct. Same for first-time-p Indeed. You're completely right. Thanks for opening my eyes! A single predicate integrates even better with the rest of CL (which is one of Iterate's points over LOOP) than another custom IF*. > >> BTW, what's the iteration pattern that lead you to ... Some other question comes to mind: does the need justify a new construct, or are the present ones "good enough"? I.e. if-first-iteration (non-sharing) could also be done using (for first-iteration initially t then nil) Of course, that would not share variables, but in DSL terms, it looks like a growth of non-orthogonal features, with slight variations between each (e.g. yours shares variables, if-first-time allows non-top-level use, if initially then is not as efficient (who cares?) etc.) > (finally (return `(progn ,@it))) Why not just `(progn .,(iter #)) ; read . , if you prefer -- it's not ,. or `(progn ,@(iter #)) since the "final" clause it never conditional? Regards, Jörg Höhle.

3 3

Re: [iterate-devel] Fwd: if-first-iteration, a little better vers ion as an arch patch
by Hoehle, Joerg-Cyril 10 Jan '06

10 Jan '06

Attila Lendvai wrote: >And finally a new version of if-first-iteration: That's more or less that, minor a few points (a documentation string, bind step-body after first-usage to avoid setf, usage of make-accum-var-binding, and probably eliminate the no-else code generation test (let the compiler do that)). I'll add it to the next version (not immediately, I'm too busy right now). I hope this is ok. BTW, what's the iteration pattern that lead you to define this and not use IF-FIRST-TIME? Could you show some sample/imaginary code? Thanks for your contribution. Regards, Jörg Höhle

2 1

[iterate-devel] Fwd: if-first-iteration, a little better version as an arch patch
by Hoehle, Joerg-Cyril 10 Jan '06

10 Jan '06

Attila Lendvai wrote: [writing Iterate extensions using iterate::* instead of exported symbols. >And after looking at the code it wasn't >obvious (for me, newbie warning). Maybe I should add a comment here and there (in code and/or TeX documentation). The implementation somewhat obviously(?) uses the internal interfaces. So of course this leads to copy&paste of this code. Actually, it's a critique of mine towards Iterate that I haven't yet identified a subset of primitives with which to write the many other Iterate clauses, and so that they work as efficiently as the predefined ones. It's missing this "growing a language" concept. >issuing a tla redo. Just in case... Indeed, I'm not yet using arch/tla. For now it doesn't make much sense since I cannot (yet?) access common-lisp.net as a developer. Thanks for the info. I just recently jumped into darcs (cffi), but did not yet try out Arch or subversion. Regards, Jörg Höhle.

2 1

[iterate-devel] wanted: complex uses of iterate, for inclusion in the testsuite
by Hoehle, Joerg-Cyril 09 Jan '06

09 Jan '06

Hi, I'd like to extent the testsuite with tests of Iterate involving several clauses. Because of things like feature interaction, I'm convinced that some bugs in software cannot be found out by testing each clause separately, as the current testsuite tends to exercise. Instead, one clause may affect the other (I know a few cases), and such complex multi-clause usage is presumably more representative of uses of Iterate by you, the application developers, than the present rather primitive testsuite. Therefore, I'd like to ask you for multi-clause uses of Iterate for inclusion in the testsuite. It could then also serve as source of nice examples to other users. Thanks, Jörg Höhle.

1 0

[iterate-devel] Fwd: if-first-iteration, a little better version as an arch patch
by Hoehle, Joerg-Cyril 09 Jan '06

09 Jan '06

Attila Lendvai wrote: >and a tla undo patch this time. Ah, I was wondering what the many strange files meant :-) I wonder why people submitting patches tend to write code against Iterate's internal structures, instead of writing using the external interface? After all, being able to expand Iterate via regular macros was one of John Amsterdam's design goals. What about something along (defmacro-clause if-first-iteration (then &optional else) `(progn (with ,(gensym) = t) (if ,gensym ,then ,else) (after-each (setq ,gensym nil))) If you really want to hack the internals, I suggest not introducing another special variable, but instead add to the existing binding variables. You can still generate a single variable for all uses of IF-FIRST-ITERATION in one Iterate by using a technique similar to that of iter::return-extremum-code. That would integrate better IMHO into the existing code base. Regards, Jörg Höhle.

2 1

Re: [iterate-devel] Accessing the result in finally clauses
by Hoehle, Joerg-Cyril 09 Jan '06

09 Jan '06

Attila Lendvai wrote: >Namely baing able to reference the loop result in finally >clauses as "it". Please try out iterate::*result-var* and report results. Couldn't you use named variables? >Any toughts? You should try to stay away from the anaphoric variable IT in LOOP. It's confusing (working in this clause, not working in that other one). Regards, Jörg Höhle.

2 1

[iterate-devel] Accessing the result in finally clauses
by Attila Lendvai 07 Jan '06

07 Jan '06

Hello, I'm missing a feature that i even tried to implement without any luck for now. Namely baing able to reference the loop result in finally clauses as "it". (iter .... (finally (return `(progn ,@it))) Any toughts? - attila

1 0