get tasks using multicall

Context:
The task manager comes with a contract that casts a multi-call, those are used to batch together multiple function calls.
When we are working with the front-end, doing too many function calls to the blockchain, even though it's read-only, will depend on the proficiency of the front-end code and the provider speed, as well as the user's internet speed.
Problem:
When searching for 20 NFTs data to be displayed on a single page, the average loading time will be around ~2 seconds for each on a good day. Since we'll be using the user-connected provider, those calls might even get blocked and correct typings should be made to make it handle errors and malfunctions.
Proposed Solution: (assuming we want to fetch the task ids 1 to 20 to display in main screen)
We batch a call using
abi.encodeWithSelector("getTask(uint256)", [1])

This is a solidity function, in ethers we can find it by loading an instance of the contract and calling:
(this example is from ENS)
contract.interface.encodeFunctionData('setText', [
        namehash('newconfigname.eth'),
        'url',
        'ethereum.com',
      ]),

So to prepare the data using typescript for the getTask function, it should be something like:
Note that this is only the instance already loaded.
bytes payload = contract.interface.encodeFunctionData('geTask', [1,]),

This should be used in a for loop to fetch the payload for all 20 transactions which will return tasks properly.
All payloads should be inside an array of the actual transaction to be sent.
for(var i = 0; i < 20; i++){
      bytes[] payload = contract.interface.encodeFunctionData('geTask', [i]);
}

// We then call the multicall function
const result = await contract.multicall(payload);

Thats it! Now the result variable will carry an array with all the 20's results. If it fails, we should just keep forcing until the public providers indexes and shares the result with us correctly.
Obs: When fetching data for the profile, we should first call:
const result = await contract.getUserTasks(wallet.address)

To retrieve all the tasks that user has.
Then we repeat the same solution steps to build the task page profile, totaling only 2 transactions.

#06015478f3b752cb57e80f5ea7dfdeb8942df58b
Implemented this feature on the contracts side.
Must apply to the front-end at the TASK PAGE and the TASK PROFILE

Implemented this feature apply to frontend ( CardMultiTasks, CardTasks )

This pull request is a subset that should be reviewed prior to this issue
#16


Training hangs at one place.There is no error no log.

I am trying to train to train 192000 image data which has been resized to 32x32 while creating LMDB using create_imageset.sh.
I kept the LMDB files to hdfs and made its location's entry into the network.
The network prototxt file i am using is same as what has been given in CIFAR10 example.
Log generated is
16/07/05 13:36:13 INFO scheduler.TaskSchedulerImpl: Removed TaskSet 4.0, whose tasks have all completed, from pool
16/07/05 13:36:13 INFO scheduler.DAGScheduler: Job 4 finished: reduce at CaffeOnSpark.scala:210, took 23.290814 s
16/07/05 13:36:13 INFO spark.SparkContext: Starting job: reduce at CaffeOnSpark.scala:210
16/07/05 13:36:13 INFO scheduler.DAGScheduler: Got job 5 (reduce at CaffeOnSpark.scala:210) with 2 output partitions
16/07/05 13:36:13 INFO scheduler.DAGScheduler: Final stage: ResultStage 5 (reduce at CaffeOnSpark.scala:210)
16/07/05 13:36:13 INFO scheduler.DAGScheduler: Parents of final stage: List()
16/07/05 13:36:13 INFO scheduler.DAGScheduler: Missing parents: List()
16/07/05 13:36:13 INFO scheduler.DAGScheduler: Submitting ResultStage 5 (MapPartitionsRDD[8] at mapPartitions at CaffeOnSpark.scala:190), which has no missing parents
16/07/05 13:36:13 INFO storage.MemoryStore: Block broadcast_6 stored as values in memory (estimated size 3.4 KB, free 20.8 KB)
16/07/05 13:36:13 INFO storage.MemoryStore: Block broadcast_6_piece0 stored as bytes in memory (estimated size 2.2 KB, free 22.9 KB)
16/07/05 13:36:13 INFO storage.BlockManagerInfo: Added broadcast_6_piece0 in memory on <IP_ADDRESS>:45502 (size: 2.2 KB, free: 511.5 MB)
16/07/05 13:36:13 INFO spark.SparkContext: Created broadcast 6 from broadcast at DAGScheduler.scala:1006
16/07/05 13:36:13 INFO scheduler.DAGScheduler: Submitting 2 missing tasks from ResultStage 5 (MapPartitionsRDD[8] at mapPartitions at CaffeOnSpark.scala:190)
16/07/05 13:36:13 INFO scheduler.TaskSchedulerImpl: Adding task set 5.0 with 2 tasks
16/07/05 13:36:13 INFO scheduler.TaskSetManager: Starting task 0.0 in stage 5.0 (TID 10, slave2-172-31-47-102, partition 0,PROCESS_LOCAL, 2244 bytes)
16/07/05 13:36:13 INFO scheduler.TaskSetManager: Starting task 1.0 in stage 5.0 (TID 11, master-172-31-47-103, partition 1,PROCESS_LOCAL, 2300 bytes)
16/07/05 13:36:13 INFO storage.BlockManagerInfo: Added broadcast_6_piece0 in memory on master-172-31-47-103:33837 (size: 2.2 KB, free: 511.5 MB)
16/07/05 13:36:13 INFO storage.BlockManagerInfo: Added broadcast_6_piece0 in memory on slave2-172-31-47-102:58709 (size: 2.2 KB, free: 511.5 MB)
16/07/05 13:42:10 INFO storage.BlockManagerInfo: Removed broadcast_5_piece0 on <IP_ADDRESS>:45502 in memory (size: 2.2 KB, free: 511.5 MB)
16/07/05 13:42:10 INFO storage.BlockManagerInfo: Removed broadcast_5_piece0 on slave2-172-31-47-102:58709 in memory (size: 2.2 KB, free: 511.5 MB)
16/07/05 13:42:10 INFO storage.BlockManagerInfo: Removed broadcast_5_piece0 on master-172-31-47-103:33837 in memory (size: 2.2 KB, free: 511.5 MB)
16/07/05 13:42:10 INFO spark.ContextCleaner: Cleaned accumulator 5
16/07/05 13:42:10 INFO storage.BlockManagerInfo: Removed broadcast_4_piece0 on <IP_ADDRESS>:45502 in memory (size: 2.2 KB, free: 511.5 MB)
16/07/05 13:42:10 INFO storage.BlockManagerInfo: Removed broadcast_4_piece0 on slave2-172-31-47-102:58709 in memory (size: 2.2 KB, free: 511.5 MB)
16/07/05 13:42:10 INFO storage.BlockManagerInfo: Removed broadcast_4_piece0 on master-172-31-47-103:33837 in memory (size: 2.2 KB, free: 511.5 MB)
16/07/05 13:42:10 INFO spark.ContextCleaner: Cleaned accumulator 4
16/07/05 13:42:10 INFO storage.BlockManagerInfo: Removed broadcast_3_piece0 on <IP_ADDRESS>:45502 in memory (size: 2.2 KB, free: 511.5 MB)
16/07/05 13:42:10 INFO storage.BlockManagerInfo: Removed broadcast_3_piece0 on slave2-172-31-47-102:58709 in memory (size: 2.2 KB, free: 511.5 MB)
16/07/05 13:42:10 INFO storage.BlockManagerInfo: Removed broadcast_3_piece0 on master-172-31-47-103:33837 in memory (size: 2.2 KB, free: 511.5 MB)
16/07/05 13:42:10 INFO spark.ContextCleaner: Cleaned accumulator 3
16/07/05 13:42:10 INFO storage.BlockManager: Removing RDD 6
16/07/05 13:42:10 INFO spark.ContextCleaner: Cleaned RDD 6
The solver and train_test prototxt file is atatched.
network.zip
Command used to run the script is is attached in cmd.txt
cmd.txt

More detailed log from the running app =>
16/07/05 13:35:50 INFO BlockManager: Found block rdd_1_0 locally
I0705 13:35:50.376612 18557 solver.cpp:237] Iteration 0, loss = 2.9456
I0705 13:35:50.376672 18557 solver.cpp:253]     Train net output #0: loss = 2.9456 (* 1 = 2.9456 loss)
I0705 13:35:50.390033 18557 sgd_solver.cpp:106] Iteration 0, lr = 0.001
I0705 13:35:52.638326 18557 solver.cpp:237] Iteration 100, loss = 26.1633
I0705 13:35:52.638391 18557 solver.cpp:253]     Train net output #0: loss = 26.1633 (* 1 = 26.1633 loss)
I0705 13:35:52.652004 18557 sgd_solver.cpp:106] Iteration 100, lr = 0.001
I0705 13:35:54.924104 18557 solver.cpp:237] Iteration 200, loss = 67.1725
I0705 13:35:54.924163 18557 solver.cpp:253]     Train net output #0: loss = 67.1725 (* 1 = 67.1725 loss)
I0705 13:35:54.941706 18557 sgd_solver.cpp:106] Iteration 200, lr = 0.001
I0705 13:35:57.788662 18557 solver.cpp:237] Iteration 300, loss = 34.1383
I0705 13:35:57.788727 18557 solver.cpp:253]     Train net output #0: loss = 34.1383 (* 1 = 34.1383 loss)
I0705 13:35:57.803102 18557 sgd_solver.cpp:106] Iteration 300, lr = 0.001
I0705 13:36:00.677893 18557 solver.cpp:237] Iteration 400, loss = 27.2034
I0705 13:36:00.677945 18557 solver.cpp:253]     Train net output #0: loss = 27.2034 (* 1 = 27.2034 loss)
I0705 13:36:00.694277 18557 sgd_solver.cpp:106] Iteration 400, lr = 0.001
I0705 13:36:03.324339 18557 solver.cpp:237] Iteration 500, loss = 37.5662
I0705 13:36:03.324394 18557 solver.cpp:253]     Train net output #0: loss = 37.5662 (* 1 = 37.5662 loss)
I0705 13:36:03.339056 18557 sgd_solver.cpp:106] Iteration 500, lr = 0.001
I0705 13:36:05.590054 18557 solver.cpp:237] Iteration 600, loss = 35.8908
I0705 13:36:05.590111 18557 solver.cpp:253]     Train net output #0: loss = 35.8908 (* 1 = 35.8908 loss)
I0705 13:36:05.604562 18557 sgd_solver.cpp:106] Iteration 600, lr = 0.001
I0705 13:36:07.884639 18557 solver.cpp:237] Iteration 700, loss = 34.151
I0705 13:36:07.884697 18557 solver.cpp:253]     Train net output #0: loss = 34.151 (* 1 = 34.151 loss)
I0705 13:36:07.898679 18557 sgd_solver.cpp:106] Iteration 700, lr = 0.001
I0705 13:36:10.181591 18557 solver.cpp:237] Iteration 800, loss = 32.3517
I0705 13:36:10.181645 18557 solver.cpp:253]     Train net output #0: loss = 32.3517 (* 1 = 32.3517 loss)
I0705 13:36:10.196151 18557 sgd_solver.cpp:106] Iteration 800, lr = 0.001
I0705 13:36:12.480675 18557 solver.cpp:237] Iteration 900, loss = 36.6911
I0705 13:36:12.480734 18557 solver.cpp:253]     Train net output #0: loss = 36.6911 (* 1 = 36.6911 loss)
I0705 13:36:12.495223 18557 sgd_solver.cpp:106] Iteration 900, lr = 0.001
16/07/05 13:36:13 INFO Executor: Finished task 0.0 in stage 4.0 (TID 9). 2015 bytes result sent to driver
16/07/05 13:36:13 INFO CoarseGrainedExecutorBackend: Got assigned task 10
16/07/05 13:36:13 INFO Executor: Running task 0.0 in stage 5.0 (TID 10)
16/07/05 13:36:13 INFO TorrentBroadcast: Started reading broadcast variable 6
16/07/05 13:36:13 INFO MemoryStore: Block broadcast_6_piece0 stored as bytes in memory (estimated size 2.2 KB, free 19.6 KB)
16/07/05 13:36:13 INFO TorrentBroadcast: Reading broadcast variable 6 took 11 ms
16/07/05 13:36:13 INFO MemoryStore: Block broadcast_6 stored as values in memory (estimated size 3.4 KB, free 23.0 KB)
16/07/05 13:36:13 INFO BlockManager: Found block rdd_1_0 locally
I0705 13:36:14.781328 18557 solver.cpp:237] Iteration 1000, loss = 73.3627
I0705 13:36:14.781388 18557 solver.cpp:253]     Train net output #0: loss = 73.3627 (* 1 = 73.3627 loss)
I0705 13:36:14.795292 18557 sgd_solver.cpp:106] Iteration 1000, lr = 0.001
I0705 13:36:17.078786 18557 solver.cpp:237] Iteration 1100, loss = 36.6632
I0705 13:36:17.078845 18557 solver.cpp:253]     Train net output #0: loss = 36.6632 (* 1 = 36.6632 loss)
I0705 13:36:17.092947 18557 sgd_solver.cpp:106] Iteration 1100, lr = 0.001
16/07/05 13:42:10 INFO BlockManager: Removing RDD 6

