text:
wasm_instance_new will skip those functions linked by loader

how an embedder can know which imports are already linked?

run $ ./iwasm target.wasm and collect messages like warning: failed to link import .... and those failures are required and others are linked by loader.
But we can provide a script to scan and report all need to be linked items in a proper order. Is it useful?

are you suggesting to hardcode the list of imports linked by the loader in an embedder?

No. users should not repeat those imported items provided by loader and only need to give the "missing" parts. In most of the time, I believe just a few.

a program using this api needs to know the list of linked imports. if not hardcoded, how?

Two ways:

run $ ./iwasm target.wasm and collect messages like warning: failed to link import .... and those are required.
develop a script to scan the wasm and report all requirements.

Two ways:
* run $ ./iwasm target.wasm and collect messages like _warning: failed to link import ...._ and those are required.

* develop a script to scan the wasm and report all requirements.

do you mean to make the program execute it and parse the result?

Yes. the first idea which involve iwasm is.
Or if it is wired, we can develop a script to analyze the .wasm.

it sounds unreasonable to me. what's wrong to invent an api to query which imports are already-linked?

Even there is the api to query linked imports, user still need to write a small program to check first. Or they need to preparation all imports and filter out some of them with the query api when running.

Even there is the api to query linked imports, user still need to write a small program to check first. Or they need to preparation all imports and filter out some of them with the query api when running.

it sounds far more usable than actually running the module and parse warnings.
am i missing something?

Develop a script to analyze the .wasm and report all necessaries ?

Develop a script to analyze the .wasm and report all necessaries ?

sorry, i don't understand what you mean.

We both agree it would be helpful and useable if there is a tool can tell developers which imports are required and which imports have been linked by loader. Right?
So I suggest we provide the tool(a script) directly instead of providing an query API and let users to create their own tools.

We both agree it would be helpful and useable if there is a tool can tell developers which imports are required and which imports have been linked by loader. Right?

no.
IMO it isn't usable without a proper api.
many of programs using wasm-c-api have a logic like this:
https://github.com/yamt/garbage/blob/master/wasm/capi/test.c#L77-L113
i can't imagine any reasonable way to adapt it with your external script approach.

So the usable way mentioned before are:

First, let users prepare all imports no matter which are already linked.
Then, Use a query API to filter out and form a proper import list and pass to wasm_instance_new.

So the usable way mentioned before are ?
* First, let users prepare all imports no matter which are already linked.

* Then, Use a query API to filter out and form a proper import list and pass to `wasm_instance_new`.

i'm not sure what's the best api.
a possible api is to return a wasm_exporttype_vec_t which contains all builtin symbols including wasi.
and make wasm_instance_new skip processing them. (just check they are already linked at load-time.)

Maybe I missed something. Because there is a problem in my view. Developers have to prepare all imports (include potential built-ins). Because there is no such knowledge on which import is linked when they are programming unless I put it into a file (like DefinedSymbol.list) and developers can check it in design phase.
And wasm-wasi can have a lot of imports and usually the missing part (need developer to provide) is a few. I thought it is not worthy to create many wasm_xxxtype_t and wasm_extern_t but not use them eventually.

Maybe I missed something. Because there is a problem in my view. Developers have to prepare all imports (include potential built-ins). Because there is no such knowledge on which import is linked when they are programming unless I put it into a file (like DefinedSymbol.list) and developers can check it in design phase.
And wasm-wasi can have a lot of imports and usually the missing part (need developer to provide) is a few. I thought it is not worthy to create many wasm_xxxtype_t and wasm_extern_t but not use them eventually.

my view is that the set of imports and exports are known to the embedder until you load/instantiate a module.
even the set of available host funcs (both for link-time and instantiate-time) can be changed with something like https://github.com/bytecodealliance/wasm-micro-runtime/tree/main/samples/native-lib.

@try-agaaain please join us
IIUC, there are some pre-condition would infect the final design choices.

