A couple API Endpoints #10658

Myoldmopar · 2024-08-12T18:28:07Z

Pull request overview

Adds an endpoint to get current IDF file path back out of the API
Adds ability to interact with EMS global variables from the API

This won't affect any existing API usage, just adds a few new endpoints.

jmarrec · 2024-08-13T13:16:18Z

src/EnergyPlus/api/datatransfer.cc

+char *inputFilePath(EnergyPlusState state)
+{
+    const auto *thisState = static_cast<EnergyPlus::EnergyPlusData *>(state);
+    char *p = new char[std::strlen(thisState->dataStrGlobals->inputFilePath.string().c_str()) + 1];
+    std::strcpy(p, thisState->dataStrGlobals->inputFilePath.string().c_str());
+    return p;
+}


Ok, no problem!

jmarrec · 2024-08-13T13:16:39Z

src/EnergyPlus/api/datatransfer.h

+/// \return A char * of the input file path.  This allocates a new char *, and calling clients must free this when done with it!
+ENERGYPLUSLIB_API char *inputFilePath(EnergyPlusState state);


User is warned this allocates, good

Yes....but now I think I need to add something to the Python API. Once Python calls this function and converts it into a Python string (PyObject*), the C string is still hanging out. I may need a very minimal function in the C API that can free one of these char*. Thoughts @jmarrec ?

I think you can to decode it to utf-8, then just free it, right?

Same as

EnergyPlus/src/EnergyPlus/api/datatransfer.py

Lines 374 to 375 in 52fee4b

list_response = [r[i].decode('utf-8', errors='ignore') for i in range(count.value)]

self.api.freeObjectNames(r, count) # free the underlying C memory now that we have a Python copy

Speaking off, you should:

Use FileSystem::toGenericString so you don't have issues with special chars

(Would be nice if the python one would return a pathlib.Path instead)

Done in 2c31f9f.

And you don't need to free the c_char_p returned by the C fun: ,if you set restype to c_char_p, ctypes returns a regular Python bytes object. and it seems it manages the memory for you. I tested with and without a C delete[] call, with ASAN enabled, and it works correctly when you do nothing, and it gives a malloc error if you try to free.

