You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The contract is that if LPython compiles your code and there are no runtime errors (in Debug mode), then it will behave exactly as in Python (and you can also use Release mode and it will be very fast and still give exactly the same answer on the same input). You have to use bounds checking in Debug mode.
The same issue is with any runtime indexing, especially arrays. It can be out of bounds and we can't be checking it all the time in Release mode. The same with integer overflow. We have to be using smaller integers like i32 or i64, but they can overflow. There is nothing we can do about it, and we should not be checking it all the time, it will be slow. But in Debug mode I think we can check it reasonably fast.
We can have a ReleaseSafe mode which keeps all these runtime checks in place, but otherwise optimizes everything out as much as it can. In this mode, it would indeed not fail silently. But the ReleaseSafe mode will almost for sure be slower than just Release mode.
The default option in LPython should be Debug mode. The Debug mode must have all runtime safety options on. In this Debug mode, you get very fast compilation, and safe runtime behavior. No silent surprises. Beautiful runtime error messages with stack traces. If you don't get any runtime error and things compiles (obviously), then it will behave just like in CPython.
Then we have two more options: Release and ReleaseSafe. ReleaseSafe should never get any segfaults or undefined/random behavior, assuming there are no bugs in our compiler, but it might not be as fast as Release. The Release mode is the fastest, but you have to check each of your inputs in Debug mode (or ReleaseSafe mode). This mode is great for computational tasks where (or if) you don't mind it might segfault. As a backend in a webbrowser code you should use ReleaseSafe to prevent exploits.
We can call these modes: Debug, ReleaseSafe, ReleaseFast.
Both of the releases will be used in production. Webbrowser will use ReleaseSafe, an HPC computational code would use ReleaseFast.
Also, if webassembly is safe (?), then we could use ReleaseFast with a WASM output as well. It just depends on what you want to do and what runtime guarantees you need.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
The contract is that if LPython compiles your code and there are no runtime errors (in Debug mode), then it will behave exactly as in Python (and you can also use Release mode and it will be very fast and still give exactly the same answer on the same input). You have to use bounds checking in Debug mode.
The same issue is with any runtime indexing, especially arrays. It can be out of bounds and we can't be checking it all the time in Release mode. The same with integer overflow. We have to be using smaller integers like i32 or i64, but they can overflow. There is nothing we can do about it, and we should not be checking it all the time, it will be slow. But in Debug mode I think we can check it reasonably fast.
We can have a ReleaseSafe mode which keeps all these runtime checks in place, but otherwise optimizes everything out as much as it can. In this mode, it would indeed not fail silently. But the ReleaseSafe mode will almost for sure be slower than just Release mode.
The default option in LPython should be Debug mode. The Debug mode must have all runtime safety options on. In this Debug mode, you get very fast compilation, and safe runtime behavior. No silent surprises. Beautiful runtime error messages with stack traces. If you don't get any runtime error and things compiles (obviously), then it will behave just like in CPython.
Then we have two more options: Release and ReleaseSafe. ReleaseSafe should never get any segfaults or undefined/random behavior, assuming there are no bugs in our compiler, but it might not be as fast as Release. The Release mode is the fastest, but you have to check each of your inputs in Debug mode (or ReleaseSafe mode). This mode is great for computational tasks where (or if) you don't mind it might segfault. As a backend in a webbrowser code you should use ReleaseSafe to prevent exploits.
We can call these modes: Debug, ReleaseSafe, ReleaseFast.
Both of the releases will be used in production. Webbrowser will use ReleaseSafe, an HPC computational code would use ReleaseFast.
Also, if webassembly is safe (?), then we could use ReleaseFast with a WASM output as well. It just depends on what you want to do and what runtime guarantees you need.
The text was updated successfully, but these errors were encountered: