Peefy

Hello, @karlhepler Generally, we use root-level variables in the entry files such as main.k and we use the import statement in the main.k and import another file such as pkg.k...

Sorry, I did not mark on this API that it is indeed not thread safe, this is a feature to be implemented.

You are right! They use the same address and global variables to share the KCL runtime, which currently does not support concurrent running. We are working hard to solve this...

Thank you for your feedback. I will investigate it. I did modify the build logic before two versions, but added locks for different build threads. 😷

Thank you very much for your feedback. I will carefully review the recent updates to identify factors. It is expected that version 0.8.6 will be released next week.

Hello @bozaro https://github.com/kcl-lang/kcl-go/blob/main/pkg/env/env.go#L77 We have introduced an experimental feature gate in kcl-go v0.9.0 beta.1 You can quickly run your code by opening it, without the need to call the `BuildArtifact`...

Hello @bozaro Thanks for the feedback. Could you please give me a simple case that reproduce the multithread error and I will fix it recently and what the API is...

> I try remove all `regex` package usages and regenerate configuration with `KCL_FAST_EVAL=1` on [3f2e611](https://github.com/kcl-lang/kcl/commit/3f2e611ac8fb11b7371bcbe83d273fbf997455c2) revision in multithread mode. Regeneration without `regex` usages passed succesfully. I see. Thanks. I will...

I've given a try to fix it in PR https://github.com/kcl-lang/kcl/pull/1458 and add parallel tests in Rust and it ran successfully, and Go tests also ran successfully.

Yes, there's a global build file lock currently to prevent common external module (e.g., kcl mod add k8s) link crash errors.