> /Users/julien/Software/Others/EnergyPlus-build/Products/pyenergyplus/datatransfer.py(377)get_input_file_path() -> c_string = self.api.inputFilePath(state) (Pdb) n > /Users/julien/Software/Others/EnergyPlus-build/Products/pyenergyplus/datatransfer.py(378)get_input_file_path() -> res = Path(c_string.decode('utf-8')) (Pdb) p c_srtring *** NameError: name 'c_srtring' is not defined (Pdb) p c_string b'/Users/julien/Software/Others/EnergyPlus/testfiles/_1ZoneUncontrolled_ForAPITesting.idf' (Pdb) type(c_string) <class 'bytes'> (Pdb) n > /Users/julien/Software/Others/EnergyPlus-build/Products/pyenergyplus/datatransfer.py(379)get_input_file_path() -> self.api.freeCString(c_string) (Pdb) s ================================================================= ==47091==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x0001072b28d0 in thread T0 #0 0x1016f5c88 in wrap__ZdaPv+0x74 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x61c88) #1 0x116cd5a04 in freeCString datatransfer.cc:293 #2 0x19b79504c in ffi_call_SYSV+0x4c (libffi.dylib:arm64e+0x804c) #3 0x19b79dadc in ffi_call_int+0x4b8 (libffi.dylib:arm64e+0x10adc) #4 0x1068b3ef4 in _ctypes_callproc+0x530 (_ctypes.cpython-39-darwin.so:arm64+0xbef4) #5 0x1068ad238 in PyCFuncPtr_call+0x48c (_ctypes.cpython-39-darwin.so:arm64+0x5238) #6 0x1021d3584 in _PyObject_MakeTpCall+0x164 (libpython3.9.dylib:arm64+0x3f584) #7 0x1022a9620 in call_function+0x1fc (libpython3.9.dylib:arm64+0x115620) #8 0x1022a6c38 in _PyEval_EvalFrameDefault+0x5a24 (libpython3.9.dylib:arm64+0x112c38) #9 0x1021d3d7c in function_code_fastcall+0x6c (libpython3.9.dylib:arm64+0x3fd7c) #10 0x1022a95c0 in call_function+0x19c (libpython3.9.dylib:arm64+0x1155c0) #11 0x1022a6c14 in _PyEval_EvalFrameDefault+0x5a00 (libpython3.9.dylib:arm64+0x112c14) #12 0x1021d3d7c in function_code_fastcall+0x6c (libpython3.9.dylib:arm64+0x3fd7c) #13 0x1068b31b4 in closure_fcn+0x21c (_ctypes.cpython-39-darwin.so:arm64+0xb1b4) #14 0x19b79df2c in ffi_closure_SYSV_inner+0x330 (libffi.dylib:arm64e+0x10f2c) #15 0x19b7951e4 in ffi_closure_SYSV+0x34 (libffi.dylib:arm64e+0x81e4) #16 0x116c99d68 in decltype(std::declval<void (*&)(void*)>()(std::declval<void*>())) std::__1::__invoke[abi:ue170006]<void (*&)(void*), void*>(void (*&)(void*), void*&&) invoke.h:340 #17 0x116c99c94 in void std::__1::__invoke_void_return_wrapper<void, true>::__call[abi:ue170006]<void (*&)(void*), void*>(void (*&)(void*), void*&&) invoke.h:415 #18 0x116c99c68 in std::__1::__function::__alloc_func<void (*)(void*), std::__1::allocator<void (*)(void*)>, void (void*)>::operator()[abi:ue170006](void*&&) function.h:193 #19 0x116c95a44 in std::__1::__function::__func<void (*)(void*), std::__1::allocator<void (*)(void*)>, void (void*)>::operator()(void*&&) function.h:364 #20 0x116c77aa4 in std::__1::__function::__value_func<void (void*)>::operator()[abi:ue170006](void*&&) const function.h:518 #21 0x116c778a8 in std::__1::function<void (void*)>::operator()(void*) const function.h:1169 #22 0x11af8c4f8 in EnergyPlus::PluginManagement::runAnyRegisteredCallbacks(EnergyPlus::EnergyPlusData&, EnergyPlus::EMSManager::EMSCallFrom, bool&) PluginManager.cc:142 #23 0x1184ecd78 in EnergyPlus::EMSManager::ManageEMS(EnergyPlus::EnergyPlusData&, EnergyPlus::EMSManager::EMSCallFrom, bool&, ObjexxFCL::Optional<int const>) EMSManager.cc:276 #24 0x119816ab8 in EnergyPlus::HeatBalanceManager::ManageHeatBalance(EnergyPlus::EnergyPlusData&) HeatBalanceManager.cc:218 #25 0x11b98a644 in EnergyPlus::SimulationManager::ManageSimulation(EnergyPlus::EnergyPlusData&) SimulationManager.cc:497 #26 0x116d1b794 in runEnergyPlusAsLibrary(EnergyPlus::EnergyPlusData&, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>> const&) EnergyPlusPgm.cc:458 #27 0x116c7f924 in energyplus runtime.cc:76 #28 0x19b79504c in ffi_call_SYSV+0x4c (libffi.dylib:arm64e+0x804c) #29 0x19b79dadc in ffi_call_int+0x4b8 (libffi.dylib:arm64e+0x10adc) #30 0x1068b3ef4 in _ctypes_callproc+0x530 (_ctypes.cpython-39-darwin.so:arm64+0xbef4) #31 0x1068ad238 in PyCFuncPtr_call+0x48c (_ctypes.cpython-39-darwin.so:arm64+0x5238) #32 0x1021d3584 in _PyObject_MakeTpCall+0x164 (libpython3.9.dylib:arm64+0x3f584) #33 0x1022a9620 in call_function+0x1fc (libpython3.9.dylib:arm64+0x115620) #34 0x1022a6c38 in _PyEval_EvalFrameDefault+0x5a24 (libpython3.9.dylib:arm64+0x112c38) #35 0x1021d3d7c in function_code_fastcall+0x6c (libpython3.9.dylib:arm64+0x3fd7c) #36 0x1022a95c0 in call_function+0x19c (libpython3.9.dylib:arm64+0x1155c0) #37 0x1022a6c14 in _PyEval_EvalFrameDefault+0x5a00 (libpython3.9.dylib:arm64+0x112c14) #38 0x1022aa4e8 in _PyEval_EvalCode+0xba8 (libpython3.9.dylib:arm64+0x1164e8) #39 0x1022a1148 in PyEval_EvalCode+0x4c (libpython3.9.dylib:arm64+0x10d148) #40 0x1022e8f98 in pyrun_file+0x12c (libpython3.9.dylib:arm64+0x154f98) #41 0x1022e6f6c in PyRun_SimpleFileExFlags+0x26c (libpython3.9.dylib:arm64+0x152f6c) #42 0x102303f40 in Py_RunMain+0x6a0 (libpython3.9.dylib:arm64+0x16ff40) #43 0x102304404 in pymain_main+0x150 (libpython3.9.dylib:arm64+0x170404) #44 0x102304480 in Py_BytesMain+0x24 (libpython3.9.dylib:arm64+0x170480) #45 0x18a4460dc (<unknown module>) Address 0x0001072b28d0 is a wild pointer inside of access range of size 0x000000000001. SUMMARY: AddressSanitizer: bad-free (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x61c88) in wrap__ZdaPv+0x74 ==47091==ABORTING Abort trap: 6

