When the table name specified in the function “enabletableshareandpersistence” is used as a parameter of dummytable in the createreactivestateengine, the error “Cannot recognize the token” will be reported. And this problem only occurs in the startup script, it won’t occur if running the code in the GUI.
DolphinDB first parses a block of script for grammar checking. The parsing phase identifies errors such as undefined variables or missing function parameters, etc. The parsing phase also stores function definitions in memory for later use. After parsing, if there is no error, DolphinDB interprets the script line by line and executes the script.
The table shared by enableTableShareAndPersistence is generated at the execution stage, so createReactiveStateEngine cannot be used directly. You can use objByName to refer to the table, or add a go statement after enableTableShareAndPersistence.
The go statement divides the program into multiple code blocks. The system parses and executes code blocks in sections.
Related
I am writing a scheme script to automate my simulation process in Ansys Fluent. One of the simulation steps involves the separation of (marked) mesh cells. This separation has to take place at every time step, which is why I am trying to automate the process. The TUI command for marked cell separation is :
/mesh/modify-zones/sep-cell-zone-mark fluid "field_value_0" yes c activate-all
When I type this command in the fluent console, it works perfectly, and the separation takes place effectively. However, when I try to put this command inside a loop, it gives an error. Basically, my script contains a do-loop which runs for 'N' number of times, and each time it runs, the above command should perform the separation. But it is giving the following error:
Error: eval: unbound variable
Error Object: /mesh/modify-zones/sep-cell-zone-mark
I created a small journal file (a journal file records all the GUI and TUI operations) that contained just that command, and it worked perfectly. However, when I inserted that command within the loop in my scheme script, it stopped working.
For context: I was reading this example of trickery one can do with a shebang. It uses
#!/bin/rm
which ends up deleting the file you executed (very funny; you can extend this to create self-deleting messages). This shows that the program (rm) is invoked with the filename as an argument and therefore has access to the whole file including the shebang that invoked it.
Another trickery I've come up with is to invoke yourself as an interpreter in shebang to create an infinite loop. For example if /usr/bin/loop starts with
#!/usr/bin/loop
t should invoke itself with itself forever. Obviously at some point an error will occur and in my particular case I get:
bash: /usr/bin/loop: /usr/bin/loop: bad interpreter: Too many levels of symbolic links
It looks like it got two levels deep. Can somebody explain to me why this particular error occurs? Or maybe share some other error messages for different shells.
In particular I would like to understand why there are symbolic links involved and whether this is an implementation detail of bash or not.
why this particular error occurs?
Because when kernel tries to run the executable, tries to run /usr/bin/loop, then tries to run /usr/bin/loop, then tries to run /usr/bin/loop, etc. and finally fails with ELOOP error. It checks that.
https://elixir.bootlin.com/linux/latest/source/fs/exec.c#L1767
hare some other error messages for different shells.
While it could be, this particular errno message comes from glibc strerror.
why there are symbolic links involved
Because ELOOP is typically returned when doing input/output operations, the message mentions them. Symbolic links are not involved.
this is an implementation detail of bash or not.
Not.
I understand that interpreter translates your source code into machine code line by line, and stops when it encounters an error.
I am wondering, what does an interpreter do when you give it for loops.
E.g. I have the following (MATLAB) code:
for i = 1:10000
pi*pi
end
Does it really run through and translate the for loop line by line 10000 times?
With compilers is the machine code shorter, consisting only of a set of statements that include a go to control statement that is in effect for 10000 iterations.
I'm sorry if this doesn't make sense, I don't have very good knowledge of the underlying bolts and nuts of programming but I want to quickly understand.
I understand that interpreter translates your source code into machine code line by line, and stops when it encounters an error.
This is wrong. There are many different types of interpreters, but very few execute code line-by-line and those that do (mostly shells) don't generate machine code at all.
In general there are four more-or-less common ways that code can be interpreted:
Statement-by-statement execution
This is presumably what you meant by line-by-line, except that usually semicolons can be used as an alternative for line breaks. As I said, this is pretty much only done by shells.
How this works is that a single statement is parsed at a time. That is the parser reads tokens until the statement is finished. For simple statements that's until a statement terminator is reached, e.g. the end of line or a semicolon. For other statements (such as if-statements, for-loops or while-loops) it's until the corresponding terminator (endif, fi, etc.) is found. Either way the parser returns some kind of representation of the statement (some type of AST usually), which is then executed. No machine code is generated at any point.
This approach has the unusual property that syntax error at the end of the file won't prevent the beginning of the file from being executed. However everything is still parsed at most once and the bodies of if-statements etc. will still be parsed even if the condition is false (so a syntax error inside an if false will still abort the script).
AST-walking interpretation
Here the whole file is parsed at once and an AST is generated from it. The interpreter then simply walks the AST to execute the program. In principle this is the same as above, except that the entire program is parsed first.
Bytecode interpretation
Again the entire file is parsed at once, but instead of an AST-type structure the parser generates some bytecode format. This bytecode is then executed instruction-by-instruction.
JIT-compilation
This is the only variation that actually generates machine code. There are two variations of this:
Generate machine code for all functions before they're called. This might mean translating the whole file as soon as it's loaded or translating each function right before it's called. After the code has been generated, execute it.
Start by interpreting the bytecode and then JIT-compile specific functions or code paths individually once they have been executed a number of times. This allows us to make certain optimizations based on usage data that has been collected during interpretation. It also means we don't pay the overhead of compilation on functions that aren't called a lot. Some implementations (specifically some JavaScript engines) also recompile already-JITed code to optimize based on newly gathered usage data.
So in summary: The overlap between implementations that execute the code line-by-line (or rather statement-by-statement) and implementations that generate machine code should be pretty close to zero. And those implementations that do go statement-by-statement still only parse the code once.
Lua features hook call BEFORE every processed line. What I need is a call AFTER line is processed, so that I can check for encountered errors and so on. Is there a way to make such kind of call?
Otherwise things get a little bit confusing if error is encountered at the last line of the script. I don't get any feedback.
UPDATE #1
We want to catch both Lua errors and 'our' errors asserted via lua_error(*L) C interface, and Lua should throw correct debug info including the line number where the error occurred.
Using return hook we always get error line number -1, which is not what we want. Using any combination of pcall and any hook setup after lua_error(*L) we get either line number -1, or number of the next executed line, never a correct one.
SOLUTION#
We managed to make everything work. The thing was that Lua throws a real C exception after it detects an error, so some of our 'cleaning & finalizing' C code called from Lua operation did not execute, which messed up some flags and so on. The solution was to execute 'cleaning code' right before calling lua_error(...). This is correct and desired Lua behavior as we really want to stop executing the function once lua_error(...) is called, it was our mistake to expect any code would be executed after lua_error(...) call.
Tnx Paul Kulchenko, some of this behavior was found while trying to design a simple example script which reproduces the problem.
Try setting a return hook: it'll be called after the last line is executed.
I'm not sure debug hook is the best solution for what you are trying to do (or you need to provide more details). If you just need to check for run-time errors, why use debug hooks at all if you can run your code with pcall and get an error message that points to the line number where the error happened (or use xpcall, which also allows you to get a stack trace)? You can combine this with debug.getinfo(func, "L") to get a table whose indexes are valid line numbers for the function.
I'm debugging a matlab script that takes ~10 minutes to run. Towards the end of the script I do some i/o and simple calculations with my results, and I keep running into errors. Is there a way to start matlab from a certain sport in a script after it exits with an error--the data is still in the workspace so I could just comment out all of the code up until the error point, but I'm wondering if anyone knows a better way to go about doing this without rerunning the entire script (the ultra-lazy/inefficient way)?
Thanks,
Colorado
Yes, use dbstop. Type dbstop if error and then run your script. The minute it hits an error, it will create a breakpoint there and you're in the workspace of the script --- which means you can debug the error, save data ; anything you want! Here's a snippet from the documentation for dbstop if error --- there are other ways to do dbstop, so do check it out:
dbstop if error
Stops execution when any MATLAB program file you subsequently run produces a run-time error, putting MATLAB in debug mode, paused at the line that generated the error. The errors that stop execution do not include run-time errors that are detected within a try...catch block. You cannot resume execution after an uncaught run-time error. Use dbquit to exit from debug mode.
Double percent signs will enable 'cell mode' which lets you run little blocks of code in steps. Sounds like just what youre looking for.