Check ThreadDump from spark UI while the job is stuck. It is likely one of the transformer threads was dead.

I found the problem.
The memory for the executor had to be increased.
When i increased it it started to run.
Thanks


Fixing CodeQL errors

Type of change

[ ] Refactor
[ ] New feature
[ ] Bug fix
[x] Optimization
[ ] Documentation Update

Description
Making sure all the CI tests are passing. Minor nit.
Checklist before requesting a review

[x] I have performed a self-review of my code.
[ ] If it is a core feature, I have added thorough tests.

Testing
Will be verified through CI.

Weird thing of the coverage change percentage, don't see how your change did that.


[RFC] Basic support for Memory64 proposal

Summary
Plan to implement basic support for the memory64 proposal, first focusing on the classic interpreter and AOT running modes.
Overview of Basic Support Plan
With basic support completed, users should experience the following:

Use cmake -DWAMR_BUILD_MEMORY64=1 to compile a memory64-enabled iwasm VM core. Initially, only memory64-enabled wasm/aot files will be supported. In other words, a memory64-enabled runtime VM core will only support memory64 wasm/aot files for basic support; running memory32 wasm/aot files is not possible (though you can still run memory32 wasm/aot files with the default runtime compile without adding the cmake flags). Further development will ensure compatibility of memory64-enabled runtime with both memory32 and memory64 wasm/aot files. Maybe make them compatible from the start

For the wamrc AOT compiler, no extra work is required during compile time. To compile a memory64 aot file, use wamrc --enable-memory64 -o test.aot test.wasm to generate a memory64 aot file.

PS: A warning/exception may be given if the memory64 feature is not actually used in a memory32 wasm file.

When you integrate a WAMR VMcore into your host application, you can use certain APIs that WAMR exports. These APIs help manage linear memory and enable the conversion and verification of addresses between the host's native environment and the app's linear memory. However, to accommodate memory64, these APIs will undergo modifications. The main changes will be in the types of arguments and return values. Specifically, the representation of a linear memory address will shift from uint32 to uint64. This change applies regardless of whether you enable memory64. In a memory32 scenario, this adjustment is seamless, as there is no narrow conversion involved. Instead, uint32 values are simply expanded to uint64. This modification affects the following APIs, here is a preview of their signature modifications:
/* See wasm_export.h for description */
WASM_RUNTIME_API_EXTERN uint64
wasm_runtime_module_malloc(WASMModuleInstanceCommon *module_inst, uint64 size, void **p_native_addr);

/* See wasm_export.h for description */
WASM_RUNTIME_API_EXTERN void
wasm_runtime_module_free(WASMModuleInstanceCommon *module_inst, uint64 ptr);

/* See wasm_export.h for description */
WASM_RUNTIME_API_EXTERN uint64
wasm_runtime_module_dup_data(WASMModuleInstanceCommon *module_inst, const char *src, uint64 size);

/* See wasm_export.h for description */
WASM_RUNTIME_API_EXTERN bool
wasm_runtime_validate_app_addr(WASMModuleInstanceCommon *module_inst, uint64 app_offset, uint64 size);

/* See wasm_export.h for description */
WASM_RUNTIME_API_EXTERN bool
wasm_runtime_validate_app_str_addr(WASMModuleInstanceCommon *module_inst, uint64 app_str_offset);

/* See wasm_export.h for description */
WASM_RUNTIME_API_EXTERN bool
wasm_runtime_validate_native_addr(WASMModuleInstanceCommon *module_inst, void *native_ptr, uint64 size);

/* See wasm_export.h for description */
WASM_RUNTIME_API_EXTERN void *
wasm_runtime_addr_app_to_native(WASMModuleInstanceCommon *module_inst, uint64 app_offset);

/* See wasm_export.h for description */
WASM_RUNTIME_API_EXTERN uint64
wasm_runtime_addr_native_to_app(WASMModuleInstanceCommon *module_inst, void *native_ptr);

/* See wasm_export.h for description */
WASM_RUNTIME_API_EXTERN bool
wasm_runtime_get_app_addr_range(WASMModuleInstanceCommon *module_inst, uint64 app_offset, uint64 *p_app_start_offset, uint64 *p_app_end_offset);

/* See wasm_export.h for description */
WASM_RUNTIME_API_EXTERN bool
wasm_runtime_get_native_addr_range(WASMModuleInstanceCommon *module_inst, uint8 *native_ptr, uint8 **p_native_start_addr, uint8 **p_native_end_addr);

Impact of memory64 proposal on WAMR's data structure
This section lists the changes in the memory64 proposal that could potentially influence WARM's internal data structure and code logic. Let's see what those influences could be

Memory initial/max page count: According to the memory64 proposal, when memory64 is used, the default page size remains unchanged(64KB), but the initial page count/max page count theoretically can maximally be 2^48 now, which is roughly 2.2 million terabytes. Given it's kind of surreal to use that much memory in real life, stick with the uint32 representation of page count.
To conclude, the data structure represents WASMMemory stay unchanged, the initial page count and max page count stay as u32.

PS: The maximum value can be 2^32 - 1 pages which is about 275 TB. The value exceeding the value is marked by a throw exception. It's not fully conform to spec but it's a practical design choice.

Data segment offset: for memory64, it should be should be i64 now

In WASMDataSeg, the offset's type will become i64
So as the offset type in AOTMemInitData

Memory instruction: The type of memarg’s offset in all memory instructions needs to be changed, as well as the parameters representing linear memory addresses taken by the memory instruction on the stack, a total of 116 opcodes.

In WASMModule and AOTModule the fields that represent linear memory address, use uint64 instead:
/* the index of auxiliary __data_end global,
  -1 means unexported */
uint32 aux_data_end_global_index;
/* auxiliary __data_end exported by wasm app */
/* TODO: type changes to uint64 */
uint32 aux_data_end;

/* the index of auxiliary __heap_base global,
  -1 means unexported */
uint32 aux_heap_base_global_index;
/* auxiliary __heap_base exported by wasm app */
/* TODO: type changes to uint64 */
uint32 aux_heap_base;

/* the index of auxiliary stack top global,
  -1 means unexported */
uint32 aux_stack_top_global_index;
/* auxiliary stack bottom resolved */
/* TODO: type changes to uint64 */
uint32 aux_stack_bottom;

Also in AOT file, those fields will be emitted as u64. So in a sense, AOT ABI will change.

In WASMMemoryInstance(AOTMemoryInstance)
/* Module type */
uint32 module_type;

/* Whether the memory is shared */
uint8 is_shared_memory;

/* TODO: changes to is_memory_64 flags */
uint8 __padding__;

/* Reference count of the memory instance:
     0: non-shared memory, > 0: shared memory */
bh_atomic_16_t ref_count;

/* Number bytes per page */
uint32 num_bytes_per_page;
/* Current page count */
uint32 cur_page_count;
/* Maximum page count */
uint32 max_page_count;
/* TODO: add new Paddings for alignment */
uint32 padding;
/* TODO: type changes to uint64 */
uint32 memory_data_size;

......other data member

memory_data_size type changes can result to AOT offset calculation logic changes(details are in create_memory_info)

In WASMExecEnv
/* TODO: boundary and bottom to uint64? */
/* Auxiliary stack boundary */
union {
    uint32 boundary;
    uintptr_t __padding__;
} aux_stack_boundary;
/* Auxiliary stack bottom */
union {
    uint32 bottom;
    uintptr_t __padding__;
} aux_stack_bottom;

