View previous topic :: View next topic |
Author |
Message |
far Guru
Joined: 10 Mar 2003 Posts: 394 Location: Stockholm, Sweden
|
Posted: Fri Jun 13, 2003 6:39 pm Post subject: |
|
|
You can't know whether clisp is expecting input.
Why do you need to wait for a prompt? _________________ The Porthole Portage Frontend |
|
Back to top |
|
|
KingOfMalkier n00b
Joined: 03 Apr 2003 Posts: 47
|
Posted: Fri Jun 13, 2003 11:10 pm Post subject: |
|
|
Right now, it seems easiest to do a lot of things if I know when the prompt gets displayed. Then I can disable input until it is (preventing gibberish from the user being entered in with the output). I also set a TextMark at the end of the prompt. This helps for sending clisp only the command entered by the user, not some of the previous output as well. I highlight errors in red text, output in blue, and leave the prompt and what the user types black, again using the mark for the prompt. Basically it seems like I can make my program more efficient and error-proof if I know when I'm at a prompt. Perhaps I can do all the above without knowing I'm officially at a prompt, but I don't see how! Oh, one reason I'm doing that junk with a home-made buffer is because on_new_input sometimes adds a character to the buffer, and sometimes and a big huge chunk of them. I assume this is due to the threading |
|
Back to top |
|
|
far Guru
Joined: 10 Mar 2003 Posts: 394 Location: Stockholm, Sweden
|
Posted: Fri Jun 13, 2003 11:27 pm Post subject: |
|
|
Hmm, tricky. I suppose you could design your own read-eval-print loop.
Code: | (loop (print (eval (read)))) |
The above is the most basic one, but you could make one that has easily parsable output. _________________ The Porthole Portage Frontend |
|
Back to top |
|
|
KingOfMalkier n00b
Joined: 03 Apr 2003 Posts: 47
|
Posted: Sat Jun 14, 2003 2:03 pm Post subject: |
|
|
Sorry, I'm being dense. Is that c++ psuedo-code or lisp? This sounds promising, but it's got me a little confused. |
|
Back to top |
|
|
far Guru
Joined: 10 Mar 2003 Posts: 394 Location: Stockholm, Sweden
|
Posted: Sat Jun 14, 2003 2:06 pm Post subject: |
|
|
KingOfMalkier wrote: | Is that c++ psuedo-code or lisp? |
It's non-pseudo lisp. Try running it in clisp. _________________ The Porthole Portage Frontend |
|
Back to top |
|
|
KingOfMalkier n00b
Joined: 03 Apr 2003 Posts: 47
|
Posted: Sat Jun 14, 2003 2:42 pm Post subject: |
|
|
Ah! I think I've got it. I can print the eval plus "SOMETHING THAT WILL NEVER HAPPEN IN CLISP!" and use that as a delimiter. Though I'm afraid I'm writing my program to aid in learning lisp, so I really don't know much lisp stuff. I tried just typing "k" into the loop and the error broke out of the loop, can those errors be handled somehow in clisp? |
|
Back to top |
|
|
KingOfMalkier n00b
Joined: 03 Apr 2003 Posts: 47
|
Posted: Sat Jun 14, 2003 3:22 pm Post subject: |
|
|
Uh-oh. I was just looking at what I said, and I think it might run into the same problem I'm having. If I understand correctly, print would print the results of eval after the eval finished. If part of the command prompted for input, I think the same problem would occur. Hopefully I'm wrong! |
|
Back to top |
|
|
far Guru
Joined: 10 Mar 2003 Posts: 394 Location: Stockholm, Sweden
|
Posted: Sat Jun 14, 2003 3:29 pm Post subject: |
|
|
I don't know much Common Lisp myself, but it's fun to play with.
Try this:
Code: | (setq *evalhook* (lambda (x y) (let ((result (eval x)))
(format t "This was the question: ~S~%" x)
(format t "This is the answer: ~S" result)
result))) |
_________________ The Porthole Portage Frontend |
|
Back to top |
|
|
KingOfMalkier n00b
Joined: 03 Apr 2003 Posts: 47
|
Posted: Sat Jun 14, 2003 6:12 pm Post subject: |
|
|
Unfortunately, I'm still quite confused with how exactly to use those bits of lisp. Fortunately, I don't think I need them! I just displaying everything as soon as I get it, then worrying about text color (output, user input, error -- all different colors) after it's already on the buffer. I've also done some gtk shenanigans so that everytime the text goes off the bottom of the buffer, it automatically scrolls down. This seems to be the best way of making sure any possible prompt is visible (not sitting below the textview, out of sight) and not waste a lot of resources scrolling after every character or something ridiculous. I might not be able to do every feature I wanted, namely preventing input during output, but I can do nearly all of them. And even though I won't be using the lisp stuff, thank you for trying! |
|
Back to top |
|
|
KingOfMalkier n00b
Joined: 03 Apr 2003 Posts: 47
|
Posted: Wed Jun 18, 2003 12:47 am Post subject: |
|
|
Ok, once again...I lied. Right now I want two things from my program. The first is that it maintains all the functionality of clisp, and the second is that it does so with a reasonably small performance hit when compared to clisp by itself. Currently I can only do one of these at a time. It's kind of bizarre, anytime I fix one problem, the other resurfaces. I think I've finally found a middle road, it's a long shot. I can use getline, instead of just get, and a homemade read-eval-print loop like you suggested to insert a newline after the prompt (to make it display at the correct time), then just automatically back up the cursor to where it should be. This gets around what appears to be the major performance hit (reading and displaying one character at a time), but destroys error handling and (read). Error handling I'm sure can be fixed, but I don't know about the (read) statement, it wants input, but doesn't display any uniform prompt. If I could overload (I don't know the exact Lisp term for doing this) the (read) statement so that it outputs a prompt, I think I'd be alright. Googling for how to do this has been fruitless. Any theories? |
|
Back to top |
|
|
far Guru
Joined: 10 Mar 2003 Posts: 394 Location: Stockholm, Sweden
|
Posted: Wed Jun 18, 2003 10:46 am Post subject: |
|
|
KingOfMalkier wrote: | This gets around what appears to be the major performance hit (reading and displaying one character at a time), |
I think updating the display is what takes time, you could try to update the display only ten times per second or so, by connecting to Glib::SignalTimeout signal, although I would call that premature optimization.
Quote: | Error handling I'm sure can be fixed, but I don't know about the (read) statement, it wants input, but doesn't display any uniform prompt. If I could overload (I don't know the exact Lisp term for doing this) the (read) statement so that it outputs a prompt, I think I'd be alright. |
Redefining the read function might not cover all cases. The behaviour of clisp can be controlled in lots of ways. I suggest you read Common Lisp the Language. Error handling can also be redefined.
An alternative to redefining the read-eval-print loop is to wrap each user command like this: Code: | (let ((result (USER INPUT GOES HERE))) (format t "Result: ~S~%" result) result) |
You only display the user input. Of course, it won't solve the problems with prompts from inside the program.
I managed to redefine (read) Code: | (setq old-read #'read)
(defun read () (format t "prompt> ") (apply old-read ())) |
But you have to type "(continue)" after that. It seems you are not really supposed to redefine (read). _________________ The Porthole Portage Frontend |
|
Back to top |
|
|
KingOfMalkier n00b
Joined: 03 Apr 2003 Posts: 47
|
Posted: Wed Jun 18, 2003 4:01 pm Post subject: |
|
|
Your probably right that updating the display is what takes time. Know that I think of it, when I read a character at a time, and didn't diplay anything until I hit a prompt, GClisp was nearly as speedy as clisp. Thanks for the recommended reading, I grabbed the html version of that and I'll read through it as I try to find a clever way of updating the TextBuffer when I need to, and only when I need to. Hopefully one path will yield an answer. Thanks again, and I'll let you know when I get something. |
|
Back to top |
|
|
KingOfMalkier n00b
Joined: 03 Apr 2003 Posts: 47
|
Posted: Thu Jun 19, 2003 4:39 pm Post subject: |
|
|
Eureka! I was thinking about what you mentioned with the timeout signal and I thought of a solution. I have a timeout that fires every quarter of a second, but it gets restarted everytime a character is read. I made a few changes to the thread_method so that it only sends the new_input signal if it encounters a line-end character or the ">" that might be a prompt. The timer fires a quarter second after any character has been added, taking care of the (read) prompts. I've applied to sourceforge for a project, and hopefully (assuming they accept it) I'll have a link and an ebuild within a few days. It's far from feature-packed, and there's still a lot I have planned but *cross fingers* I think I'll have a working program soon. |
|
Back to top |
|
|
|