jmarrec · 2024-08-13T13:20:42Z

src/EnergyPlus/api/datatransfer.cc

+{
+    auto *thisState = static_cast<EnergyPlus::EnergyPlusData *>(state);
+    int index = 0;
+    for (auto const &erlVar : thisState->dataRuntimeLang->ErlVariable) {


Are you really sure this is the right array, at least unbounded whatsoever like this? More on this in a bit

Great catch, so now I am skipping the built-in EMS variables. If someone wants to get one of those built-in variables, they can get them through normal API methods.

jmarrec · 2024-08-13T13:22:18Z

src/EnergyPlus/api/datatransfer.cc

+void setEMSGlobalVariableValue(EnergyPlusState state, int handle, Real64 value)
+{
+    auto *thisState = static_cast<EnergyPlus::EnergyPlusData *>(state);
+    if (handle < 0 || handle > thisState->dataRuntimeLang->NumErlVariables) {
+        // need to fatal out once the plugin is done
+        // throw an error, set the fatal flag, and then return
+        EnergyPlus::ShowSevereError(
+            *thisState, fmt::format("Data Exchange API: Problem -- index error in setEMSGlobalVariableValue; received handle: {}", handle));
+        EnergyPlus::ShowContinueError(*thisState,
+                                      "The setEMSGlobalVariableValue function will return to allow the plugin to finish, then EnergyPlus will abort");
+        thisState->dataPluginManager->apiErrorFlag = true;
+    }
+    thisState->dataRuntimeLang->ErlVariable(handle).Value.Number = value;
+}


Here, I'm pretty sure this is not ok.

ErlVariable array contains a bunch of builtins that you aren't supposed to be able to mess with. NullVariableNum, YEAR, FALSE, TRUE, PI, ACTUALTIME, etc.

If you haven't defined any EMS stuff in your IDF, this is what the ErlVariable array contains:

1 - NULL 2 - FALSE 3 - TRUE 4 - OFF 5 - ON 6 - PI 7 - TIMESTEPSPERHOUR 8 - YEAR 9 - CALENDARYEAR 10 - MONTH 11 - DAYOFMONTH 12 - DAYOFWEEK 13 - DAYOFYEAR 14 - HOUR 15 - TIMESTEPNUM 16 - MINUTE 17 - HOLIDAY 18 - DAYLIGHTSAVINGS 19 - CURRENTTIME 20 - SUNISUP 21 - ISRAINING 22 - SYSTEMTIMESTEP 23 - ZONETIMESTEP 24 - CURRENTENVIRONMENT 25 - ACTUALDATEANDTIME 26 - ACTUALTIME 27 - WARMUPFLAG

Most of these (except the constants such as TRUE, FALSE) are being assigned a value in InitializeRuntimeLanguage

EnergyPlus/src/EnergyPlus/RuntimeLanguageProcessor.cc

Line 183 in 52fee4b

state.dataRuntimeLang->ErlVariable(state.dataRuntimeLangProcessor->YearVariableNum).Value = SetErlValueNumber(double(state.dataEnvrn->Year));

So a change would be therefore limited to any calling points after the point where you are setting a new value. (eg change that in BeginNewEnvironement calling point).

Not sure whether that makes a ton of sense. If not, maybe considering slicing the ErlVariable array to ommit the built in ones, so the user ones only are left.

first 27 values in ErlVariable() are constant and built-in variables

EMS Sensors, Actuators and InternalVariables declared in the IDF are actually emplaced before the built-in ones.

GetEMSInput is called before

EnergyPlus/src/EnergyPlus/EMSManager.cc

Line 603 in 52fee4b

VariableNum = RuntimeLanguageProcessor::NewEMSVariable(state, cAlphaArgs(1), 0);

So Sensors, Actuators and InternalVariables are loaded in the array first, and only then the InitializeRuntimeLanguage is called

EnergyPlus/src/EnergyPlus/EMSManager.cc

Lines 839 to 840 in 52fee4b

RuntimeLanguageProcessor::InitializeRuntimeLanguage(

state); // Loads built-in globals and functions, then performs GetInput for runtime language objects

jmarrec · 2024-08-13T13:23:03Z

tst/EnergyPlus/api/TestDataTransfer.c

+        char *filePath = inputFilePath(state);
+        printf("Input file path accessed via API: %s\n", filePath);
+        free(filePath);


Ok, but where's the getEMSGlobalVariableValue / setEMSGlobalVariableValue test at?

(and I suppose the python version would be nice too).

Myoldmopar

Alright, this seems very close now. Thanks @jmarrec for the deep review. I would like to resolve the char * issue when calling via Python, and then this should be ready. I think.

Myoldmopar · 2024-08-13T17:08:49Z

scripts/dev/verify_idfs_in_cmake.py

@@ -94,7 +94,7 @@
 # there are a few files we purposely skip
 files_to_skip = {"_1a-Long0.0.idf", "_ExternalInterface-actuator.idf", "_ExternalInterface-schedule.idf",
                 "_ExternalInterface-variable.idf", "HVAC3Zone-IntGains-Def.imf", "HVAC3ZoneChillerSpec.imf",
-                 "HVAC3ZoneGeometry.imf", "HVAC3ZoneMat-Const.imf"}
+                 "HVAC3ZoneGeometry.imf", "HVAC3ZoneMat-Const.imf", "_1ZoneUncontrolled_ForAPITesting.idf"}


I made a special IDF that I can fiddle with all willy-nilly and not bother the core 1ZoneUncontrolled.idf file. But I need to ignore it here in custom_check.

Myoldmopar · 2024-08-13T17:09:16Z

src/EnergyPlus/CMakeLists.txt

@@ -991,7 +991,7 @@ if(BUILD_TESTING)
                   -DEPW_FILE=USA_CO_Golden-NREL.724666_TMY3.epw -P ${PROJECT_SOURCE_DIR}/cmake/RunCallbackTest.cmake)

  set(EPW_FILE "${PROJECT_SOURCE_DIR}/weather/USA_IL_Chicago-OHare.Intl.AP.725300_TMY3.epw")
