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

[iterate-devel] Your message to cl-muproc-devel awaits moderator approval
by cl-muproc-devel-bounces＠common-lisp.net 17 Jan '07

17 Jan '07

Your mail to 'cl-muproc-devel' with the subject [SPAM] PRESADO CLIENTE TEVE UM PROBLEMA NO SEU EMAIL DO ORKUT VEJA E RESOLVA!!! Is being held until the list moderator can review it for approval. We're sorry, due to the volume of spam we receive most mailinglists require you to subscribe before posting. You may cancel this post (at the URL below) or waiting for the moderator to approve it. Thanks and sorry for the inconvenience. The reason it is being held: Message has implicit destination Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://common-lisp.net/cgi-bin/mailman/confirm/cl-muproc-devel/c3128d4e0369…

1 0

[iterate-devel] Your message to cl-darcs-devel awaits moderator approval
by cl-darcs-devel-bounces＠common-lisp.net 17 Jan '07

17 Jan '07

Your mail to 'cl-darcs-devel' with the subject [SPAM] PRESADO CLIENTE TEVE UM PROBLEMA NO SEU EMAIL DO ORKUT VEJA E RESOLVA!!! Is being held until the list moderator can review it for approval. We're sorry, due to the volume of spam we receive most mailinglists require you to subscribe before posting. You may cancel this post (at the URL below) or waiting for the moderator to approve it. Thanks and sorry for the inconvenience. The reason it is being held: Message has implicit destination Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://common-lisp.net/cgi-bin/mailman/confirm/cl-darcs-devel/2396f24b5665f…

1 0

[iterate-devel] Your message to cffi-devel awaits moderator approval
by cffi-devel-bounces＠common-lisp.net 17 Jan '07

17 Jan '07

Your mail to 'cffi-devel' with the subject [SPAM] PRESADO CLIENTE TEVE UM PROBLEMA NO SEU EMAIL DO ORKUT VEJA E RESOLVA!!! Is being held until the list moderator can review it for approval. We're sorry, due to the volume of spam we receive most mailinglists require you to subscribe before posting. You may cancel this post (at the URL below) or waiting for the moderator to approve it. Thanks and sorry for the inconvenience. The reason it is being held: Message has implicit destination Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://common-lisp.net/cgi-bin/mailman/confirm/cffi-devel/5d54c1244be30339d…

1 0

[iterate-devel] [SPAM] PRESADO CLIENTE TEVE UM PROBLEMA NO SEU EMAIL DO ORKUT VEJA E RESOLVA!!!
by iterate-devel 17 Jan '07

17 Jan '07