Do developers know which imports require host implementations and which will be handled by WAMR? Usually, WAMR supports all (import "wasi_snapshot_preview1" generated by wasi-sdk when setting WAMR_BUILD_LIBC_WASI=1.  Based on that rule, it would be ok for developers to prepare all other imports beside wasi_snaphost_preview.

Do developers know where required imports are. For me , there are two ways to find out indexes of an import item. The first way is using a tool (like wasm-objdump) to dump the import section. The second way is using wasm_module_imports to get wasm_importtype_vec_t and searching in it.  WASM_API_EXTERN const wasm_name_t* wasm_importtype_name(const wasm_importtype_t*) can return the field name. And WAMR should make sure the order of wasm_moudle_imports() return value is same with the order of the argument imports of wasm_instance_new.

Should WAMR ignore or override a loader-linked import item if meets it in the argument imports of wasm_instance_new(). For example, WAMR would provide a built-in implementation for wasi_snapshot_preview1.fd_seek. But a developer passes another one via the imports of wasm_instnace_new() by accident or on purpose. I tend to ignore it because the developer should use WAMR_BUILD_LIBC_WASI=0 if wants to use  a private implementation.

My proposal for how to create  the imports argument for wasm_intance_new would be:

prepare a host function list covers all import requirements. Don't need to be worried about the order at this step. Will deal with it later. Usually, for a wasm32-wasi module, requirements are quite obviously.  Be sure to provide names.
get the import list of current .wasm by wasm_module_imports.
create an wasm_extern_vec_t* imports. It should have same length with wasm_importtype_vec_t returned at previous step.
fill the imports based on both name information provided by wasm_importtype_t and the host function list.

@yamt @lum1n0us The discussion is mainly about how developer should prepare the import list for wasm_instance_new, right? There may be some questions:

Whether developer should fill all import functions/globals into the import list? Can the built-in native APIs be ignored in the import list?
Can the import functions/globals be unordered?
Can developer overwrite the runtime built-in native API with API written by himself?

My opinion is that (1) a full import functions/globals should be filled into the import list, if not, it may be difficult for developer to know which APIs are built-in and can be ignored (e.g. libc-builtin APIs), and also, developer may want to rewrite the native API by himself, (2) The import type can be unordered, but elements of each type should be ordered, for example, all ordered functions followed by all ordered globals, or, all ordered globals followed by all ordered functions, or, mixed elements of all ordered functions and all ordered globals.
I think it is really difficult for developer to create the import list, my suggestion is that we develop a tool to help generate the native API template, somewhat like the Java tool javah, the tool (suppose we name it as wamrh) generates header/source files with empty native APIs, import list and the register process, for example, suppose there is a wasm file below:
(module
  (import "wasi_snapshot_preview1" "args_get" (func $wasi_args_get (param i32 i32) (result i32)))
  (import "wasi_snapshot_preview1" "args_sizes_get" (func $wasi_args_sizes_get (param i32 i32) (result i32)))
  (import "env" "foo1" (func $foo1 (param i32) (param i64) (result i32)))
  (import "env" "foo2" (func $foo2 (param f32) (param f64) (result i32)))
  (func (export "main") (param $x i32) (param $y i32) (result i32)
        ...
  )
)

Note that it imports two wasi built-in APIs which have been implemented by runtime.
The wasm-c-api native API source file generated may be as below:
#include <stdint.h>
#include <stdbool.h>

#include "wasm_c_api.h"

static wasm_trap_t *
foo1_callback(const wasm_val_vec_t *args, wasm_val_vec_t *results)
{
    int32_t arg0 = args->data[0].of.i32;
    int64_t arg1 = args->data[1].of.i64;

    /* TODO */
    return NULL;
}

static wasm_trap_t *
foo2_callback(const wasm_val_vec_t *args, wasm_val_vec_t *results)
{
    float arg0 = args->data[0].of.f32;
    double arg1 = args->data[0].of.f64;

    /* TODO */
    return NULL;
}

static wasm_instance_t *
wasm_instance_create(wasm_store_t *store, wasm_module_t *module)
{
    wasm_functype_t *type_foo1 = NULL;
    wasm_functype_t *type_foo2 = NULL;
    wasm_func_t *func_foo1 = NULL;
    wasm_func_t *func_foo2 = NULL;
    wasm_instance_t *instance = NULL;

    /* Create func types */
    type_foo1 = wasm_functype_new_2_1(
        wasm_valtype_new_i32(), wasm_valtype_new_i64(), wasm_valtype_new_i32());
    type_foo2 =
        wasm_functype_new_1_1(wasm_valtype_new_f32(), wasm_valtype_new_i32());
    if (!type_foo1 || !type_foo2)
        goto fail;

    /* Create functions */
    func_foo1 = wasm_func_new(store, type_foo1, foo1_callback);
    func_foo2 = wasm_func_new(store, type_foo2, foo2_callback);
    if (!func_foo1 || !func_foo2)
        goto fail;

    /* Create instance */
    wasm_extern_t *externs[] = {
        NULL, /* ignore for built-in ("wasi_snapshot_preview1" "args_get") */
        NULL, /* ignore for built-in ("wasi_snapshot_preview1" "args_sizes_get") */
        wasm_func_as_extern(func_foo1), wasm_func_as_extern(func_foo2)
    };
    wasm_extern_vec_t imports = WASM_ARRAY_VEC(externs);
    instance = wasm_instance_new(store, module, &imports, NULL);

fail:
    if (type_foo1)
        wasm_functype_delete(type_foo1);
    if (type_foo2)
        wasm_functype_delete(type_foo1);
    if (func_foo1)
        wasm_func_delete(func_foo1);
    if (func_foo2)
        wasm_func_delete(func_foo2);

    return instance;
}

By this way, developer can just implement the empty APIs and call wasm_instance_create to create the wasm instance, he dont' need to care about the prototype of the native APIs, the import list and the native API register process. It can greatly reduce the effort the developer.
And the template of the wamr runtime API may be like:
#include <stdlib.h>
#include <stdint.h>
#include <stdbool.h>

#include "wasm_export.h"

static int32_t
foo1_wrapper(wasm_exec_env_t exec_env, int32_t arg0, int64_t arg1)
{
    wasm_module_inst_t module_inst = wasm_runtime_get_module_inst(exec_env);

    /* TODO */
    return 0;
}

static int32_t
foo2_wrapper(wasm_exec_env_t exec_env, float arg0, double arg1)
{
    wasm_module_inst_t module_inst = wasm_runtime_get_module_inst(exec_env);

    /* TODO */
    return 0;
}

#define REG_NATIVE_FUNC(func_name, signature) \
    { #func_name, func_name##_wrapper, signature, NULL }

static NativeSymbol native_symbols[] = {
    REG_NATIVE_FUNC(foo1, "(iI)i"),
    REG_NATIVE_FUNC(foo2, "(fF)i")
};

uint32_t
get_native_lib(char **p_module_name, NativeSymbol **p_native_symbols)
{
    *p_module_name = "env";
    *p_native_symbols = native_symbols;
    return sizeof(native_symbols) / sizeof(NativeSymbol);
}

Looking forward for your feedbacks.

prepare a host function list covers all import requirements. Don't need to be worried about the order at this step. Will deal with it later. Usually, for a wasm32-wasi module, requirements are quite obviously. Be sure to provide names.
get the import list of current .wasm by wasm_module_imports.
create an wasm_extern_vec_t* imports. It should have same length with wasm_importtype_vec_t returned at previous step.
fill the imports based on both name information provided by wasm_importtype_t and the host function list.

@lum1n0us Thank you for your suggestion, it seems to be feasible.
However, when I tried to do this, in step four, I couldn't find a proper way to fill the imports with the information from wasm_importtype_t. Because for the compiler, wasm_importtype_t is an "incomplete type", which makes it impossible for me to access its fields.
Is there an existing API or another way that can complete step four?

@yamt @lum1n0us The discussion is mainly about how developer should prepare the import list for wasm_instance_new, right? There may be some questions:
* Whether developer should fill all import functions/globals into the import list? Can the built-in native APIs be ignored in the import list?

* Can the import functions/globals be unordered?

* Can developer overwrite the runtime built-in native API with API written by himself?

My opinion is that (1) a full import functions/globals should be filled into the import list, if not, it may be difficult for developer to know which APIs are built-in and can be ignored (e.g. libc-builtin APIs), and also, developer may want to rewrite the native API by himself, (2) The import type can be unordered, but elements of each type should be ordered, for example, all ordered functions followed by all ordered globals, or, all ordered globals followed by all ordered functions, or, mixed elements of all ordered functions and all ordered globals.

are you talking about wasm-c-api in general?
or about WAMR-specific extensions to it?
if the former, i guess (1) everything should be filled and (2) it should be ordered to match the order in module's imports.
if the latter, i guess we should make it explicit.

I think it is really difficult for developer to create the import list, my suggestion is that we develop a tool to help generate the native API template, somewhat like the Java tool javah, the tool (suppose we name it as wamrh) generates header/source files with empty native APIs, import list and the register process, for example, suppose there is a wasm file below:

IMO, it shouldn't be an offline tool because the list of native symbols can be dynamic.
(wasm_runtime_register_natives/wasm_runtime_unregister_natives)

(module
  (import "wasi_snapshot_preview1" "args_get" (func $wasi_args_get (param i32 i32) (result i32)))
  (import "wasi_snapshot_preview1" "args_sizes_get" (func $wasi_args_sizes_get (param i32 i32) (result i32)))
  (import "env" "foo1" (func $foo1 (param i32) (param i64) (result i32)))
  (import "env" "foo2" (func $foo2 (param f32) (param f64) (result i32)))
  (func (export "main") (param $x i32) (param $y i32) (result i32)
        ...
  )
)

Note that it imports two wasi built-in APIs which have been implemented by runtime. The wasm-c-api native API source file generated may be as below:
#include <stdint.h>
#include <stdbool.h>

#include "wasm_c_api.h"

static wasm_trap_t *
foo1_callback(const wasm_val_vec_t *args, wasm_val_vec_t *results)
{
    int32_t arg0 = args->data[0].of.i32;
    int64_t arg1 = args->data[1].of.i64;

    /* TODO */
    return NULL;
}

static wasm_trap_t *
foo2_callback(const wasm_val_vec_t *args, wasm_val_vec_t *results)
{
    float arg0 = args->data[0].of.f32;
    double arg1 = args->data[0].of.f64;

    /* TODO */
    return NULL;
}

static wasm_instance_t *
wasm_instance_create(wasm_store_t *store, wasm_module_t *module)
{
    wasm_functype_t *type_foo1 = NULL;
    wasm_functype_t *type_foo2 = NULL;
    wasm_func_t *func_foo1 = NULL;
    wasm_func_t *func_foo2 = NULL;
    wasm_instance_t *instance = NULL;

    /* Create func types */
    type_foo1 = wasm_functype_new_2_1(
        wasm_valtype_new_i32(), wasm_valtype_new_i64(), wasm_valtype_new_i32());
    type_foo2 =
        wasm_functype_new_1_1(wasm_valtype_new_f32(), wasm_valtype_new_i32());
    if (!type_foo1 || !type_foo2)
        goto fail;

    /* Create functions */
    func_foo1 = wasm_func_new(store, type_foo1, foo1_callback);
    func_foo2 = wasm_func_new(store, type_foo2, foo2_callback);
    if (!func_foo1 || !func_foo2)
        goto fail;

    /* Create instance */
    wasm_extern_t *externs[] = {
        NULL, /* ignore for built-in ("wasi_snapshot_preview1" "args_get") */
        NULL, /* ignore for built-in ("wasi_snapshot_preview1" "args_sizes_get") */
        wasm_func_as_extern(func_foo1), wasm_func_as_extern(func_foo2)
    };
    wasm_extern_vec_t imports = WASM_ARRAY_VEC(externs);
    instance = wasm_instance_new(store, module, &imports, NULL);

fail:
    if (type_foo1)
        wasm_functype_delete(type_foo1);
    if (type_foo2)
        wasm_functype_delete(type_foo1);
    if (func_foo1)
        wasm_func_delete(func_foo1);
    if (func_foo2)
        wasm_func_delete(func_foo2);

    return instance;
}

By this way, developer can just implement the empty APIs and call wasm_instance_create to create the wasm instance, he dont' need to care about the prototype of the native APIs, the import list and the native API register process. It can greatly reduce the effort the developer.
And the template of the wamr runtime API may be like:
#include <stdlib.h>
#include <stdint.h>
#include <stdbool.h>

#include "wasm_export.h"

static int32_t
foo1_wrapper(wasm_exec_env_t exec_env, int32_t arg0, int64_t arg1)
{
    wasm_module_inst_t module_inst = wasm_runtime_get_module_inst(exec_env);

    /* TODO */
    return 0;
}

static int32_t
foo2_wrapper(wasm_exec_env_t exec_env, float arg0, double arg1)
{
    wasm_module_inst_t module_inst = wasm_runtime_get_module_inst(exec_env);

    /* TODO */
    return 0;
}

#define REG_NATIVE_FUNC(func_name, signature) \
    { #func_name, func_name##_wrapper, signature, NULL }

static NativeSymbol native_symbols[] = {
    REG_NATIVE_FUNC(foo1, "(iI)i"),
    REG_NATIVE_FUNC(foo2, "(fF)i")
};

uint32_t
get_native_lib(char **p_module_name, NativeSymbol **p_native_symbols)
{
    *p_module_name = "env";
    *p_native_symbols = native_symbols;
    return sizeof(native_symbols) / sizeof(NativeSymbol);
}

Looking forward for your feedbacks.

My opinion is that (1) a full import functions/globals should be filled into the import list, if not, it may be difficult for developer to know which APIs are built-in and can be ignored (e.g. libc-builtin APIs), and also, developer may want to rewrite the native API by himself, (2) The import type can be unordered, but elements of each type should be ordered, for example, all ordered functions followed by all ordered globals, or, all ordered globals followed by all ordered functions, or, mixed elements of all ordered functions and all ordered globals.

are you talking about wasm-c-api in general? or about WAMR-specific extensions to it? if the former, i guess (1) everything should be filled and (2) it should be ordered to match the order in module's imports. if the latter, i guess we should make it explicit.

It is a WAMR-specific tool and we may publish it with other binary files released. The usage may be like:
wamrh --wasi-c-api -o test.c test.wasm     # generate native API template src file for wasm-c-api mode
wamrc --wamr-api -o test.c test.wasm       #generate native API template src file for wamr-api mode

We can name it wamrh or others, and the options can be discussed, more options may be provided.

I think it is really difficult for developer to create the import list, my suggestion is that we develop a tool to help generate the native API template, somewhat like the Java tool javah, the tool (suppose we name it as wamrh) generates header/source files with empty native APIs, import list and the register process, for example, suppose there is a wasm file below:

IMO, it shouldn't be an offline tool because the list of native symbols can be dynamic. (wasm_runtime_register_natives/wasm_runtime_unregister_natives)

I think it can be an offline tool, the goal is to generate the empty import function definitions and the symbols array to register: for wasm-c-api mode, it generates the wasm_extern_t *externs[] array and a API wasm_instance_create to call wasm_instance_new to register the callbacks, developer can just call the wasm_instance_create to register the callbacks. For wamr-api mode, it generates NativeSymbol native_symbols[] array, and developer can register them with wasm_runtime_register_natives. See samples above for details.
It is like javah tool: https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javah.html
IMO, wasm vm is somewhat like java vm, the jvm can provide the tool, why wasm vm can not provide such tool?
For a wasm file, the import functions are pre-specified in the wasm file, and some of them may be implemented by runtime builit-in native APIs, we may generate the empty functions that aren't implemented by runtime, or add options to control whether to generate their empty definitions.

I'm probably missing something from the discussion but agree with @yamt that there should be an API or some way to generate this dynamically since the host does not know ahead of time what APIs the wasm is going to import from the runtime. A codegen/compile time solution wont work for my use case at least.
Is the suggestion above to prepare a list of all possible WASI imports, then all host defined native imports, pass it when instantiating the module and then having the runtime ignore imports from the list which are not required?

I'm probably missing something from the discussion but agree with @yamt that there should be an API or some way to generate this dynamically since the host does not know ahead of time what APIs the wasm is going to import from the runtime. A codegen/compile time solution wont work for my use case at least.
Is the suggestion above to prepare a list of all possible WASI imports, then all host defined native imports, pass it when instantiating the module and then having Wamr ignore imports from the list which are not required?

Yes, the suggested tool is to generate a list of both all possible WASI imports and all host defined native imports, but there may be option to control how to fill all possible WASI imports into the list: (1) fill the list with NULL pointers and runtime just ignores them since there are built-in WASI import implementations of them, (2) generate empty WASI import definitions, but the code is commented, and if developer wants to re-write the import, he can uncomment the code and fill the list with the related function pointer.
For the non-wasi (or non-builtin) imports, the tool generates the empty definitions, so developer can just implement them.
For example, if a wasm module imports two wasi APIs and two host defined APIs:
  (import "wasi_snapshot_preview1" "args_get" (func $wasi_args_get (param i32 i32) (result i32)))
  (import "wasi_snapshot_preview1" "args_sizes_get" (func $wasi_args_sizes_get (param i32 i32) (result i32)))
  (import "env" "foo1" (func $foo1 (param i32) (param i64) (result i32)))
  (import "env" "foo2" (func $foo2 (param f32) (param f64) (result i32)))

Then the tool generates the empty definitions of the host defined APIs:
static wasm_trap_t *
foo1_callback(const wasm_val_vec_t *args, wasm_val_vec_t *results)
{
    int32_t arg0 = args->data[0].of.i32;
    int64_t arg1 = args->data[1].of.i64;

    /* developer to implement the API */
    return NULL;
}

static wasm_trap_t *
foo2_callback(const wasm_val_vec_t *args, wasm_val_vec_t *results)
{
    float arg0 = args->data[0].of.f32;
    double arg1 = args->data[0].of.f64;

    /* developer to implement the API */
    return NULL;
}

And then it generates an API, which creates a import list and then invokes wasm_instance_new with the import list to register all the imports:
static wasm_instance_t *
wasm_instance_create(wasm_store_t *store, wasm_module_t *module)
{
    ...
    /* Create functions */
    func_foo1 = wasm_func_new(store, type_foo1, foo1_callback);
    func_foo2 = wasm_func_new(store, type_foo2, foo2_callback);
    if (!func_foo1 || !func_foo2)
        goto fail;

    /* Create instance */
    wasm_extern_t *externs[] = {                       ==> The import list
        NULL, /* ignore for built-in ("wasi_snapshot_preview1" "args_get") */
        NULL, /* ignore for built-in ("wasi_snapshot_preview1" "args_sizes_get") */
        wasm_func_as_extern(func_foo1),           ==> user defined API
        wasm_func_as_extern(func_foo2)            ==> user defined API
    };
    wasm_extern_vec_t imports = WASM_ARRAY_VEC(externs);
    instance = wasm_instance_new(store, module, &imports, NULL);      ==> new the wasm module with the import list
    ...
    return instance;
}

Then developer can call this API wasm_instance_create to new the wasm module instance. He can integrate this source file with his project.
I think this way should be friendly and clearly, and it can reduce the effort of developer.
Not sure whether it meets the requirements of you?

@try-agaaain The way of using wasm_importype_vect_t to create an import list likes below.  It only includes the key part but not a fully runnable function.
static wasm_instance_t *
wasm_instance_create(wasm_store_t *store, wasm_module_t *module) {
    wasm_importtype_vec_t import_types = { 0 };
    wasm_module_imports(module, &import_types);

    wasm_extern_t *externs[4] = { 0 };

    for (unsigned i = 0; i < import_types.num_elems; i++) {
        wasm_importtype_t *import_type = &(import_types.data[i]);
        wasm_byte_vec_t *module_name = wasm_importtype_module(import_type);
        wasm_byte_vec_t *field_name = wasm_importtype_name(import_type);
        char module_name_str[64] = { 0 };
        char field_name_str[64] = { 0 };

        memcpy(module_name_str, module_name->data, module_name->num_elems);
        memcpy(field_name_str, field_name->data, field_name->num_elems);

        /* ignore for built-int. It is WAMR's duty to provide imports of
         * `wasm_snapshot_preview1 */
        if (strncmp(module_name_str, "wasm_snapshot_preview1",
                    strlen("wasm_snapshot_preview1"))
            == 0)
            continue;

        if (strncmp(field_name_str, "foo1", strlen("foo1")) == 0) {
            wasm_functype_t *type_foo1 = wasm_functype_new_2_1(
                wasm_valtype_new_i32(), wasm_valtype_new_i64(),
                wasm_valtype_new_i32());
            wasm_func_t *func_foo1 =
                wasm_func_new(store, type_foo1, foo1_callback);

            externs[i] = wasm_func_as_extern(func_foo1);
        }
        else if (strncmp(field_name_str, "foo2", strlen("foo2")) == 0) {
            wasm_functype_t *type_foo2 = wasm_functype_new_1_1(
                wasm_valtype_new_f32(), wasm_valtype_new_i32());
            wasm_func_t *func_foo2 =
                wasm_func_new(store, type_foo2, foo2_callback);

            externs[i] = wasm_func_as_extern(func_foo2);
        }
    }

    wasm_extern_vec_t imports = WASM_ARRAY_VEC(externs);
    /* Create instance */
    wasm_instance_t *instance =
        wasm_instance_new(store, module, &imports, NULL);
}

use wasm_moudle_import to retrieve wasm_importtype_t list. The big advantage here is there are name information in wasm_importtype_t.
create a wasm_externvec_t as a target to filled in. It should have the same length of wasm_importtype_vec_t from previous step.
traversal wasm_importtype_t in a loop. Since it has the same required order with wasm_importtype_vec_t, it is convenient to check the name of import.
It should be Wasm runtime's duty to provide all import with a module name like wasm_snapshot_preview1. It is a big assumption and it is the key point to allow developers to form imports without scanning .wasm.

many of programs using wasm-c-api have a logic like this:
https://github.com/yamt/garbage/blob/master/wasm/capi/test.c#L77-L113
i can't imagine any reasonable way to adapt it with your external script approach.

@yamt  IIUC, the only difference is let Wasm runtime handle "standard APIs" and let users handle "private functions"
@wenyongh  The script idea will work well if wasm-c-api users just have a few target .wasm. It would be hard when the amount of target .wasm growing.
If we are going to suggest wasm-c-api users to create the imports list based on name information from wasm_importtype_t,

make sure wasm_importtype_vec_t from wasm_module_import has the proper order which wasm_instance_new required.
make sure always be compatible with wasi-libc. May need a CI to compare __imported_wasi_snapshot_preview1_XXX in https://github.com/WebAssembly/wasi-libc/blob/b4814997f61ee352d8c1ae397561a813fb30c701/expected/wasm32-wasi/undefined-symbols.txt with native_symbols_libc_wasi?

@wenyongh The script idea will work well if wasm-c-api users just have a few target .wasm. It would be hard when the amount of target .wasm growing.

@lum1n0us Not sure what the amount of target .wasm means? Does it mean the amount of the import functions? If yes, wondering why it is hard when the amount of import functions grows? For developer, after generating the template file, normally there are two things to do:

Implement the empty functions
Integrate the file into his project, and call wasm_instance_create to create the instance with the imports

For the first thing, he should do it no matter using the tool or not. For the second thing, it should be simple enough: he doesn't need to prepare the import list and create the function types and the functions for the list, and he doesn't need to care the import function order inside the import list, all these are done by tool.

If we are going to suggest wasm-c-api users to create the imports list based on name information from wasm_importtype_t,

make sure wasm_importtype_vec_t from wasm_module_import has the proper order which wasm_instance_new required.

Seems it is difficult (at least not very easy) for developer to prepare the list with proper order, firstly he should know what the is order required by runtime, secondly he should know what the imports are in the wasm file and what the order of them is, normally he should use special tool (e.g. wasm-objdump, wasm2wat) to do it.

My opinion is that (1) a full import functions/globals should be filled into the import list, if not, it may be difficult for developer to know which APIs are built-in and can be ignored (e.g. libc-builtin APIs), and also, developer may want to rewrite the native API by himself, (2) The import type can be unordered, but elements of each type should be ordered, for example, all ordered functions followed by all ordered globals, or, all ordered globals followed by all ordered functions, or, mixed elements of all ordered functions and all ordered globals.

are you talking about wasm-c-api in general? or about WAMR-specific extensions to it? if the former, i guess (1) everything should be filled and (2) it should be ordered to match the order in module's imports. if the latter, i guess we should make it explicit.

It is a WAMR-specific tool and we may publish it with other binary files released. The usage may be like:
wamrh --wasi-c-api -o test.c test.wasm     # generate native API template src file for wasm-c-api mode
wamrc --wamr-api -o test.c test.wasm       #generate native API template src file for wamr-api mode

We can name it wamrh or others, and the options can be discussed, more options may be provided.

I think it is really difficult for developer to create the import list, my suggestion is that we develop a tool to help generate the native API template, somewhat like the Java tool javah, the tool (suppose we name it as wamrh) generates header/source files with empty native APIs, import list and the register process, for example, suppose there is a wasm file below:

IMO, it shouldn't be an offline tool because the list of native symbols can be dynamic. (wasm_runtime_register_natives/wasm_runtime_unregister_natives)

I think it can be an offline tool, the goal is to generate the empty import function definitions and the symbols array to register: for wasm-c-api mode, it generates the wasm_extern_t *externs[] array and a API wasm_instance_create to call wasm_instance_new to register the callbacks, developer can just call the wasm_instance_create to register the callbacks. For wamr-api mode, it generates NativeSymbol native_symbols[] array, and developer can register them with wasm_runtime_register_natives. See samples above for details.
It is like javah tool: https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javah.html IMO, wasm vm is somewhat like java vm, the jvm can provide the tool, why wasm vm can not provide such tool?
For a wasm file, the import functions are pre-specified in the wasm file, and some of them may be implemented by runtime builit-in native APIs, we may generate the empty functions that aren't implemented by runtime, or add options to control whether to generate their empty definitions.

it can be an offline tool and we can provide it. maybe it works for some static usage.
however, there are use cases for which such an offline tool is not appropriate.
for my use case, none of following is known ahead of time:

available set of native symbols
what a wasm module imports

so, my suggestion is to provide a runtime api for an embedder to query which imports are already linked at load time. the embedder then can/should use a dummy extern entry like NULL for them.

it can be an offline tool and we can provide it. maybe it works for some static usage.
however, there are use cases for which such an offline tool is not appropriate. for my use case, none of following is known ahead of time:

available set of native symbols
what a wasm module imports

so, my suggestion is to provide a runtime api for an embedder to query which imports are already linked at load time. the embedder then can/should use a dummy extern entry like NULL for them when calling wasm_instance_new().

Got it, it sounds reasonable, shall we query each kind of import? How about:
bool wasm_runtime_is_import_func_linked(const char *module_name, const char *field_name);
bool wasm_runtime_is_import_global_linked(const char *module_name, const char *field_name);

Import memory and import table are not supported.
BTW, do you agree that for wasm_module_new, developer should provide a full list of the imports, and the order of each import type (functions or globals) should be same as the order of them in the wasm file? And if a NULL func pointer is filled, runtime can just ignore it?

my suggestion is to provide a runtime api for an embedder to query which imports are already linked at load time. the embedder then can/should use a dummy extern entry like NULL for them when calling wasm_instance_new().

Just to solidify with a use case, consider for example I have a Wamr application with a plugin system - the plugin system has an API where the plugin can define a set of functions which can be used by Wasm at runtime. Plugins can be developed at any time, including tomorrow after I ship my application, so I don't know what functions might be used in the future. The Wasm run on the device may or may not make use of the plugin for whatever reason.
Further to that, I might also add some code down the line which adds or removes the use of some Wasi API and so I can't know ahead of time which Wasi functions are required from the runtime either.
With the scenario described above:

I need to be able to dynamically generate a list of imports provided from the application including its plugins.
I need to be able to know all supported wasi functions from Wamr.

The suggestion above, where we can just get a list of all functions from Wamr makes sense to me, it can then be appended to my list of plugin functions, and passed to Wamr when instantiating the module, so long as unused/unlinked functions are ignored, and order doesn't matter.
Note that this scenario was already kind of working with register_natives. I keep a list of registered native functions which I then register with Wamr using the register_natives function. When instantiating the module I was passing NULL as the imports vector, and Wamr would work everything out, but the functionality broke recently. It would be preferable though if I could use the wasm C api to link all these imports at instantiate time because managing all these functions though the engine singleton means I need to be careful particularly if I have wasm running on multiple threads not to unload plugins.

my suggestion is to provide a runtime api for an embedder to query which imports are already linked at load time. the embedder then can/should use a dummy extern entry like NULL for them when calling wasm_instance_new().

Just to solidify with a use case, consider for example I have a Wamr application with a plugin system - the plugin system has an API where the plugin can define a set of functions which can be used by Wasm at runtime. Plugins can be developed at any time, including tomorrow after I ship my application, so I don't know what functions might be used in the future. The Wasm run on the device may or may not make use of the plugin for whatever reason.
Further to that, I might also add some code down the line which adds or removes the use of some Wasi API and so I can't know ahead of time which Wasi functions are required from the runtime either.
With the scenario described above:

I need to be able to dynamically generate a list of imports provided from the application including its plugins.
I need to be able to know all supported wasi functions from Wamr.

The suggestion above, where we can just get a list of all functions from Wamr makes sense to me, it can then be appended to my list of plugin functions, and passed to Wamr when instantiating the module, so long as unused/unlinked functions are ignored, and order doesn't matter.

Do you mean that the API bool wasm_runtime_is_import_func_linked(const char *module_name, const char *func_name) makes sense? Or runtime should provide another API to get all the linked functions? The latter API may be a little complex.
BTW, the order of the functions does matter, my understanding is that the order of functions in the import list should be exactly same with the order in the wasm file, since the import list doesn't take the info of import function's module name and function name, runtime cannot know which import func of the instance to new should be linked to for each function in the import list. It seems runtime had better link them by the index in the import list (suppose no globals in import list): imports[i] is linked to instance->imports[i], and if imports[i]'s func_ptr is NULL, runtime just ignores linking.

I think that wasm_runtime_is_import_func_linked would work fine, if I load the module then ahead of instantiation can get all the function imports and use this API to check if I should set as NULL in the imports vector.
Modifying code form above, but something like:
static wasm_instance_t *
wasm_instance_create(wasm_store_t *store, wasm_module_t *module) {
    wasm_importtype_vec_t import_types = { 0 };
    wasm_module_imports(module, &import_types);

    wasm_extern_t *externs[4] = { 0 };

    for (unsigned i = 0; i < import_types.num_elems; i++) {
        wasm_importtype_t *import_type = &(import_types.data[i]);
        wasm_byte_vec_t *module_name = wasm_importtype_module(import_type);
        wasm_byte_vec_t *field_name = wasm_importtype_name(import_type);
        char module_name_str[64] = { 0 };
        char field_name_str[64] = { 0 };

        memcpy(module_name_str, module_name->data, module_name->num_elems);
        memcpy(field_name_str, field_name->data, field_name->num_elems);

        if (wasm_runtime_is_import_func_linked(module_name_str, field_name_str)) {
            continue;
        }

        if (is_function_from_a_plugin(module_name_str, field_name_str)) {
            // Set up import from host function
        }
    }

    wasm_extern_vec_t imports = WASM_ARRAY_VEC(externs);
    wasm_instance_t *instance =
        wasm_instance_new(store, module, &imports, NULL);
}

it can be an offline tool and we can provide it. maybe it works for some static usage.
however, there are use cases for which such an offline tool is not appropriate. for my use case, none of following is known ahead of time:

available set of native symbols
what a wasm module imports

so, my suggestion is to provide a runtime api for an embedder to query which imports are already linked at load time. the embedder then can/should use a dummy extern entry like NULL for them when calling wasm_instance_new().

Got it, it sounds reasonable, shall we query each kind of import? How about:
bool wasm_runtime_is_import_func_linked(const char *module_name, const char *func_name);
bool wasm_runtime_is_import_global_linked(const char *module_name, const char *global_name);

Import memory and import table are not supported.
BTW, do you agree that for wasm_module_new, developer should provide a full list of the imports, and the order of each import type (functions or globals) should be same as the order of them in the wasm file? And if a NULL func pointer is filled, runtime can just ignore it?

i was thinking something like:
bool wasm_importtype_linked(wasm_importtype_t *);

to examine the result of wasm_module_imports.
i guess your wasm_runtime_is_import_func_linked/wasm_runtime_is_import_global_linked need to take a type. (function signature incase of func)
spec-wise wasm allows type-based overloading with the same import name. while wamr might or might not want to support it, it's better not to exclude it in the api. how do you think?

i was thinking something like:
bool wasm_importtype_linked(wasm_importtype_t *);

This requires a bit less work for the embedder - I guess we can also propose this for addition to wasm-c-api?

i was thinking something like:
bool wasm_importtype_linked(wasm_importtype_t *);

to examine the result of wasm_module_imports.
i guess your wasm_runtime_is_import_func_linked/wasm_runtime_is_import_global_linked need to take a type. (function signature incase of func) spec-wise wasm allows type-based overloading with the same import name. while wamr might or might not want to support it, it's better not to exclude it in the api. how do you think?

Maybe we can provide both wasm_runtime_is_import_func_linked and wasm_is_importtype_linked, the former is declared in wasm_export.h and the latter is declared in wasm_c_api.h. For developer using WAMR API in wasm_export.h, he can use the former to check whether an import func is linked, for developer using wasm-c-api, he can use the latter. And both of them require signature. The prototype may be:
bool
wasm_runtime_is_import_func_linked(const char *module_name, const char *func_name,
                                                            const char *signature);
bool
wasm_runtime_is_import_global_linked(const char *module_name, const char *global_name);

bool
wasm_is_importtype_linked(wasm_importtype_t *import_type);

For the signature argument in wasm_runtime_is_import_func_linked, the supported format is like the format of signature in wasm_runtime_register_natives, character i/I/f/F mean i32/i64/f32/f64 types, e.g. "(iI)f" mean func argument type (i32, i64) and return type f32.
And if the above is OK, maybe we can implement these APIs and fix the import linking process in wasm-c-api accordingly.

Maybe we can provide both wasm_runtime_is_import_func_linked and wasm_is_importtype_linked, the former is declared in wasm_export.h and the latter is declared in wasm_c_api.h.

do you imply we might introduce instantiate-time linking for wasm_export.h api?
(otherwise this functionality doesn't seem necessary there.)

we tend to keep "loading-time-linking" in wasm_export.h and keep "instantiate-time-linking" in wasm_c_api.h both. Hope we can maintain the capability on both sides or else we might be looking at a big U-turn.

Maybe we can provide both wasm_runtime_is_import_func_linked and wasm_is_importtype_linked, the former is declared in wasm_export.h and the latter is declared in wasm_c_api.h.

do you imply we might introduce instantiate-time linking for wasm_export.h api? (otherwise this functionality doesn't seem necessary there.)

@yamt @nchamzn Liang has basically implemented the feature with samples and document provided, could you help review the PR? If there is no issue left, we may merge the PR.
The wasm_runtime_is_import_func_linked and wasm_is_importtype_linked are added, and another API wasm_extern_new_empty is also implemented to create an empty placeholder if the linking of that function/global is to be ignored. The sample code provided by @nchamzn may be changed like:
static wasm_instance_t *
wasm_instance_create(wasm_store_t *store, wasm_module_t *module) {
    wasm_importtype_vec_t import_types = { 0 };
    wasm_module_imports(module, &import_types);

    // should be dynamic
    wasm_extern_t *externs[4] = { 0 };

    for (unsigned i = 0; i < import_types.num_elems; i++) {
        wasm_importtype_t *import_type = &(import_types.data[i]);

        if (wasm_is_importtype_linked(import_type)) {
            // push empty placeholder to externs
            externs[i] = wasm_extern_new_empty(store, wasm_externtype_kind(wasm_importtype_type(importtype)));
        } else if (is_function_from_a_plugin(module_name_str, field_name_str)) {
            // Set up import from host function and add to externs
        } else {
            // warn/err
        }
    }

    wasm_extern_vec_t imports = WASM_ARRAY_VEC(externs);
    wasm_instance_t *instance =
        wasm_instance_new(store, module, &imports, NULL);
}

Thanks @wenyongh and @lum1n0us . As discussed, this should address my issues. To test this is going to require a bit of refactoring since I'm currently using the register_natives apis, but I will have a look at this and report back if I have some problems.

authors: lum1n0us nchamzn try-agaaain wenyongh yamt

repo: bytecodealliance/wasm-micro-runtime


text:
Prepare for v0.13.1 release.

I think some API docs were deleted by accident. Did you run build.sh?

Yes, I did. There wasn't any error message. I'm re-running that and checking what happened

source: gharchive/pull-request

repo: bytewax/bytewax

license_type: permissive

license_source: github-api


text:
Update Composer dependencies (2023-03-28-00-10)

Visual regression test passed!
View the visual regression test report

license: MIT


text:
Update Composer dependencies (2024-08-20-00-07)

Visual regression test failed!


text:
Lora sam

This is outdated, can be closed

repo: caroteu/micro-sam


text:
refactor: fix object/provider.go:316:2: unreachable code

@wrongch stop making spam PRs in the repo again. Or you will be banned and reported to GitHub

authors: hsluoyz wrongch

repo: casdoor/casdoor


text:
Updated balsamiq-mockups

Thank you for the contribution. It was merged directly as 8a784190306c031807223fdc21cf81c4fb295aa0 to keep commit history cleaner. Your contribution is still credited to you.

repo: caskroom/homebrew-cask


text:
handylock.rb: updated vendor comment

Merged as a59bd112df8e98a5dfdd97d3fbbef3ebd1e588d3.


text:
Implement deploys table using sidecar

Moving to middleware.

source: gharchive/issue


text:
spot check xbrl metadata calculations within electric_operating_revenues_ferc1: usable or not?

See #2016 for full notes. This table is missing two sub-components which originate from the rate schedule table and will need to be incorporated as a cross-table calculation. Otherwise, all calculations appear as expected.

Reopening now that this sub-component issue has been fixed in #2599 as there are still missing data issues.

Missing data issues seem to have been resolved in the reorganization of the transformer in #2618

authors: cmgosnell e-belfer

repo: catalyst-cooperative/pudl

license: mit

license_source: bigquery


text:
Clean up the README

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@6858eed). Click here to learn what that means.
The diff coverage is n/a.

@@          Coverage Diff           @@
##             main      #3   +/-   ##
======================================
  Coverage        ?   50.0%
======================================
  Files           ?       1
  Lines           ?       6
  Branches        ?       0
======================================
  Hits            ?       3
  Misses          ?       3
  Partials        ?       0

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6858eed...b97abb8. Read the comment docs.

authors: codecov-commenter zaneselvans

repo: catalyst-cooperative/python-template


text:
[Monitoring] If an expired bearer token has been used (or attempted to be used)

Should be closed when https://github.com/cds-snc/forms-terraform/pull/175 is merged

repo: cds-snc/platform-forms-client


text:
Jh dev

。

OK

authors: JunhongC-coder hoshinokiichi

repo: charlottechengg/starducks


text:
feat: Add generating ts files on changes

@anikitinDSR This will likely not be needed, depending on Buf.build publishing in cheqd-node repo

Not necessary when using buf.build upstream

authors: anikitinDSR ankurdotb

repo: cheqd/ts-proto


text:
Save, read last_user_inline_dialogue as list

This PR is canceled. Will be combined in the next PR.


text:
Add VarPassedTo2Submodules test

It waits for https://github.com/chipsalliance/Surelog/issues/2316

repo: chipsalliance/UHDM-integration-tests


text:
Adding Stereoisomer Enumeration

I looked through the changes and made some particular notes. Below are more general ones;

We may remove complex_id argument and use mol_id and stereo_id by default to name individual records. This will simplify code. Breaking backward compatibility should be a minor issue. Default value of stereo_id should be 0
Let's make implementation of alternative protonation scheme in a separate pull request. It is a little bit more complex. We have to add a command line argument, and a user may specify which protonation utility should be used from the list of supported ones. Dimorphite is not the best one and in future I'm thinking to implement support of different tools. Therefore, implementation should not be hard coded.
Please insert spaces where they usually needed and replace stereo_index with stereo_id to be more consistent with database field names.

I have edited some of the commits based on your suggestions. Is there any more edits that I have missed?

After those comments will be fixed, I think we will test and accept the PR.
Regarding replacement of chemaxon. I'll implement a generic interface which should enable easy integration of third-party protonation tools and you will be able to commit Dimorphite-DL. This will be really useful - https://github.com/ci-lab-cz/easydock/issues/17.

Alright, I have edited the naming. Can you check if that is alright before testing it?

It looks OK, I do not see any issues for main functionality. It can be tested.
The will be one more change required - get_sdf_from_dock_db.py. It should be also adapted to stereoisomers, but I cannot decide how to do this to keep backward compatibility and easiness to use. I suggest to do that after we will implement the current changes. Probably I'll fix this script by myself. It has a little bit complex logic because we use it to extract data from similar database structures but not identical and keeping this compatibility is very convenient for other projects.

It seems that everything works fine. Hope so)
Thanks a lot for the contribution!
I hope I'll soon implement a new interface to easily integrate custom protonation tools

authors: DrrDom Feriolet

repo: ci-lab-cz/easydock


text:
Add a version command to display version based on tage and checksum

Pull Request Test Coverage Report for Build 2200694766

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 0.0%

Totals

Change from base Build 2198313650:
0.0%

Covered Lines:
0

Relevant Lines:
0

💛  - Coveralls

authors: clarkezone coveralls

repo: clarkezone/previewd


text:
Add health endpoint

Closing in favour of https://github.com/clearlydefined/website/pull/1068
Doing via NGINX is simpler

repo: clearlydefined/website


text:
Fix missing interpretation_description values in new clinical_assertion tables

Need to ensure the DrugForTherapeuticAssertion value is preserved somewhere. Add test for this.
<ClinicalAssertion ID="9794255" SubmissionDate="2024-06-27" DateLastUpdated="2024-06-29" DateCreated="2024-06-02">
        <ClinVarSubmissionID localKey="civic.AID:7" localKeyIsSubmitted="1" />
        <ClinVarAccession Accession="SCV005045669" DateUpdated="2024-06-29" DateCreated="2024-06-02" Type="SCV" Version="2" SubmitterName="Wagner Lab, Nationwide Children's Hospital" OrgID="509553" OrganizationCategory="laboratory" />
        <RecordStatus>current</RecordStatus>
        <Classification DateLastEvaluated="2018-05-15">
          <ReviewStatus>criteria provided, single submitter</ReviewStatus>
          <SomaticClinicalImpact ClinicalImpactAssertionType="therapeutic" ClinicalImpactClinicalSignificance="sensitivity/response" DrugForTherapeuticAssertion="Dabrafenib;Trametinib">Tier I - Strong</SomaticClinicalImpact>
          <Citation>
            <ID Source="PubMed">25265492</ID>
          </Citation>
          <Citation>
            <ID Source="PubMed">23020132</ID>
          </Citation>
          <Citation>
            <ID Source="PubMed">28891408</ID>
          </Citation>
          <Citation>
            <ID Source="PubMed">25399551</ID>
          </Citation>
          <Comment>Combination treatment of BRAF inhibitor dabrafenib and MEK inhibitor trametinib is recommended for adjuvant treatment of stage III or recurrent melanoma with BRAF V600E mutation detected by the approved THxID kit, as well as first line treatment for metastatic melanoma. The treatments are FDA approved based on studies including the Phase III COMBI-V, COMBI-D and COMBI-AD Trials. Combination therapy is now recommended above BRAF inhibitor monotherapy. Cutaneous squamous-cell carcinoma and keratoacanthoma occur at lower rates with combination therapy than with BRAF inhibitor alone.</Comment>
        </Classification>
        <Assertion>variation to disease</Assertion>
        <AttributeSet>
          <Attribute Type="AssertionMethod">AMP/ASCO/CAP Guidelines, 2017</Attribute>
          <Citation>
            <ID Source="PubMed">27993330</ID>
          </Citation>
        </AttributeSet>
        <ObservedInList>
          <ObservedIn>
            <Sample>
              <Origin>somatic</Origin>
              <Species TaxonomyId="9606">human</Species>
              <AffectedStatus>yes</AffectedStatus>
            </Sample>
            <Method>
              <MethodType>curation</MethodType>
            </Method>
            <ObservedData>
              <Attribute Type="Description">not provided</Attribute>
            </ObservedData>
          </ObservedIn>
        </ObservedInList>
        <SimpleAllele>
          <GeneList>
            <Gene Symbol="BRAF" />
          </GeneList>
          <VariantType>Variation</VariantType>
          <OtherNameList>
            <Name Type="SubmitterVariantId">civic.mpid:12</Name>
          </OtherNameList>
          <AttributeSet>
            <Attribute Type="HGVS">NM_004333.4:c.1799T>A</Attribute>
          </AttributeSet>
        </SimpleAllele>
        <TraitSet Type="Disease">
          <Trait Type="Disease">
            <Name>
              <ElementValue Type="Preferred">Melanoma</ElementValue>
            </Name>
          </Trait>
        </TraitSet>
        <SubmissionNameList>
          <SubmissionName>SUB14487648</SubmissionName>
          <SubmissionName>SUB14568896</SubmissionName>
        </SubmissionNameList>
      </ClinicalAssertion>

repo: clingen-data-model/clinvar-ingest


text:
Multi tenancy gitops cp4s

I am not sure what is going on with my latest pull requests.


text:
introduce cloudflare platform object containing all the cloudflare context relative to the request

I don't think we should move env away from process.env. This means apps won't "just work" when deployed to Pages.

ah.... I guess for env you do have a point 😕
I'm not sure what you don't like about cf and ctx 😢 (we should however have a way to expose them to the users)
we could also move them directly into the process.env but I am afraid of name conflicts (unless we call them something else)

After discussing it offline with @GregBrimble we decided to try something different, so I am closing this PR

Yeah, why hide cf from users?

@shiqimei thank you for your comment 🙂
I will bring this to the team and see if we can decide, it does sound like it would be a valuable change (especially for now and we can change things later in a major version if need be)
One small thing to note is that your solution does introduce a sort of breaking change because if users has a binding called CloudflareContext it would get overridden by yours... but yeah that sounds extremely unlikely so maybe it's something that can be overlooked...

Regarding why we haven't yet implemented a solution, that's only because we've been trying to decide on an agnostic solution that could be applied generally by anyone using Cloudflare workers/pages, we have some ideas but it's taking quite some time since different teams are involved, truthfully I need to chase that up!
Anyways as I said we could go with a temporary solution anyways now and revert it in a major maybe... let me check with the team and come back to you 👍

authors: dario-piotrowicz shiqimei

repo: cloudflare/next-on-pages


text:
Improve the search for clang;

Is the old way causing problems somewhere @joergdw? Not that the change isn't better, just wondering what situation triggered the change.

Yes, it is causing problems, see https://github.com/cloudfoundry/bosh-package-ruby-release/issues/36. In our case it is located elsewhere, defined by PATH.

Hi @joergdw this looks good now, however could you make the changes to ci/templates/packages/ruby/packaging.erb and ci/templates/src/compile.env.erb too? Those are actually the templates that are used to generate the scripts.

Thank you for that comment @jpalermo. I have adapted the two templates you have mentioned.

authors: joergdw jpalermo

repo: cloudfoundry/bosh-package-ruby-release


text:
sharpen-progress-dial does not support Result Pending state.

I am updating the component so that you just pass in the description you want, it doesn't try to auto-generate it:
<sharpen-progress-dial
    description="Result Pending"
    progress-val="0"
    high-threshold="200"
    low-threshold="75"
    elevated-threshold="180">
  </sharpen-progress-bar>

authors: jabbett mohd-anas-ansari

repo: coggen/kezuri


text:
thermald: non-blocking power save configuration

Closing for now as it's unclear how to cleanly resolve the race condition with on-lining the cores. Let's revisit this when we look into going onroad faster.

repo: commaai/openpilot


text:
[dev] update build from main for testing flang-rt; mk. 3

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe/meta.yaml:

ℹ The recipe is not parsable by parser conda-souschef (grayskull). Your recipe may not receive automatic updates and/or may not be compatible with conda-forge's infrastructure. Please check the logs for more information and ensure your recipe can be parsed.
ℹ The recipe is not parsable by parser conda-recipe-manager. Your recipe may not receive automatic updates and/or may not be compatible with conda-forge's infrastructure. Please check the logs for more information and ensure your recipe can be parsed.

This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/12284555615. Examine the logs at this URL for more detail.

authors: conda-forge-admin h-vetinari

repo: conda-forge/clangdev-feedstock


text:
@conda-forge-admin, please add @rmcd-mscb

@conda-forge-admin, please add @rmcd-mscb

Not sure why this one failed but I re-issued the command in #7

authors: ocefpaf rmcd-mscb

repo: conda-forge/gdptools-feedstock


text:
Update composable-injective.json

Changing IBC connections can be quite problematic. Do we have any proof the the originally used connection has little to no funds transferred (and to be abandoned)?

Well the composable team ask us to do that, I am also the one wgo create the previous channel and it is expried

and yes there are no funds on that channel @JeremyParish69 so we decide to create a new channel instead of reviving it by gov

OK I found this: https://www.mintscan.io/injective/relayers/channel-141/not-established/channel-10

repo: cosmos/chain-registry


text:
Task endpoints

depends on #32
cc: @cichan02

repo: cqqqt/Task-Viewer-Backend


text:
Update version to 1.3.1-beta

Codecov Report

Merging #109 (75d3c3a) into main (a8fb996) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main      #109   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           16        16
  Lines          729       729
=========================================
  Hits           729       729

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

authors: codecov-commenter craigktreasure

repo: craigktreasure/SlnUp


text:
configuration cleanup: nuke.ps1

https://github.com/cykomaniacs/cyko/commit/82cee6e5a89e6e149e5fc8e18a0b0cf9131f4e0e

repo: cykomaniacs/cyko


text:
Transaksisection

penambahan histori page dan beberapa komponen dan penyatuan package.json

repo: cykrya/gigih-waste-bank


text:
changed confluentinc/cp-kafka version to 3.5.6

Hi, I've done updates to the Docker images and Python code. I used 5.3.5 image versions.

authors: damklis tinkoosingh

repo: damklis/DataEngineeringProject


text:
Update in dutch translations

As already mentioned:

Create a new branch for every PR.
A PR should contain only commits relevant for this PR.

I will do for further updates. sorry i am an noobing on Github 🤦♂.
Is it something i can solve on this PR ?

I think it 's easier to close this one.
Maybe this helps.

authors: SukramJ Voxxie


text:
Small test improvements

Codecov Report

Merging #1145 (c8875dd) into devel (f409ba2) will increase coverage by 0.25%.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##            devel    #1145      +/-   ##
==========================================
+ Coverage   90.99%   91.24%   +0.25%
==========================================
  Files          48       48
  Lines        5585     5585
==========================================
+ Hits         5082     5096      +14
+ Misses        503      489      -14

see 2 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

authors: SukramJ codecov-commenter


text:
Sync fixes for smallest node selection from Terraform

Codecov Report
Base: 40.87% // Head: 40.87% // No change to project coverage :thumbsup:

Coverage data is based on head (cc6b2f0) compared to base (b2139ac).
Patch coverage: 0.00% of modified lines in pull request are covered.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #301   +/-   ##
=======================================
  Coverage   40.87%   40.87%
=======================================
  Files          46       46
  Lines        2662     2662
=======================================
  Hits         1088     1088
  Misses       1485     1485
  Partials       89       89

Impacted Files
Coverage Δ

service/clusters/node_type.go
0.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

authors: alexott codecov-commenter

repo: databricks/databricks-sdk-go


text:
bump spark version

Codecov Report

Merging #150 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #150   +/-   ##
=======================================
  Coverage   85.37%   85.37%
=======================================
  Files          34       34
  Lines        1922     1922
  Branches       41       41
=======================================
  Hits         1641     1641
  Misses        281      281

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f42fb76...4f36f26. Read the comment docs.

LGTM

authors: codecov-io mengxr yogeshg

repo: databricks/spark-deep-learning


text:
#1042: Onboarding documentation

This issue has been mirrored in Jira: https://reddata.atlassian.net/browse/GROK-14829

This issue has been mirrored in Jira: https://reddata.atlassian.net/browse/GROK-16086

authors: dnillovna skalkin

repo: datagrok-ai/public


text:
Logout issue: the user is not redirected from where the logout was initiated

It is not an issue.

repo: dataquest-dev/dspace-angular


text:
Update index.yaml

@eyarz This change has introduced an indentation syntax error which broke crd.directory

authors: eyarz shimont

repo: datreeio/CRDs-catalog


text:
The type or namespace name 'MediaPlayerElement' could not be found (are you missing a using directive or an assembly reference?)

Should i use any package to solve this problem

Ping!

authors: azizsayfullayev robertsynoradzki

repo: davidbritch/dotnet-maui-videoplayer


text:
Refactoring non-internationalized strings. Refs: #18312

Yeah, that's better now.

Hi there, I've reviewed the changes in this pull request, and it seems that the issues highlighted by Codacy are actually pre-existing ones. I'm a bit concerned about making modifications and potentially introducing new bugs.

authors: LonwoLonwo LucianoVirmes

repo: dbeaver/dbeaver


text: Date picker: Design focused states for visual calendar dates

repo: defencedigital/mod-uk-design-system


text:
Failing test for #44

test added in #47

authors: bitner gadomski


text:
Tests

Started writing tests. Altered some lines in the db storage.

repo: devharnold/earwall


text:
docs: add git documentation

requested @Panquesito7 for better docs info. pushed.

requested @Panquesito7 for better docs info. to be pushed.

@ibrahimraimi: Are you working on it?

@aminoxix: Yeah, have made the corrections.
And am so sorry it took me this long to correct this. My sincere apologies. 🙏

@Panquesito7 keep me updated on this!

@ibrahimraimi: Do you mind updating 10, 11, and 12 points? I think that's missing..

@ibrahimraimi I made some changes that's mentioned by @Panquesito7, so you have to pull the latest change in your branch, & try to accomplish it asap!

authors: aminoxix ibrahimraimi

repo: devstrons/git-and-github-playground


text:
Add input select component

:tada: This PR is included in version 0.4.0 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)
v0.4.0

Your semantic-release bot :package::rocket:


text:
fix Dockerfile

#2 の変更に依存しているためブロッキングしています。

#2 merged

authors: Mogyuchi cm-ayf

repo: discordjs-japan/om


text:
PowerOfTwo.py

@dixitt5 kindly merge it :))