-  set(IDF_FILE "${PROJECT_SOURCE_DIR}/testfiles/1ZoneUncontrolled.idf")
+  set(IDF_FILE "${PROJECT_SOURCE_DIR}/testfiles/_1ZoneUncontrolled_ForAPITesting.idf")


Use the specialized file for testing here, this way we can do things like add EMS vars to the IDF without affecting the core 1ZoneUncontrolled.idf file.

Myoldmopar · 2024-08-13T17:09:35Z

src/EnergyPlus/DataRuntimeLanguage.hh

+    // In the API, we allow the user to manipulate user-defined EMS globals, but we skip the built-in ones to avoid
+    // problems.  This constexpr should be incremented if we ever add more built-ins so that we skip the right amount
+    // in the API calls.
+    static int constexpr NumBuiltInErlVariables = 27;


OK, so create a single location constexpr where we declare the number of built-in EMS variables.

Myoldmopar · 2024-08-13T17:09:56Z

src/EnergyPlus/RuntimeLanguageProcessor.cc

@@ -160,6 +160,9 @@ void InitializeRuntimeLanguage(EnergyPlusData &state)
        state.dataRuntimeLangProcessor->ActualTimeNum = NewEMSVariable(state, "ACTUALTIME", 0);
        state.dataRuntimeLangProcessor->WarmUpFlagNum = NewEMSVariable(state, "WARMUPFLAG", 0);

