Comments:<Riastradh> Proper tail recursion is a particular space safety guarantee.<nowhere_man> what is the problem with special variables?<Riastradh> nowhere_man, you must bind them and then restore them after control has returned; storage is needed to remember their original values.<eructate> OK. but not everybody accepts that nomenclature, because to call something proper bakes a value judgement in the cake,.<eructate> it would be like calling static typing "good typing"<nyef> (I'll admit that special variables are a bit of a red herring, as there are possible solutions to allow binding them while still allowing tail recursion.)<Riastradh> eructate, `proper tail recursion' has been pretty well established, I think, at least since the first Lisp that guaranteed it.<nowhere_man> I can't see the interference...<eructate> it's not safe for space if you have to remember something new on each call.<lisppaste> dionisos pasted "endless LOOP?" at http://paste.lisp.org/display/36278<dionisos> I'm using a LOOP construct, but it keeps looping endlessly. Can someone explain why?<Riastradh> dionisos, I think you mean FOR, not WITH.<dionisos> ah!<nowhere_man> eructate: but isn't proper TCO only about not eating stack?<Riastradh> nowhere_man, `remembering something new on each call' *is* occupying space on the stack.

<eructate> whether it's in the stack or the heap makes no algorithmic difference<dionisos> Riastradh: man, that took me a whole evening. thanks!<nowhere_man> but in this case isn't it something the programmer asked for?<eructate> you can easily make an implementation that doesn't have a stack. instead of stack frames, "activation records" are heap allocated only.<eructate> the point is whether those records can always be reused by tail calls.<housel> William Clinger's PLDI 1998 paper "Proper tail recursion and space efficiency" defines precisely what is meant by proper tail recursion<nowhere_man> when I call a function, I don't ask for space to be used<Riastradh> Yes, nowhere_man, but the point is that you can't bind a special *and* in the body of the binding have proper tail recursion.<pkhuong> Riastradh: darius bacon's got a complicated hack to support TCO with specials. Assignment makes the exercise pretty painful...<nowhere_man> OK<Riastradh> I think I remember your pointing me to that, and I think I remember having some objection to it, but I can't remember any details.<Riastradh> (What a persuasive rebuttal, eh?)<pkhuong> Riastradh: probably not me, but even if it is flawless, it's complicated.<Riastradh> OK, perhaps someone else pointed me to it.<Riastradh> This? <http://www.accesscom.com/~darius/writings/dynatail.html><pkhuong> Riastradh: to a certain extent, the problem is similar to TCO w/ block/return or catch/throw.<Riastradh> ?<pkhuong> I think so.<eructate> ok, this stuff is not news =)<pkhuong> eructate: why would it be?<eructate> there are a lot of things you can do if you don't care about about speed<pkhuong> eructate: and even more if you don't care about correctness!<eructate> or debug info.<jjkola> night<Xach> hello.<Exotics_user> hi all<Exotics_user> EXOTICS ADULT FORUM ::::::::::: http://exotics.ezbbforum.com .....<valizas> pjb: i wonder if I could lounch emacs from within an xterm and let emacs think it is working in a console like style<pjb> valizas: yes, indeed you'll need to launch an xterm and have curses work on the pty hooked to that terminal.<valizas> s/lounch/launch/<pjb> I don't see the relationship between ncurses and emacs.<valizas> let's see, I lounch an xterm, from there, I lounch emacs+slime, which is desired to render within the xterm, then I load cl-ncurses, does it make sense ?<valizas> pjb mmmmm<valizas> s/lounch/launch/<valizas> s/lounch/launch/g <grin><pjb> well, it doens't make much sense, because emacs uses the terminal.<pjb> Why do you want to do the user interface in ncurses when you have emacs to implement the user interface?<valizas> pjb: well I 'd like to write ncurses apps<valizas> CL ones , not elisp ones<valizas> at least for now :)<pjb> What you could do is to launch your cl implementation in an xterm, to run swank in it, and to connect to it from an emacs launched from X or another xterm.<pjb> Then you will be able to debug the cl-ncurse code displaying on one terminal from another X window running emacs+slime.<Thas> pjb's method is how I did it when I was playing around with roguelike dungeon generation and line-of-sight algorithms ("lethack")<Thas> It works well.<valizas> pjb: sounds good, but too complex for me by now. Look, I opened emacs directly from a tty console, and for now it seems like a solution<valizas> pjb: I sort of get lost in the intricacies of swank, ptys etc <shrug><pjb> valizas: it's rather simple. There are several tutorials showing how to do it, and even a video (slime.mov)<valizas> wow<valizas> things usually are simpler than one might imagine<valizas> thanks !<valizas> i'll go step by step<pjb> basically, you launch your cl, load swank, and start the swank server. Then in emacs, you use M-x slime-connect insteaad of M-x slime, to connect to it.<valizas> pjb: thank you very very much. That expands my symbolic world :)<valizas> in order to load swank, i eval (swank) ?<valizas> or require it ?<pjb> require might work. (asdf:oos 'asdf:load-op :swank)<valizas> yeah !<valizas> pjb: (asdf:oos 'asdf:load-op :swank) yields debugger invoked on a ASDF:MISSING-COMPONENT in thread #<THREAD "initial thread" {A6DD671}>: component "swank" not found<pjb> Well, obviously you need to "install" the asdf system first.<pjb> Put the directory where you installed slime in the asdf:*central-registry* list .<valizas> pjb: i guess I installed and loaded it correctly ...

<valizas> oh, ok<valizas> well I don't want to bother you with simple details, let me bang my head myself in order to learn :)<pjb> valizas: there are good manuals for asdf, asdf-install and slime.<pjb> google for asdf manual and for slime manual.<valizas> pjb: i'll browse through them all<Urfin> valizas: comine them and reimplement eliza? ;)<Urfin> combine rather<valizas> Urfin: that would make a fair trade-off ;-) maybe the proffesor accept such a thesis <grin><valizas> in fact, i'm a "combine"-type mind<valizas> asdf:*central-registry* seems to eval to a progn-like ***pr, is that sort of true?<pjb> it's a list of pathnames or forms that evaluate to pathnames.<valizas> (eval (car asdf:*central-registry*)) evals a pathname, as I expected<pjb> (mapcar (function eval) asdf:*central-registry*)<valizas> pjb: right<valizas> pjb: that works fine ! thanks. this is fun :)<lisppaste> slyrus pasted "stack weirdness" at http://paste.lisp.org/display/36286<valizas> pjb: after loading swank, what else should be done in order to make swank listen on standard (?) port 4005 ?<pjb> I don't remember. This is indicated in the tutorials.<valizas> pjb: ok, thanks<beslyrus> weird... it's like somebody (the kernel?) locked those pages out from underme. I don't _think_ this is the guard page stuff at work.<pjb> Have you browsed http://www.cliki.net/ ?<valizas> pjb: not for this very issue. I'll do<pjb> IIRC there's a specific tutorial there.<NightBird> when I redefine a class, how do I have Lisp call a function on the old instances of that class to promote them up to the new version of the class?<antifuchs> clhs update-instance-of-redefined-class<specbot> Sorry, I couldn't find anything for update-instance-of-redefined-class.<antifuchs> mop update-instance-of-redefined-class<antifuchs> (hrmpf)<pjb> clhs update-instance-for-redefined-class<specbot> http://www.lispworks.com/reference/HyperSpec/Body/f_upda_1.htm<antifuchs> thanks (:<valizas> pjb: (swank:create-server :port 4005 :dont-close t) does. thanks<NightBird> thank you<pjb> :-)<NightBird> how would I specify an :initarg slot using make-instance?<_deepfire> wow, i happened to meet something i'm nost sure maps into a standard flow of things:<_deepfire> Unable to display error condition: The value VISUAL::VISUAL is not of type SB-KERNEL:CLASSOID<NightBird> sweet<_deepfire> does it mean something weird? (i would expect that objects of types established by defstruct are "classoids")<NightBird> I have no idea<Athas> _deepfire: I have seen that error with elderly SBCLs. Which version do you use?<_deepfire> Athas, debian's 1.0<_deepfire> this was caused by myself specifying parameters to a lispbuilder-sdl function in wrong order<_deepfire> i would expect an error, but not such an suspiciously sounding one<NightBird> woo! done with my seminar paper...<NightBird> now I just have a week to get together a power point...<NightBird> but first... I think I'll order a pizza<valizas> in slime-hotwo, it says regarding its features that although slime works similarly in most implementations, "though for overall featurefulness CMUCL > SBCL > OpenMCL ~= LispWorks at present.". Does anyone know what subtleties differ sbcl/slime from cmucl/slime ?<chandler> I'm not sure that's up to date, actually.<valizas> chandler thanks.<beslyrus> hmm... the apple kernel guys say it's always wrong to allocate or free memory in a signal handler.<Riastradh> Doing *anything* but modifying volatile globals in a signal handler is a nasal demon waiting to erupt in a programmer's violent sneezing fit.<chandler> Of course, such restrictions are widely violated.<Riastradh> ...which is why so many people sneeze every *day* around the world, of course!<beslyrus> lovely.<Riastradh> ...oh, actually, that's not right. There's a big list of system routines that are allowed to be called from signal handlers.<Riastradh> <http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html><beslyrus> right, and malloc and mprotect aren't on there.<Riastradh> Yep.<beslyrus> which are two things we definitely do from signal handlers.<Riastradh> Too bad! Isn't Unix lovely?<beslyrus> well, we can blame Unix, or we can blame SBCL...<beslyrus> but, yeah :(<Riastradh> Or better, we can continue to blame Unix and then fix SBCL...<Modius> Anyone on right now have much knowledge of Franz and/or Lispworks?<penultimatefire> for my AI project I'm going to tackle tetris<penultimatefire> embed or extend lisp?<lnostdal> (cffi) how do you guys handle cases where a function returns char* .. but in cases where there is no result it returns NULL?<lnostdal> like for instance: http://developer.gnome.org/doc/API/2.0/gobject/gobject-Type-Information.html#g-type-name<lnostdal> for instance: (typeName 134821256) => GtkWindow ... but if i type a random number representing a type that does not exist it gives me a sb-kernel::memory-fault-error .. i assume it is trying to parse the "C-string"<Thas> lnostdal: do something like (defctype string-or-nil :pointer), declare a method on translate-from-foreign to Do The Right Thing, then tell defcfun that gtypename returns a "string-or-nil"<lnostdal> thanks - i'll look into that