text:
Update _initialize_path_ops_io.dart

Sorry, I created this accidentally! I was working on a fork.


text:
Implement pruning in connection pool

Relates to https://github.com/dotnet/SqlClient/issues/343

repo: dotnet/SqlClient


text:
Fix the feature flag script to correctly use vsRegEdit

The good news: this makes it so locally this works.
The bad news: CI still isn't.
That said, I'll check in as general goodness

repo: dotnet/razor


text:
Stg

d


text:
Fix get gauges query

The tests seem to be failing. although I don't see any failures there's a comment about x/incentives/client/cli/cli_test.go:65:5: unknown field 'Pagination' in struct literal of type "github.com/duality-labs/duality/x/incentives/types".GetGaugesRequest
So I think we could delete all references to Pagination in x/incentives/client/cli/cli_test.go

☝ got tests passing

Thanks @dib542

repo: duality-labs/duality


text:
Add median to BaseComputationModel

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 100.00%. Comparing base (1aaa5ab) to head (78ee934).

Additional details and impacted files
@@            Coverage Diff            @@
##              main       #34   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           29        29
  Lines          521       531   +10
  Branches        46        47    +1
=========================================
+ Hits           521       531   +10

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

authors: codecov-commenter durandtibo

repo: durandtibo/batcharray


