I'm still learning lisp, so, when I came across this problem, it confused me.
I have a simple function where I want to print first and then read the input:
(defun ask()
(princ '?)
(read))
So, when I ran this with CLISP, it showed what was expected, it printed ?, and then, on the same line, I could write the input to the read function.
When I ran this with SBCL, it went wrong. First asks me the input and then prints ?. I figured it could be because I'm not making a newline, but I really wanted to know how can I make this work in SBCL in the same line. Also, I wonder why the result in CLISP is right and in SBCL is not.
Thank you for your help in advance.
It works in the proper order for me, but maybe your case can be connected with output buffering, performed by SBCL. You can add (finish-output) after princ to guarantee, that printing will be finished, before read is called.
For those stumbling upon this, I have found that the print / read statements seem to get out of order more often for me when running sbcl from inside an emacs shell. If I run my code from inside a gnome terminal, however, it seems to output correctly most of the time.
Related
Does anyone know how I can deobfuscate a lua script that uses xfuscator to hide it? The obfuscation looks like this. If anyone could give me a point into the right direction on how I can get this done that would bne awesome! I didnt share the source because I wanted help figuring out how to deobfusate myself and didnt want the answer!
https://gyazo.com/d2a9a2bcc602d1a1146491158271e3e6
See that long table? That's the real code. It's a pattern you see quite often with obfuscators. Other than that, keep in mind that _, __0 and such are all valid Lua identifiers, to you can have variables named like that.
_ is a function that turns a number into a character; __0 is a table that contains some standard functions. There's nothing special going on beyond that. If you see a __0[1]("Hello"), that'd be the same as print("Hello"); it just looks weird, because they put print into the __0 table at index 1.
Ultimately, the obfuscator just makes use of Lua features that people often don't understand well enough to understand what's going on. If you know the language though, it's all just smoke and mirrors.
Does anyone know how I can deobfuscate a lua script that uses xfuscator to hide it? The obfuscation looks like this. If anyone could give me a point into the right direction on how I can get this done that would bne awesome! I didnt share the source because I wanted help figuring out how to deobfusate myself and didnt want the answer!
https://gyazo.com/d2a9a2bcc602d1a1146491158271e3e6
See that long table? That's the real code. It's a pattern you see quite often with obfuscators. Other than that, keep in mind that _, __0 and such are all valid Lua identifiers, to you can have variables named like that.
_ is a function that turns a number into a character; __0 is a table that contains some standard functions. There's nothing special going on beyond that. If you see a __0[1]("Hello"), that'd be the same as print("Hello"); it just looks weird, because they put print into the __0 table at index 1.
Ultimately, the obfuscator just makes use of Lua features that people often don't understand well enough to understand what's going on. If you know the language though, it's all just smoke and mirrors.
I write a wrong expression sum(A14+A15:A19). Actually the right way for me is A14+sum(A15:A19). Curiously, the former can run as well with no error. So I spent much time to check the adequate result and find the odd phenomenon.
Besides, when I input the expression in the row 20,21 , error appears. Is that a bug? What's the meaning?
Thanks.
The sum function takes in parameters separated by ,s (not +s).
It's a little counterintuitive, since you're trying to add things together, but instead of =sum(A14+A15:A19) try = sum(A14,A15:A19).
All that being said, I assume there's a reason why you wouldn't simplify the whole thing and use =sum(A14:A19).
I am preparing overall knowledge on building a Forth interpreter and want to disassemble some of the generic Forth code words such as +, -, *, etc.
My Gforth (I currently have version 0.7.3, installed on Ubuntu Linux) will allow me to disassemble colon definitions that I make with the command see, as well as the single code word .. But when I try it with other code words, see + or see /, I get an error that says, Code +, and then I'm not able to type in my terminal anymore, even when I press control-c.
I should be able to decompile/disassemble the code words, as shown by the Gforth manual: https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Decompilation-Tutorial.html
Has anyone else had this issue, and do you know how to fix it?
Reverting to the old ptrace method did it for me.
First, from the command line as user root run:
echo 0 >/proc/sys/kernel/yama/ptrace_scope
After which see should disassemble whatever it can't decompile. Command line example (need not be root):
gforth -e "see + bye"
Output:
Code +
0x000055a9bf6dad66 <gforth_engine+2454>: mov %r14,0x21abf3(%rip) # 0x55a9bf8f5960 <saved_ip>
0x000055a9bf6dad6d <gforth_engine+2461>: lea 0x8(%r13),%rax
0x000055a9bf6dad71 <gforth_engine+2465>: mov 0x0(%r13),%rdx
0x000055a9bf6dad75 <gforth_engine+2469>: add $0x8,%r14
0x000055a9bf6dad79 <gforth_engine+2473>: add %rdx,(%rax)
0x000055a9bf6dad7c <gforth_engine+2476>: mov %rax,%r13
0x000055a9bf6dad7f <gforth_engine+2479>: mov -0x8(%r14),%rcx
0x000055a9bf6dad83 <gforth_engine+2483>: jmpq *%rcx
end-code
Credit: Anton Ertl
Most versions of SEE that I've seen are meant only for decompiling colon definitions. + and / and other arithmetic operations are usually written in assembly code and SEE doesn't know what to do with them. That's why you were getting the CODE error message: they're written in code, not Forth. There are several Forth implementations I've seen that have built in assemblers, but I don't think I've ever seen a dis-assembler. Your best bet for seeing the inner workings of + or / or other such words might be to use DUMP or another such word to get a list of the bytes in the word and either disassemble the word by hand or feed the data into an external disassembler. Or see if you can find the source code for your implementation or a similar one.
SEE is a word that has not a tightly controlled behaviour. It is a kind of best effort to show the code of a word X if invoked as
SEE X
It behaves slightly different according how difficult it is to do this. If you defined the word yourself in the session, you're pretty much guaranteed to get your code back. If it is a built in word, especially if it is a very elementary word like + , it is harder. It may look nothing much like the original definition, because of optimisation or compilation into machine code.
Specifically for gforth, if it gets hard gforth invokes the standard tools that are present on the system to analyse object files. So it may be necessary to install gdb and/or investigate how gforth tries to connect to it. For the concrete example of Ubuntu and gforth 0.7.3 Lutz Mueller gives a recipee.
.
I think SEE does it's job as designed.
There are words in FORTH defined in machine code (often called as primitives) and also there is a possibility to define machine code via assembler by the user ie.:
: MYCODE assembler memonics ;CODE
So the output of SEE shows not Code error, but that (ie.) + word was defined as machine code and one can see the disassembled mnenonics on the right of it's output.
I'm working on some legacy code in which there are a lot of WriteLn(F, '...') commands scattered pretty much all over the place. There is some useful information in these commands (what information variables contain, etc), so I'd prefer not to delete it or comment it out, but I want to stop the program from writing the file.
Is there any way that I can assign the F variable so that anything written to it is ignored? We use the console output, so that's not an option.
Going back a long long time to the good old days of DOS - If you assign 'f' to the device 'nul', then there should be no output.
assign (f, 'nul')
I don't know whether this still works in Windows.
Edit:
You could also assign 'f' to a file - assignfile (f, 'c:\1.txt') - for example.
Opening the null device and letting output go there would probably work. Under DOS, the performance of the NUL device was astonishingly bad IIRC (from what I understand, it wasn't buffered, so the system had to look up NUL in the device table when processing each byte) but I would not be at all surprised if it's improved under newer systems. In any case, that's probably the easiest thing you can do unless you really need to maximize performance. If performance is critical, it might in theory be possible to override the WriteLn function so it does nothing for certain files, but unfortunately I believe it allows syntax forms that were not permissible for any user-defined functions.
Otherwise, I would suggest doing a regular-expression find/replace to comment out the WriteLn statements in a fashion that can be mechanically restored.