MetaCall: The ultimate polyglot programming experience.

Overview
METACALL

MetaCall Polyglot Runtime

MetaCall.io | Install | Docs

MetaCall allows calling functions, methods or procedures between multiple programming languages.

sum.py

def sum(a, b):
  return a + b

main.js

const { sum } = require('./sum.py');

sum(3, 4); // 7

shell

metacall main.js

MetaCall is a extensible, embeddable and interoperable cross-platform polyglot runtime. It supports NodeJS, Vanilla JavaScript, TypeScript, Python, Ruby, C#, Java, WASM, Go, C, C++, Rust, D, Cobol and more.

Install

The easiest way to install MetaCall is the following:

curl -sL https://raw.githubusercontent.com/metacall/install/master/install.sh | sh

For more information about other install methodologies and platforms or Docker, check the install documentation.

Examples

You can find a complete list of examples in the documentation. If you are interested in submitting new examples, please contact us in our chats.

Comments
  • Review the design of the extensions

    Review the design of the extensions

    We should take into account that extensions can fail to load, this is not shown in the current design as the entry point of each extension returns void. In order to avoid this, we should return an int or maybe better, an enum with some different states (in case of using the enum it should be published in some place in order to have it available in the extension API or metacall API). Once this is done, we should refactor the load_extension in order to have that into account and check for errors.

    Related to the path inside the load_extension, I think it is fine to have it there, but then we should change the deploy path from the extensions (i.e where are they installed, and where are they built) so it works properly.

    We should also add some test for the load_extension.

    This is related to: https://github.com/metacall/core/pull/287

    @rxbryan

    opened by viferga 11
  • Dynamic execution path and load from file function

    Dynamic execution path and load from file function

    Description

    • java loader execution_path - Add execution path function and bootstrap_execution_path functions
    • java_load_from_file - compiling class and storing in an handle

    Please include a summary of the change and which issue is fixed. List any dependencies that are required for this change.

    Fixes #(issue_no)

    Type of change

    • [ ] Bug fix (non-breaking change which fixes an issue)
    • [ ] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
    • [ ] This change requires a documentation update
    • [ ] Documentation update

    Checklist:

    • [ ] My code follows the style guidelines (clang-format) of this project.
    • [ ] I have performed a self-review of my own code.
    • [ ] I have commented my code, particularly in hard-to-understand areas.
    • [ ] I have made corresponding changes to the documentation.
    • [ ] My changes generate no new warnings.
    • [ ] I have added tests/screenshots (if any) that prove my fix is effective or that my feature works.
    • [ ] I have tested the tests implicated (if any) by my own code and they pass (make test or ctest -VV -R <test-name>).
    • [ ] If my change is significant or breaking, I have passed all tests with ./docker-compose.sh &> output and attached the output.
    • [ ] I have tested my code with OPTION_BUILD_SANITIZER and OPTION_TEST_MEMORYCHECK.
    • [ ] I have tested with Helgrind in case my code works with threading.
    • [ ] I have tested with Helgrind in case my code works with threading.
    • [ ] I have run make clang-format in order to format my code.

    If you are unclear about any of the above checks, have a look at our documentation here

    opened by ketangupta34 6
  • signal handlers are not working when using node loader

    signal handlers are not working when using node loader

    🐛 Bug Report

    I am using metacall shared library to embed nodejs code into my c++ application inside my nodejs code I am spawning a child process and I am connecting signal handlers inside c++ when the child process which is invoked from nodejs is finished SIGCHLD handler is not called in C++

    Steps to Reproduce

    Using the attached child_process_sample.zip The sample has three cases

    1. run nodejs executable with JS file that spawn "ps" process
    2. run metacall python loader and run py code that spawn "ps" process
    3. run metacall node loader and run JS code that spawn "ps" process

    the C++ SIGCHLD handler will be called for cases 1 & 2 and will not be called for case#3

    To reproduce:

    1. Prepare build environment setenv GCC_PATH <path to gcc directory that contains bin & lib directories> setenv NODE_EXE <path to node executable> setenv METACALL_BUILD <path to metacall build that contains lib directory>

    The used metacall build has node loader and py loader

    1. cd child_process_sample
    2. make
    3. ./invoke_app.sh
    4. the three cases will be run sequentially, you can notice that the log message "c++: received signal SIGCHLD" will be printed for cases 1 & 2 and will not be printed for case#3

    Context (Environment)

    OS: CentOS Linux 7 Metacall: 0.2.22 gcc: 5.4.0 nodejs: 10.19.0

    opened by amagdy19 5
  • add base support for cli plugin architecture

    add base support for cli plugin architecture

    Description

    add base support for cli plugin architecture add support for building metacallcli-bootstrap

    Type of change

    • [ ] Bug fix (non-breaking change which fixes an issue)
    • [x] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
    • [x] This change requires a documentation update
    • [ ] Documentation update

    Checklist:

    • [x] I have performed a self-review of my own code.
    • [x] I have commented my code, particularly in hard-to-understand areas.
    • [ ] I have made corresponding changes to the documentation.
    • [x] My changes generate no new warnings.
    • [ ] I have added tests/screenshots (if any) that prove my fix is effective or that my feature works.
    • [ ] I have tested the tests implicated (if any) by my own code and they pass (make test or ctest -VV -R <test-name>).
    • [ ] If my change is significant or breaking, I have passed all tests with ./docker-compose.sh build &> output and attached the output.
    • [ ] I have tested my code with OPTION_BUILD_SANITIZER or ./docker-compose.sh test &> output and OPTION_TEST_MEMORYCHECK.
    • [ ] I have tested with Helgrind in case my code works with threading.
    • [x] I have run make clang-format in order to format my code and my code follows the style guidelines.

    If you are unclear about any of the above checks, have a look at our documentation here.

    opened by rxbryan 5
  • Add metacall include path and metacall library path in c loader

    Add metacall include path and metacall library path in c loader

    Description

    Add metacall include path so including metacall/metacall.h #include <metacall/metacall.h> works. Add metacall library path so libtcc can find libmetacall.so.

    Fixes #(issue_no)

    Type of change

    • [ ] Bug fix (non-breaking change which fixes an issue)
    • [x] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
    • [ ] This change requires a documentation update
    • [ ] Documentation update

    Checklist:

    • [x] I have performed a self-review of my own code.
    • [x] I have commented my code, particularly in hard-to-understand areas.
    • [ ] I have made corresponding changes to the documentation.
    • [ ] My changes generate no new warnings.
    • [ ] I have added tests/screenshots (if any) that prove my fix is effective or that my feature works.
    • [ ] I have tested the tests implicated (if any) by my own code and they pass (make test or ctest -VV -R <test-name>).
    • [ ] If my change is significant or breaking, I have passed all tests with ./docker-compose.sh build &> output and attached the output.
    • [ ] I have tested my code with OPTION_BUILD_SANITIZER or ./docker-compose.sh test &> output and OPTION_TEST_MEMORYCHECK.
    • [ ] I have tested with Helgrind in case my code works with threading.
    • [ ] I have run make clang-format in order to format my code and my code follows the style guidelines.

    If you are unclear about any of the above checks, have a look at our documentation here.

    opened by rxbryan 5
  • All Python code exits with a `SystemError` after an exception has occurred

    All Python code exits with a `SystemError` after an exception has occurred

    🐛 Bug Report

    When running python code through the CLI, once there's a python error (for example, a TypeError), all subsequent python calls, even to the same function, fail with:

    Python Error: [Type: <class 'SystemError'>]: _PyEval_EvalFrameDefault returned a result with an error set
    

    Expected Behavior

    Subsequent correct python code should run as expected.

    Current Behavior

    No python code runs after an exception has occurred,

    Possible Solution

    The error/exception needs to be cleared. Not sure how.

    Steps to Reproduce

    1. Create a python file named hello.py with:
      def add(a, b):
          return a + b
      
      print("Hello world")
      
    2. Run the following in metacallcli:
      load py hello.py
      call add(5, 10)
      call add(1, "a")
      call add(1, 1)
      
    3. Notice that the first call runs correctly giving the output 15
    4. The 2nd call fails with:
      Error: Python Error: [Type: <class 'TypeError'>]: unsupported operand type(s) for +: 'int' and 'str'
      Traceback not available
      
    5. The 3rd and all subsequent calls fail with:
      Error: Python Error: [Type: <class 'SystemError'>]: _PyEval_EvalFrameDefault returned a result with an error set
      Traceback not available
      (null)
      

    Context (Environment)

    I built metacall from source with python loader support. I was trying out metacall with a simple python example when this issue occurred.

    Detailed Description

    N/A

    Possible Implementation

    N/A

    bug 
    opened by Samyak2 5
  • completed copy for exception_create

    completed copy for exception_create

    Description

    Implemented copy for exeception_create function.

    Type of change

    • [ ] Bug fix (non-breaking change which fixes an issue)
    • [ ] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
    • [ ] This change requires a documentation update
    • [ ] Documentation update

    Checklist:

    • [x] My code follows the style guidelines (clang-format) of this project.
    • [x] I have performed a self-review of my own code.
    • [ ] I have commented my code, particularly in hard-to-understand areas.
    • [ ] I have made corresponding changes to the documentation.
    • [ ] My changes generate no new warnings.
    • [ ] I have added tests/screenshots (if any) that prove my fix is effective or that my feature works.
    • [x] I have tested the tests implicated (if any) by my own code and they pass (make test or ctest -VV -R <test-name>).
    • [ ] I have tested my code with OPTION_BUILD_SANITIZER and OPTION_TEST_MEMORYCHECK.
    • [ ] I have tested with Helgrind in case my code works with threading.

    If you are unclear about any of the above checks, have a look at our documentation here

    opened by siv2r 5
  • Implementing LLVM loader

    Implementing LLVM loader

    🚀 Feature

    See the ideas page for more information.

    To Do The following checklists will become more specific in future [ ] import llvm libraries [ ] initialize [ ] introspect

    duplicate 
    opened by siv2r 5
  • Types like function, class, object not mentioned on docs

    Types like function, class, object not mentioned on docs

    📚 Documentation

    The types Future, Function, Class, Object are not mentioned in the documentation of Type System under Reflect.

    These are present in the codebase (under reflect module) https://github.com/metacall/core/blob/52572bc3de960da922a4032df2f6b4d6be21221a/source/reflect/source/reflect_type_id.c#L40-L45

    Is there any specific reason for this? I can add them if needed :)

    opened by siv2r 5
  • Unable to compile source with cmake

    Unable to compile source with cmake

    When trying to compile with the latest version of cmake (3.20.0) it gives the following errors and warnings:

    CMake Error at CMakeLists.txt:31 (string): string no output variable specified

    CMake Warning (dev) at CMakeLists.txt:81 (add_definitions): Policy CMP0005 is not set: Preprocessor definition values are now escaped automatically. Run "cmake --help-policy CMP0005" for policy details. Use the cmake_policy command to set the policy and suppress this warning. This warning is for project developers. Use -Wno-dev to suppress it.

    CMake Warning (dev) at CMakeLists.txt:81 (add_definitions): Policy CMP0005 is not set: Preprocessor definition values are now escaped automatically. Run "cmake --help-policy CMP0005" for policy details. Use the cmake_policy command to set the policy and suppress this warning. This warning is for project developers. Use -Wno-dev to suppress it.

    CMake Warning (dev) at CMakeLists.txt:81 (add_definitions): Policy CMP0005 is not set: Preprocessor definition values are now escaped automatically. Run "cmake --help-policy CMP0005" for policy details. Use the cmake_policy command to set the policy and suppress this warning. This warning is for project developers. Use -Wno-dev to suppress it.

    CMake Warning (dev) at CMakeLists.txt:81 (add_definitions): Policy CMP0005 is not set: Preprocessor definition values are now escaped automatically. Run "cmake --help-policy CMP0005" for policy details. Use the cmake_policy command to set the policy and suppress this warning. This warning is for project developers. Use -Wno-dev to suppress it.

    CMake Warning (dev) at CMakeLists.txt:81 (add_definitions): Policy CMP0005 is not set: Preprocessor definition values are now escaped automatically. Run "cmake --help-policy CMP0005" for policy details. Use the cmake_policy command to set the policy and suppress this warning. This warning is for project developers. Use -Wno-dev to suppress it.

    -- Lib version CMake Error at version/CMakeLists.txt:21 (include): include could not find requested file:

    Warnings
    

    CMake Error at version/CMakeLists.txt:27 (include): include could not find requested file:

    SecurityFlags
    

    CMake Error at version/CMakeLists.txt:33 (string): string no output variable specified

    CMake Error at version/CMakeLists.txt:34 (string): string no output variable specified

    CMake Error at version/CMakeLists.txt:57 (source_group_by_path): Unknown CMake command "source_group_by_path".

    CMake Warning (dev) in CMakeLists.txt: No cmake_minimum_required command is present. A line of code such as

    cmake_minimum_required(VERSION 3.20)
    

    should be added at the top of the file. The version specified may be lower if you wish to support older CMake versions for this project. For more information run "cmake --help-policy CMP0000". This warning is for project developers. Use -Wno-dev to suppress it.

    opened by samarthpusalkar 5
  • Remove the need of set up environment variables in CLI or MetaCall

    Remove the need of set up environment variables in CLI or MetaCall

    🚀 Feature

    MetaCall has the need to set up multiple environment variables ( https://github.com/metacall/core/blob/develop/docs/README.md#42-environment-variables ), for example, in order to find the global configuration or plugins. This can be basically avoided if we use a trick for locating libmetacall.so / metacall.dll / libmetacall.dylib from the executable itself. This solution is platform dependent but we can use it just as a fallback in case the environment variables are not detected, so MetaCall is still able to work as normally it does in multiple platforms.

    The trick is the following:

    1. First of all, we get the list of the modules that the current executable (usually metacallcli) is linked too, this includes dynamic loaded modules, as in the case (in the future) we will support MetaCall to be imported from python.exe or node.exe ( https://github.com/metacall/core/issues/231 ), and in this case libmetacall.so / metacall.dll / libmetacall.dylib will be linked dynamically by dlopen or LoadLibrary.
    2. Once we get the list, we try to find libmetacall.so / metacall.dll / libmetacall.dylib (taking into account versioning in the future if any, probably we need some way of parsing the library name or finding a symbol inside of the library in order to verify that it is the correct library).
    3. We extract the absolute path of this module, and then we can obtain all the modules from there. For example, let's say we find MetaCall library in: /home/custom/metacall/lib/libmetacall.so, we can take this path and obtain all the environment variables from it. All the *_LIBRARY_PATH would be pointing to /home/custom/metacall/lib and the configuration CONFIGURATION_PATH can be deduced from it too and it will be pointing to /home/custom/metacall/configurations/global.json.

    With this we remove all the need for setting up metacall and we improve the user experience with it, specially when using Ports because it is problematic to set them up properly.

    Something we must review and it's critical in order to make this work properly, some loaders rely on getting the environment variables by themselves, specially in node loader or typescript loader with bootstrap.js and bootstrap.ts. We should remove the environment variable access from them and pass them from the C/C++ side, so it works too. This can be done easily because in the initialize step of each loader, we pass the configuration with the required paths as values, we can take them from there and pass them into JavaScript land.

    Some of the reference for implementing this can be found here:

    • Windows: https://docs.microsoft.com/en-us/windows/win32/psapi/enumerating-all-modules-for-a-process
    • Linux: https://linux.die.net/man/3/dl_iterate_phdr
    • MacOs: https://stackoverflow.com/questions/10009043/dl-iterate-phdr-equivalent-on-mac (specially on: https://stackoverflow.com/a/10053641 )

    The function for finding the module path can be implemented either on dynlink or in portability (dynlink can be interesting because it contains suffixes and prefixes for the dynamic libraries for each platform).

    enhancement good first issue c/c++ 
    opened by viferga 4
  • add base support for exporting objects and classes in node_loader

    add base support for exporting objects and classes in node_loader

    Description

    add base support for exporting objects and classes in node_loader

    Fixes #(issue_no)

    Type of change

    • [ ] Bug fix (non-breaking change which fixes an issue)
    • [ ] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
    • [ ] This change requires a documentation update
    • [ ] Documentation update

    Checklist:

    • [ ] I have performed a self-review of my own code.
    • [ ] I have commented my code, particularly in hard-to-understand areas.
    • [ ] I have made corresponding changes to the documentation.
    • [ ] My changes generate no new warnings.
    • [ ] I have added tests/screenshots (if any) that prove my fix is effective or that my feature works.
    • [ ] I have tested the tests implicated (if any) by my own code and they pass (make test or ctest -VV -R <test-name>).
    • [ ] If my change is significant or breaking, I have passed all tests with ./docker-compose.sh build &> output and attached the output.
    • [ ] I have tested my code with OPTION_BUILD_SANITIZER or ./docker-compose.sh test &> output and OPTION_TEST_MEMORYCHECK.
    • [ ] I have tested with Helgrind in case my code works with threading.
    • [ ] I have run make clang-format in order to format my code and my code follows the style guidelines.

    If you are unclear about any of the above checks, have a look at our documentation here.

    opened by rxbryan 0
  • Handling kill signals while running python with metacall

    Handling kill signals while running python with metacall

    🐛 Bug Report

    On pressing Ctrl-C the kill signal doesnt behave the way it should when previously a python program is loaded

    image

    Expected Behavior

    Should exit on pressing Ctrl-C

    Current Behavior

    A Python keyboard interrupt is thrown instead

    Steps to Reproduce

    1. Open the metacall Cli by typing metacall on your terminal
    2. Type load py test.py (It doesnt matter if it passes or fails)
    3. Press Ctrl-C The error is shown
    bug 
    opened by lucasace 0
  • Segmentation fault in TypeScript loader tests related to logs

    Segmentation fault in TypeScript loader tests related to logs

    🐛 Bug Report

    This bug gets shown with logs but probably it's a race condition related to threading, specially in destruction of TypeScript loader. This has to be reviewed carefully because the behavior is not deterministic. I have achieved to remove all the logs, making a no-op the log_write macro, and then the error happened in a different place, but I do not have those logs right now.

    I am leaving here ./docker-compose.sh test logs in order to provide basic info about the bug. This should be reviewed with either helgrind or thread sanitizer. docker-compose.sh.test.output.txt

    bug 
    opened by viferga 2
  • Memory Leak in Windows for `metacall_python_exception_test`

    Memory Leak in Windows for `metacall_python_exception_test`

    🐛 Bug Report

    Memory Leak in Windows for metacall_python_exception_test

    Logs

    Spoiler (Click to View)
    Running the tests...
    Invalid value for '--test-output-size-failed': 3221000000
    Test project D:/a/metacall-core-detached/metacall-core-detached/build
          Start  1: preprocessor-test
          Start  2: environment-test
     1/58 Test  #1: preprocessor-test ..............................   Passed    1.27 sec
          Start  3: log-test
     2/58 Test  #2: environment-test ...............................   Passed    1.33 sec
          Start  4: log-custom-test
     3/58 Test  #4: log-custom-test ................................   Passed    0.13 sec
          Start  5: adt-set-test
     4/58 Test  #5: adt-set-test ...................................   Passed    0.11 sec
          Start  6: adt-trie-test
     5/58 Test  #3: log-test .......................................   Passed    0.26 sec
          Start  7: adt-vector-test
     6/58 Test  #6: adt-trie-test ..................................   Passed    0.02 sec
          Start  8: adt-map-test
     7/58 Test  #7: adt-vector-test ................................   Passed    0.02 sec
          Start  9: reflect-value-cast-test
     8/58 Test  #8: adt-map-test ...................................   Passed    0.02 sec
          Start 10: reflect-function-test
     9/58 Test  #9: reflect-value-cast-test ........................   Passed    0.03 sec
          Start 11: reflect-object-class-test
    10/58 Test #10: reflect-function-test ..........................   Passed    0.02 sec
          Start 12: reflect-scope-test
    11/58 Test #11: reflect-object-class-test ......................   Passed    0.02 sec
          Start 13: reflect-metadata-test
    12/58 Test #12: reflect-scope-test .............................   Passed    0.02 sec
          Start 14: dynlink-test
    13/58 Test #13: reflect-metadata-test ..........................   Passed    0.02 sec
          Start 15: serial-test
    14/58 Test #14: dynlink-test ...................................   Passed    0.02 sec
          Start 16: configuration-test
    15/58 Test #15: serial-test ....................................   Passed    0.02 sec
          Start 17: portability-path-test
    16/58 Test #16: configuration-test .............................   Passed    0.02 sec
          Start 18: metacall-logs-test
    17/58 Test #17: portability-path-test ..........................   Passed    0.02 sec
          Start 19: metacall-load-memory-test
    18/58 Test #18: metacall-logs-test .............................   Passed    0.15 sec
          Start 20: metacall-load-configuration-test
    19/58 Test #19: metacall-load-memory-test ......................   Passed    0.41 sec
          Start 21: metacall-handle-export-test
    20/58 Test #20: metacall-load-configuration-test ...............   Passed    0.35 sec
          Start 22: metacall-test
    21/58 Test #21: metacall-handle-export-test ....................   Passed    0.34 sec
          Start 23: metacall-distributable-test
    22/58 Test #22: metacall-test ..................................   Passed    0.38 sec
          Start 24: metacall-cast-test
    23/58 Test #23: metacall-distributable-test ....................   Passed    0.35 sec
          Start 25: metacall-init-fini-test
    24/58 Test #24: metacall-cast-test .............................   Passed    0.34 sec
          Start 26: metacall-ducktype-test
    25/58 Test #25: metacall-init-fini-test ........................   Passed    0.35 sec
          Start 27: metacall-inspect-test
    26/58 Test #26: metacall-ducktype-test .........................   Passed    0.34 sec
          Start 28: metacall-configuration-exec-path-test
    27/58 Test #27: metacall-inspect-test ..........................   Passed    0.38 sec
          Start 29: metacall-clear-test
    28/58 Test #28: metacall-configuration-exec-path-test ..........   Passed    0.38 sec
          Start 30: metacall-python-test
    29/58 Test #29: metacall-clear-test ............................   Passed    0.38 sec
          Start 31: metacall-python-object-class-test
    30/58 Test #30: metacall-python-test ...........................   Passed    0.39 sec
          Start 32: metacall-python-gc-test
    31/58 Test #31: metacall-python-object-class-test ..............   Passed    0.39 sec
          Start 33: metacall-python-dict-test
    32/58 Test #32: metacall-python-gc-test ........................   Passed    0.58 sec
          Start 34: metacall-python-varargs-test
    33/58 Test #33: metacall-python-dict-test ......................   Passed    0.35 sec
          Start 35: metacall-python-fail-test
    34/58 Test #34: metacall-python-varargs-test ...................   Passed    0.34 sec
          Start 36: metacall-python-relative-path-test
    35/58 Test #35: metacall-python-fail-test ......................   Passed    0.37 sec
          Start 37: metacall-python-without-functions-test
    36/58 Test #36: metacall-python-relative-path-test .............   Passed    0.37 sec
          Start 38: metacall-python-builtins-test
    37/58 Test #37: metacall-python-without-functions-test .........   Passed    0.35 sec
          Start 39: metacall-python-async-test
    38/58 Test #39: metacall-python-async-test .....................   Passed    0.34 sec
          Start 40: metacall-python-exception-test
    39/58 Test #38: metacall-python-builtins-test ..................   Passed    0.65 sec
          Start 41: metacall-map-test
    40/58 Test #40: metacall-python-exception-test .................***Failed    0.34 sec
    [==========] Running 1 test from 1 test suite.
    [----------] Global test environment set-up.
    [----------] 1 test from metacall_python_exception_test
    [ RUN      ] metacall_python_exception_test.DefaultConstructor
    [Wed Aug 31 10:27:33] #3444 [ 104 | metacall_initialize | D:\a\metacall-core-detached\metacall-core-detached\source\metacall\source\metacall.c ] @Debug : MetaCall default logger to stdout initialized
    [Wed Aug 31 10:27:33] #3444 [ 114 | metacall_initialize | D:\a\metacall-core-detached\metacall-core-detached\source\metacall\source\metacall.c ] @Debug : Initializing MetaCall
    [Wed Aug 31 10:27:33] #3444 [ 77 | configuration_initialize | D:\a\metacall-core-detached\metacall-core-detached\source\configuration\source\configuration.c ] @Debug : Global configuration loaded from D:/a/metacall-core-detached/metacall-core-detached/build/configurations/global.json
    [Wed Aug 31 10:27:33] #3444 [ 44 | plugin_descriptor_create | D:\a\metacall-core-detached\metacall-core-detached\source\plugin\source\plugin_descriptor.c ] @Debug : Loading plugin: rapid_json_seriald
    [Wed Aug 31 10:27:33] #3444 [ 57 | plugin_descriptor_create | D:\a\metacall-core-detached\metacall-core-detached\source\plugin\source\plugin_descriptor.c ] @Debug : Loading plugin symbol: rapid_json_serial_impl_interface_singleton
    [Wed Aug 31 10:27:33] #3444 [ 172 | metacall_initialize | D:\a\metacall-core-detached\metacall-core-detached\source\metacall\source\metacall.c ] @Information : Set MetaCall log level to Debug
    [Wed Aug 31 10:27:33] #3444 [ 77 | loader_manager_impl_script_paths_initialize | D:\a\metacall-core-detached\metacall-core-detached\source\loader\source\loader_manager_impl.c ] @Debug : Loader script path: D:/a/metacall-core-detached/metacall-core-detached/build/scripts\
    [Wed Aug 31 10:27:33] #3444 [ 191 | loader_initialization_register_plugin | D:\a\metacall-core-detached\metacall-core-detached\source\loader\source\loader.c ] @Debug : Loader __metacall_host__ registered at position (0) in thread #3444
    [Wed Aug 31 10:27:33] #3444 [ 137 | loader_initialize | D:\a\metacall-core-detached\metacall-core-detached\source\loader\source\loader.c ] @Debug : Loader host initialized
    [Wed Aug 31 10:27:33] #3444 [ 44 | plugin_descriptor_create | D:\a\metacall-core-detached\metacall-core-detached\source\plugin\source\plugin_descriptor.c ] @Debug : Loading plugin: py_loaderd
    [Wed Aug 31 10:27:33] #3444 [ 57 | plugin_descriptor_create | D:\a\metacall-core-detached\metacall-core-detached\source\plugin\source\plugin_descriptor.c ] @Debug : Loading plugin symbol: py_loader_impl_interface_singleton
    [Wed Aug 31 10:27:33] #3444 [ 247 | loader_get_impl_plugin | D:\a\metacall-core-detached\metacall-core-detached\source\loader\source\loader.c ] @Debug : Created loader (py) implementation <0000025823C75C20>
    [Wed Aug 31 10:27:33] #3444 [ 320 | loader_load_from_memory | D:\a\metacall-core-detached\metacall-core-detached\source\loader\source\loader.c ] @Debug : Loading buffer from memory (py):
    def py_throw_error():
    	raise TypeError('yeet')
    
    def py_return_error():
    	return BaseException('asdf')
    
    
    [Wed Aug 31 10:27:33] #3444 [ 937 | loader_impl_load_from_memory | D:\a\metacall-core-detached\metacall-core-detached\source\loader\source\loader_impl.c ] @Debug : Loading from memory def py_thr...
    [Wed Aug 31 10:27:33] #3444 [ 2723 | py_loader_impl_initialize | D:\a\metacall-core-detached\metacall-core-detached\source\loaders\py_loader\source\py_loader_impl.c ] @Warning : Invalid garbage collector module creation
    [Wed Aug 31 10:27:33] #3444 [ 191 | loader_initialization_register_plugin | D:\a\metacall-core-detached\metacall-core-detached\source\loader\source\loader.c ] @Debug : Loader py registered at position (1) in thread #3444
    [Wed Aug 31 10:27:33] #3444 [ 153 | loader_initialization_debug | D:\a\metacall-core-detached\metacall-core-detached\source\loader\source\loader.c ] @Debug : Loader initialization order:
    -----------------------------------
    0) __metacall_host__ #3444
    1) py #3444
    [Wed Aug 31 10:27:33] #3444 [ 2767 | py_loader_impl_initialize | D:\a\metacall-core-detached\metacall-core-detached\source\loaders\py_loader\source\py_loader_impl.c ] @Debug : Python loader initialized correctly
    [Wed Aug 31 10:27:33] #3444 [ 4190 | py_loader_impl_sys_path_print | D:\a\metacall-core-detached\metacall-core-detached\source\loaders\py_loader\source\py_loader_impl.c ] @Debug : Python System Paths:
    D:/a/metacall-core-detached/metacall-core-detached/build/Debug\
    D:\a\metacall-core-detached\metacall-core-detached\runtimes\python\python39_d.zip
    D:\a\metacall-core-detached\metacall-core-detached\runtimes\python\Lib
    D:\a\metacall-core-detached\metacall-core-detached\runtimes\python\DLLs
    C:\hostedtoolcache\windows\Python\3.9.13\x64\Lib
    C:\hostedtoolcache\windows\Python\3.9.13\x64\DLLs
    D:\a\metacall-core-detached\metacall-core-detached\build\Debug
    C:\hostedtoolcache\windows\Python\3.9.13\x64
    C:\hostedtoolcache\windows\Python\3.9.13\x64\lib\site-packages
    [Wed Aug 31 10:27:33] #3444 [ 4190 | py_loader_impl_sys_path_print | D:\a\metacall-core-detached\metacall-core-detached\source\loaders\py_loader\source\py_loader_impl.c ] @Debug : Python System Paths:
    D:/a/metacall-core-detached/metacall-core-detached/build/scripts/
    D:/a/metacall-core-detached/metacall-core-detached/build/Debug\
    D:\a\metacall-core-detached\metacall-core-detached\runtimes\python\python39_d.zip
    D:\a\metacall-core-detached\metacall-core-detached\runtimes\python\Lib
    D:\a\metacall-core-detached\metacall-core-detached\runtimes\python\DLLs
    C:\hostedtoolcache\windows\Python\3.9.13\x64\Lib
    C:\hostedtoolcache\windows\Python\3.9.13\x64\DLLs
    D:\a\metacall-core-detached\metacall-core-detached\build\Debug
    C:\hostedtoolcache\windows\Python\3.9.13\x64
    C:\hostedtoolcache\windows\Python\3.9.13\x64\lib\site-packages
    [Wed Aug 31 10:27:33] #3444 [ 3303 | py_loader_impl_load_from_memory | D:\a\metacall-core-detached\metacall-core-detached\source\loaders\py_loader\source\py_loader_impl.c ] @Debug : Python loader (0000025823C75C20) importing 0000025823C75C20-00007FF689A70300-103-1893257302 from memory module at (000002582649DA70)
    [Wed Aug 31 10:27:33] #3444 [ 970 | loader_impl_load_from_memory | D:\a\metacall-core-detached\metacall-core-detached\source\loader\source\loader_impl.c ] @Debug : Loader interface: 00007FFFB184C000 - Loader handle: 0000025824819040
    [Wed Aug 31 10:27:33] #3444 [ 3988 | py_loader_impl_discover_module | D:\a\metacall-core-detached\metacall-core-detached\source\loaders\py_loader\source\py_loader_impl.c ] @Debug : Introspection: function py_throw_error, args count 0
    [Wed Aug 31 10:27:33] #3444 [ 3988 | py_loader_impl_discover_module | D:\a\metacall-core-detached\metacall-core-detached\source\loaders\py_loader\source\py_loader_impl.c ] @Debug : Introspection: function py_return_error, args count 0
    [Wed Aug 31 10:27:33] #3444 [ 499 | loader_get_cb_iterate | D:\a\metacall-core-detached\metacall-core-detached\source\loader\source\loader.c ] @Debug : Loader (py) get value: py_throw_error <000002582489EAA8>
    [Wed Aug 31 10:27:33] #3444 [ 719 | value_type_destroy | D:\a\metacall-core-detached\metacall-core-detached\source\reflect\source\reflect_value_type.c ] @Debug : Destroy throwable value <000002582489E9C8> containing the value <000002582489E958>
    [Wed Aug 31 10:27:33] #3444 [ 711 | value_type_destroy | D:\a\metacall-core-detached\metacall-core-detached\source\reflect\source\reflect_value_type.c ] @Debug : Destroy exception value <000002582489E958>
    [Wed Aug 31 10:27:33] #3444 [ 499 | loader_get_cb_iterate | D:\a\metacall-core-detached\metacall-core-detached\source\loader\source\loader.c ] @Debug : Loader (py) get value: py_return_error <000002582489E108>
    [Wed Aug 31 10:27:33] #3444 [ 719 | value_type_destroy | D:\a\metacall-core-detached\metacall-core-detached\source\reflect\source\reflect_value_type.c ] @Debug : Destroy throwable value <000002582489E488> containing the value <000002582489DC38>
    [Wed Aug 31 10:27:33] #3444 [ 711 | value_type_destroy | D:\a\metacall-core-detached\metacall-core-detached\source\reflect\source\reflect_value_type.c ] @Debug : Destroy exception value <000002582489DC38>
    [Wed Aug 31 10:27:33] #3444 [ 718 | loader_destroy | D:\a\metacall-core-detached\metacall-core-detached\source\loader\source\loader.c ] @Debug : Begin to destroy all the loaders
    [Wed Aug 31 10:27:33] #3444 [ 153 | loader_initialization_debug | D:\a\metacall-core-detached\metacall-core-detached\source\loader\source\loader.c ] @Debug : Loader initialization order:
    -----------------------------------
    0) __metacall_host__ #3444
    1) py #3444
    [Wed Aug 31 10:27:33] #3444 [ 678 | loader_unload_children | D:\a\metacall-core-detached\metacall-core-detached\source\loader\source\loader.c ] @Debug : Loader unloading (py) from thread #3444
    [Wed Aug 31 10:27:33] #3444 [ 1476 | loader_impl_destroy | D:\a\metacall-core-detached\metacall-core-detached\source\loader\source\loader_impl.c ] @Debug : Destroy loader implementation py
    [Wed Aug 31 10:27:33] #3444 [ 574 | loader_impl_destroy_handle | D:\a\metacall-core-detached\metacall-core-detached\source\loader\source\loader_impl.c ] @Debug : Destroying handle 0000025823C75C20-00007FF689A70300-103-1893257302
    A
    s
    s
    e
    r
    t
    i
    o
    n
     
    f
    a
    i
    l
    e
    d
    :
     
    (
    i
    t
    e
    m
     
    !
    =
     
    N
    U
    L
    L
    )
     
    ^
     
    (
    P
    y
    E
    r
    r
    _
    O
    c
    c
    u
    r
    r
    e
    d
    (
    )
     
    !
    =
     
    N
    U
    L
    L
    )
    ,
     
    f
    i
    l
    e
     
    D
    :
    \
    a
    \
    1
    \
    s
    \
    O
    b
    j
    e
    c
    t
    s
    \
    a
    b
    s
    t
    r
    a
    c
    t
    .
    c
    ,
     
    l
    i
    n
    e
     
    1
    5
    8
    
    
    
          Start 42: metacall-initialize-test
    41/58 Test #42: metacall-initialize-test .......................   Passed    0.03 sec
          Start 43: metacall-initialize-ex-test
    42/58 Test #43: metacall-initialize-ex-test ....................   Passed    0.03 sec
          Start 44: metacall-reinitialize-test
    43/58 Test #44: metacall-reinitialize-test .....................   Passed    0.05 sec
          Start 45: metacall-initialize-destroy-multiple-test
    44/58 Test #45: metacall-initialize-destroy-multiple-test ......   Passed    0.03 sec
          Start 46: metacall-invalid-loader-test
    45/58 Test #46: metacall-invalid-loader-test ...................   Passed    0.03 sec
          Start 47: metacall-return-monad-test
    46/58 Test #41: metacall-map-test ..............................   Passed    0.38 sec
          Start 48: metacall-version-test
    47/58 Test #48: metacall-version-test ..........................   Passed    0.02 sec
          Start 49: metacall-dynlink-path-test
    48/58 Test #49: metacall-dynlink-path-test .....................   Passed    0.02 sec
          Start 50: metacall-library-path-without-env-vars-test
    49/58 Test #50: metacall-library-path-without-env-vars-test ....   Passed    0.03 sec
          Start 51: metacall-ext-test
    50/58 Test #51: metacall-ext-test ..............................   Passed    0.03 sec
          Start 52: metacall-plugin-extension-destroy-order-test
    51/58 Test #52: metacall-plugin-extension-destroy-order-test ...   Passed    0.03 sec
          Start 53: metacallcli
    52/58 Test #53: metacallcli ....................................***Failed    0.01 sec
    The syntax of the command is incorrect.
    
          Start 54: metacallcli-py-naming
    53/58 Test #54: metacallcli-py-naming ..........................***Failed    0.01 sec
    The syntax of the command is incorrect.
    
          Start 55: metacallcli-py-argv
    54/58 Test #55: metacallcli-py-argv ............................***Failed    0.01 sec
    The syntax of the command is incorrect.
    
          Start 56: metacallcli-py-main
    55/58 Test #56: metacallcli-py-main ............................***Failed    0.01 sec
    The syntax of the command is incorrect.
    
          Start 57: metacallcli-py-exception
    56/58 Test #57: metacallcli-py-exception .......................***Failed    0.01 sec
    The syntax of the command is incorrect.
    
          Start 58: metacalllog
    57/58 Test #58: metacalllog ....................................   Passed    0.02 sec
    58/58 Test #47: metacall-return-monad-test .....................   Passed    0.36 sec
    
    90% tests passed, 6 tests failed out of 58
    
    Label Time Summary:
    MEMCHECK_IGNORE                                 =   1.10 sec*proc (3 tests)
    adt-map-test                                    =   0.02 sec*proc (1 test)
    adt-set-test                                    =   0.11 sec*proc (1 test)
    adt-trie-test                                   =   0.02 sec*proc (1 test)
    adt-vector-test                                 =   0.02 sec*proc (1 test)
    configuration-test                              =   0.02 sec*proc (1 test)
    dynlink-test                                    =   0.02 sec*proc (1 test)
    environment-test                                =   1.33 sec*proc (1 test)
    log-custom-test                                 =   0.13 sec*proc (1 test)
    log-test                                        =   0.26 sec*proc (1 test)
    metacall-cast-test                              =   0.34 sec*proc (1 test)
    metacall-clear-test                             =   0.38 sec*proc (1 test)
    metacall-configuration-exec-path-test           =   0.38 sec*proc (1 test)
    metacall-distributable-test                     =   0.35 sec*proc (1 test)
    metacall-ducktype-test                          =   0.34 sec*proc (1 test)
    metacall-dynlink-path-test                      =   0.02 sec*proc (1 test)
    metacall-ext-test                               =   0.03 sec*proc (1 test)
    metacall-handle-export-test                     =   0.34 sec*proc (1 test)
    metacall-init-fini-test                         =   0.35 sec*proc (1 test)
    metacall-initialize-destroy-multiple-test       =   0.03 sec*proc (1 test)
    metacall-initialize-ex-test                     =   0.03 sec*proc (1 test)
    metacall-initialize-test                        =   0.03 sec*proc (1 test)
    metacall-inspect-test                           =   0.38 sec*proc (1 test)
    metacall-invalid-loader-test                    =   0.03 sec*proc (1 test)
    metacall-library-path-without-env-vars-test     =   0.03 sec*proc (1 test)
    metacall-load-configuration-test                =   0.35 sec*proc (1 test)
    metacall-load-memory-test                       =   0.41 sec*proc (1 test)
    metacall-logs-test                              =   0.15 sec*proc (1 test)
    metacall-map-test                               =   0.38 sec*proc (1 test)
    metacall-plugin-extension-destroy-order-test    =   0.03 sec*proc (1 test)
    metacall-python-builtins-test                   =   0.65 sec*proc (1 test)
    metacall-python-dict-test                       =   0.35 sec*proc (1 test)
    metacall-python-exception-test                  =   0.34 sec*proc (1 test)
    Errors while running CTest
    metacall-python-fail-test                       =   0.37 sec*proc (1 test)
    metacall-python-gc-test                         =   0.58 sec*proc (1 test)
    metacall-python-object-class-test               =   0.39 sec*proc (1 test)
    metacall-python-relative-path-test              =   0.37 sec*proc (1 test)
    metacall-python-test                            =   0.39 sec*proc (1 test)
    metacall-python-varargs-test                    =   0.34 sec*proc (1 test)
    metacall-python-without-functions-test          =   0.35 sec*proc (1 test)
    metacall-reinitialize-test                      =   0.05 sec*proc (1 test)
    metacall-return-monad-test                      =   0.36 sec*proc (1 test)
    metacall-test                                   =   0.38 sec*proc (1 test)
    metacall-version-test                           =   0.02 sec*proc (1 test)
    metacallcli                                     =   0.01 sec*proc (1 test)
    metacallcli-py-argv                             =   0.01 sec*proc (1 test)
    metacallcli-py-exception                        =   0.01 sec*proc (1 test)
    metacallcli-py-main                             =   0.01 sec*proc (1 test)
    metacallcli-py-naming                           =   0.01 sec*proc (1 test)
    metacalllog                                     =   0.02 sec*proc (1 test)
    portability-path-test                           =   0.02 sec*proc (1 test)
    preprocessor-test                               =   1.27 sec*proc (1 test)
    reflect-function-test                           =   0.02 sec*proc (1 test)
    reflect-metadata-test                           =   0.02 sec*proc (1 test)
    reflect-object-class-test                       =   0.02 sec*proc (1 test)
    reflect-scope-test                              =   0.02 sec*proc (1 test)
    reflect-value-cast-test                         =   0.03 sec*proc (1 test)
    serial-test                                     =   0.02 sec*proc (1 test)
    
    Total Test time (real) =   6.84 sec
    
    The following tests FAILED:
    	 40 - metacall-python-exception-test (Failed)
    	 53 - metacallcli (Failed)
    	 54 - metacallcli-py-naming (Failed)
    	 55 - metacallcli-py-argv (Failed)
    	 56 - metacallcli-py-main (Failed)
    	 57 - metacallcli-py-exception (Failed)
    

    Expected Behaviour

    The memory leak shouldn't happen.

    Current Behaviour

    The test fails and there's a memory leak (@viferga).

    Possible Solution

    Investigate why the leak happens and modify the test(s) and/or source code to fix it.

    Steps to Reproduce

    1. Go here: https://github.com/paramsiddharth/metacall-core-detached/tree/tests/windows
    2. Run the scripts a dictated in the workflow inside test.yml.
    3. Check the logs.
    bug 
    opened by paramsiddharth 0
  • refactor cli

    refactor cli

    refactor cli add repl plugin

    Description

    Please include a summary of the change and which issue is fixed. List any dependencies that are required for this change.

    Fixes #(issue_no)

    Type of change

    • [ ] Bug fix (non-breaking change which fixes an issue)
    • [x] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
    • [ ] This change requires a documentation update
    • [ ] Documentation update

    Checklist:

    • [x] I have performed a self-review of my own code.
    • [ ] I have commented my code, particularly in hard-to-understand areas.
    • [ ] I have made corresponding changes to the documentation.
    • [ ] My changes generate no new warnings.
    • [ ] I have added tests/screenshots (if any) that prove my fix is effective or that my feature works.
    • [ ] I have tested the tests implicated (if any) by my own code and they pass (make test or ctest -VV -R <test-name>).
    • [ ] If my change is significant or breaking, I have passed all tests with ./docker-compose.sh build &> output and attached the output.
    • [ ] I have tested my code with OPTION_BUILD_SANITIZER or ./docker-compose.sh test &> output and OPTION_TEST_MEMORYCHECK.
    • [ ] I have tested with Helgrind in case my code works with threading.
    • [ ] I have run make clang-format in order to format my code and my code follows the style guidelines.

    If you are unclear about any of the above checks, have a look at our documentation here.

    opened by rxbryan 1
