| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
* Implement compileSetting() and compileSettingSeq()
* Change from magic to vmop
* better design for querySetting
Co-authored-by: genotrance <dev@genotrance.com>
|
| |
|
|
|
|
|
| |
* Revert "remove default argument for readLines (#12807) [backport]"
This reverts commit c949b81efdeb08b38224e1678ad140b7b7663b15.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Cleanup compiler code base
* Unify add calls
* Unify len invocations
* Unify range operators
* Fix oversight
* Remove {.procvar.} pragma
* initCandidate -> newCandidate where reasonable
* Unify safeLen calls
|
| | |
|
| |
|
|
|
|
| |
* added cpuTime to VM
* Hide VM-time cpuTime() behind --benchmarkVM flag
|
| | |
|
| |
|
|
| |
* fixes #12125
|
| |
|
|
|
|
|
|
| |
* hashes: implement murmur3
* refactoring; there is only one murmurHash and it works at compile-time via VM hooks
* fixes JS tests
* makes toOpenArrayByte work with C++
* make it bootstrap in C++ mode for 0.20
|
| |
|
|
|
|
|
|
| |
* Implement isExported for macros
* Reimplement isExported using VM callback mechanism
* VM does not support exceptions, use stacktrace() instead.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This plugin provides essential building block for implementing incremental computations in your programs. The idea behind incremental computations is that if you do the same calculation multiple times but with slightly different inputs you don't have to recompute everything from scratch. Also you don't want to adopt special algorithms either, you would like to write your code in standard from scratch manner and get incrementality for free when it is possible.
The plugin computes the digest of the proc bodies, recursively hashing all called procs as well . Such digest with the digest of the argument values gives a good "name" for the result. Terminology loosely follows paper "Incremental Computation with Names" link below. It works well if you have no side effects in your computations. If you have global state in your computations then you will need problem specific workarounds to represent global state in set of "names" . SideEffect tracking in Nim also useful in this topic.
Classical examples:
Dashboard with ticking data. New data arrives non stop and you would like to update the dashboard recomputing only changed outputs.
Excel spreadsheet where user changes one cell and you would like to recompute all cells that are affected by the change, but do not want to recompute every cell in the spreadsheet.
|
| | |
|
| |
|
|
| |
add tests for vmops (#9925)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
* make `mod` on floats available in the VM
* add testcase
* removed no longer needed imports
|
| |
|
|
| |
between modules
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|