text:
Update package tests

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (f797c4a) 100.00% compared to head (1baea57) 100.00%.

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #453   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           58        58
  Lines         1579      1579
  Branches       193       193
=========================================
  Hits          1579      1579

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

repo: durandtibo/coola


text:
Add docs

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 100.00%. Comparing base (bb0739b) to head (a415e79).

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #375   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           92        92
  Lines         2370      2370
  Branches       213       213
=========================================
  Hits          2370      2370

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

repo: durandtibo/flamme


text:
Bug fix

Closing the PR.

repo: dwp/dataworks-aws-kickstart-adg

license: ISC


text:
feat: Ordered arrays in object model

Current dependencies on/for this PR:

main

PR #2247   👈

This comment was auto-generated by Graphite.

authors: dmaretskyi mykola-vrmchk

repo: dxos/dxos


text:
Release 3.5.17

https://github.com/dzikoysk/reposilite/releases/tag/3.5.17

repo: dzikoysk/reposilite


text:
Feature/fix dependabots

Codecov Report
Attention: Patch coverage is 25.00000% with 6 lines in your changes are missing coverage. Please review.

Project coverage is 88.38%. Comparing base (41011ee) to head (9810972).

:exclamation: Current head 9810972 differs from pull request most recent head a14d993. Consider uploading reports for the commit a14d993 to get more accurate results