Releases(v0.5.37)
Nixt is an interpreted programming language written in Rust

Nixt Nixt is an interpreted lisp inspired programming language written in Rust Index About Examples Installation Build About Nixt goal is to provide a

Wafelack 17 Jul 18, 2022
A programming language somewhat resembling cellular processes.

cytosol An embeddable programming language somewhat resembling cellular processes. State of the implementation tokenising parsing semantic analysis an

null 33 Sep 14, 2022
Orion lang is a lispy programming language that is strongly and statically typed.

Orion Orion is a lisp inspired statically typed programming language written in Rust Install To install orion you can either: Download binary from the

Wafelack 228 Sep 16, 2022
Mote is a systems-programming language designed to be practical, performant, and simple.

Mote NOTE: this following lists the goals for what Mote is supposed to be. It does not promise that any of the features here will be accomplished or a

The Mote Programming Language 14 Jul 28, 2021
a function programming language for real world applications made in rust

a function programming language for real world applications made in rust

Tanay Pingalkar 6 Jun 12, 2022
Rust implementation of µKanren, a featherweight relational programming language.

µKanren-rs This is a Rust implementation of µKanren, a featherweight relational programming language. See the original Scheme implementation here for

Eric Zhang 98 Sep 1, 2022
A stack based interpreted programming language.