Topics for Further Discussion
😄 Suggestions or input on the following topics (or others you can think of) are appreciated.
1. Should Memory64 Only Be Supported on 64-Bit Machines?
I believe it's not very useful to support the memory64 proposal on 32-bit machines, as more than 4GB of memory can't be utilized anyway. If linear memory is below 4GB, sticking with default memory32 seems sensible. Supporting memory64 on 32-bit machines would also add implementation complexity. Therefore, the initial plan is not to support the memory64 proposal on 32-bit machines.
2. Exported Runtime APIs for Host Use When Embedding WAMR VMCore
As previously mentioned, the initial plan is to add new APIs like wasm64_xxx for memory64 wasm/aot files, while keeping the old APIs unchanged for memory32 wasm/aot files.
// New APIs
WASM_RUNTIME_API_EXTERN uint64
wasm64_runtime_module_malloc(WASMModuleInstanceCommon *module_inst, uint64 size, void **p_native_addr);
// Old counterpart APIs
WASM_RUNTIME_API_EXTERN uint32
wasm_runtime_module_malloc(WASMModuleInstanceCommon *module_inst, uint32 size, void **p_native_addr);

Alternatively, we could modify existing APIs without adding new ones.
// Choice 1: use uintptr_t
WASM_RUNTIME_API_EXTERN uintptr_t
wasm_runtime_module_malloc(WASMModuleInstanceCommon *module_inst, uintptr_t size, void **p_native_addr);
// Choice 2: use uint64
WASM_RUNTIME_API_EXTERN uint64
wasm_runtime_module_malloc(WASMModuleInstanceCommon *module_inst, uint32 size, void **p_native_addr);

These two choices are worth considering. The first fits well on 32-bit platforms, and the second maintains consistent function signatures. At first glance, they seem preferable to adding new wasm64_xxx APIs. However, they could cause problems for existing programs that want to be compiled with the updated version of WAMR, which is why adding new APIs is the primary choice. Additionally, new APIs can reduce programming errors and enhance readability by clearly indicating the memory standard used for a given WASM file/module, with explicit return value types.

Plan to go with choice 2: use uint64 to modify existing APIs, keeping one set of APIs is easier for future maintenance.

3. Internal API implementation choice
Adding new export APIs or changing the export APIs requires corresponding changes in internal implementation APIs too. For example:
/* Internal API */
uint32
wasm_runtime_module_realloc_internal(WASMModuleInstanceCommon *module_inst,
                                    WASMExecEnv *exec_env, uint32 ptr,
                                    uint32 size, void **p_native_addr);

The ptr, size, and returned ptr should be uint64 when it's Memory64.
So we can change those types to:

typedef mem_offset_t = uint32/uint64; based on CMake flag
uintptr_t;
uint64;

The initial choice is 1 for it won't have any change if the CMake flag is disabled. Only when it is enabled for runtime, then we change the internal implementation, change the code logic, do type conversion, etc.

Plan to go with choice 1
#ifdef WASM_ENABLE_MEMORY64 != 0
typedef linear_mem_ptr_t uint64;
#else
typedef linear_mem_ptr_t uint32;
#endif

4. Maximum size for memory64 linear memory
Theoretically, the linear memory for memory64 can be much larger even using our existing u32 data representation for page count, it is in the scale of hundreds of TeraBytes.
Should we have a practical maximum size for linear memory to control the actual usage of memory? Like 64GB or something

running memory32 wasm/aot files is not possible (though you can still run memory32 wasm/aot files with the default runtime compile without adding the cmake flags)

I wonder if we could consider adding support for running both wasm32 and wasm64 on wamr64 runtime from the start? Our team is very interested in that scenario as that'd enable us to do a/b testing without having sequential native updates. I'd be happy to help with the work around that.

WASMMemory stay unchanged
I agree that max page count bigger than UINT32 doesn't make sense; but just out of curiosity, would that break the ABI for AOT? Or what's the reason for not making the change to conform the spec?

I wonder if we could consider adding support for running both wasm32 and wasm64 on wamr64 runtime from the start? Our team is very interested in that scenario as that'd enable us to do a/b testing without having sequential native updates. I'd be happy to help with the work around that.

Yes, I think we can definitely support both from the start, it wouldn't change too much from my original design, mostly some instantiating logic changes I guess. I was merely considering my bandwidth so aiming for simplicity for testing. With your team's help, I think we can definitely support both from the start.

I agree that max page count bigger than UINT32 doesn't make sense; but just out of curiosity, would that break the ABI for AOT? Or what's the reason for not making the change to conform the spec? If it's due to ABI change, I think it's ok since we're breaking the ABI with this feature anyway.

You are right that we are breaking AOT ABI anyway, but breaking ABI is not my main concern. I was thinking since we won't be using more pages, changing the type would change more code logic for no actual benefits but also take up more space, making the whole changes more complex.
I just realized that my statement can cause some confusion here. What I truly mean is that:

In the loader, we can conform to the spec, loading any uint64 values that the spec allows, but the wasm loader can set a special value(like UINT32MAX - 1) value to indicate it is larger than the allowed value(I was thinking maybe we can set a reasonable allowed value like 32GB or something?).

As long as you are not instantiating it, you are fine. But if you do, then in the wasm instantiating stage or in the wamrc compiling stage we will test if the special value of page count is set and correspondingly throw an exception.

Of course, I could miss something, feel free to point it out and we can discuss other alternatives together 😄

So we can change those types to:
typedef mem_offset_t = uint32/uint64; based on CMake flag
uintptr_t;
uint64;

I'd strongly discourage us from using uintptr_t - this is used for representing the host address, and using that for linear memory address is not good for the following reasons:

it might be not big enough (if we ever, for whatever reason, decide to run wasm64 on 32bit systems)
it might be unnecessarily big (e.g. in case of wasm32 running on x86_64)
it's confusing (if I see uintptr_t, I immediately think of the host virtual memory, not linear memory)

I think the first option:
#ifdef WASM64
typedef mem_offset_t uint64;
#else
typedef mem_offset_t uint32;
#endif

looks best. I'm not 100% sure though whether offset is the best name to represent the address; I'd assume the offset can be negative, but if we want to use it to represent an absolute address, then perhaps we could use mem_address_t or linear_mem_ptr_t etc.

Also, we'll be having a discussion next week in the WASI SG about memory64 support in WASI-libc/WASI SDK: https://github.com/WebAssembly/meetings/pull/1479

looks best. I'm not 100% sure though whether offset is the best name to represent the address; I'd assume the offset can be negative, but if we want to use it to represent an absolute address, then perhaps we could use mem_address_t or linear_mem_ptr_t etc.

I think linear_mem_ptr_t is a solid choice

Hi, for the linear memory related APIs exposed (and its internal APIs), I think there may be several questions to discuss: what is type of related linear memory offset arguments/results in these APIs? Whether to define mem_offset_t or linear_mem_ptr_t type? And whether to use cmake flag to control it?
Note that developer may directly include wasm_export.h and use wamr static/shared lib in his project, in which the cmake flag in WAMR won't take effect in wasm_export.h, so we should not use internal macro to control API definitions in wasm_export.h.
So my opinion is that there may be two options:

One is to use uint64 as the type of linear memory offset for both 32-bit target and 64-bit target, and all related APIs are changed to uint64 offset. And no need to introduce mem_offset_t or linear_mem_ptr_t.
The other is to use uint32 in 32-bit target and uint64 for 64-bit target, and use macro #if UINTPTR_MAX == UINT64_MAX (or UINT32_MAX) to auto-detect the bit width of the target, and define mem_offset_t or something else accordingly. This supposes that 32-bit target only supports memory32 and memory64 is unsupported. And note that in 64-bit target, the offset is uint64 no matter the linear memory is memory32 or memory64.

I think the first one simplifies the implementation and reduces the maintain effort, but it may slightly impact the footprint and performance. Since there are too many features now and the source code is already very complex, it is my personal preference.
BTW, we had better refactor the current code to change API definitions and data structure definitions (memory instance, module instance, etc.) and resolve historical issues (e.g. UINT32_MAX linear memory size limitation), to make the AOT ABI well defined before we start to implement memory64, since we may release 2.0.0 after GC is merged and before memory64 is implemented.

https://github.com/bytecodealliance/wasm-micro-runtime/commit/0ee5ffce8573a0e41f5a33dce562f541e98eb28a

https://github.com/bytecodealliance/wasm-micro-runtime/pull/3240
https://github.com/bytecodealliance/wasm-micro-runtime/pull/3260
https://github.com/bytecodealliance/wasm-micro-runtime/pull/3266

do you have any plans on table64? https://github.com/WebAssembly/memory64/issues/51

Currently, there is no plan regarding the table64 proposal implementation,  a corresponding new RFC issue probably would be open if anyone were to implement it

They clearly f things up on 64 bit support. I want to duplicate all wasi apis to have a _wasm64 suffix but they seem to even ignore what i am saying. I would like to hear what you guys think.

Thanks @gajanak , this is a known issue and we were planning to address it as part of the WASI work (overall, memory64 support is in still quite an experimental stage)

And one more TODO in the future, not WIP currently, but listed here for reference: Implement table64 extension

Great to see this being worked on -- any insight into when this feature will be ready for use in a development setting and in a production setting?

I start to work on table64 and hopefully, it can be ready in a month or so


Auto-generated types improvements for actions and forms (opposit way)

Describe the problem
Hello, today if I return data in load or action functions, the type appear in data and form props. That's really nice. But would it be possible to do opposit? E.g. type appearing in FormData, based on form on client-side?
E.g. let's say we have:
+page.svelte:
<form method="POST">
    <input type="text" name="employee">
    <input type="number" name="salary">
    <button>Submit</button>
<form>

+page.server.js:
export const actions: {
    default: async ({ request }) => {
        const data = Object.fromEntries(await request.formData());
        //   ^^^^^ type: `{[k: string]: FormDataEntryValue}`
    }
}

Describe the proposed solution
And instead of {[k: string]: FormDataEntryValue}, I would like to have:
{
    employee: string;
    salary: number;
}

Alternatives considered
No response
Importance
would make my life easier
Additional Information
I know this may be more tricky and harder to do (if not impossible), because of main two reasons:

We would need to know that there are no dynamic elements in form, or otherwise, we would need to fallback to "generic" {[k: string]: FormDataEntryValue}, this may be hardest part.
We would need to be carefull about method and action property (including named actions stuff)

There are way too many edgecases to consider. Taking the html as source of truth isnt a thing here. Take a look at superforms to add types and validation to your forms instead.

Even with all the edge cases covered, this still wouldn't work. Form Actions are HTTP endpoints like any other, so we don't actually know what data will be passed to them.
The Type inference described would falsely tell developers that the input has been sanitized. It hasn't.
I would recommend taking a look at SvelteKit Superforms

I think this has nothing to do with validations, it's just about types. Also, it's possible to implement type like:
{
    employee?: string;
    salary?: number;
    [key: string]: FormDataEntryValue
}

I get the intention but it's way too hard to implement. You need to know all form inputs at build time, maybe you are using deeply nested components to render these inputs. You would have to recursively traverse through all child components to find them.
You are better of doing it the other way around. Define the types and build the inputs around those types. And