+        // this ensures we stay in sync with the number of skipped built-ins for API calls
+        assert(state.dataRuntimeLang->NumErlVariables == state.dataRuntimeLang->NumBuiltInErlVariables);


And here make sure we abide by that number of built-in variables. Which we do. Thanks for the heads up here @jmarrec

Myoldmopar · 2024-08-13T17:10:13Z

src/EnergyPlus/api/datatransfer.cc

+char *inputFilePath(EnergyPlusState state)
+{
+    const auto *thisState = static_cast<EnergyPlus::EnergyPlusData *>(state);
+    char *p = new char[std::strlen(thisState->dataStrGlobals->inputFilePath.string().c_str()) + 1];
+    std::strcpy(p, thisState->dataStrGlobals->inputFilePath.string().c_str());
+    return p;
+}


Myoldmopar · 2024-08-13T17:12:13Z

src/EnergyPlus/api/datatransfer.h

+/// \return A char * of the input file path.  This allocates a new char *, and calling clients must free this when done with it!
+ENERGYPLUSLIB_API char *inputFilePath(EnergyPlusState state);


Yes....but now I think I need to add something to the Python API. Once Python calls this function and converts it into a Python string (PyObject*), the C string is still hanging out. I may need a very minimal function in the C API that can free one of these char*. Thoughts @jmarrec ?

Myoldmopar · 2024-08-13T17:13:26Z

tst/EnergyPlus/api/TestDataTransfer.c

@@ -91,11 +91,27 @@ void afterZoneTimeStepHandler(EnergyPlusState state)
        wallConstruction = getConstructionHandle(state, "R13WALL");
        floorConstruction = getConstructionHandle(state, "FLOOR");

-        // don't forget to free memory from the API!
+        // checking for EMS globals


Test EMS global access via C API.

Myoldmopar · 2024-08-13T17:13:36Z

tst/EnergyPlus/api/TestDataTransfer.c

@@ -106,6 +122,13 @@ void afterZoneTimeStepHandler(EnergyPlusState state)
            wallConstruction == -1 || floorConstruction == -1) {
            exit(1);
        }
+
+        char *idfPath = inputFilePath(state);


Test IDF/EPW access via C API.

Myoldmopar · 2024-08-13T17:13:46Z

tst/EnergyPlus/api/TestDataTransfer.py

@@ -101,6 +101,26 @@ def time_step_handler(state):

            wall_construction_handle = api.exchange.get_construction_handle(state, "R13WALL")
            floor_construction_handle = api.exchange.get_construction_handle(state, "FLOOR")
+
+            idf_path = api.exchange.get_input_file_path(state)


Test IDF/EPW access via Python API.

Myoldmopar · 2024-08-13T17:13:58Z

tst/EnergyPlus/api/TestDataTransfer.py

+            print(f"Got an input file path of: {idf_path}, and weather file path of: {epw_path}")
+
+            # checking for EMS globals
+            ems_global_valid = api.exchange.get_ems_global_handle(state, "MaximumEffort")


Test EMS global access via Python API.

Myoldmopar · 2024-08-13T21:10:49Z

Interesting, that number isn't always 27 at that point in the code @jmarrec. I may have to be a little more careful...

…eAPIEndpoints

Myoldmopar · 2024-08-19T16:01:21Z