Nightmare Nightmare is a dynamically-typed, procedural programming language that aims to be fast & simple. let user = input() as Int; print("You were

&potato 4 Nov 12, 2021
lints and suggestions for the nix programming language

statix Lints and suggestions for the Nix programming language. statix highlights antipatterns in Nix code. statix --fix can fix several such occurrenc

Akshay 285 Sep 26, 2022
Aspect-oriented programming in Rust

Aspect Oriented Programming (AOP) for Rust The needs of AOP Aspect-oriented programming (AOP) is a programming paradigm that aims to increase modulari

null 8 Jul 4, 2022
Gecko is a high-level, general-purpose programming language built on top of the LLVM project.

Gecko is a high-level, general-purpose programming language built on top of the LLVM project. Gecko Technology & principles Gecko is a general-purpose

Gecko 18 Jul 23, 2022
This repository contains the source of "The Rust Programming Language" book.

The Rust Programming Language This repository contains the source of "The Rust Programming Language" book. The book is available in dead-tree form fro

The Rust Programming Language 10.1k Sep 20, 2022
A short exercise to introduce people to the Rust programming language

Searching primes by brute force This code is ment to be an exercice to teach rust and give a first impression on how to work with the language during

JoelImgu 2 Dec 2, 2021
A repository for showcasing my knowledge of the Rust programming language, and continuing to learn the language.

Learning Rust I started learning the Rust programming language before using GitHub, but increased its usage afterwards. I have found it to be a fast a

Sean P. Myrick V19.1.7.2 1 Aug 26, 2022
A turing-complete programming language using only zero-width unicode characters, inspired by brainfuck and whitespace.

Zero-Width A turing-complete programming language using only zero-width unicode characters, inspired by brainfuck and whitespace. Currently a (possibl

Gavin M 2 Jan 14, 2022
The Rust Programming Language, Chapter 8, Exercise 1

Rust Common Collections - Exercise 1 In the book The Rust Programming Language by Steve Klabnik and Carol Nichols, chapter 8 - Common Collections - pr

David Jones 0 Dec 24, 2021
clone of grep cli written in Rust. From Chapter 12 of the Rust Programming Language book

minigrep is a clone of the grep cli in rust Minigrep will find a query string in a file. To test it out, clone the project and run cargo run body poem

Raunak Singh 1 Dec 14, 2021
Functional Reactive Programming library for Rust

Carboxyl is a library for functional reactive programming in Rust, a functional and composable approach to handle events in interactive applications.

Emilia Bopp 377 Aug 1, 2022
Rust Programming Fundamentals - one course to rule them all, one course to find them...

Ultimate Rust Crash Course This is the companion repository for the Ultimate Rust Crash Course published online, presented live at O'Reilly virtual ev

Nathan Stocks 984 Sep 27, 2022
The Rust Compiler Collection is a collection of compilers for various languages, written with The Rust Programming Language.

rcc The Rust Compiler Collection is a collection of compilers for various languages, written with The Rust Programming Language. Compilers Language Co

null 2 Jan 17, 2022