Main refactor

removed some unused vars, removed empty space, added curly brackets in some cases, changed some functions into arrow functions.

Uncaught (in promise) ReferenceError: mesh is not defined
at init (main.js:153)
at App.js:30


true/false for boolean reporters should be translated.

Expected Behavior
Please describe what should happen
Getting the output of a boolean reporter should be translated. The actual value will still be true or false, but the value shown to the user should be translated.
Actual Behavior
Describe what actually happens

Steps to Reproduce
Select a language other than English. Then get the value of a boolean.

Curious to know how to carry this across to a project that checks a boolean value against the specific strings "true" or "false"...?
At the moment, <<1=1>=[true]> is true, as is <<1=0>=[false]> (i.e. the string "true" is equivalent to boolean , similar for "false").
I suspect there are projects that check if some expression is false by doing <=[false]> (rather than the expected <not>), and probably even some that check <=[true]> (when they could just do ).
–Wondering how to deal with such cases with multiple translations of "true" and "false"...?
Furthermore, 'list contains' can also use strings "true" & "false" to test if a boolean value is in the list (as well as testing if a list contains a string "true" or "false" using a boolean value – i.e. "list contains <1=1>" will give true if the list contains the string "true"; similarly "list contains [true]" will give true if the list contains a  value from a boolean expression).
More generally (slightly off-topic, but related), the equivalence between the string "true" and the boolean , and the equivalence between the numerical value 1 and the boolean  leads to some interesting curiosities  (e.g. numerical 1 is clearly not equivalent to the string "true", even though both are equivalent to ). Similar for "false" and numerical value zero... :)

@thisandagain following up on the discussion, this might be an incompatible change with 2.0. In 2.0 the boolean blocks report 'true' or 'false' regardless of language. If there are projects that are using the string, they would probably break. I'm going to postpone it, and we can discuss it along with localizing numbers.
/cc @rschamp

@chrisgarrity 👍 Thanks.


update julia (0.4.5)

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


feat: Support for tokens namespace

Description

[x] tokens.info
[x] tokens.create
[x] tokens.update

Related Issue
Fixes liftedinit/roadmap#21
Testing
Added unit tests for the above functions and fixed a bug where automatically adding a nonce wouldn't work outside of browsers.
Breaking Changes (if applicable)
None. Everything is under a new namespace.

@hansl We do use maps everywhere internally. I feel like one of the high-level design goals of ManyJs is to allow developers to do this...
network.tokens.create({
  summary: {
    name: "MyToken",
    symbol: "MTK",
    precision: 9,
  },
  owner: address,
  distribution: new Map([[address, BigInt(inputs.amount)]]),
});