Files
Patch %
Lines

tests/test_point_nearest.py
25.00%
6 Missing :warning:

Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #104      +/-   ##
===========================================
+ Coverage    87.21%   88.38%   +1.16%
===========================================
  Files           96       83      -13
  Lines         7175     7139      -36
===========================================
+ Hits          6258     6310      +52
+ Misses         917      829      -88

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

authors: codecov-commenter mathleur

repo: ecmwf/polytope


text:
Inform pre-commit that the mypy check needs scipy installed

Current dependencies on/for this PR:

main

PR #24

PR #25   👈

PR #26

This comment was auto-generated by Graphite.

Merge activity

Oct 28, 9:00 PM: @eguiraud started a stack merge that includes this pull request via Graphite.

repo: eguiraud/correctionlib-gradients


text:
Fix tests

Now that wait_for_active_shards is gone, I need to reconsider this.

Closing in favor of more recent progress where I've made fixes one by one.

repo: elastic/elasticsearch-serverless-python


text:
Made add_label option default true

I think some additional work is needed to make the columns line up nicely when the row label is added. Could you post a screenshot of what your case looks like using this branch?

I think some additional work is needed to make the columns line up nicely when the row label is added. Could you post a screenshot of what your case looks like using this branch?

Correct, it doesn't work yet.
There is a picture here. I'll continue working on this now, I'm happy to rebase this if https://github.com/epics-containers/pvi/pull/42 is merged first.

