Commands which are invoked from LISP are having trouble with buffered IO streams, how to turn it off? I found only flushing functions, which are good for nothing in this situation.
You cannot do that
There is no portable way to turn buffering on and off, and for a very good reason: buffered i/o is orders of magnitude faster.
You should not try to do that
You might be able to find out how to do it in the implementation you use, but it will be a waste of time - you will soon realize that it was a mistake. Please do yourself a favor and do not retrace my steps - I tried that almost 20 years ago.
There is a better way
When you are done writing, just flush the output.
You can encapsulate this using classes or macros, so that no additional typing would be involved.
It is better for many reasons
Please note that the approach I suggest will make your code more readable - it will require you to specify your message boundaries explicitly.
Remember, you write code for others (and yourself 6 months from now!) to read, modify, and debug.
So, I finally found the problem (maybe bug??)
Form looks like this (SBCL API)
(run-program "sudo" '("mv" "foo.txt" "/usr/bin")
:search t
:output t
:input t
:wait t)
This works exactly how I wanted, problem was that instead of t in input and output args, I specified *standard-input* and *standard-output* which caused not proper working of command (if invoked program wanted some input from user like sudo for example).
No idea why, but at least, it works now.
Related
I type the following in a repl (clozure common lisp)
(defparameter test 1)
The repl responds with test
Now I enter:
(format *standard-input* "(defparameter test 2)")
Repl outputs (defparameter test 2) followed by nil.
But the value of test remains unchanged at 1.
Why is this? Isn't writing to the variable *standard-input* the same as entering the text at the repl?
How do I achieve the desired evaluation?
Some context:
I'm making a custom frontend for common lisp development using sockets. I need to write to standard input because even though I can evaluate code using eval and read, I cannot debug the code on errors.
For instance entering 1 to unwind the stack and return to top level is impossible without writing to standard input (as far as I can tell). I have the output parts figured out.
*standard-input* is an input stream, as its name implies. It's a stream you read from, not one you write to. It may be an output stream as well, but if it is then writing to it is not going to inject strings into the REPL.
I'd suggest looking at SLIME or SLY if you want to understand how to have REPLs & debuggers which interact with things down streams. In particular SWANK is probably the interesting bit to understand, or the equivalent for SLY, which is SLYNK (or slynk, not sure of the capitalisation). The implementations of these protocols in various Lisps are not entirely trivial, but the implementations exist already: you don't have to write them. Screen-scraping an interface made for humans to interact with is almost always a terrible approach: it's only reasonable when there is no better way, and in this case there is a better way, in fact there are at least two.
I would like to know Why we need to compile the program of progress 4GL? Really what is happening behind there? Why we are getting .r file after compiled the program? When we check the syntax if its correct then we will get one message box 'Syntax is correct' how its finding the errors and showing the messages.Any explanations welcome and appreciated.
Benefits of compiled r-code include:
Syntax checking
Faster execution (r-code executes faster)
Security (r-code is not "human readable" and tampering with it will likely be noticed)
Licensing (r-code runtime licenses are much less expensive)
For "how its finding the errors and showing the messages" -- at a high level it is like any compiler. It evaluates the provided source against a syntax tree and lets you know when you violate the rules. Compiler design and construction is a fairly advanced topic that probably isn't going to fit into a simple SO question -- but if you had something more specific that could stand on its own as a question someone might be able to help.
The short answer is that when you compile, you're translating your program to a language the machine understands. You're asking two different questions here, so let me give you a simple answer to the first: you don't NEED to compile if you're the only one using the program, for example. But in order to have your program optimized (since it's already at the machine language level) and guarantee no one is messing with your logic, we compile the code and usually don't allow regular users to access the source code.
The second question, how does the syntax checker work, I believe it would be better for you to Google and choose some articles to read about compilers. They're complex, but in a nutshell what they do is take what Progress expects as full, operational commands, and compare to what you do. For example, if you do a
Find first customer where customer.active = yes no-error.
Progress will check if customer is a table, if customer.active is a field in that table, if it's the logical type, since you are filtering if it is yes, and if your whole conditions can be translated to one single true or false Boolean value. It goes on to check if you specified a lock (and default to shared if you haven't, like in my example, which is a no-no, by the way), what happens if there are multiple records (since I said first, then get just the first one) and finally what happens if it fails. If you check the find statement, there are more options to customize it, and the compiler will simply compare your use of the statement to what Progress can have for it. And collect all errors if it can't. That's why sometimes compilers will give you generic messages. Since they don't know what you're trying to do, all they can do is tell you what's basically wrong with what you wrote.
Hope this helps you understand.
I've got a legacy TP5 program. It compiles and runs OK using TP7. I'd like to capture and log some of the write / writeln statements. I can do a global search-and-replace for write and writeln, so I don't mind code changes like that. It does use some formated output:
write(r:4:2)
so I'd like to keep that.
I don't know any way to capture write/writeln other than writing to a file, then reading each line back and writing it again :~( But it occured to me that that is very like writing to a stream (introduced in Tp5.5), then streaming copies to multiple outputs.
Has anyone done this before? Is it possible? Is there another way?
Afaik it is possible, and commonly done in FPC and Delphi, TP's successors. The only trouble is that the TEXTREC isn't exported by TP, so you have to copy it from sources to somewhere.
The textrec has a bunch of procedure variables (like function pointers in C) that you can set to your own functions to process I/O. Setting these variables is what Assign() does.
The problem is finding the room to store the state (e.g. the pointer to the stream) though. IIRC the TP textrec is tighter than Delphi's.
Anyway, search for a unit StreamIO by Peter Below. This is a FPC/Delphi unit that you will have to adopt, but at least it demonstrates the principles. It would be better to simply migrate to something newer anyway. Maybe SWAG has a TP equivalent too.
I'm very new to unix programming, so please bear with me. :)
I'd like to pass data between two processes. I was going to use named pipes, but read about these "half-duplex" pipes, and it was very intriguing, so I figured that I would give them a try first.
I have two issues with these pipes thus far:
I haven't figured out how to get execlp to run another application from my child process
Even if I could, debugging is tough because I've only been able to set breakpoints in the parent process
I'm sure there are reasons for these issues. I am starting to wonder if it makes sense to just forget about them and just use named pipes so I can debug each application in a separate instance of eclipse.
If there is any relevant information, please let me know. The code I am using is essentially what it found on tldp.org.
EDIT -- I renamed my question to be about unix pipes in general. I had assumed that for named pipes, I wouldn't have to use fork(), but all of the examples I have seen so far require it. So regardless of half-duplex or named pipes, I'm going to need to be able to debug the child process somehow!
EDIT #2 -- this example clearly shows that what I had seen before (on an IBM link) regarding named pipes wasn't necessarily true.
I recommend two tools:
strace -ff should give you a trace of all significant events, allowing you to examine in detail what's going on, namely, all reads and writes;
lsof allows you to dump file descriptors of involved processes, clearly showing what is connected to what else and, in particular, if you forgot to close() some descriptors and the whole thing deadlocks.
Newbie Common Lisp question here.
Is there a way to reset the state of the environment? What I mean, is there some command that brings the REPL back to the same state it was right after it started up, that is, uninterning all variables, functions, etc. Or if that's not in the Common Lisp standard, is there some extension in SBCL (the implementation I use) to do that?
(EDIT: I know that in SLIME, M-x slime-restart-inferior-lisp does that but I wonder if there's a way without restarting the process)
Not in general, no. I occasionally want to do something like that, so my workflow is generally to create a new package to hold whatever project I'm starting, then when I want to reset things I use DELETE-PACKAGE. I never do any work in the CL-USER package, since different implementations have different things stuffed into it.
Use C-c M-o, as given in REPL menu's Clear Buffer