...instead of this...
network.tokens.create(new Map([
  [0, new Map([
    [0, "MyToken"],
    [1, "MTK"],
    [2, 9],
  ]),
  [1, address],
  [2, new Map([[address, BigInt(inputs.amount)]])],
]);

Is that reasonable?

Okay, comments addressed. The PR is already approved so I'll merge assuming tests pass.


Rename :retry bolt key to :pending

See https://github.com/CartoDB/cartodb/pull/15272#issuecomment-559552505

What I had suggested in this comment was to get rid of the retry/pending REDIS key, and instead, check the keys that Resque stores in Redis to represent each enqueued job.
In Rails we would just need to add resque-loner and add include Resque::Plugins::UniqueJob into our GTM jobs. That way, if you try to enqueue a job that is already enqueued, it would be ignored.
On the other hand, in the TIS, we would have to implement the same logic, which basically consists in get the MD5 hash of the class name and args and look for it in Redis.
This way, we would avoid the coupling and the code should be simpler and we would avoid the coupling between cartodb and TIS (although it's already quite coupled, so it's not a big deal for me).
What do you think?

I really like the idea of removing a bit of coupling and just use the regular resque keys to have unique GT jobs per user. But since next iteration I (or anyone else) will be working on this we barely have time now to finish this as is.
So, on one hand I'll open a ticket somewhere with that idea to be implemented both in TIS and cartodb.
On the other hand I would like to put in production now the implementation I've sketched here (this very PR and this in TIS: https://github.com/CartoDB/node-cartodb-invalidation-service/pull/48). But it feels like a rush now, I think we better leave this to be handled property in that other ticket later.

Ok, as you prefer. This implementation looked good and was an improvement, but yeah, it's a bit delicate and should be reviewed and tested with enough time...
Thanks for your work and for creating the new issue! :heart:


Force reevaluation of autoformat settings at buffer write time

Summary
Fixes #233
Test Plan
Regression tests:

If g:prettier#autoformat == 1 and g:prettier#autoformat_config_present == 0, ensure that prettier runs on buffer save, regardless of whether or not a config file is present.
If g:prettier#autoformat_config_present == 1, ensure that prettier runs on buffer save if and only if a config file is present.

Tests for new behavior:

Test for both bugs originally reported in #233

Awesome! thank you for this !


Thompson Nicola Regional District, BC

To be added: http://tnrdmap.tnrd.ca/arcgis/rest/services/Basemap_Detail_Cache/MapServer/3

Closed by https://github.com/openaddresses/openaddresses/pull/1409


libreoffice-qt: fix build

Description of changes
Libreoffice 7.3 configure now checks for KFileWidget instead of kcoreaddons (commit).

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Oops, didnt see https://github.com/NixOS/nixpkgs/pull/172451


[DOCFIX]update doc for Spark-on-Alluxio

Updates Chinese doc for Running-Spark-on-Alluxio.md and adds the solutions for Failed to login.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/15245/
Test PASSed.


test(slo): update to js-version

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en
Pull request type
Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[x] Other (please describe): SLO

Codecov Report
Patch coverage has no change and project coverage change: -0.01 :warning:

Comparison is base (de39d21) 64.97% compared to head (2b2c7ba) 64.97%.

: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.
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #758      +/-   ##
==========================================
- Coverage   64.97%   64.97%   -0.01%
==========================================
  Files         229      229
  Lines       22725    22725
==========================================
- Hits        14766    14765       -1
+ Misses       7204     7203       -1
- Partials      755      757       +2

Flag
Coverage Δ

51.76% <ø> (-0.04%)
:arrow_down:

go-1.17.x
64.59% <ø> (-0.10%)
:arrow_down:

go-1.19.x
64.76% <ø> (+0.15%)
:arrow_up:

go-1.20.x
64.55% <ø> (-0.28%)
:arrow_down:

integration
51.76% <ø> (-0.04%)
:arrow_down:

macOS
41.16% <ø> (+0.03%)
:arrow_up:

ubuntu
41.15% <ø> (ø)

unit
41.20% <ø> (ø)

windows
40.89% <ø> (-0.27%)
:arrow_down:

ydb-22.5
51.33% <ø> (-0.23%)
:arrow_down:

ydb-23.1
51.45% <ø> (-0.20%)
:arrow_down:

ydb-23.2
51.52% <ø> (+<0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.
see 7 files with indirect coverage changes

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


Add the ability to set pool on azdo pipeline create

https://stackoverflow.com/questions/77090200/how-to-specify-default-agent-pool-in-azure-devops-create-pipeline-api

Can default to just Hosted, apparently. But needs manually set.

Default "Azure Pipelines" is fine, as people can override the pool in the YAML as needed.


OS/X 10.11.6 - no kext available - using 10.10 version causes kernel panic

[X ] Programmer/board type: e.g Stlink/v1, Stlink/v2, Stlink/v2-onboard

Stlink/v2 - ideally

[ ] Programmer firmware version: e.g STSW-LINK007 2.27.15

[ X] Operating system: e.g Linux, Mac OS X, Windows (with specific version)

OS/X 10.11.6 El Capitan

[X ] Stlink tools version and/or git commit hash: e.g v1.1.0/git-c722056

v1.2.0
Release date: 16 may 2016

[X ] Stlink commandline tool name: e.g st-info, st-flash, st-util

st-flash
st-flash will read - but not write

[X ] Target chip (and optional board): e.g STM32F402VG (STM32Fxxx Discovery)

STM32F746G-DISCO
st-util
2016-07-22T10:20:49 INFO src/common.c: Loading device parameters....
2016-07-22T10:20:49 INFO src/common.c: Device connected is: F7 device, id 0x10016449
2016-07-22T10:20:49 INFO src/common.c: SRAM size: 0x50000 bytes (320 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2016-07-22T10:20:49 INFO src/gdbserver/gdb-server.c: Chip ID is 00000449, Core ID is  5ba02477.
2016-07-22T10:20:49 INFO src/gdbserver/gdb-server.c: Chip clidr: 09000003, I-Cache: off, D-Cache: off
2016-07-22T10:20:49 INFO src/gdbserver/gdb-server.c:  cache: LoUU: 1, LoC: 1, LoUIS: 0
2016-07-22T10:20:49 INFO src/gdbserver/gdb-server.c:  cache: ctr: 8303c003, DminLine: 32 bytes, IminLine: 32 bytes
2016-07-22T10:20:49 INFO src/gdbserver/gdb-server.c: D-Cache L0: 2016-07-22T10:20:49 INFO src/gdbserver/gdb-server.c: f003e019 LineSize: 8, ways: 4, sets: 32 (width: 10)
2016-07-22T10:20:49 INFO src/gdbserver/gdb-server.c: I-Cache L0: 2016-07-22T10:20:49 INFO src/gdbserver/gdb-server.c: f007e009 LineSize: 8, ways: 2, sets: 64 (width: 11)
2016-07-22T10:20:49 INFO src/gdbserver/gdb-server.c: Listening at *:4242...
The kexts available are:
stlink_shield10_10.kext
stlink_shield10_6.kext
stlink_shield10_8.kext
stlink_shield10_11.kext
stlink_shield10_7.kext
stlink_shield10_9.kext
Missing is stlink_shield10_11.kext
When I tried to modify and use stlink_shield10_10.kext - the system failed with a kernel panic.

Hi @fustbariclation, I'm not sure but on my Macbook with OSX 10.11 I didn't need a kernel module at all. And I used only stlink/v2 and stlink/v2-1. There is no real "error message" from the tools. But "only" a kernel panic. Have you tried without the module? I think this is only necessary because OS X will claim the stlink/v1 which is also not supported by ST anymore.

Dear Jerry,
Thank you very much for those comments. I've been having trouble getting
this to work for some time, actually. I wanted to get it working on my
Raspberry Pi to begin with - and it did flash the board once, but I've not
managed to do it again - the serial /dev files are not there.
So, I tried on the Mac.
It gets the stats from the card  OK:
st-info --flash
0x100000
st-info --sram
0x50000
st-info --descr
F7 device
st-info --pagesize
0x800
st-info --chipid
0x0449
st-info --serial
303636434646353735323536383637
st-info --hla-serial
"\x30\x36\x36\x43\x46\x46\x35\x37\x35\x32\x35\x36\x38\x36\x37"
st-info --probe
Found 1 stink programmers
It even reads OK:
st-flash read code.out 0x800000 0x007777
2016-07-22T12:14:57 INFO src/common.c: Loading device parameters....
2016-07-22T12:14:57 INFO src/common.c: Device connected is: F7 device, id
0x10016449
2016-07-22T12:14:57 INFO src/common.c: SRAM size: 0x50000 bytes (320 KiB),
Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
The problem comes trying to flash it:
st-flash read code.out 0x800000 0x007777
2016-07-22T12:14:57 INFO src/common.c: Loading device parameters....
2016-07-22T12:14:57 INFO src/common.c: Device connected is: F7 device, id
0x10016449
2016-07-22T12:14:57 INFO src/common.c: SRAM size: 0x50000 bytes (320 KiB),
Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
sh-3.2#  st-flash write code.out 0x800000 0x007777
2016-07-22T12:15:37 WARN src/sg.c: Failed to find an stlink v1 by VID:PID
2016-07-22T12:15:37 ERROR src/sg.c: Could not open stlink devic
As you can see, it looks as if it's trying, and failing, to use stink v1.
This is why I tried to load the kext for the stlinkv1_macosx_driver
Regards,
Peter
On 22 July 2016 at 10:28, Jerry Jacobs<EMAIL_ADDRESS>wrote:

Hi @fustbariclation https://github.com/fustbariclation, I'm not sure
but on my Macbook with OSX 10.11 I didn't need a kernel module at all. And
I used only stlink/v2 and stlink/v2-1. There is no real "error message"
from the tools. But "only" a kernel panic. Have you tried without the
module? I think this is only necessary because OS X will claim the
stlink/v1 which is also not supported by ST anymore.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/texane/stlink/issues/446#issuecomment-234484854, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AESqRwCZIz0-HCiQtyzLrj9yAcN7g9qWks5qYH9FgaJpZM4JSi09
.

 Where can I download those built kernel module files? E.g. stlink_shield10_11.kext

@yagamy4680 these are located in the repository

Thanks for feedbacks. However, I've tried to clone the entire repository, and try to find any "kext" file but nothing.
# yagamy @ grandia in /tmp [21:07:26]
$  git clone https://github.com/texane/stlink.git
Cloning into 'stlink'...
remote: Counting objects: 5419, done.
remote: Total 5419 (delta 0), reused 0 (delta 0), pack-reused 5419
Receiving objects: 100% (5419/5419), 14.51 MiB | 1.81 MiB/s, done.
Resolving deltas: 100% (3354/3354), done.
Checking connectivity... done.

# yagamy @ grandia in /tmp [21:08:58] C:1
$  find ./stlink | grep "kext"

Do I miss something, or shall I check out any branch to find those pre-built kernel modules?

True, these are located in a tarball:
https://github.com/texane/stlink/tree/master/stlinkv1_macosx_driver

Thanks again. I've download that tarball file, and extract it, but still cannot find stlink_shield10_11.kext. (Other kernel module files are found: 10.10, 10.9, ...)
$  find . | grep "kext"
./stlink_shield/build/Release/stlink_shield.kext
./stlink_shield/build/Release/stlink_shield.kext/Contents
./stlink_shield/build/Release/stlink_shield.kext/Contents/Info.plist
./stlink_shield/build/Release/stlink_shield.kext/Contents/Resources
./stlink_shield/build/Release/stlink_shield.kext/Contents/Resources/English.lproj
./stlink_shield/build/Release/stlink_shield.kext/Contents/Resources/English.lproj/InfoPlist.strings
./stlink_shield/build/Release/stlink_shield10_7.kext
./stlink_shield/build/Release/stlink_shield10_7.kext/Contents
./stlink_shield/build/Release/stlink_shield10_7.kext/Contents/Info.plist
./stlink_shield/build/Release/stlink_shield10_7.kext/Contents/Resources
./stlink_shield/build/Release/stlink_shield10_7.kext/Contents/Resources/English.lproj
./stlink_shield/build/Release/stlink_shield10_7.kext/Contents/Resources/English.lproj/InfoPlist.strings
./stlink_shield10_10.kext
./stlink_shield10_10.kext/Contents
./stlink_shield10_10.kext/Contents/Info.plist
./stlink_shield10_10.kext/Contents/Resources
./stlink_shield10_10.kext/Contents/Resources/English.lproj
./stlink_shield10_10.kext/Contents/Resources/English.lproj/InfoPlist.strings
./stlink_shield10_6.kext
./stlink_shield10_6.kext/Contents
./stlink_shield10_6.kext/Contents/Info.plist
./stlink_shield10_6.kext/Contents/Resources
./stlink_shield10_6.kext/Contents/Resources/English.lproj
./stlink_shield10_6.kext/Contents/Resources/English.lproj/InfoPlist.strings
./stlink_shield10_7.kext
./stlink_shield10_7.kext/Contents
./stlink_shield10_7.kext/Contents/Info.plist
./stlink_shield10_7.kext/Contents/Resources
./stlink_shield10_7.kext/Contents/Resources/English.lproj
./stlink_shield10_7.kext/Contents/Resources/English.lproj/InfoPlist.strings
./stlink_shield10_8.kext
./stlink_shield10_8.kext/Contents
./stlink_shield10_8.kext/Contents/Info.plist
./stlink_shield10_8.kext/Contents/Resources
./stlink_shield10_8.kext/Contents/Resources/English.lproj
./stlink_shield10_8.kext/Contents/Resources/English.lproj/InfoPlist.strings
./stlink_shield10_9.kext
./stlink_shield10_9.kext/Contents
./stlink_shield10_9.kext/Contents/Info.plist
./stlink_shield10_9.kext/Contents/Resources
./stlink_shield10_9.kext/Contents/Resources/English.lproj
./stlink_shield10_9.kext/Contents/Resources/English.lproj/InfoPlist.strings

No, it's not there.
That's part of the problem. I'm running 10.11, so the script fails. I tried
copying the kext for 10.10 and fixing up the references - and that's what
caused the kernel panic.
So, either, it'd be nice to have it working with out the kext, or, it'd be
nice to have a kext that works for 10.11.
Regards,
Peter
On 22 July 2016 at 14:18, Yagamy<EMAIL_ADDRESS>wrote:

Thanks again. I've download that tarball file, and extract it, but still
cannot find stlink_shield10_11.kext. (Other kernel module files are
found: 10.10, 10.9, ...)
$  find . | grep "kext"
./stlink_shield/build/Release/stlink_shield.kext
./stlink_shield/build/Release/stlink_shield.kext/Contents
./stlink_shield/build/Release/stlink_shield.kext/Contents/Info.plist
./stlink_shield/build/Release/stlink_shield.kext/Contents/Resources
./stlink_shield/build/Release/stlink_shield.kext/Contents/Resources/English.lproj
./stlink_shield/build/Release/stlink_shield.kext/Contents/Resources/English.lproj/InfoPlist.strings
./stlink_shield/build/Release/stlink_shield10_7.kext
./stlink_shield/build/Release/stlink_shield10_7.kext/Contents
./stlink_shield/build/Release/stlink_shield10_7.kext/Contents/Info.plist
./stlink_shield/build/Release/stlink_shield10_7.kext/Contents/Resources
./stlink_shield/build/Release/stlink_shield10_7.kext/Contents/Resources/English.lproj
./stlink_shield/build/Release/stlink_shield10_7.kext/Contents/Resources/English.lproj/InfoPlist.strings
./stlink_shield10_10.kext
./stlink_shield10_10.kext/Contents
./stlink_shield10_10.kext/Contents/Info.plist
./stlink_shield10_10.kext/Contents/Resources
./stlink_shield10_10.kext/Contents/Resources/English.lproj
./stlink_shield10_10.kext/Contents/Resources/English.lproj/InfoPlist.strings
./stlink_shield10_6.kext
./stlink_shield10_6.kext/Contents
./stlink_shield10_6.kext/Contents/Info.plist
./stlink_shield10_6.kext/Contents/Resources
./stlink_shield10_6.kext/Contents/Resources/English.lproj
./stlink_shield10_6.kext/Contents/Resources/English.lproj/InfoPlist.strings
./stlink_shield10_7.kext
./stlink_shield10_7.kext/Contents
./stlink_shield10_7.kext/Contents/Info.plist
./stlink_shield10_7.kext/Contents/Resources
./stlink_shield10_7.kext/Contents/Resources/English.lproj
./stlink_shield10_7.kext/Contents/Resources/English.lproj/InfoPlist.strings
./stlink_shield10_8.kext
./stlink_shield10_8.kext/Contents
./stlink_shield10_8.kext/Contents/Info.plist
./stlink_shield10_8.kext/Contents/Resources
./stlink_shield10_8.kext/Contents/Resources/English.lproj
./stlink_shield10_8.kext/Contents/Resources/English.lproj/InfoPlist.strings
./stlink_shield10_9.kext
./stlink_shield10_9.kext/Contents
./stlink_shield10_9.kext/Contents/Info.plist
./stlink_shield10_9.kext/Contents/Resources
./stlink_shield10_9.kext/Contents/Resources/English.lproj
./stlink_shield10_9.kext/Contents/Resources/English.lproj/InfoPlist.strings
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/texane/stlink/issues/446#issuecomment-234528874, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AESqR8uu_-fff2qcGPj9tCw9-PhvF8Yvks5qYLUBgaJpZM4JSi09
.

I'm not sure because you have a F7 board and a stlink/v2 programmer and you should not need a kernel module at all. If I remember correctly this is only used to unclaim the usb-disk programmer from the kernel and let libusb use it.

Just notice that using stlink/v2 programmer without OSX kernel module can work normally. I will buy stlink/v2 programmer to test. Thanks for supports. 👍

Thank you for that thought.
I hope so. I thought so, to begin with. However, as I said, now I've used
Mac/OS, Linux (through VirtualBox), and my Raspberry Pi. In each case, this
USB <-> serial connection to flash the board has been the problem.
It's not clear to me why it's able to read from the board, easily, but
simply trying to flash things back doesn't work.
To read from the board, it must know the protocol, it must know the /dev/
file. It must know the serial addressing.
Why can't it write?
On 22 July 2016 at 14:27, Jerry Jacobs<EMAIL_ADDRESS>wrote:

I'm not sure because you have a F7 board and a stlink/v2 programmer and
you should not need a kernel module at all. If I remember correctly this is
only used to unclaim the usb-disk programmer from the kernel and let libusb
use it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/texane/stlink/issues/446#issuecomment-234530597, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AESqR48Fbjgp5Iq9Sea5A37N03Xw3dczks5qYLc9gaJpZM4JSi09
.

The main reason is because of two errors you've made. First, the flash address is 0x8000000 (not 0x800000). Second, the command line parser differentiate from st-link v2 to v1 by the number of arguments, so the commands you need to perform are:
st-flash read code.out 0x8000000 0x007777

st-flash write code.out 0x8000000

And that's it, it should work (and you don't need any kext on ElCapitan)

Thanks @X-Ryl669 for your reaction and verification!

Thanks all for your contributions. I'm closing this now.


bugfix(*): fix record creators name access

access name via creator.person_or_org.name.
partial fix for #153

Pre
Front Page:

Search Page:

Post
Front Page:

Search Page:


fix: If no key attribute is defined for the entity, the logic to add association to ChangeView should be skipped.

Adopting "Change-tracking" library:
BEM project repo: https://github.tools.sap/Climate-21/c21-networkcalculation-srv
Reproduce PR:
https://github.tools.sap/Climate-21/c21-networkcalculation-srv/pull/2386
The step “npm run build” fails currently at entity FlowModelService.senderNodeEnergyCarrier (https://github.tools.sap/Climate-21/c21-networkcalculation-srv/blob/94cb4d6048aa69a5a368e02c2311b17d30d9da94/srv/model/FlowModelService.cds#L478).
Error Message:

Best Regards
Jocelyn

Hi Nikica,
Thanks for your reminder. It is my mistake. If use return statement here will exit the complete form loop.
So I will use continue here. The continue statement terminates execution of the statements in the current iteration of the current or labeled loop, and continues execution of the loop with the next iteration.
And I also test in my local application. continue can be worked multiple entities and only one of them not having keys, the loop not be exit when one of them not having keys appeared.
Best Regards
Jocelyn


icloudEnabled is set to true too late after notes table view controller has loaded.

The first time app is loaded and launched, an alert controller will pop up and asks user for storage choice while table view in the background is being loaded. Because user has not made the choice yet, table view reloads nothing because the property iCloudEnabled is still set to false.

solution: https://github.com/yoha/Thoughtless/commit/e0b4faaa22e0e1f01556bd0a680328cae5c2a0dc


[Task]: Implement icons for audit logs

Is there an existing issue for this?

[X] I have searched the existing issues

SubTasks

Need to get icons from design.
Then implement based on the event type etc.

Refer: https://github.com/appsmithorg/appsmith/issues/15373


IMPORTANT! Security Vulnerability Detected in your Repository

Hey there!
We have detected a security vulnerability in your repository. Please contact us at https://github-scanner.com to get more information on how to fix this issue.
Best regards,
Github Security Team

您好，信件已收到。


Add tree syntax

One idea is to add tree syntax as a way of making it simpler to create structured data.
ancient_egypt {
  early_dynastic_period,
  old_kingdom_era,
}

This is the same as:
(early_dynastic_period, ancient_egypt)
(old_kingdom_era, ancient_egypt)

Related to https://github.com/advancedresearch/avalog/issues/164
An idea is to combine tree syntax with namespaces:
ns ancient_egypt {
  ::early_dynastic_period,
  ::old_kingdom_era,
}

This is the same as:
(ancient_egypt::early_dynastic_period, ancient_egypt)
(ancient_egypt::old_kingdom_era, ancient_egypt)


ARTEMIS-4350 use consistent delimiters when constructing mqtt subscription queues

see https://issues.apache.org/jira/browse/ARTEMIS-4350

@jbertram can you look into this?
@jbertram , @erwindon what about compatibility with previous versions? usually compatibility is a deterrent for things like this.

@erwindon checkstyle issues ^^
but we should spend some time on the compatibility

I do believe this will break compatibility for users who upgrade and also have existing MQTT subscriptions and a non-default wildcard configuration (which is fairly common among folks who use the broker mainly for MQTT).
Furthermore, I'm not entirely sure this is actually more consistent overall. Using the configured delimiter instead of . is certainly more consistent with MQTT syntax, but the name of the queue is an internal implementation detail and . characters are used in other places for queue names so now this name is inconsistent with that.
I think this should probably just stay the way it is.

I wouldn't change it in this way either. It is a breaking change as Justin says, very questionable for whats only marked as a 'minor improvement', and as the ClientID and address are ultimately distinct things and the wildcard deliminator is about the address its also not clear to me either that this would really be 'more consistent'.

checkstyle issues
ah, sorry, my local build did not croak on that. adjusted+pushed.

And the rest of my comments have become obsolete after the recommendations from @jbertram and @gemmellr.

@erwindon what's the point of using the same subscription between MQTT and AMQP anyways? each client should have its own subscription.
if you really do for any reason I can't understand, you should use FQQN and bypass the subscription altogether.

@clebertsuconic

what's the point of using the same subscription between MQTT and AMQP anyways[...]

but that was not the intention...
I was investigating a scenario where MQTT messages were published using a MQTT connection and then consumed as AMQP messages using an AMQP connection. Obviously with Artemis in the middle. But I goofed on the configuration of the delimiter, so the defaults still applied. The mistake was that I had placed the whole {{wildcard-addresses}} block just after the {{core}} section in the config.
the MQTT connection published on topic {{aaa/bbb/ccc}} but Artemis converted that to address {{aaa.bbb.ccc}} inside the broker.
but for AMQP, no conversion takes place and Artemis uses the address {{aaa/bbb/ccc}} as given by the consumer.
this mismatch prevented messages from reaching their destination application.
this problem was quickly solved by your team's comments ("no problem here!") and myself verifying the config one more time, and then fixing that.
the cosmetic issue that I tried to solve in this PR was just something that I found while investigating how addresses were handled by the MQTT protocol handler to solve the above problem. This PR was about the generated queue names for the MQTT subscriptions only that I found to be slightly inconsistent.

I don't understand.. was this closed?

after I spoke with Justin, it's a common change to mess with wildcard configuration.. that will really create issues with previous versions.


Update dependencies and fix OCSP stapling

Hi
This PR fixes two things:

It updates dependencies for golang.org/x/crypto so the correct certificate chain is included in the LE certs (older versions included the expired certificates)
Fixes OCSP stapling which failed because the wrong certificate was selected as issuer certificate.

Tested these changes and works as expected.
Please let me know if this needs changes.
Thanks!
Kind regards,
Cedric

Thanks much for you contribution! I will look at it soon.


Use MkDocs to build the documentation

The documentation is generated using MkDocs, using the Material theme plus mkdocstrings (and a few minor supporting extensions) to build the API documentation extracted from code comments.
For now the home page is a place holder, and the supporting script docs/mkdocstrings-autoapi.py should eventually be moved to a common repository.
TODO

[x] Build and publish the docs via GitHub Pages in the CI.
[x] Generate site for each version using mike.
[x] Do some basic documentation fixing, like using admonitions for Copyright and License.

Probably for another PR

[x] Think about what is the public interface, and hide modules that are internal (probably we only want to publish what's exported via frequenz.channels). #30
[x] Add class attributes documentation. #31
[ ] Move documentation tips (section above) to some more permanent place so it doesn't get lost.
[x] Generate docs for the v0.10.0 release
[x] Configure the default version in mike on the final website.
[x] Look for failing deployment (permissions)

Notes on how documentation should be written:

Properties:

@properties are rendered as function (with a special mark for being a property)

Removing documentation from the function and using Attributes: instead somewhat works, but you only get a table in the Class documentation, attributes are not shown in the right ToC, which makes them hard to discover IMHO.

The best approach to @properties, that works well with pydocstyle and darglint seems to be the following:
class AClass:
    """A class."""

    @property
    def a_prop(self) -> int:
        """Get the a prop.

        Returns:
            The a prop of the class.
        """
        return 1

    @a_prop.setter
    def a_prop(self, a: int) -> None:
        pass

The only downside is properties are still listed as functions, not attributes, and there is redundancy in the documentation (basically we need to document it twice, one for the description and one for the Returns:. mkdocstrings doesn't show the type if Returns: is not specified, and if the description is not included, pydocstyle complains.

Class / instance attributes:

Attributes should be documented in general using docstrings, not the Attributes: section, as the Attribute: section doesn't produce ToC entries and doesn't extract a lot of info.
class A:
    """A class.

    Attributes:
        some_attr_in_attributes: Attribute in `Attributes:`, shows nice in the
            docs (the type is shown, no value is shown) but no ToC.
    """

    class_attr: str
    "This is marked as class attribute, not good."

    def __init__(self, t: tuple[int, int]):
        self.some_attr_in_attributes: tuple[int, int] = t

        self.some_docstr_attr_with_init: tuple[int, int] = t
        "This is marked as a instance attribute, but the value is shown out of context, not good."

        self.some_docstr_attr_without_init: tuple[int, str]
        "If we separate declaration from initialization, the declaration is not show, not good."

        self.some_docstr_attr_without_init = (2, "a")

        self.some_docstr_attr_without_init_doc_in_assign: tuple[int, str]
        self.some_good_attr = (2, "a")
        "But if we document the assignment, it is shown, but no type and out of context value, not good."

So it looks like there is no perfect solution, but using the style of some_docstr_attr_with_init seems to be the best approach.

Module attributes / type aliases
I tried this:
"""Module docs.

Attributes:
    SomeType: This is a type with lala.
"""

SomeType = str

And it produces:

While:
"""Module docs."""

SomeType = str
"""This is a type with lala."""

And it produces:

So the former is definitely the way to go.

To make cross-reference links we need to use this format [some_symbol[fully.qualified.symbol.name].

We should consider to make only the frequenz.channels documentation public, as the rest is not intended for end users and just makes the documentation harder to navigate (and could lead to users using inner modules, like frequenz.channels.select.Select instead of simply frequenz.channels.Select. We could also build 2 sets of API references: one for users and one for developers/collaborators.

We need to use from __future__ import annotations and use the symbols instead of strings, otherwise the documentation doesn't get the cross references for these types.

Examples should be put indented and at the end of the documentation for better rendering:
"""Doc doc doc

Doc doc doc.

Example:
    ```python
    print("test")
    ```
"""

There is a difference between Example: and Examples: (plural). The former creates an admonition and the later is used to write Python REPL examples directly, for example:
"""Doc doc doc

Doc doc doc.

Examples:
    >>> 1 + 1
    2
    ```
"""

Two other minor commits with fixes are included:

ci/labeler: Sort file patterns
ci/labeler: Add missing noxfile.py

I'm unable to build it locally with Python 3.10, with this error:
INFO     -  Cleaning site directory
INFO     -  Building documentation to directory: /home/sahas/code-oss/frequenz-channels-python/site
reference/frequenz/channels/index.md src/frequenz/channels/__init__.py
reference/frequenz/channels/anycast.md src/frequenz/channels/anycast.py
reference/frequenz/channels/base_classes.md src/frequenz/channels/base_classes.py
reference/frequenz/channels/bidirectional.md src/frequenz/channels/bidirectional.py
reference/frequenz/channels/broadcast.md src/frequenz/channels/broadcast.py
reference/frequenz/channels/merge.md src/frequenz/channels/merge.py
reference/frequenz/channels/merge_named.md src/frequenz/channels/merge_named.py
reference/frequenz/channels/select.md src/frequenz/channels/select.py
reference/frequenz/channels/utils/index.md src/frequenz/channels/utils/__init__.py
reference/frequenz/channels/utils/file_watcher.md src/frequenz/channels/utils/file_watcher.py
reference/frequenz/channels/utils/timer.md src/frequenz/channels/utils/timer.py
ERROR    -  mkdocstrings: frequenz.channels could not be found
ERROR    -  Error reading page 'reference/frequenz/channels/index.md':
ERROR    -  Could not collect 'frequenz.channels'

Aborted with a BuildError!

Do you know why that is?  Also,  what do you think about adding a test in CI that ensures the docs are building?

ERROR    -  mkdocstrings: frequenz.channels could not be found

Did you make a local install via pip install -e .[docs]?

Do you know why that is? Also, what do you think about adding a test in CI that ensures the docs are building?

Yeah, it is in the plan.

Updated with some fixes to the docs and added some notes I took on things to watch out for when writing documentation in the future. FYI @ela-kotulska-frequenz too.

I did. I followed the steps in the instructions, and I still get the error.

This is super weird. I built a venv from scratch and did a pip install -e .[docs] and it works perfectly. From the error you get it seems like mkdocs can't find the frequenz.channels package, which should only point to . not being installed :thinking:

All comments addressed and I added versioning support for the website. You can see an example here: https://leandro-lucarella-frequenz.github.io/

Removing the draft status, as this should be ready to merge after the review.

In docstrings, Example: sections (singular) will be rendered as admonitions, while Examples: sections (plural) will be parsed by mkdocstrings to support regular Python REPL examples, for example:

OK, this one is unexpected. Did I missed something in the mkdocstrings documentation again or it is an undocumented feature?
While I have your attention, I wonder if there are any plans or reasons not to include Attributes: of a class in the ToC sidebar? Also what would be your recommended way to document @properties?
Thanks!

I added how to document class / instance attributes and module attributes to the "Notes on how documentation should be written:" section in the issue.
I still have to test how property setters are handled.

I built a venv from scratch and did a pip install -e .[docs] and it works perfectly.

works for me in a venv as well.  looks like my python env is broken.  I will look into it.
The PR looks good to me,  if you want to take this in and deal with properties next.

Yeah, I would merge first and then do further fixing, I think that's lower prio. It is important to know how should we do the documentation though, so we document new code in a correct way, but fixing old stuff is lower prio IMHO. Will do a rebase and then it is ready to merge. We'll need to find a way to put the documentation guidelines/tips I collected above.

OK, the deployment is failing because of permissions problems (I didn't have this in my fork because it is less restrictive). I will look into it tomorrow.

While I have your attention, I wonder if there are any plans or reasons not to include Attributes: of a class in the ToC sidebar?

Attributes sections, just like Parameters, Returns, Yields, etc., are rendered as tables, without any particular heading. The absence of headings means there will be no entry in the Table of Contents.
If you do want to get a heading for each documented attribute, you have to document the attribute itself rather than describing it in its parent class or module:
SOME_ATTR: int = 0
"""Description of this attribute."""

It boils down to preference: are the attribute important enough that they should have a dedicated heading (and therefore permalink, which is quite useful I admit), or can we just have it described succinctly in the parent object :confused:

Also what would be your recommended way to document @properties (as functions or as Attributes:)?

Currently, properties are fetched as functions (because that's how they are declared), but I do not like this and am planning on returning them as attributes instead, since that's how they accessed (which is more important than how they are declared, since we're documenting API usage). It's in the backlog :smile: In the meantime, properties are rendered as functions, with trailing parentheses :confused: IIRC, properties setter and deleters are simply not taken into account, but we have plans for them as well, something like the ability to merge their docstrings together.

It boils down to preference: are the attributes important enough that they should have a dedicated heading (and therefore permalink, which is quite useful I admit), or can we just have it described succinctly in the parent object confused

Yeah, for me the table is not an option because I think the visibility gets drastically reduced. At least my expectation from an API documentation is to find attributes in the TOC. It's what happens in most other languages documentation systems.

Currently, properties are fetched as functions (because that's how they are declared), but I do not like this and am planning on returning them as attributes instead, since that's how they accessed (which is more important than how they are declared, since we're documenting API usage).

Yeah, 100%, for the user reading the docs it should be transparent if the implementation changes from a pure attribute to a property and vice-versa.

It's in the backlog smile In the meantime, properties are rendered as functions, with trailing parentheses confused IIRC, properties setter and deleters are simply not taken into account, but we have plans for them as well, something like the ability to merge their docstrings together.

:tada: :tada: :tada:
Good to know what's the future direction so we can document things properly and when things get improved we'll get the improvements without extra effort.
Thanks a lot for sharing, it is really useful stuff!

PS: we have a valuable conversation here, I might re-use your questions and my answers in the docs since I think it would help other users slightly_smiling_face Thanks!

Great, glad to be of help too!


I'm writing a test cases by mocking the Hystrix call

I'm able to mock the Hystrix command and my test case is passing but while building my war I'm facing an error that is
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'gatewayConfiguration' defined in URL [jar:file:/Users/boinapally/.m2/repository/com//connect/common/gateway-common/<IP_ADDRESS>/gateway-common-<IP_ADDRESS>.jar!/com/garmin/connect/common//config/GatewayConfiguration.class]: Initialization of bean failed; nested exception is java.lang.IllegalStateException: Another strategy was already registered.
Caused by: java.lang.IllegalStateException: Another strategy was already registered.
The lines of code I added in my test-applicationContext.xml is : <context:component-scan base-package="com.garmin.connect.common.gateway.config"/>
and for in every test method the two lines I used to mock my Hystrix call is:
HystrixRequestContext.initializeContext();
HystrixRequestContext.getContextForCurrentThread().shutdown();
Any solutions please

The error is occurring because you've got multiple code paths that are attempting to set up some static (singleton) data structures that Hystrix needs to operate.
If you want to understand why that's occurring, it would be useful to add breakpoints to all of the HystrixPlugins.register* methods.  Generally, it's the case that some init logic is running at the same time as commands executing.  Whenever this occurs, if the commands find a necessary null data structure, the command initializes it with a default.  Then the init logic runs and shows the error message you see.  If this is the case, then the fix is to make sure that all init logic runs before any command runs.  The specifics of that vary, depending on your exact situation.
Also see Operational FAQ

Thank you so much for the response. fixed it by resting the hystrix call before executing the each test case and then performing the mocking option helped me to solve. one issue I faced is the service I'm working is using different dependency during the runtime compared to  compile time. fixed it by excluding the runtime dependency in gateway-common .

I'm not familiar with gateway-common - that sounds custom to your setup.  In any case, glad you got it resolved


Enable sparse support in TorchConnector and other minor updates

Summary
The PyTorch connector TorchConnector supports sparse output in both passes. That means a hybrid network that has a quantum layer must rely on PyTorch sparse operations only.
Details:
Added more tests for the connector to test_torch_connector.py
On hold until we drop support of python 3.7 since the code depends on the newer version of sparse that does not support 3.7 anymore.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

34 of 59 (57.63%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.4%) to 90.454%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit_machine_learning/connectors/torch_connector.py
34
59
57.63%

Totals

Change from base Build<PHONE_NUMBER>:
-0.4%

Covered Lines:
3430

Relevant Lines:
3792

💛  - Coveralls

Coverage went down on python 3.7 which is not supported in sparse test cases.
@woodsp-ibm Can you please take a look at the PR?

Unit tests don't test sparse configuration on python 3.7.

We could check they raise the exception as expected, which is all that can be done, to assert its behaving as expected in this case (instead of skipping the tests completely)


The new version doesn't seem to support windows right now.

Version
2021.1
Operating System

[ ] Any
[ ] Linux
[ ] macOS
[X] Windows
[ ] Other Unix

OS Version
windows10
Processor

[ ] Any
[ ] Arm (using Rosetta)
[X] x86-64 (64-bit)
[ ] Other

System Component
Installation
Severity
Major
Description
The new version doesn't seem to support windows right now.
Older versions are supported such as 110.99.3.
Transcript
No response
Expected Behavior
No response
Steps to Reproduce
none.
Additional Information
No response
Email address
<EMAIL_ADDRESS>

This is correct and documented.  For Windows, you should use the legacy branch (110.99.3 is the latest version).  We will support Windows with the main development branch in the future, but probably not before the end of next Summer.


Improve Log Metrics Reporter to support ELK solution

Purpose
This PR will update the existing LogMetricsReporter class to support the ELK solution.
Approach
This logger can be enabled using the following approach,
Step 1 - Configuring the deployment.toml file.
[apim.analytics]
enable = true
properties."publisher.reporter.class" = "org.wso2.am.analytics.publisher.reporter.log. LogMetricReporter"
logger.reporter.level = "INFO"

Step 2 - Enabling Logs from wso2am-4.x.x/repository/conf/log4j2.properties
appenders = APIM_METRICS_APPENDER, .... (list of other available appenders)

appender.APIM_METRICS_APPENDER.type = RollingFile
appender.APIM_METRICS_APPENDER.name = APIM_METRICS_APPENDER
appender.APIM_METRICS_APPENDER.fileName = ${sys:carbon.home}/repository/logs/apim_metrics.log
appender.APIM_METRICS_APPENDER.filePattern = ${sys:carbon.home}/repository/logs/apim_metrics-%d{MM-dd-yyyy}.log
appender.APIM_METRICS_APPENDER.layout.type = PatternLayout
appender.APIM_METRICS_APPENDER.layout.pattern = %d{HH:mm:ss,SSS} [%X{ip}-%X{host}] [%t] %5p %c{1} %m%n
appender.APIM_METRICS_APPENDER.policies.type = Policies
appender.APIM_METRICS_APPENDER.policies.time.type = TimeBasedTriggeringPolicy
appender.APIM_METRICS_APPENDER.policies.time.interval = 1
appender.APIM_METRICS_APPENDER.policies.time.modulate = true
appender.APIM_METRICS_APPENDER.strategy.type = DefaultRolloverStrategy
appender.APIM_METRICS_APPENDER.strategy.max = 20

loggers = reporter, ...(list of other available loggers)

logger.reporter.name = org.wso2.am.analytics.publisher.reporter.log
logger.reporter.level = INFO
logger.reporter.additivity = false
logger.reporter.appenderRef.APIM_METRICS_APPENDER.ref = APIM_METRICS_APPENDER

Security checks

Followed secure coding standards in http://wso2.com/technical-reports/wso2-secure-engineering-guidelines? yes
Ran FindSecurityBugs plugin and verified report? yes
Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets? yes

Codecov Report

Merging #70 (b9bd545) into main (165ec96) will increase coverage by 0.29%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##               main      #70      +/-   ##
============================================
+ Coverage     46.82%   47.11%   +0.29%
- Complexity      111      112       +1
============================================
  Files            35       35
  Lines           724      728       +4
  Branches         72       72
============================================
+ Hits            339      343       +4
  Misses          340      340
  Partials         45       45

Flag
Coverage Δ

unit_tests
47.11% <100.00%> (+0.29%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...ytics/publisher/reporter/log/LogCounterMetric.java
92.30% <100.00%> (+1.39%)
:arrow_up:

...tics/publisher/reporter/log/LogMetricReporter.java
85.71% <100.00%> (+5.71%)
:arrow_up:


Abnormal CPU usage of the CPU module

For some reason, even with a 30 second interval, the CPU module makes Waybar consume a lot of cycles (~75% of a core). As soon as I disable it and restart Waybar, it remains idle. I also have the RAM module enabled, but no problems there. Persists between reboots.

First thx for reporting.
It's weird, you're on which distribution ?

Arch, up-to-date.


Dumping expected results to .npy files does not roundtrip with --expected_output

Problem description + Reproducer
Simple elementwise add
!tensor_t = tensor<4xf32>

func.func @forward(
    %A : !tensor_t, %B : !tensor_t) -> !tensor_t {
  %C = tensor.empty() : !tensor_t
  %0 = linalg.add ins(%A, %B : !tensor_t, !tensor_t)
                     outs(%C : !tensor_t) -> !tensor_t
  return %0 : !tensor_t
}

Compile + run and try to roundtrip the expected output with the same vmfb
iree-compile elementwise.mlir \
    --iree-llvmcpu-target-triple=x86_64-unknown-linux \
    --iree-hal-target-backends=llvm-cpu \
    -o /tmp/elementwise.vmfb

iree-run-module \
    --module=/tmp/elementwise.vmfb \
    --device=local-task \
    --function=forward \
    --input=4xf32=1.0 \
    --input=4xf32=2.0 \
<EMAIL_ADDRESS>
iree-run-module \
    --module=/tmp/elementwise.vmfb \
    --device=local-task \
    --function=forward \
    --input=4xf32=1.0 \
    --input=4xf32=2.0 \
<EMAIL_ADDRESS>
Produces the following failure to match
EXEC @forward
EXEC @forward
[FAILED] result[0]: element at index 0 (3) does not match the expected (2.23669E+08); expected that the view is equal to contents of a view of 4xf32
  expected:
4xf32=2.23669E+08 1.23875E-40 3.48335E-15 4.48986E+21
  actual:
4xf32=3 3 3 3

Using .bin files instead of .npy files works as expected.

by saying --expected_output=4xf32=file you are saying that the file should be parsed as binary. Just use<EMAIL_ADDRESS>

ah, ok that worked

The way the help documentation for --expected_output works makes it seem like I'm supposed to pass the shape.
# An expected function output following the same format as `--input=`.
# When present the results of the invocation will be compared against
# these values and the tool will return non-zero if any differ. If the
# value of a particular output is not of interest provide `(ignored)`.
# --expected_output=...

And then the format for --input isn't very clear about this to me
# Raw binary files can be read to provide buffer contents:
#<EMAIL_ADDRESS># Numpy npy files from numpy.save can be read to provide 1+ values:
#   @some.npy

but this issue solved so closing it, thanks!

binary files need shapes/types, numpy files don't
comments here may be more informative and should probably be copied back into the help:
https://github.com/openxla/iree/blob/main/runtime/src/iree/tooling/function_io.h#L23-L46

We also have this documentation page: https://iree.dev/developers/general/developer-overview/#iree-run-module
I focused on clarifying scalar/tensor types when I wrote that... should also talk about files (npy and binary)

yeah the reasoning for metadata makes sense. Copying back to the help would be nice.


Maintenance

Hi, I can't help but realise that lawin server on Heroku is undergoing maintenance. When will it be coming back up? Sorry for being a pain. :(

Never

Never

Use aurora V1 or Neonite

Use aurora V1 or Neonite

Why? LawinServer is the best thing in the whole world. I don't get why it would get shut it down.

Why? LawinServer is the best thing in the whole world. I don't get why it would get shut it down.

Oh, was it epic games?

Oh, was it epic games?

 Ugh...

 Ugh...

Well, Lawin wanted to leave the fortnite Scene
and 2. Epic would have shut it down if he didn't
I can help you get it back, DM on Discord (ImpossiblePlayz#3368) :)

Well, Lawin wanted to leave the fortnite Scene
and 2. Epic would have shut it down if he didn't
I can help you get it back, DM on Discord (ImpossiblePlayz#3368) :)

Mine is Spenzy3 and I have sent a request.

Mine is Spenzy3 and I have sent a request.

Well, Lawin wanted to leave the fortnite Scene and 2. Epic would have shut it down if he didn't
I can help you get it back, DM on Discord (ImpossiblePlayz#3368) :)

Help me too! I'm lorenzohappy19#0001

use:
https://lawinservertest.herokuapp.com
(NOTE: This will shutdown at the 28.11.2022 thanks to heroku EOL of free dyons)


ROLE should be a top level config

In practice, the concept of a USER (i.e. their DEFAULT_ROLE) is ambiguous in Snowflake.
Currently role can be passed through OPTIONS but this approach does not surface the control very well.
It should be a top level config to be explicit on what role will be used to perform all database activity.
For convenience the config can remain optional (to rely on DEFAULT_ROLE of the USER when unset).

I initially implemented ROLE as a top level option before d3833b0670a7518a5bd79eb2113fbd6350c8ee27. As I remember, I moved it because it's an optional value and I didn't like that there would be two possible places to specify it (top level and in OPTIONS). I guess the same argument about "two possible places to specify" could be made for other Snowflake-specific top-level options like ACCOUNT, SCHEMA, and WAREHOUSE, even as these are required options. I suppose I could be convinced either way on this.

Thank you for taking a look at this request Tim. We could keep it as-is and simply document it as another popular option in  https://github.com/Snowflake-Labs/django-snowflake/pull/66?

That sounds helpful. Thanks.


Console spam

Caused a lot of spam to my log and my console

This occurs when I use pvp_joinoverride "1"

I found it in the error log when I used "pvp_joinoverride" "0".


Add quarto R package

Summary
Did not realize the CLI Quarto is different than the quarto R package so adding the quarto R package.

It doesn't seem like the package installation was successful: https://github.com/jhudsl/ottr_docker/actions/runs/8789392387/job/24119043823?pr=17


javascript info

Issue Description
Please provide a clear and concise description of the resource you would like to add, including the topic or category it pertains to.
Resource Details
Resource Type: [Video/Website/Challenge/Tool/Books/Other]  website
Title/Name of the Resource: [Enter the title or name]  javascript info
Description: [Briefly describe the content and relevance of the resource]
URL or Source: [Provide the link to the resource or mention the source] Javascript.info
Topic or Category
Specify the topic or category that best represents the subject matter of the resource.
Intended Audience (optional)
Who is the intended audience for this resource? (e.g., beginners, intermediate, advanced, researchers)
Benefits of Adding this Resource
Explain how this resource would be valuable to users and contributors of the project/repository.
Additional Information (optional)
Include any additional information or context that might be helpful for evaluating the resource or understanding its relevance.

Checklist (optional)

[x] I have conducted a search to ensure this resource is not a duplicate.
[x] I confirm that this resource complies with the guidelines and policies of the project/repository.

already added!


⚠ Turnos 24x7 has degraded performance

In 9d9bc29, Turnos 24x7 (https://reservas-dev.alternativasinteligentes.com/) experienced degraded performance:

HTTP code: 200
Response time: 861 ms

Resolved: Turnos 24x7 performance has improved in 7187742.


Open discussion to the interested audience

Remember that there's a list of people that have volunteered to contribute in our pad:
https://pad.gwdg.de/deRSE23-session-pads-teaching-rseng
Some of them have contributed long paragraphs at the end of the pad. We should bring them in to contribute them and merge them to the main paper.

I've integrated my section into the manuscript as part of #27.

We are through with major contributors. Next come the participants.

The mail to all participants that put their mail in, is out. Next comes the DE-RSE ML at some point.

Thanks for getting this together. One thing that I noticed reading this paper is that in some instances Germany is mentioned specifically when the issue is more generic. So I wonder if this paper is targeted specifically at a German audience or whether we could leave it more generic with maybe some German examples.

now also been presented at the undeRSE23

remember #187 when we mail this to the entire community.

Announced on the mailing list, let's see when my mail gets moderated....


Support formatting for $-expressions

We should support a FMT-stype format for $-expressions when evaluating an integer or floating-point value

In GitLab by @ksiero on Mar 22, 2021, 13:39
mentioned in commit 26b5b46be8e9838ee4cd102304db34e62e5b3250

In GitLab by @ksiero on Mar 26, 2021, 17:10
mentioned in commit bfe01ac9e9d487e41163a6b43b0087ea445af371

In GitLab by @ksiero on Mar 26, 2021, 17:27
mentioned in commit 1731fbc8fd819e80e80caa36215188f799f0c668


fix: prevent append-release from running on PRs

Kinda just have to merge this and see if it fixes it (the triggering workflow is on main rn)


reuse window when attempting to create a context, fix #349

For each format attempt, the renderer creates a window and try to create a context using this window.
But anytime a context cannot be created, the next one is tried without destroying the previous window first, or reusing it.
This is an attempt to fix #349.

LGTM