|
osdir.com mailing list archive |
|
Subject: Re: Re: clear-input not working from dos box? - msg#00038List: lisp.clisp.general> * On the subject of "Re: [clisp-list] Re: clear-input not working from dos > box?" > * Sent on Mon, 11 Nov 2002 13:33:40 -0800 > * Honorable don-sourceforge@xxxxxxxxxxxxxxxx (Don Cohen) writes: > > > > But I notice that input seems to be discarded by the top level > > > read-eval-print loop. Which I suppose is the same thing. > > > That is, if I type > > > (read)3 > > > I don't immediately see 3 returned. Rather it waits for input. > > > Then if I type > > > 4 > > > it returns 4. > > > > CLISP REPL works like this: first we read a line and check for commands > > (like "help" ":w" &c), then, if there was no command, we create a > > concatenated stream out of the line and *STANDARD-INPUT* and read from > > there. I.e., the first line can contain at most 1 form. > I don't see why that means the rest of the first line is discarded. > If I type > (read)3 > then the concatenated stream still contains "(read)3", right? > If I do (read)(read) from that stream shouldn't I get the 3 on the > second read? your READ does not read from the concatenated stream but from *STANDARD-INPUT*. note that read_form() does not set *STANDARD-INPUT*. > > An obvious alternative is to read from *STANDARD-INPUT* and then look up > > the form read in the *KEY-BINDINGS* table. > > > > The problem is that this way you will not be able to evaluate symbols > > like "help" because they will be interpreted as commands. > Doesn't this have the same problem? > If I type help that could either be the name of a variable or a > command. I guess for the variable I have to type something like > (progn help) or > package:help or maybe > help ? indeed. right now, a space before the variable name or a package prefix works, but if we just READ from *STANDARD-INPUT* without the READ-LINE trick, only PROGN will work. > I've occasionally noticed problems like > - I type abort and get another level of error cause ABORT has no value haven't seen this for quite a while. I thought I fixed that... > - I type abort and get another level of error cause BORT has no value. never seen that! -- Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> If you try to fail, and succeed, which have you done? ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf Thread at a glance:
Previous Message by Date: click to view message previewRe: Re: clear-input not working from dos box?> > But I notice that input seems to be discarded by the top level > > read-eval-print loop. Which I suppose is the same thing. > > That is, if I type > > (read)3 > > I don't immediately see 3 returned. Rather it waits for input. > > Then if I type > > 4 > > it returns 4. > > CLISP REPL works like this: first we read a line and check for commands > (like "help" ":w" &c), then, if there was no command, we create a > concatenated stream out of the line and *STANDARD-INPUT* and read from > there. I.e., the first line can contain at most 1 form. I don't see why that means the rest of the first line is discarded. If I type (read)3 then the concatenated stream still contains "(read)3", right? If I do (read)(read) from that stream shouldn't I get the 3 on the second read? > An obvious alternative is to read from *STANDARD-INPUT* and then look up > the form read in the *KEY-BINDINGS* table. > > The problem is that this way you will not be able to evaluate symbols > like "help" because they will be interpreted as commands. Doesn't this have the same problem? If I type help that could either be the name of a variable or a command. I guess for the variable I have to type something like (progn help) or package:help or maybe help ? I've occasionally noticed problems like - I type abort and get another level of error cause ABORT has no value - I type abort and get another level of error cause BORT has no value. I never looked into them, but it sounds related. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf Next Message by Date: click to view message previewgdi module problem solvedI determined the cause of the problem. Following is the incorrect code: object p; begin_callback(); p = allocate_fpointer(hWnd); pushSTACK(p); end_callback(); begin_callback(); funcall(O(onCreate),1); end_callback(); A stackcheck is done between the pushSTACK and the funcall, and of course, my fpointer was stored on the stack. Following is the corrected code: object p; begin_callback(); p = allocate_fpointer(hWnd); pushSTACK(p); funcall(O(onCreate),1); end_callback(); However, I still don't understand why linking in my module causes a failure with SAFETY>1 on entry to clisp. Dan Stanger ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf Previous Message by Thread: click to view message previewRe: Re: clear-input not working from dos box?> > But I notice that input seems to be discarded by the top level > > read-eval-print loop. Which I suppose is the same thing. > > That is, if I type > > (read)3 > > I don't immediately see 3 returned. Rather it waits for input. > > Then if I type > > 4 > > it returns 4. > > CLISP REPL works like this: first we read a line and check for commands > (like "help" ":w" &c), then, if there was no command, we create a > concatenated stream out of the line and *STANDARD-INPUT* and read from > there. I.e., the first line can contain at most 1 form. I don't see why that means the rest of the first line is discarded. If I type (read)3 then the concatenated stream still contains "(read)3", right? If I do (read)(read) from that stream shouldn't I get the 3 on the second read? > An obvious alternative is to read from *STANDARD-INPUT* and then look up > the form read in the *KEY-BINDINGS* table. > > The problem is that this way you will not be able to evaluate symbols > like "help" because they will be interpreted as commands. Doesn't this have the same problem? If I type help that could either be the name of a variable or a command. I guess for the variable I have to type something like (progn help) or package:help or maybe help ? I've occasionally noticed problems like - I type abort and get another level of error cause ABORT has no value - I type abort and get another level of error cause BORT has no value. I never looked into them, but it sounds related. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf Next Message by Thread: click to view message previewCompile and Debugging optionsIs there a document, it the clisp distribution that covers the various safety and debugging options available for clisp compilation? Thanks, Dan Stanger ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf Loading Comments...
|
|