OK sure I understand.
I think actually Giles' work to update to use pydantic will be merged first because that will cause lots of conflicts that need resolving.

repo: epics-containers/pvi


text:
ci: using checkout latest - v2

closing due to this bug: https://github.com/actions/checkout/issues/335

repo: epsagon/otel-js


text:
New release v0.0.2

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.2 out of 3 committers have signed the CLA.:white_check_mark: SIthuralde:white_check_mark: guidomodarelli:x: ithurraldeYou have signed the CLA already but the status is still pending? Let us recheck it.

authors: CLAassistant guidomodarelli

repo: equodev/sdk


text:
feat: upgrade core-utils

:tada: This PR is included in version 3.10.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

repo: esbuild-kit/tsx


text:
Routing for allinternhip inside facultysupervisor achieved

Sorun halledilmiş gözüküyor

repo: esogu-ceng/internship-management-system


text:
Bael 6242 move code

retest this please

retest this please

repo: eugenp/tutorials


text:
Test

/web-test

/test-web

/test

/test-web

/test-web

/web-test

/test-web

/test-web

/test-web

/test-web

/test-web

/test-web


text:
add centos to packit builds

stuff doesn't install, so :woman_shrugging:

repo: evgeni/bley


text:
navbar updates and page navigation.

great job bro


text:
Update pom property fabric8-ui.version to vb6144a3

[merge]


text:
wip

Merged into https://github.com/facebook/react-native-website/pull/4279
@yungsters @javache I'll incorporate your feedback there!

repo: facebook/react-native-website


text:
update nugets

