I took a look at this question and believe I understand the solution, except for the following:
try get_all_lines(Device)
after file:close(Device)
end.
Looking in the documentation, specifically the 7.19 Try section, it looks like one would typically use after clauses as a failsafe block to execute regardless of the execution of a conditional block. If that is a correct assumption, why would the given example use after when, not only is there not a conditional block, there's not a block at all! It just looks like the try get_all_lines(Device) block is completely empty, and an unnecessary after clause was appended. Am I misinterpreting the example, or could this code be written better?
The block isn't empty, it contains a single function call: get_all_lines(Device). If io:get_line inside this function throws an exception (e.g. because the file was deleted while reading it, then get_all_lines will throw as well, and you need to close the file both in this case and when the function returns without an exception. This is precisely what after is for.
Related
Is there a way to print what the condition of an if statement evaluates to in LLDB ? Or the value value of any conditionnal expression at some point in of the execution of the program ?
I know how to print a variable with var or print, how to print an array's values with parray 10 arr,
how to get the return value of a function by stepping-out of it and thread info but I
don't know how to get the value of a conditional expression.
Any debugging tips much appreciated.
Edit : I just learned from a comment below that one can just use print with some conditionnal expression to see what it evaluates to.
Still, is there somme command that allows to see that without typing the whole condition and have lldb evalluate it again from the state of the variables but to print what a specific condition has evaluated to at some specific point in the program ?
There isn't such a command.
It would be pretty hard to write one that would be fully general since individual source lines are very often not complete statements, and we'd have to do something sensible in that case, etc...
Also, I don't think you actually want "evaluate this line as an expression", you want something more complex. I imagine you have a source line like:
if (!strncmp(token_table[i].token, input , token_table[i].len))) {
That's not an expression in C, so we couldn't evaluate the whole source line directly. You really want "find anything that looks like it's a conditional in this source line, pull it out and evaluate that." That looks tractable in simple cases like the one above, but in the general case this starts to get complicated, and it would be hard to get it right.
OTOH, it would be pretty straightforward to write a Python command that only handles simple instances of an if conditional, using the SB API's to pull out the source line, then some Python parsing to pull out the condition, then SBFrame.EvaluateExpression to evaluate it. So you could certainly use the Python API's to whip up something that's good enough for your purposes.
More details about the Python affordances in lldb are here:
https://lldb.llvm.org/use/python-reference.html
and the lldb API's are documented here:
https://lldb.llvm.org/python_reference/index.html
I need to read a lot of data from .txt files using dlmread which works fine in 80% cases the problem is for the 20% which are not in the general rule and dlm read fails due to random occurrences of unexpected data(mostly multiple header-lines (strings) present in row).
What I need is a way to still make my script run by skipping the file if dlmread fails (like by storing some boolean variable that would let me know it has failed)
OR
another more generalised function in MATLAB that I can run to read the data and automate it anyway.
If you can even partially solve my problem it would be of great help.
PS: For some cases the row numbers are predictable where the header lines are present.
also I have tried importdata but it takes too long.
If you have a function that potentially errors, and you want to simply skip it if it does, you should use the keyword try (and possibly catch). It's sort of like an if / else except that it doesn't crash if a function errors.
try
dlmdata = dlmread('Invalid call') % Will crash
catch
dlmdata = 0;
warning('Call to dlmread failed')
end
Warning: Call to dlmread failed
Note that you don't need the catch part, but it's good practice. It's often needed to assign a value to variables, in order to avoid "Undefined function or variable 'dlmdata'".
So I've been stewing over this for a long time, thinking about it. Here's a code example first, and then I'll explain it.
:main
dostuff
otherlabel
:otherlabel
dostuff
Alright so in this example, main is where the code starts, and it 'calls' the label 'otherlabel'. This is really just a shortcut for a jump command that changes execution to a different location in memory. My problem though is, how do I handle these labels so that they don't have to be declared before they are called?
At the moment, I'm doing a single step compilation reading straight from the source and outputting the bytecode. I am simply handling labels and adding them to a dictionary when I find them. And then I replace 'otherlabel' with a jump command to the correct location in code. But in this case that code wouldn't compile.
I've thought of a few ways to do this:
First is handling labels before anything else but this requires me to do everything in two steps and I have to deal with the same code twice, this slows down the process and just seems like a mess.
Second is queueing up the label calls until AFTER I've gone through the entire file and compiled everything else and then dealing with them, this seems much cleaner.
I'm writing this in C so I'd rather not implement complex data structures, I'm looking for the most straight forward way to handle this.
Use multiple passes. One pass isn't going to suffice for a scripting language, especially when you are getting to the more complex structures.
In a first pass, before compiling, construct your dictionary of labels.
In a later pass, when the compiling happens, just use that dictionary.
You could use "backpatching", although it sounds like that's what you've tried already; and it could be consstrued as a complex structure.
When you encounter a call to an undefined label, you emit the jump with a blank address field (probably into a buffer, otherwise this becomes the same as "multipass" if you have to re-read the file to patch it); and you also store a pointer to the blank field in a "patch-up" list in the dictionary. When you encounter the label definition, you fill-in all the blanks in the list, and proceed normally.
This may sound like a silly question but I could see no mention anywhere of this particular problem. Basically:
I want to execute a Lua script line by line, primarily to have the ability to pause/resume execution anytime and anywhere I want. What I do is simple: load a chunk with luaL_loadbuffer() and then issue a lua_pcall().
Thing is... How can I properly detect Lua blocks in order to execute them atomically?
For instance, suppose there's a function in the script -- by executing the file line by line with the method described above, I can't seem to have a way to properly recognize the function, and in consequence its contents are loaded and called one by one.
I can imagine that one solution would be to manually handle a stack where I push control keywords I can recognize in the script ("function", "if", "do", etc) and their corresponding "end" clause if I find nested blocks. Once I push the final "end" I call the entire block, but that sounds simply awful. Surely there must be a better way of doing this.
Hope it makes some sense, and thank you!
Please take a look at Lua coroutines to implement that functionality for scripting game entities. The idea is to yield the coroutine in the sleep() and waitforevent() routines you mentioned, and then resume later (e.g. after a timeout or event occurs).
Use lua_sethook().
Note that you probably do want to experiment with what exact hook call granularity you need. I'd recommend executing chunks of bytecode instructions instead. One really long line may contain many instructions.
I am creating the file using Createfile function.
The C program is working fine but I am unable to see the created file in the respective folder.
Also "view hidden files" option is checked.
You can check if the function worked correctly by checking out the returned HANDLE value.
edit: A C program continues to function (incorrectly though) if a functions fails. It's therefore very important to check each and every returned HANDLE.
edit: The returned HANDLE should not be INVALID_HANDLE_VALUE. (But I can imagine that NULL isn't good either).
Two things to check for. Number one, did it actually succeed? From the docs:
Return Value
If the function succeeds, the return value is an open handle to the specified file, device, named pipe, or mail slot.
If the function fails, the return value is INVALID_HANDLE_VALUE. To get extended error information, call GetLastError.
Number two, are you looking in the right place. Frequently, people who run their code from within an IDE don't realise that their current working directory is not always what they think it is. You can system("cd"); or something similar to see what it actually is.
Or, you can use absolute pathnames to ensure the file is being created at the right place (for testing, that is - you should never use absolute paths for production code).
If neither of those two suggestions help, you should post the code that shows the particular problem. Preferably enough so that we don't have to come back and ask for more.