gtk(mm) -- connecting output of a program to a text buffer

far · 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

KingOfMalkier · n00b Joined: 03 Apr 2003 Posts: 47

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

far · Posted: Fri Jun 13, 2003 11:27 pm Post subject:

Hmm, tricky. I suppose you could design your own read-eval-print loop.

KingOfMalkier · n00b Joined: 03 Apr 2003 Posts: 47

Sorry, I'm being dense. Is that c++ psuedo-code or lisp? This sounds promising, but it's got me a little confused. :oops:

far · Posted: Sat Jun 14, 2003 2:06 pm Post subject:

KingOfMalkier · n00b Joined: 03 Apr 2003 Posts: 47

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?

KingOfMalkier · n00b Joined: 03 Apr 2003 Posts: 47

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!

far · 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:

KingOfMalkier · n00b Joined: 03 Apr 2003 Posts: 47

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!

KingOfMalkier · n00b Joined: 03 Apr 2003 Posts: 47

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?

far · Posted: Wed Jun 18, 2003 10:46 am Post subject:

KingOfMalkier · n00b Joined: 03 Apr 2003 Posts: 47

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.

KingOfMalkier · n00b Joined: 03 Apr 2003 Posts: 47

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.