@fantakim Could you please approve my PR and release new nuget version

repo: fantakim/Sendbird


text:
🌐 Add Russian translation for /docs/ru/docs/tutorial/sql-databases.md

@Xewus, @AlertRED, @gitgernit, @anklav24
Сделайте пожалуйста ревью по переводу :blush:

@gitgernit, @AlertRED
Спасибо! :blush: :heart_hands:

Thanks for your contribution! @alv2017 :sparkles:
And thanks for the reviews @AlertRED @gitgernit :mag:

@alejsdev Thank you for your help! :smiley: :+1:

repo: fastapi/fastapi


text:
Expose rename local variables on context menu

Nice!

authors: girba refactoringdr

repo: feenkcom/gtoolkit


text:
支持WebGL吗？

yes


text:
wip: introduce oauth clients into Ruby generator

Implemented in https://github.com/fern-api/fern/pull/3842

repo: fern-api/fern


text:
Export missing globals for compat

Buffer doesn't export these in node? What's the intent?

https://nodejs.org/docs/latest/api/buffer.html#class-blob
https://nodejs.org/docs/latest/api/buffer.html#class-file
https://nodejs.org/docs/latest/api/buffer.html#nodebuffer-module-apis

$ node
Welcome to Node.js v21.6.1.
Type ".help" for more information.
> require('buffer').Blob
[class Blob]
> require('buffer').File
[class File extends Blob]
> require('buffer').atob
[Function: atob]
> require('buffer').btoa
[Function: btoa]

Interesting, I thought this would be equivalent
node
Welcome to Node.js v21.6.1.
Type ".help" for more information.
> Buffer.atob
undefined
> require('buffer').atob
[Function: atob]

Thanks @chjj

Ah, the global scope only has Buffer, nevermind

This is silly, but I'm now actually having second thoughts on this one.
I know this is compatible with browserify as browserify exposes global to the module, but I'm curious about other bundlers: parcel/webpack/rollup/esbuild/etc (I know the latter two steer their users towards ES modules, but I think they have some kind of CJS compatibility plugins too?).
Maybe we should switch this to a typeof x !== 'undefined' pattern to avoid potentially breaking non-browserify bundlers?
Or maybe I'm just being paranoid and they all support global.

I'm happy with the cautious approach, but ideally, can we test this package, in our CI, using some other bundlers?

authors: chjj dcousens

repo: feross/buffer


text:
fixes for godot 4.2.1

I actually created a fork to adapt to 4.2.x new plugin structure

Merged! Thanks!

authors: finepointcgi ivanfemia jturbide

repo: finepointcgi/PGSGP


text:
Fix release workflow

:tada: This PR is included in version 1.2.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

repo: fingerprintjs/fingerprintjs-pro-angular


text:
Test migrate release flow to reusable workflow attempt 3

:tada: This PR is included in version 1.1.1-test.1 :tada:
The release is available on:

npm package (@test dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

repo: fingerprintjs/fingerprintjs-pro-spa


text:
fix: Versions

This PR is included in version 1.0.1 :tada:


text:
scrub html

I merged this (thanks!) but I'm unsure if I want to just bleach everything -- I wonder if we should have bleached and non-bleached node. Leaving html around seems more trusting in general, and more useful in some cases?

I was on the fence about this. I decided to do the work and if we wanna
keep it we can keep it, and if we want to remove it we can remove it.
On Fri, Jan 14, 2022 at 2:30 PM flancian @.***> wrote:

I merged this (thanks!) but I'm unsure if I want to just bleach everything
-- I wonder if we should have bleached and non-bleached node. Leaving html
around seems more trusting in general, and more useful in some cases?
—
Reply to this email directly, view it on GitHub
https://github.com/flancian/agora-server/pull/33#issuecomment-1013516887,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASY6ZZDKGS3U6RSNXESYMG3UWCPXRANCNFSM5L554DHQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

Yeah, that makes sense! I think if we allow  and images (so people can hot link images elsewhere?) and a few more we can bleach the rest by default? I'll see how that would look like.

authors: flancian fuck-capitalism

repo: flancian/agora-server


text:
Support not only headless service.

https://github.com/fleetboard-io/fleetboard/pull/106 in this PR, We add virtual cluster IP for multi-cluster service.
But there is some cases ard hard coded.

repo: fleetboard-io/fleetboard


text:
On home, get stock of restaurant's product in order to display/disable if out of stock

@Anatole-Godard add isOutofStock property in getters of product

repo: floriaaan/goodfood


text:
Review: Block Details

Working with soljuno to add a nums_messages column

Will get rid of the detailed tx list component (or at least hide it)


text:
Hotfix for reinstantiating prediction_history if a miner registers

Could you also update the version in predictionnet/init.py to 2.0.1?

authors: hscott-fd rahulfoundry

repo: foundryservices/snpOracle


text:
New version

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

repo: francoisbonneau/TestCI


text:
test branch 2

@friederikelbauer  sieht gut aus

repo: friederikelbauer/correlaidx-kn-git


text:
Cache Implementation for Parsed Documents

Closing this PR, because we have to implement it differently.

repo: ftd-lang/fpm


text:
Support file delete in vscode

Implemented

repo: galacean/vscode-extension


text:
[extractor:nhgroup] fixed uncommon url parsing

Thanks for letting me know. Will fix with #131

authors: AnotherXDay gan-of-culture

repo: gan-of-culture/get-sauce


text:
Generate image sequence from the saved mask data

##I've made a python script that converts the npy files saved in a folder to png with full black and full whites. It has a basic gui.
import tkinter as tk
from tkinter.filedialog import askdirectory
from PIL import Image
import os
import numpy as np
def set_everything_not_black_to_full_white(image):
"""Sets all pixels in an image that are not black to full white.
Args:
    image (Image): The image to modify.

Returns:
    The modified image.
"""
image = np.array(image)
image[image != 0] = 255
return Image.fromarray(image)

def convert_npy_to_png(npy_file):
"""Converts a numpy image file to a grayscale png file.
Args:
    npy_file (str): The path to the numpy image file.

Returns:
    None.
"""
image = Image.fromarray(np.array(np.load(npy_file)).astype(np.uint8)).convert("L")
image = set_everything_not_black_to_full_white(image)
image.save(npy_file.replace(".npy", ".png"))

def main():
"""The main function."""
# Create the GUI window.
root = tk.Tk()
# Create a label for the folder selection.
folder_label = tk.Label(root, text="Select a folder containing npy image files:")
folder_label.pack()

# Create a text entry box for the folder selection.
folder_entry = tk.Entry(root)
folder_entry.pack()

# Create a button to select the folder.
select_folder_button = tk.Button(root, text="Select Folder", command=lambda: select_folder(folder_entry))
select_folder_button.pack()

# Create a button to convert the npy files to png files.
convert_npy_files_button = tk.Button(root, text="Convert NPY Files to PNG Files", command=lambda: convert_npy_files(folder_entry.get()))
convert_npy_files_button.pack()

# Start the GUI event loop.
root.mainloop()

def select_folder(folder_entry):
"""Selects a folder and updates the folder entry.
Args:
    folder_entry (tk.Entry): The text entry box for the folder selection.

Returns:
    None.
"""
# Get the selected folder.
folder = askdirectory()

# Update the folder entry.
folder_entry.delete(0, "end")
folder_entry.insert(0, folder)

def convert_npy_files(folder):
"""Converts all npy files in the specified folder to grayscale png files.
Args:
    folder (str): The path to the folder containing the npy files.

Returns:
    None.
"""
# Get all the npy files in the folder.
npy_files = [f for f in os.listdir(folder) if f.endswith(".npy")]

# Convert each npy file to a png file.
for npy_file in npy_files:
    convert_npy_to_png(os.path.join(folder, npy_file))

if name == "main":
main()

authors: jcnwholland zk-wz

repo: gaomingqi/Track-Anything


text:
Develop to main (ver.0.20 PR)

PR ってレビュー必須だったっけ．．．？
まあいいや、承認してマージします

まって、自分で出した PR って確か承認できなかったような気がする
bot にレビューする方法もあるみたいだけど．．．
めんどいし早急にマージしたいので今回はレビューの過程すっ飛ばします

repo: gckohaku/WebClock


text:
Update Jenkinsfile to use external library

Thank you for submitting this PR but due to the age and the lack of activity we are going to close it.

Thanks @deanwilson, appreciate the timely response

authors: deanwilson surminus

repo: gds-operations/vcloud-launcher


text:
Rewrite @sentry/replay imports

Completed via https://github.com/getsentry/sentry-migr8/commit/520ffee93a35c287307687493ac83baab6892c16


text:
test: behaviors-plan_on_push (2024-02-29 22:39:45.436572+00:00)

automatic test cleanup


text:
Test inference with randomized condensation points

Unlikely that this would work, because #245 showed that the condensation points are not random at all


text:
First pass - v9 update + some other RE doc things

what's the go on this

Honestly I'd just globally suppress that rule, because that rule is stupid. Unfortunately, remark doesn't seem to have any docs on how to do this, yay JS ecosystem.

Ok #20 and #21 should fix that, feel free to update and merge at your convenience

Checking on this

authors: KazWolfe philpax

repo: goatcorp/dalamud-docs


text:
Adding credentials and locations

Codecov Report
Base: 55.29% // Head: 55.64% // Increases project coverage by +0.35% :tada:

Coverage data is based on head (d788ddc) compared to base (03870e7).
Patch coverage: 49.20% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #484      +/-   ##
==========================================
+ Coverage   55.29%   55.64%   +0.35%
==========================================
  Files          26       28       +2
  Lines        1351     1452     +101
==========================================
+ Hits          747      808      +61
- Misses        604      644      +40

Impacted Files
Coverage Δ

aws-lambda/src/databricks_cdk/resources/handler.py
25.49% <10.00%> (-0.39%)
:arrow_down:

...atabricks_cdk/resources/unity_catalog/metastore.py
38.33% <14.28%> (+2.74%)
:arrow_up:

...dk/resources/unity_catalog/metastore_assignment.py
57.69% <33.33%> (-5.95%)
:arrow_down:

...ks_cdk/resources/unity_catalog/external_storage.py
58.33% <58.33%> (ø)

...cdk/resources/unity_catalog/storage_credentials.py
70.00% <70.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

authors: codecov-commenter ffinfo

repo: godatadriven/databricks-cdk


text:
Add GRPC API for worker-service api-gateway side.

It should be a day max.

authors: afsalthaj vigoo

repo: golemcloud/golem


text:
cli tests on release

Note that CI is supposed to reuse the cached debug build in the CLI test step:
https://github.com/golemcloud/golem/blob/main/.github/workflows/ci.yaml#L403
So this change alone would break the current CI caching

authors: senia-psm vigoo


text:
Linux: Avoid identifer collision with glibc

@100espressos thanks for the contribution. You need to sign the CLA before we can accept it. See "Details" above.

While I understand some of the motivations, some agreements and signatories will tend to discourage the tradition of FOSS drive-by patching. On a variety of established grounds I don't anticipate creating a Google account or entering into a contract with Google. ..but FOSS forever ❤

repo: google/filament


text:
Fix OwlBot configurations and regenerate

Urgh - not sure why this has multiple commits. Will fix.

Okay, sorted - PTAL

repo: googleapis/google-cloud-dotnet


text:
refactor: drop dependency on nodejs-repo-tools

Samples and systems are also failing on the release pr. I think quota is low.

Samples test failure seems real?
1) instances
       should list zones:
     Error: Command failed: node instances.js "nodejs-bigtable-samples-369c21"