Spam detection software, running on the system "clnet", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Orkut Problemas com sua conta. Prezado usuário, Atenção [...] Content analysis details: (7.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.2 INVALID_DATE Invalid Date: header (not RFC 2822) 1.7 MSGID_FROM_MTA_ID Message-Id for external message added locally 0.7 SUBJ_ALL_CAPS Subject is all capitals 0.1 HTML_80_90 BODY: Message is 80% to 90% HTML 0.5 HTML_IMAGE_ONLY_24 BODY: HTML: images with 2000-2400 bytes of words -1.1 BAYES_40 BODY: Bayesian spam probability is 20 to 40% [score: 0.3128] 0.0 HTML_MESSAGE BODY: HTML included in message 0.2 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.3 MIME_BASE64_TEXT RAW: Message text disguised using base64 encoding 0.6 FORGED_OUTLOOK_HTML Outlook can't send HTML message only 0.1 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag 0.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format 0.0 PLING_PLING Subject has lots of exclamation marks 0.0 MIME_BOUND_NEXTPART Spam tool pattern in MIME boundary 3.9 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor.

1 0

[iterate-devel] bug and fix, multiple nil tags in tagbody
by Henrik Hjelte 05 Dec '06

05 Dec '06

The Allegro compiler won't compile some iterate forms that expand to a tagbody form that has several nil tags. At first I thought that it was a bug with allegro, since it worked fine in sbcl, and in allegros own interpreter. But on second thought and some reading of the hyperspec, I think it is the allegro compiler that is right: hyperspec: ...The statements in a tagbody are evaluated in order from left to right, and their values are discarded. If at any time there are no remaining statements, tagbody returns nil. However, if (go tag) is evaluated, control jumps to the part of the body labeled with the tag. (Tags are compared with eql.) ... and since tags are compared with eql, how can we allow several nils? If tags with the same label was allowed, the description should say something about "the first" or "the last" tag. Now it says labeled with THE tag, singularis. I have attached two bundled darcs-patches, first a testcase that shows the problem, then a solution. I have run all tests with sbcl and allegro. As usual it turns out it was more difficult to write a test than to fix the bug. /Henrik Hjelte (TAGBODY (print "hi") NIL (print "ciao") LOOP-TOP-NIL (print "hello") NIL (print "second nil") ) ; the Allegro error is : ;;Tag NIL is used more than once ;;Problem detected when processing ;; (TAGBODY (PRINT "hi") NIL...) ;;inside (BLOCK MYTEST (TAGBODY (PRINT "hi") NIL...)) ;;inside (PROGN (BLOCK MYTEST (TAGBODY # NIL...))) ;; ;; [Condition of type PARSE-ERROR] And why these nils turn up in iterate, see the testcase in the patch for an example.

3 3

[iterate-devel] envs
by Attila Lendvai 03 Aug '06

03 Aug '06

hi! for reference see this UCW common pitfall note: Consider this code in a render method: (iter (for newval in '("a" "b" "c")) (let ((newval-1 newval)) (<ucw:a :action (setf (value test) newval-1) (<:as-html newval)))) Seems like it should work fine, the variable is even rebound, but in fact it won't work due to something that can be considered a bug, but a non-trivial to fix one. segv it's iterates 'fault'. iterate walks and macroexpands its body but doesn't modify the lexical environment while it does that, so it causes with-call/cc to get expanded with the iter's env, and not the iter's env + the let binding. attila_lendvai ehh segv (fwiw arnesi's own code walker doesn't do that either) segv this explains why it works fine with loop and dolist segv and dolist* attila_lendvai is it easy to fix? i can push to iterate, but have no experience with envs segv attila_lendvai: i requires looking through the various lisps to figure out how to do that, and fixing iterate's code-walker to do the proper environment augmentation for let, let*, flet, labels, macrolet and symbol-macrolet forms. segv doable, but not trivial. segv at that point it'd probbaly be easier to rework iterate to use arnesi's code walker (which would be easier to fix since some of the non portable environment stuff is already there) attila_lendvai hm, doesn't sound like something i would chop my axe in... :) attila_lendvai iterate is non-trivial in itself segv yup. Workarounds: - use loop or dolist until iterate is fixed. - in the ajax branch you can disable with-call/cc wrapping (which is not needed here): (iter (for newval in '("a" "b" "c")) (let ((newval newval)) (<ucw:a :action (register-action () ;; :with-call/cc is #f by default (setf (value self) newval)) (<:ah newval)))) -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" Ingmar Bergman - Smultronstället (Wild Strawberries)

1 0

[iterate-devel] Texinfo version of The Iterate Manual
by Luís Oliveira 13 Jul '06

13 Jul '06

Hello, I have converted The Iterate Manual to Texinfo format. It has the advantage of producing nice browsable HTML and an info file for Emacs, etc... I hope you find it useful. You can look at the built documentation here: http://common-lisp.net/~loliveira/tmp/iterate-manual/ And here's the darcs patch: http://common-lisp.net/~loliveira/patches/texinfo-manual.patch -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

1 0

[iterate-devel] for var in non-list
by Attila Lendvai 30 Jun '06

30 Jun '06

hi! the (for var in list) clause silently skips non-lists. after a quick look i saw this in the sources: ;;; This is so the advanced user can choose how the end of a list is checked ;;; for. ;;; There are three choices for termination predicate in FOR...ON and ;;; FOR...IN, differing in their behavior on lists with a non-nil cdr: ;;; NULL: If lucky, will get an error when taking the cdr. Bad choice. ;;; ATOM: Will terminate correctly with no error. ;;; ENDP: Will give an appropriate error message. (defparameter *list-end-test* 'atom) 1) why is 'atom the default and not 'endp? it's not that hard to accidentally pass in a vector instead of a list... and then it's just silently skipped. imho 'endp as the default is much more reasonable, unless i miss something. 2) thinking this further, (for in) could even be smart enough to work on all kind sequences (possibly specializing for list at runtime to avoid elt-ing lists) and an in-list/on-list could be introduced for the current (for in) behaviour? this leads a bit far, though... any opinions? i think if there's no huge performance penalty then we should change 1 to use 'endp. -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" Ingmar Bergman - Smultronstället (Wild Strawberries)

1 0

Re: [iterate-devel] thereis vs. collect ?
by Hoehle, Joerg-Cyril 31 May '06

31 May '06

Chris Dean writes: >I'm getting an error when using thereis and collect in the >same iterate: > (iter (for x :in '(3 1 4 1 5 9)) > (thereis (evenp x)) > (collect x))) This is ill-defined. Thinking about signatures and/or functional programming helps to understand what matches and what doesn't. COLLECT means that the value is a list type. THEREIS means that the value is some element type. These are not combinable. What would be a proper type declaration for the result variable? THEREIS is combinable with ALWAYS, NEVER, IF-EXISTS: the generalized boolean finders. COLLECT is combinable with APPENDING, UNIONING etc. >I can rewrite it to bypass thereis: LEAVE bypasses every accumulation, so it always works. >or use my own accumulation variable: Indeed, the conflict only arises when collecting into the same variable: either the default one, as in (COLLECT x), or sharing an explicit one, as in (COLLECT x INTO y). > (iter (for x :in '(3 1 4 1 5 9)) > (thereis x) > (collect x :into y))) collect/y is ignored here. Did you forget (FINALLY (return y))? I'm not sure that the documentation clearly specifies when the epilogue is bypassed and when not. The above FINALLY only makes sense if THEREIS exists without running the epilogue in case of success. The implementation is like this, but one should only depend on it if its documented. I've had plans to fix specification holes in the documentation, add summarizing tables, but no time so far. Documentation patches are welcome. Regards, Jorg Hohle.

1 0

[iterate-devel] thereis vs. collect ?
by Chris Dean 31 May '06

31 May '06

I'm getting an error when using thereis and collect in the same iterate: (iter (for x :in '(3 1 4 1 5 9)) (thereis (evenp x)) (collect x))) gives Attempt to do COLLECT accumulation into a variable already being used for IF-EXISTS accumulation. I don't really understand how these variables in collect, thereis, etc are chosen, maybe soemone could enlighten me. I can rewrite it to bypass thereis: (iter (for x :in '(3 1 4 1 5 9)) (let ((result (evenp x))) (when result (leave result))) (collect x))) or use my own accumulation variable: (iter (for x :in '(3 1 4 1 5 9)) (thereis x) (collect x :into y))) but I prefer not to do either of those. Far too much typing! Cheers, Chris Dean

1 0