* Changed argument exceptions so that they used the nameof() operator for parameter names
* Update IQSocket.cs
---------
Co-authored-by: John Doe <john@doe>
Co-authored-by: Martin-Molinero <martin@quantconnect.com>
* Append the full stacktrace to the algorithm loading exception message.
* Remove exception message loader duplication
Co-authored-by: Martin Molinero <martin.molinero1@gmail.com>
- Adding `WorkerThread` class, wrapper for a worker thread that will
execute given `Actions`.
- Algorithm related code (`Construction`, `Initialization`,
`Execution` will be executed by the same `WorkerThread` instance,
this is required for `Python` debugging.
When the algorithm type in config.json was not found, Loader.cs
would throw a confusing error message. Modified the error message
to make it clearer.
Previous error message: "Unable to resolve multiple algorithm types
to a single type...". New error message: "Algorithm type name not
found,or unable to resolve multiple algorithm types to a single type...".
Improves the message when the Loader cannot resolve the algorithm to load. It happens when the assemblies don't have a QCAlgorithm class that match the algorithm name or you have 2-of them so Lean doesn't know which one to backtest.
The possible Loader exceptions are thrown as `AlgorithmSetupException` to mach the pattern for exceptions during initialization.
Move the logic of importing the module into AlgorithmPythonWrapper where it is wrapped.
Throws an exception if the script does not have a class that inherits from either QCAlgorithm not QCAlgorithmFramework.
Adds a check for OnData being defined in the module. If not, OnData from the base class will not be called (it causes stack overflow otherwise)
Use interpreter.GetMessageHeader(e) instead of e.Message to produce to collated exception message containing the messages from inner exceptions.
Add the DllNotFoundPythonExceptionInterpreterTests to the test project.
In order to access the custom data classes, the module containing them was added to the ObjectActivator. This was unnecessary if it wasn't a custom data algorithm.
Also, this operation would not be taken into account if the custom data class were defined after the algorithm was created: this is the case for QuantBook.
We refactor how custom data is handled: a new class was added to provide a instance creation factory that creates an instance of each python custom type.
- Adds log to display the python version the algorithm is using.
- Fixes python algorithms that were failing because of small subtleties
like leading zeroes.
- Updates pythonnet with a version compiled with python 3.6 flags
- Changes in DockerfileFoundation: we now use miniconda to manage the python
environment.
- Took the opportunity to add NTLK (#1349), Tensorforce (#1369) and
PyTorch/Pyro (#1385).
- Changes readme in Algorithm.Python to show steps to install miniconda
These two path expressions evaluate to the same physical directory, differing only by the trailing separator char:
- new FileInfo(assemblyPath).DirectoryName
- AppDomain.CurrentDomain.BaseDirectory
Calling Impromptu.ActLike<IAlgorithm> to make the python object acts like a IAlgorithm caused multiple AlgorithmPythonWrapper objects running in parallel to hold the same python object. That call was removed and instead we access the python object directly.
- Removes AlgorithmPythonUtil.py and add its code directly in AlgorithmPythonWrapper.cs
- Clean up: removes all references to IronPython and ImpromptuInterface
TrtCreatePythonAlgorithm looks for compiled python (*.pyc) before it fetches python scripts (*.py). If we have used the build script, we have the compiled objects and make a faster load.
Ricardo Andrés Marino Rojas