instances.js <command>

authors: JustinBeckwith crwilcox

repo: googleapis/nodejs-bigtable


text:
initDepPkgs fix: allow pubName not found

Codecov Report

Merging #130 (8c6a367) into main (3d3e43d) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #130   +/-   ##
=======================================
  Coverage   87.41%   87.41%
=======================================
  Files          10       10
  Lines        3298     3298
=======================================
  Hits         2883     2883
  Misses        330      330
  Partials       85       85

Impacted Files
Coverage Δ

cl/multifiles.go
81.76% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3d3e43d...8c6a367. Read the comment docs.

authors: codecov-commenter xushiwei


text:
Authentication support via OAuth2 for Gmail/Microsoft mail in addition to basic authentication

Any plans to do this in the near future?

It looks like we will no longer be able to send email via Gmail with this plugin starting on September 30, 2024, since sending email with this plugin requires having "Less Secure Apps" enabled.
https://workspaceupdates.googleblog.com/2023/09/winding-down-google-sync-and-less-secure-apps-support.html

authors: svenrenner tylervz vsachinv

repo: grails/grails-mail


text:
Résoudre les problèmes de style et de changements de pages

Changement de la structure de l'app pour qu'elle devienne une SPA

repo: gus-fmt/e-caiz


text:
32 als klant wil ik een review bericht kunnen verwijderen zodat ik mijn review terug kan trekken als het niet meer van toepassing is

Prachtig gedaan, ik wist alleen niet dat ik dotnet ef database update moest doen in de ReviewManagementAPI folder. Misschien volgende keer dit in de review notes zetten.

authors: DannyLoen luukjp


text:
chore: Correct link to Contributing Guidelines file

GSSoC22 ;)

@DhairyaBahl hey can you update the label from GSSoC'22 to GSSoC22 because the leaderboard is not able to track this merged PR of mine :)


text:
New changes

Pull request in error from a workshop run.

authors: israeldahan omkensey

repo: hashicorp/hashicat-aws


text:
Remove duplicated check on withdraw

Test fails because we need to merge #346 first

repo: hats-finance/hats-contracts


text:
Rustify C-Style docs

bors r+

authors: mkroening stlankes

repo: hermitcore/libhermit-rs


text:
如果一张图片同时有中文/英文/日文，那么该如何选择模型呢？

目前没有模型能同时支持中+日，只能中英或日英。
如果文字的位置相对固定（如双语字幕），可以先切割出中文 / 日文区域的图片，单独送入OCR。
如果文字位置随机，那么可以按以下步骤：

对同一张图片，分别用中文 / 日文库跑一遍，得到两份结果。
遍历两份结果，去除其中置信度（["score"]）较差的条目，去除其中重叠的条目（比如含同一句英文）。
合并为一份结果。

目前没有模型能同时支持中+日，只能中英或日英。
如果文字的位置相对固定（如双语字幕），可以先切割出中文 / 日文区域的图片，单独送入OCR。
如果文字位置随机，那么可以按以下步骤：

对同一张图片，分别用中文 / 日文库跑一遍，得到两份结果。
遍历两份结果，去除其中置信度（["score"]）较差的条目。
遍历两份结果，去除其中重叠的条目（比如含同一句英文，或者["box"]的位置相同）。
合并为一份结果。

我的需求是需要知道这个图片上的文字类型，可能是中文，日文，英文、德文等。这种情况下也是分别用不同语言库跑一遍取置信度高的结果就可以了吧？

是的。据我所知，并没有一种好的办法或现成的开源项目，能快速检测图片中的语种，而不需要经过完整的OCR流程。所以，判断语种最靠谱的办法只有用多个语言库各跑一遍OCR，取其中置信度最高的语言。

repo: hiroi-sora/PaddleOCR-json


text:
Send large message metadata to transit-movements

You need to ensure you call this in the incomingLargeMessage method in the controller too, and set up all the error handling and such there.

repo: hmrc/transit-movements-router


text:
algo: Added support for Deflex limit order create and cancel

Related to #239

repo: hodgerpodger/staketaxcsv


text:
create a new api to associate a device to a home+room with a better logic. A device should be assigned to a single room and cannot be part of different rooms at the same time

probably the existing API is not so bad, however it's important to remove previous association before applying a new one

repo: home-anthill/api-server


text:
Update dict_fa.po

Thanks a lot!

authors: Fadavvi horsicq

repo: horsicq/XTranslation


text:
Implement gofmt

Support was added in #47

repo: hougesen/mdsf


text:
[refactor] rename command entry as cli.py

lgtm

repo: hpcaitech/ColossalAI-Platform-CLI


text:
reordering output links

THX for the PR @ryanj. LGTM

authors: hpgrahsl ryanj


text:
Issues 1, 11, 15 and 16 by HYTK

Updates AllCitiesInAContinent, App and Country files

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@aa4fe45). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #37   +/-   ##
=========================================
  Coverage          ?   45.81%
  Complexity        ?       48
=========================================
  Files             ?       10
  Lines             ?      251
  Branches          ?       14
=========================================
  Hits              ?      115
  Misses            ?      136
  Partials          ?        0

Flag
Coverage Δ

IntegrationTests
45.81% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

authors: codecov-commenter hsuyatikhin-alissa


text:
Merge 0.22 -> 0.23

I'm going to take a pass through and try and update the build.

Many of the conflicts were related to the sbt-http4s-org-0.10, and I did my best, but I'm sure I missed a few things.  That and the blaze changes were the big two tumults.

Yeah, the divide between 0.22 and 0.23 wrt the build is too big. But, it will be a lot nicer now b/c I was able to upstream some stuff into sbt-typelevel.

And now, we fight mima.

Oh, crap.  I thought quicklint ran that and we were clear.

Ha ha, no way. There's never-before-reported Scala 3 and Scala.js issues to go through.

Ok, so these are legit bin-compat breaks on Scala 3 that happened in https://github.com/http4s/http4s/pull/5758 when we de-case-classed FileService#Config. The problem is that the binary encoding of case classes changed between Scala 2/3 such that it is impossible to imitate it without splitting our sources across 2/3. E.g. the return type of unapply on Scala 2 is Option[Config], on Scala 3 it is just Config thanks to Option-less Pattern Matching™.
[error]  * static method unapply(org.http4s.server.staticcontent.FileService#Config)org.http4s.server.staticcontent.FileService#Config in class org.http4s.server.staticcontent.FileService#Config has a different result type in current version, where it is scala.Option rather than org.http4s.server.staticcontent.FileService#Config
[error]    filter with: ProblemFilters.exclude[IncompatibleResultTypeProblem]("org.http4s.server.staticcontent.FileService#Config.unapply")
[error]  * the type hierarchy of object org.http4s.server.staticcontent.FileService#Config is different in current version. Missing types {scala.deriving.Mirror$Product,scala.deriving.Mirror}
[error]    filter with: ProblemFilters.exclude[MissingTypesProblem]("org.http4s.server.staticcontent.FileService$Config$")
[error]  * method unapply(org.http4s.server.staticcontent.FileService#Config)org.http4s.server.staticcontent.FileService#Config in object org.http4s.server.staticcontent.FileService#Config has a different result type in current version, where it is scala.Option rather than org.http4s.server.staticcontent.FileService#Config
[error]    filter with: ProblemFilters.exclude[IncompatibleResultTypeProblem]("org.http4s.server.staticcontent.FileService#Config.unapply")

I'd rather revert https://github.com/http4s/http4s/pull/5758 than split our sources. But I'll also make an argument that we look the other way—this breakage would only affect Scala 3 users who are doing stuff with FileService#Config other than just constructing and directly passing to FileService which I assume is 99.9% of uses. Who in the hell is pattern matching it, or doing Mirror-based derivation?

What would it cost to "do it right"?  A platform companion object for the differing unapplies, and a platform trait to provide the Mirror?  In a shim trait in a Scala 2 and Scala 3 directory?
I am loath to make exceptions, but this is an exotic case on an as yet little used Scala version, so I'd look the other way as long as we flag it in the notes.

What would it cost to "do it right"? A platform companion object for the differing unapplies, and a platform trait to provide the Mirror? In a shim trait in a Scala 2 and Scala 3 directory?

I think you're right. That doesn't sound too bad. I was feeling particularly pessimistic since it was a case class nested inside of an object, but maybe that doesn't matter. I will muster up the will to try and fix this.

Cool cool. We've moved on from mima to explicit dependencies which I guess don't work on Scala.js. There's an unmerged fix upstream.

https://github.com/cb372/sbt-explicit-dependencies/pull/100

Looks like unused compile dependencies tests and Scala.JS are a bad fit.

I tried to set the unused compile dependency checks in sbt-http4s-org to run only on the JVM, but .jvmSettings requires a project, and I couldn't quickly untangle the magic that the crossproject plugin is doing.  I'll take a look at this later unless someone knows the prior art for a platform-specific build setting in a plugin.

I think I figured it out.

I'll take a look at this later unless someone knows the prior art for a platform-specific build setting in a plugin.

AFAIK there's no easy way to do this. Unlike Scala version which is a setting on every project, cross-projects are really just sets of (independent) projects that happen to share the same sources. I would like to find a way to make this easier and put it in sbt-typelevel but for now we'll have to do something manual and ugly.

authors: armanbilge rossabaker


text:
Add FastAgency

Thanks for updating!


text:
feat: update contract schema and encryption cert for REV 15 release

Tested by provisioning REV 15 on staging.


text:
fix: small typo at create_networking_config

Hi @fchpr thanks again for you PR. We incorporated your changes into the variables.tf file as indicated by @jdiebold, in commit https://github.com/idealo/terraform-aws-mwaa/commit/9337baf45fbd269dafb5d5636fef1e28212256a5 - closing here.

authors: fchpr mgerlach

repo: idealo/terraform-aws-mwaa


text:
Centralize *gen_problem functions. Parameterize graph type.

karate and singlegraph have parts in common.

Idea: instead of centralize all, step one, end up with two, one gen_problem for multigraph and another one for singlegraph.


text:
the site is down.. are you still maintaining this repo?

No, I have nothing to do with this project, I just took it as a sample for my project.

license: Unlicense