This is completely green now that I'm doing proper index handling. If there are any issues, speak up, otherwise this will merge soon.

Myoldmopar · 2024-08-19T17:49:00Z

Alright, dropping this in as well. It's all happy locally.

Myoldmopar added 4 commits July 18, 2024 15:56

Add API endpoints to access EMS global variables

c1a2396

Add API endpoint for accecssing the specified IDF path

5d4c911

Use fs::path::string method to get windows compiling

9cfd988

Add string() method on fs::path, location 2

125f244

Myoldmopar added this to the EnergyPlus 24.2 IOFreeze milestone Aug 12, 2024

Myoldmopar added the NewFeature Includes code to add a new feature to EnergyPlus label Aug 12, 2024

Merge remote-tracking branch 'origin/develop' into ACoupleAPIEndpoints

315edf1

jmarrec reviewed Aug 13, 2024

View reviewed changes

Myoldmopar added 2 commits August 13, 2024 09:15

Merge remote-tracking branch 'origin/develop' into ACoupleAPIEndpoints

f13047c

Skip builtin EMS vars and add testing of new endpoints

c01601c

Myoldmopar commented Aug 13, 2024

View reviewed changes

jmarrec and others added 5 commits August 14, 2024 14:43

Use toGenericString and return a Pathlib.Path instead of a string

2c31f9f

Add better range checking on erl var index

0ba4621

Merge remote-tracking branch 'origin/ACoupleAPIEndpoints' into ACoupl…

c0caf7d

…eAPIEndpoints

Use handle not index

49f4d36

Merge remote-tracking branch 'origin/develop' into ACoupleAPIEndpoints

58ef554

Myoldmopar merged commit 2fda843 into develop Aug 19, 2024
15 checks passed

Myoldmopar deleted the ACoupleAPIEndpoints branch August 19, 2024 17:49

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

A couple API Endpoints #10658

A couple API Endpoints #10658

Myoldmopar commented Aug 12, 2024

jmarrec Aug 13, 2024

Myoldmopar Aug 13, 2024

jmarrec Aug 13, 2024

Myoldmopar Aug 13, 2024

jmarrec Aug 14, 2024

jmarrec Aug 14, 2024

jmarrec Aug 14, 2024 •

edited

Loading

jmarrec Aug 14, 2024

jmarrec Aug 13, 2024

Myoldmopar Aug 13, 2024

jmarrec Aug 13, 2024

jmarrec Aug 13, 2024

jmarrec Aug 13, 2024

jmarrec Aug 13, 2024

jmarrec Aug 14, 2024

jmarrec Aug 13, 2024

Myoldmopar left a comment

Myoldmopar Aug 13, 2024

Myoldmopar Aug 13, 2024

Myoldmopar Aug 13, 2024

Myoldmopar Aug 13, 2024

Myoldmopar Aug 13, 2024

Myoldmopar Aug 13, 2024

Myoldmopar Aug 13, 2024

Myoldmopar Aug 13, 2024

Myoldmopar Aug 13, 2024

Myoldmopar Aug 13, 2024

Myoldmopar commented Aug 13, 2024

Myoldmopar commented Aug 19, 2024

Myoldmopar commented Aug 19, 2024

		/// \return A char * of the input file path. This allocates a new char *, and calling clients must free this when done with it!
		ENERGYPLUSLIB_API char *inputFilePath(EnergyPlusState state);

	list_response = [r[i].decode('utf-8', errors='ignore') for i in range(count.value)]
	self.api.freeObjectNames(r, count) # free the underlying C memory now that we have a Python copy

	RuntimeLanguageProcessor::InitializeRuntimeLanguage(
	state); // Loads built-in globals and functions, then performs GetInput for runtime language objects

A couple API Endpoints #10658

A couple API Endpoints #10658

Conversation

Myoldmopar commented Aug 12, 2024

Pull request overview

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jmarrec Aug 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Myoldmopar left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Myoldmopar commented Aug 13, 2024

Myoldmopar commented Aug 19, 2024

Myoldmopar commented Aug 19, 2024

jmarrec Aug 14, 2024 •

edited

Loading