[WIP] Microkernels for CUDA target

This PR introduces microkernels for CUDA target. It is a very first step, and there are many TODOs, but it works e2e linalg.matmul.
It implements followings:

Introduce a new Op MicroKernelOp in IREECodegen dialect.
Adds new compilation pipeline LLVMGPU_Microkernel, and sets it if micro kernel flag is enabled.
Lowers linalg.matmul into MicroKernelOp after bufferization.
Lowers MicroKernelOp into a trampoline function call before LLVM/NVVM generation.
Inserts pre-compiled PTX microkernels just before ptx compilation.

PR also introduces CUDA microkernels code. The idea is to call optimized CUDA codes here.
PR inserts microkernels as PTX. I confirmed that ptxas inlines trampoline function and the microkernels when I look at the output sass code.

Can't comment much on the microkernel op stuff, but we should have a chat about this so we can dig into some of the goo layers.
TLDR is for linking we need to align this with the infrastructure in place for custom linking that we use for either full dispatch replacement on CUDA or partial substitution on the CPU. See https://github.com/iree-org/iree/tree/main/samples/custom_dispatch.
The only work that should be required is extending CUDATarget.cpp to handle multiple IREE::HAL::ExecutableObjectAttrs like the LLVMCPUTarget.cpp already does - if it's as simple as concatenating the PTX blobs that should be really easy.
Steps:

the microkernel needs to get turned into a call (https://github.com/iree-org/iree/blob/main/samples/custom_dispatch/cpu/embedded/example_hal.mlir#L187)
the external function needs to be declared (https://github.com/iree-org/iree/blob/f19cc5b977e5210411068c820dab688cec5cc377/samples/custom_dispatch/cpu/embedded/example_hal.mlir#L152-L156)
the object files to link in need to be attached (https://github.com/iree-org/iree/blob/f19cc5b977e5210411068c820dab688cec5cc377/samples/custom_dispatch/cpu/embedded/example_hal.mlir#L61-L74)

This then supports multiple external objects coming in for if multiple microkernels are used in the same dispatch. It'll also let us link things in once when we are combining PTX blobs (which we really need to do...).
Actually producing the ptx blobs for the microkernels is going to be the difficult part and will need some build infrastructure. The custom_dispatch sample shells out to nvcc but that doesn't scale beyond a few - if we can keep this bounded to just 5-10 microkernels then we should be ok keeping it simple, and if it extends beyond that this should probably live in a separate location/layer of the stack (we don't want to rebuild cublas :). The biggest issue this entire approach has is that we want to be compiling the microkernels with the same target configuration being used by the compiler and we can't enumerate all possible target combinations. How we organize the files, decide what to compile with what settings, and how to select from those is going to be the biggest chunk of work. Again if we can keep this set small then things stay simple - otherwise this will need to live separate (some big cmake flag to enable as opt-in, etc).
The source files themselves shouldn't be in runtime/ as they aren't related to runtime at all. compiler/Codegen/Microkernels/CUDA/ is probably a good place to put them for now.

The other thing worth investigating here is bitcode - if we could get in before PTX that'd be much better and let us build our own libdevice.bc-equivalent. Getting nvcc to spit out LLVM bitcode instead of PTX would mean that we'd be able to perform linking ourselves via LLVM and avoid the need for one file per microkernel and at least somewhat control the target configuration (lots still baked in to the bitcode but much less than PTX). The object file reference attributes above would just change to .bc instead of .ptx and we'd link them just like how we link libdevice: https://github.com/google/iree/blob/21dd0aae7fd4914873ad5caa75ab10bbc40a0a09/compiler/src/iree/compiler/Dialect/HAL/Target/CUDA/CUDATarget.cpp#L102-L128

Actually producing the ptx blobs for the microkernels is going to be the difficult part and will need some build infrastructure.

What Ben says: the code organization so everything plays together is the hard (and annoying) part and things break down a lot if cutting against the grain.
This is cool work, and I'm willing to help on the build esoterica as it comes up. It's non trivial and requires a bit of thought, but mirrors a lot of what I helped put in place for the CPU targets. I'd recommend getting the actual code and layering aligned to Ben's prescription and doing the simplest possible thing on the build side (guarded by an experimental flag) and then passing off to one of us who specializes in making that stuff more tractable.

Thanks a lot for your prompt review. This is really a spike implementation that I implemented in a couple of days. It is great it started a discussion here. I would be happy if we meet up to chat about this. Thanks for showing me the dispatch infra, it looks cool! It is really useful to have multiple ptx for different targets.
Let me explain the rationale behind choosing PTX. In fact, I also prefer the bitcode :) The idea of having our own libdevice fits perfectly with our toolchain. The bitcode can be linked by llvm and the microkernels can be verified in the compile time and many more benefits. Bitcode gives us full control.
But the only reason for this project is performance, so I chose nvcc whose performance is guaranteed, unfortunately, it can only generate PTX. There is clang, it generates bitcode but I don't know whether it generates code as well as nvcc, I haven't seen any metric. nvcc is based on nvidia's proprietary llvm which is different from open source llvm what we have. Also, I don't know if clang supports the latest and greatest CUDA and GPU features :) The hopper GPU is already here, its ISA is large. So the PTX route made more sense since the purpose of this project was to use the latest CUDA codes as microkernels.
Just to give an idea about the clang vs nvcc compilation, I put their flow. We have only clang to generate bitcode that I wanted to show. The public nvcc does not generate a bitcode. Here, ptxas is nvidia ptx compiler.
input.cu --[clang]--> input.ll --[llvm]--> input.ptx  --[ptxas]--> binary.sass

input.cu --[nvcc]--> input.ptx --[ptxas]--> binary.sass

Then let me continue with this project like that: I can do benchmarks with nvcc and clang on certain CUDA codes like cutlass. If clang performs well, then we can use bitcode.

Experiments are fine, but the situation in which we require specific proprietary nvidia compilers as part of our core compilation flow is not likely to go much beyond experimental in IREE's core codebase. Having a black-box compiler in our low-level infrastructure is just like if clang passed IR to LLVM which then under the covers shells out to gcc to do codegen for specific functions - it may work, but it's not sustainable :) Nesting compiler flows like that is fine for wrapping layers to do (a user wants to compile half their code with gcc and half with clang then passes all the .o's to ld) but not really something we want in the core compiler itself.
The bitcode approach meets more of the needs we have as a compiler and will be what we want to focus real development on for sustained usage. If there are performance deltas between the proprietary compiler and LLVM those should be raised with LLVM and used to improve the compiler. But we should support both (and the linking mechanism can) but leave it to users/libraries/frameworks/etc to make the more complex decisions around compiler mixes, timelines, tradeoffs in configuration and control, etc rather than us imposing that upon all users. As we build out more extension mechanisms (like microkernels/linking) we can use these experiments as driving examples for user workflows to ensure we have the right points for hooking in. We just don't want to be the ones maintaining and supporting those :)
The custom_dispatch sample shows how to use entire PTX blobs with no changes needed - that's still the best route for "I just want to use nvcc to compile a kernel" - microkernels and mixing compilers in the same local function unit is always going to be sketchy. You can see if you can do some of your experiments using that and KISS :)

Thanks a lot for your prompt review. This is really a spike implementation that I implemented in a couple of days. It is great it started a discussion here. I would be happy if we meet up to chat about this. Thanks for showing me the dispatch infra, it looks cool! It is really useful to have multiple ptx for different targets.
Let me explain the rationale behind choosing PTX. In fact, I also prefer the bitcode :) The idea of having our own libdevice fits perfectly with our toolchain. The bitcode can be linked by llvm and the microkernels can be verified in the compile time and many more benefits. Bitcode gives us full control.
But the only reason for this project is performance, so I chose nvcc whose performance is guaranteed, unfortunately, it can only generate PTX. There is clang, it generates bitcode but I don't know whether it generates code as well as nvcc, I haven't seen any metric. nvcc is based on nvidia's proprietary llvm which is different from open source llvm what we have. Also, I don't know if clang supports the latest and greatest CUDA and GPU features :) The hopper GPU is already here, its ISA is large. So the PTX route made more sense since the purpose of this project was to use the latest CUDA codes as microkernels.
Just to give an idea about the clang vs nvcc compilation, I put their flow. We have only clang to generate bitcode that I wanted to show. The public nvcc does not generate a bitcode. Here, ptxas is nvidia ptx compiler.
input.cu --[clang]--> input.ll --[llvm]--> input.ptx  --[ptxas]--> binary.sass

input.cu --[nvcc]--> input.ptx --[ptxas]--> binary.sass

Then let me continue with this project like that: I can do benchmarks with nvcc and clang on certain CUDA codes like cutlass. If clang performs well, then we can use bitcode.

Let's review and look at results/options before committing to a path. These things have long range costs and implications, and I'd like to make the decision with facts.

I updated my PR, here are the changes:

Created a bitcode library, used clang++ to compile CUDA microkernels
Linked iree generated code to the bitcode library (no more inline PTX)
Moved CUDA microkernels to runtime/src/builtins/uGPUkernels

I still need to compare performance of nvcc vs clang++ to see if this is the best choice.
@benvanik do you think do I still need #hal.executable.object here?

I updated my PR, here are the changes:

Created a bitcode library, used clang++ to compile CUDA microkernels
Linked iree generated code to the bitcode library (no more inline PTX)
Moved CUDA microkernels to runtime/src/builtins/uGPUkernels

I still need to compare performance of nvcc vs clang++ to see if this is the best choice.
@benvanik do you think do I still need #hal.executable.object here?

Some follow up. Guray and I chatted about this. I am working on the path to call microkernels from CPU backend. Its very similar to what Guray has, just a bit more flushed out. Doesnt solve a lot of the issues w.r.t this example though. Agree with Ben, this is probably not want to use microkernels for, but I do know you want to use for something else, and this was a way for you to put in the scaffolding needed to experiment. I'd suggest instead of trying to hook this into the compiler directly, just write an .cu file and experiment with performance and microkernels you want there. We can then look into what you want the generated code to look like and how to get the compiler to hit that... Doing this in a compiler directly is harder, so would be one way to justify the investment.

Please include me in any future meetings too - I've got a lot of state on these things and don't think anyone particularly enjoys me writing up big responses after the fact :)
Agreed with Mahesh that we still want to better quantify what this route would entail as all the complex parts come when it scales beyond a single reference kernel or single target. As recommended before a way to side-step the issues for now is using the object linking support to reference external files as that can be done without needing to solve the bigger issues until ready (just point it at files on disk or embed the file as a binary blob inside of the IR from an earlier stage). We are going to end up with one way to do this kind of thing such that users and bring-your-own-codegen approaches can be done in a way consistent with what the compiler does - and that means the compiler also needs to be consistent with how it does things wherever possible (meaning if we have a story for linking custom microkernels on the CPU the CUDA side needs to follow that).
On the CPU side we've already done some work to author libraries to bitcode that are retargetable and unsurprisingly it's nearly identical to what CUDA itself does for libdevice. We will need to follow that pattern here. The two bitcode files you have in this PR, for example, differ by exactly 5 of 7652 bytes (something we see in a lot of our codegen output, too) and if you crack them open you'll see those 5 bytes are just the target-cpu and target-features strings - otherwise the entire rest of each file is identical. It's easy to ignore 8KB for now but if each new microkernel added for each new platform is 8KB then you can imagine if we had even 20 microkernels and were targeting 8 concurrent target configurations things get out of hand fast (we don't want MB of churn in the .git every time we tweak a microkernel or integrate and have a new version of LLVM that generates ever so slightly different byte patterns). In other words, we should be looking to generate a single LLVM module that is parameterized on compiler-fed values instead of stamping out an entire copy of each library for each target configuration. This is a good example of the kind of thing we need to understand more before building out infrastructure.
It's informative to take a look at how libdevice handles this - if you crack it open (llvm-dis on libdevice.10.bc) you'll see normal control flow based on placeholders populated by later stages of the compiler:
@.str.1 = private unnamed_addr constant [12 x i8] c"__CUDA_ARCH\00", align 1
define i32 @__nv_isinfd(double %a) #0 {
  %1 = call i32 @__nvvm_reflect(ptr @.str.1)
  %2 = icmp eq i32 %1, 200
  br i1 %2, label %9, label %3

For more information, see:
https://llvm.org/docs/NVPTXUsage.html#linking-with-libdevice
specifically __nvvm_reflect, which matches what we do on the CPU side during linking:
https://github.com/iree-org/iree/tree/main/runtime/src/iree/builtins/device#link-time-configuration
(as is a common saying around here: GPU and CPU have way more in common in a lot of aspects than people with experience in either side tend to think :)
This means that we shouldn't use preprocessor macros to switch code behavior but instead normal if statements conditional on a placeholder - for a concrete reason why there's ~250 such queries as above in libdevice saving them 250 copies of libdevice (400KB instead of 100MB) while having no impact on runtime performance as all of the branches are evaluated at compile-time and dead paths are stripped. There may be some very coarse reasons to fork the files - like 32-bit vs 64-bit - but it needs to be an exceedingly good reason. We can have our own __nvvm_reflect-alike that we can populate as we want. This also intersects with executable-level constants (aka specialization constants) and other runtime-based selection, and that too is solved in a way similar to the __nvvm_reflect just done at runtime instead of in the offline linker: https://github.com/google/iree/blob/b07528bfac7cc72362c82bdc7c769dec033690c0/compiler/src/iree/compiler/Dialect/HAL/IR/test/executable_ops.mlir/#L65-L92. The benefits of this kind of stuff will make more sense if we are using JIT LTO to specialize things at load-time: https://developer.nvidia.com/blog/cuda-12-0-compiler-support-for-runtime-lto-using-nvjitlink-library/ - I'm likely going to enable on the runtime side so that we can do full load-time specialization soon and that means that microkernels will be able to be conditionally selected/specialized all the way at runtime if desired so long as we wire it up right.
Incidentally, the same thing we need to do for that in the hand-authored code is what we should be doing in codegen: generate the potential paths and then prune when appropriate and parameterize much more. The more we make both the hand-authored side and the compiler-generated side the same the easier things are to maintain and scale. And it's strictly less work :)
As an aside because it can be tricky to pick apart the whys just from the dir tree, but compiler/Codegen/Microkernels/CUDA/ is where these belong - the builtins/ in the runtime are there because they are shared with the runtime (used by VMVX, etc) - these would only exist in the compiler and have no relation to the runtime. If you find yourself wanting to put things in the runtime that's a big deal so as a general rule it's best to avoid that :)
But all that said, experimenting in a lightweight way and building out the experience of how to piece together the puzzle should be the priority - we need things like the number of microkernels we estimate to exist, how they are produced, who produces them (end users, library authors, us, vendors, etc), what repo they live in (if this grows in scope to something like aitemplate then it's an entire project, vs if it's model architecture specific and belongs in some model library, vs it really is just for conv/matmul), the variance of the final compiled microkernels across different targets, etc etc, and I think what you have here as an experiment would let you do some of that before we lock into any particular path. We also need to solve this for the CPU side for all the same reasons and it's why we haven't fully finished that: it's easy to wire up flags and function calls but much more difficult to decide what those function calls should be :)
What we'll want to do is cut what lands down to the bare minimum to allow for user-specified objects to be linked in to our generated code using the same mechanism we have on the CPU side. We'll then want to experiment with what we link in. Then we can work through the goo and get things wired up for default paths. E.g., instead of trying to productionize these bitcode files right now add a flag that points at a file and adds the #hal.executable.object attrs - then you can still iterate on all the rest of the stuff and not complicate builds until we know how to mitigate some of the complexity.

It's informative to take a look at how libdevice handles this - if you crack it open (llvm-dis on libdevice.10.bc) you'll see normal control flow based on placeholders populated by later stages of the compiler:
@.str.1 = private unnamed_addr constant [12 x i8] c"__CUDA_ARCH\00", align 1
define i32 @__nv_isinfd(double %a) #0 {
  %1 = call i32 @__nvvm_reflect(ptr @.str.1)
  %2 = icmp eq i32 %1, 200
  br i1 %2, label %9, label %3

For more information, see: llvm.org/docs/NVPTXUsage.html#linking-with-libdevice specifically __nvvm_reflect, which matches what we do on the CPU side during linking: main/runtime/src/iree/builtins/device#link-time-configuration (as is a common saying around here: GPU and CPU have way more in common in a lot of aspects than people with experience in either side tend to think :)
This means that we shouldn't use preprocessor macros to switch code behavior but instead normal if statements conditional on a placeholder - for a concrete reason why there's ~250 such queries as above in libdevice saving them 250 copies of libdevice (400KB instead of 100MB) while having no impact on runtime performance as all of the branches are evaluated at compile-time and dead paths are stripped. There may be some very coarse reasons to fork the files - like 32-bit vs 64-bit - but it needs to be an exceedingly good reason. We can have our own __nvvm_reflect-alike that we can populate as we want. This also intersects with executable-level constants (aka specialization constants) and other runtime-based selection, and that too is solved in a way similar to the __nvvm_reflect just done at runtime instead of in the offline linker<EMAIL_ADDRESS>The benefits of this kind of stuff will make more sense if we are using JIT LTO to specialize things at load-time: developer.nvidia.com/blog/cuda-12-0-compiler-support-for-runtime-lto-using-nvjitlink-library - I'm likely going to enable on the runtime side so that we can do full load-time specialization soon and that means that microkernels will be able to be conditionally selected/specialized all the way at runtime if desired so long as we wire it up right.

Ha! Almost verbatim what I told Guray in our 1:1!

It's informative to take a look at how libdevice handles this - if you crack it open (llvm-dis on libdevice.10.bc) you'll see normal control flow based on placeholders populated by later stages of the compiler:
@.str.1 = private unnamed_addr constant [12 x i8] c"__CUDA_ARCH\00", align 1
define i32 @__nv_isinfd(double %a) #0 {
  %1 = call i32 @__nvvm_reflect(ptr @.str.1)
  %2 = icmp eq i32 %1, 200
  br i1 %2, label %9, label %3

For more information, see: llvm.org/docs/NVPTXUsage.html#linking-with-libdevice specifically __nvvm_reflect, which matches what we do on the CPU side during linking: main/runtime/src/iree/builtins/device#link-time-configuration (as is a common saying around here: GPU and CPU have way more in common in a lot of aspects than people with experience in either side tend to think :)
This means that we shouldn't use preprocessor macros to switch code behavior but instead normal if statements conditional on a placeholder - for a concrete reason why there's ~250 such queries as above in libdevice saving them 250 copies of libdevice (400KB instead of 100MB) while having no impact on runtime performance as all of the branches are evaluated at compile-time and dead paths are stripped. There may be some very coarse reasons to fork the files - like 32-bit vs 64-bit - but it needs to be an exceedingly good reason. We can have our own __nvvm_reflect-alike that we can populate as we want. This also intersects with executable-level constants (aka specialization constants) and other runtime-based selection, and that too is solved in a way similar to the __nvvm_reflect just done at runtime instead of in the offline linker<EMAIL_ADDRESS>The benefits of this kind of stuff will make more sense if we are using JIT LTO to specialize things at load-time: developer.nvidia.com/blog/cuda-12-0-compiler-support-for-runtime-lto-using-nvjitlink-library - I'm likely going to enable on the runtime side so that we can do full load-time specialization soon and that means that microkernels will be able to be conditionally selected/specialized all the way at runtime if desired so long as we wire it up right.

Ha! Almost verbatim what I told Guray in our 1:1!

@ThomasRaoux There's a lot of what Ben and Mahesh are saying that matches what I was referring to with you today about the way to get to a concrete design on this stuff. I think that some lighter weight prototyping to arrive at the minimal microkernel surface and interface is probably the more interesting thing (and can be prototyped in C) vs the plumbing to make it all work in one step.

It's informative to take a look at how libdevice handles this - if you crack it open (llvm-dis on libdevice.10.bc) you'll see normal control flow based on placeholders populated by later stages of the compiler:
@.str.1 = private unnamed_addr constant [12 x i8] c"__CUDA_ARCH\00", align 1
define i32 @__nv_isinfd(double %a) #0 {
  %1 = call i32 @__nvvm_reflect(ptr @.str.1)
  %2 = icmp eq i32 %1, 200
  br i1 %2, label %9, label %3

For more information, see: llvm.org/docs/NVPTXUsage.html#linking-with-libdevice specifically __nvvm_reflect, which matches what we do on the CPU side during linking: main/runtime/src/iree/builtins/device#link-time-configuration (as is a common saying around here: GPU and CPU have way more in common in a lot of aspects than people with experience in either side tend to think :)
This means that we shouldn't use preprocessor macros to switch code behavior but instead normal if statements conditional on a placeholder - for a concrete reason why there's ~250 such queries as above in libdevice saving them 250 copies of libdevice (400KB instead of 100MB) while having no impact on runtime performance as all of the branches are evaluated at compile-time and dead paths are stripped. There may be some very coarse reasons to fork the files - like 32-bit vs 64-bit - but it needs to be an exceedingly good reason. We can have our own __nvvm_reflect-alike that we can populate as we want. This also intersects with executable-level constants (aka specialization constants) and other runtime-based selection, and that too is solved in a way similar to the __nvvm_reflect just done at runtime instead of in the offline linker<EMAIL_ADDRESS>The benefits of this kind of stuff will make more sense if we are using JIT LTO to specialize things at load-time: developer.nvidia.com/blog/cuda-12-0-compiler-support-for-runtime-lto-using-nvjitlink-library - I'm likely going to enable on the runtime side so that we can do full load-time specialization soon and that means that microkernels will be able to be conditionally selected/specialized all the way at runtime if desired so long as we wire it up right.

Ha! Almost verbatim what I told Guray in our 1:1!

@ThomasRaoux There's a lot of what Ben and Mahesh are saying that matches what I was referring to with you today about the way to get to a concrete design on this stuff. I think that some lighter weight prototyping to arrive at the minimal microkernel surface and interface is probably the more interesting thing (and can be prototyped in C) vs the plumbing to make it all work in one step.

That makes sense. I'll talk to Guray tomorrow and we'll figure out a lighter version of the prototype.
For the linking part, note that even with ptx we can wrap it in an llvm bc file and do linking the same way we handle libdevice. How we generate the code is a separate problem and out of scope for the first prototype.

@grypp might be useful for you to track https://github.com/iree-org/iree/pull/12026 . That bsaically does a lot of what you have here. For now just track it, once I land that you can rebase on top of that PR.

Related to this, I've been experimenting with building clang as part of our compiler build - it's an extra ~3mins on my machine, but if people are going to start going hog wild with microkernels it may be the only option. We'd build clang ourselves (like we do lld), invoke that as part of cmake with a very constrained environment, have it produce the bitcode files we need for use by the compiler, and then not have to check in bitcode. It'd not change any of the above with respect to what kind of code we put in the thing we're compiling (still needs to be parameterized for compile/link/runtime-time so we don't invoke clang 10000x times), but would solve the .git pain for both CPU and GPU. I'll keep fiddling with it.

@benvanik using the __nvvm_reflect type makes sense, @MaheshRavishankar  mentioned exactly the same thing. I will implement a prototype for this. As sm_80 is server gpu I did not consider MB of the bitcode. But why not reduce size/number of bitcode if it is possible, I am going to include this in my prototype. Thanks!
Nevertheless, I envision the microkernel code of sm_80 vs sm_90 will be significantly different.

I understand this is a draft, but would be really good to use a uniform approach for all micro kernel hand off. Lets chat about this offline.

Have all the new ops landed? It wasn't the case when this started and the point of the prototype is to figure out the pieces specific to GPU. It would definitely move to using the common ops to land.

Yup. All the ops have landed and I am connecting them to vmvx e2e now. There still might be some changes to the specifics of the op. So this has to tag along behind the micro kernel work already in flight before it can land. Also I think the explicit recommendation was to not try to do this in the compiler first, but rather do this in just a CUDA kernel outside IREE. You should be able to write/evaluate micro kernels completely independent of IREE

Yup. All the ops have landed and I am connecting them to vmvx e2e now. There still might be some changes to the specifics of the op.

great, perfect timing.

So this has to tag along behind the micro kernel work already in flight before it can land.

yep

Also I think the explicit recommendation was to not try to do this in the compiler first, but rather do this in just a CUDA kernel outside IREE. You should be able to write/evaluate micro kernels completely independent of IREE

I don't want to speak for Guray but he has been mixing pure cuda and compiler for experiments. I think giving him the freedom to experiment is important so I don't think we need to change the course of actions at this point.

great if there's progress being made - experiments are awesome and we need more of them - they just don't need to land in main :)

There's been a lot of discussion here so probably worth summarizing:
Experimenting with microkernels is interesting, infrastructure for microkernels is interesting, user-serviceable features for making microkernels possible to integrate end-to-end without lots of code changes is interesting, evaluating what cutlass is doing and how its techniques may help us author our own microkernels sustainably or improve our codegen is interesting, but compiling cutlass kernels to ptx and then splicing them into codegen results as part of the core compiler flow is not a production path we'll support. Doesn't mean users can't and libraries layered on top of IREE can't but it's not a piece of engineering we want in the compiler.

@ThomasRaoux

However we can and will want to use cutlass based group level functions by explicitly replacing linalg.matmul by a micro-kernel kind of op referencing to a cutlass based kernel that would include extra metadata like the tile size.
so the proposal is to map linalg.matmul style to a library call that is internally based on cutlass instantiations?

@ThomasRaoux

However we can and will want to use cutlass based group level functions by explicitly replacing linalg.matmul by a micro-kernel kind of op referencing to a cutlass based kernel that would include extra metadata like the tile size.

so the proposal is to map linalg.matmul style ops with a library call that is internally based on cutlass instantiations?

Correct, the library call would be a just wrapper around an instantiation of threadblock level cutlass function.
We would pre-compile (to ptx or llvm ir) some of those functions for a few sets of tile sizes/pipeline depth. Then those can replace linalg.matmul op after tiling to block level. This allows us to use cutlass while doing codegen for the rest of the kernel which may include anything we want to fuse.

Closing stale PR.


Selecting and then hovering over a sprite in the viewport produces error stream in output log and console

Godot version:

38284bc
OS/device including version:

Windows 7
Issue description:

Clicking a sprite in the 2d viewport and then hovering/moving your mouse on top of the sprite produces a stream of errors in both the output and the console as you move.
An example error in the output log reads:
core\image.cpp:1950 - Index p_x="671" out of size (width=64)
An example error in the console reads:
ERROR: Image::get_pixel: Index p_x=671 out of size (width=64)
At: core\image.cpp:1950
It is similar to #18229 but Region does not have to be enabled this time to achieve the error in fact enabling region still produces an error even after the PR merge.
Steps to reproduce:

Add sprite node with texture
Select the sprite in the viewport
Hover and move your mouse over the sprite for a bit
Check the console and Output log

Minimal reproduction project:

this error has occurred since new inspector.


Snap not refreshing and showing old version

Do you have any idea why the snap doesn't refresh on my system?
It just shows that there are no updates?
user@jenkins:~$ sudo snap refresh wekan
snap "wekan" has no updates available

user@jenkins:~$ snap info  wekan
name:      wekan
summary:   The open-source Trello-like kanban
publisher: xet7
description: |
  Wekan is an open-source and collaborative kanban board application.

  Whether you’re maintaining a personal todo list, planning your holidays with
  some friends, or working in a team on your next revolutionary idea, Kanban
  boards are an unbeatable tool to keep your things organized. They give you a
  visual overview of the current state of your project, and make you productive
  by allowing you to focus on the few items that matter the most.
  Depending on target environment, some configuration settings might need to be
  adjusted.
  For full list of configuration options call:
  $ wekan.help
snap-id: jtpboSYvTCEyHoutkkRo1SI9ioSMOUb3
commands:
  - wekan.database-backup
  - wekan.database-list-backups
  - wekan.database-restore
  - wekan.help
services:
  wekan.mongodb: simple, enabled, active
  wekan:         simple, enabled, active
tracking:        stable
installed:       0.63-9-gf7ef629 (103) 125MB -
refreshed:       2018-01-12 03:41:06 +0100 CET
channels:
  stable:        0.63-9-gf7ef629  (103) 125MB -
  candidate:     0.63-9-gf7ef629  (103) 125MB -
  beta:          0.63-9-gf7ef629  (103) 125MB -
  edge:          0.63-15-g7963171 (106) 125MB -

yes, snap is failing store review as it has handling symlink outside of the snap package, I'm trying to address this with following pull request:
https://github.com/wekan/wekan/pull/1469

Cool thanks! I tried to refresh it, but it's still not updateing. Probably I have to wait until its published i think?

@lichtamberg
Yes, it did take about 15min to build ubuntu snap package, upload it to snap store, and then I added changeslog and released it.
Now it's released, you can try refreshing again.

Thaaaanks so much! Worked fine! ❤


InstaDapp INST/ETH Strategy

Intro
InstaDApp is a smart wallet with an intuitive interface built on top of popular DeFi projects like MakerDAO, Compound, Uniswap, etc. for managing assets. It’s optimized for users lacking advanced technical or financial experience.
InstaDApp was release very recently, and has quickly climbed to #3 on defi pulse with $8B in TVL.
The INST token is their native governance token. The liquidity for INST is on uni v3, in an INST/ETH pair.
Strategy

User deposits ETH and INST on Pickle
Pickle takes the ETH and INST and deposits it in the InstaDApp protocol, which puts it in the automatically managed INST/ETH v3 LP.
Rewards are paid out once a week by InstaDApp. Pickle harvests rewards.
Pickle sells half of INST rewards for ETH, deposits into InstaDApp again.

APY and target TVL
INST reward APR (paid out weekly) is currently 334%. With Pickle’s 20% performance fee and a Strategist fee of 7.5%, the base APR after accounting for fees is:
334*(1-0.275) = 242% Base APR
Compounded weekly, the APY comes out to 964%
The TVL of the INST/ETH pool is $9m. This is expected to grow, as InstaDApp has only launched recently. With a good marketing push, this jar can target to have a TVL of $1-2m.
Looking forward to hear what you guys think!

Thanks again for the great idea @icecreamman8! InstaDapp has certainly been growing at a very impressive rate - I've personally farmed INST/ETH myself.
The APRs and TVL look quite good for the INST/ETH pair. However, the weekly claiming is a big issue which we don't currently have a solution to yet, and so I think that a jar for this is unfortunately infeasible. Per our current contract structure, a user depositing on Day 1 would receive the same rewards as a user depositing on Day 7, meaning that it's massively susceptible to sandwich attacks. This is also the reason we haven't created Jars for Balancer or BarnBridge, for example.
I also wanted to clarify that the strategist fee would be available only where significant changes to the strategy contracts were made. For example, adapting the ALCX/ETH strategy to farm another pool2 pair would not constitute a large enough change to warrant the fee. However, if you were to find a solution to the weekly epochs of Instadapp, that would certainly be enough!

Maybe a time window could work wherein people could deposit, and they can't deposit outside of that window, but could queue their deposits outside of it.
This would need a pretty big disclaimer but might be an alright bandaid fix while something more sophisticated would eventually replace it.

This would need a pretty big disclaimer but might be an alright bandaid fix while something more sophisticated would eventually replace it.

If people cannot economically attack the jar by getting rewards they're not entitled to, that is enough to satisfy the requirements. As long as there are no UI bandaid fixes, that would do.


VSC debugger errors out with ts_helpers.js not found

When trying to run debugger in VSC with stopOnEntry: true debugger throws the following error and stops.
Unable to open 'ts_helpers.js': File not found (file:///data/data/com.appxxx/files/internal/ts_helpers.js).

I’m not sure where this path is set so i looked in the file systems and found a couple of similar folders
/home/xxx/dev/appxxx/platforms/android/app/build/intermediaries/assets/debug/internal
/home/xxx/dev/appxxx/platforms/android/app/src/main/assets/internal
When VSC shows the error it also offers to create the missing file. When clicked it also errors out with the “Permissions denied” error.
I’ve changed permissions on the above folders and contained files to 777 (wide open to all) but with the same result.
Setting stopOnEntry: false resolves the problem but then i miss some early breakpoints.
I’ve tried everything i could think of and Google is not being helpful on this matter.
Please help.
Thanks in advance.

Also if i ignore the error messages above and attempt to walk through the application in debugger i also get bundle.js not found error.  Searching for that file yield the following folders
/home/zzz/dev/appxxx/platforms/android/app/build/intermediates/assets/debug/app/bundle.js
/home/zzz/dev/appxxx/platforms/android/app/src/main/assets/app/bundle.js
changing file permissions to 777 does not change anything.  it appears that the debugger is looking for these files in a different place but i have no idea where these path settings are specified.

It's a Nativescript core / Typescript app.  What other info do you need?

Can you share your launch config?

{
            "name": "Launch on Android",
            "type": "nativescript",
            "request": "launch",
            "platform": "android",
            "appRoot": "${workspaceRoot}",
            "sourceMaps": true,
            "stopOnEntry": true,
            "watch": true,
            "sourceMapPathOverrides": {
                "webpack:///*": "${workspaceRoot}/app/*"
            },
            "tnsArgs": [
            "--bundle"
            ]
        },

I've reinstalled everything again.  Reran nativescript-dev-webpack update scripts that generated new webpack config file.  I also tried without the --bundle option.  The same result.  Unable to open ts_helpers.js.    If i ignore the error and continue it works sometimes but sometimes debugger crashes.
I can be on skype if you'd like a more real time feedback.

The debugger crash is reproduceable.  It happens on any file change after the initial debugger launch and is caused by topmost().currentEntry being null when trying to navigate to a page.

Perhaps its a problem with the nativescript plugin with VSC.  I'll try posting there as well.


Labels metadata example URL does not work

The example URL for the labels API does not work. It appears to be using a made up label:
https://[baseURI\]/metadata/Labels(Id='@SVC\_ODataLabelFile:Label1',Language='en-us')
None of the components of the URL, ("@SVC", "_ODataLabelFile", "Label1"(, are explained, so finding appropriate substitutions is difficult.
Please change the example to something that will fetch a label that actually does exist in the base product.
eg.
How do I get the label that I would get if I used the "@ApplicationPlatform:EmptyFileName" markup from x++?
If I had that example, then I would expect the URL to contain "ApplicationPlatform" and "EmptyFileName", which I would then be able to substitute for my own label details.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 133cc363-a550-5cbf-622a-f0bd3da87eb6
Version Independent ID: a7b1ce5d-ba20-b723-e3b0-23a9b79cde9d
Content: Service endpoints overview - Finance & Operations | Dynamics 365
Content Source: articles/fin-ops-core/dev-itpro/data-entities/services-home-page.md
Service: dynamics-ax-platform
Product: ****
Technology: ****
GitHub Login: @Sunil-Garg
Microsoft Alias: sunilg

@mattiferg, thanks for the feedback.
@Sunil-Garg, please review.

Bug #477428 logged to track this issue.


In extensions.yaml, docstrings say "int32ean" in multiple places

"int32ean" -> "boolean" ?
This seems like a find-and-replace accident.
    doc: int32ean flag indicating data preprocessing before main EXTRACT function

Related: are these attributes supposed to be boolean?


Toggle hint is inserted into code blocks when clicking inside them

Describe the bug
context
When a code-block is nested inside a toggle region and one clicks inside this block the toggle hint, i.e. Click to show or Click to hide is inserted into the beginning of the block
These two screenshots are form the sphinx-togglebutton read the docs page
Before clicking into the code block

And after

Reproduce the bug

Go to https://sphinx-togglebutton.readthedocs.io/en/latest/ for example
Click the first toggle button
Click inside the revealed code block

List your environment
No response

closed by https://github.com/executablebooks/sphinx-togglebutton/pull/45


IMvcBuilder interface is inflexible

Most IServiceCollection extensions do the intuitive thing and return the passed IServiceCollection. However the minimal ("Core") MVC extension methods, AddMvcCore() in particular, return an IMvcBuilder implementation with a single property of type IServiceCollection. This imposes an unnatural order on Add...() methods.
For example the MvcMinimalSample.Web project chains extension methods as follows:
            services
                .AddMvcCore()
                .AddAuthorization()
                .AddFormatterMappings(m => m.SetMediaTypeMappingForFormat("js", new MediaTypeHeaderValue("application/json")))
                .AddJsonFormatters(j => j.Formatting = Formatting.Indented);

This order is imposed and only the AddAuthorization() method can move before AddMvcCore(). So where would a user call AddLogging()? The working options are:
            services
                .AddLogging()
                .AddMvcCore()
...

or
...
                .AddJsonFormatters(j => j.Formatting = Formatting.Indented)
                .Services.AddLogging();

A user trying to find the correct method name would likely add a period after AddJsonFormatters(), observe the IntelliSense suggestions, and scratch their heads, wondering what using or package they forgot.
Suggest changing IMvcBuilder to inherit from IServiceCollection. At least then adding new services to the end would work -- some flexibility restored. This approach would also continue to hide the low-level extension methods that are not needed when using the full AddMvc().

I'm confused. AddMvcCore() takes in an IServiceCollection and returns an IMvcBuilder. Every other MVC builder extension both takes in and returns an IMvcBuilder.
What doesn't work?
BTW making IMvcBuilder derive from IServiceCollection would completely break the model - every other service extension method would show up.

Every other MVC builder extension both takes in and returns an IMvcBuilder.

No. Only low-level extensions show up e.g. AddRazorViewEngine(). These are mostly additions AddMvc() provides in one call when using the whole thing. However none of the high-level IServiceCollection extensions are available e.g. AddLogging() or our own AddMvcLocalization() and AddWebApiConventions().

every other service extension method would show up.

What's wrong with that? It closely matches the model everywhere else e.g. AddMvc() returns the IServiceProvider and thus can be chained before or after AddLogging(). And it would still allow the low-level builder extensions to be chained -- as long as those remain together.
I know of no IServiceCollection extension except AddMvcCore() that returns anything but the IServiceCollection.

Missed a question...

What doesn't work?

Adding logging or any other IServiceCollection extension anywhere in the chain after AddMvcCore(). As shown in my description, AddLogging() works if placed first or if the user tries the Services property (not particularly discoverable) to switch back to the expected chain.

I'm just guessing, but I don't think the work is entirely done. It might be better to understand the goals of the design and its current state first.

Regarding AddLogging, that's not an MVC method - why should you be able to chain it to AddMvc??

why should you be able to chain it to AddMvc??

You can chain AddLogging() (or AddStaticFiles() or whatever from our larger system) after AddMvc(). The inconsistency / problem here is that doesn't work with AddMvcCore().

There are big changes coming to how this all works. Also, AddMvc is not meant to be the same as AddMvcCore.

There are big changes coming to how this all works

So much this. It will be consistent once we update the other parts of the system.


Add more information on the backend technical details to the wiki

I think you just wrote a bunch of this in response to my discord questions :)


add video support

friend with https://github.com/julesvirallinen/digitalgarden-dev/pull/1

any updates?


Squid Proxy „Before Auth“ is missing in GUI

Sorry for my Bad english. I Even do not know if this is the right Place for my concern.
With the current Version of opnsense its not possible to get Windows Updates working if Proxy transparent Mode is selected. You get an error Message(0x801901f7)
To get this 100% working the only way is to modify the „before auth“ in squid. But this field is not available in opnsense. Is there a change to get this Problem fixed?
Read this:
https://wiki.squid-cache.org/SquidFaq/WindowsUpdate
This is the solution for pfsense. And this works without any problems in pfsense!. I have tested it for one year of using pfsense.
PFsense  -> Menu Package -> Proxy Server -> General Settings -> Show Advanced Options -> "Before Auth": but the code in this field:
code:
acl DiscoverSNIHost at_step SslBump1
acl NoSSLIntercept ssl::server_name_regex microsoft.com
acl NoSSLIntercept ssl::server_name_regex .microsoft.com
acl NoSSLIntercept ssl::server_name_regex windowsupdate.com
acl NoSSLIntercept ssl::server_name_regex .windowsupdate.com
acl NoSSLIntercept ssl::server_name_regex update.microsoft.com.akadns.net
ssl_bump splice NoSSLIntercept
ssl_bump peek DiscoverSNIHost
ssl_bump bump all
acl BrokenButTrustedServers dstdomain download.microsoft.com
acl BrokenButTrustedServers dstdomain update.microsoft.com
acl BrokenButTrustedServers dstdomain update.microsoft.com.akadns.net
acl BrokenButTrustedServers dstdomain update.microsoft.com.nsatc.net
acl DomainMismatch ssl_error SQUID_X509_V_ERR_DOMAIN_MISMATCH
sslproxy_cert_error allow BrokenButTrustedServers DomainMismatch
sslproxy_cert_error deny all

@opnsenseuser Something is probably wrong with your git branch as you are having more than 250 commits on this branch which leads to a not reviewable diff.  This patch would also allow MITM attacks and therefore should be avoided (for example it would allow a connection to my server because it has a valid certificate and the only issue is that the domain would not match).


Credentials is private

After running cargo add qbit-rs and trying to use use qbit_rs::{Qbit, Credential} I get an error:
 --> src/qbit_manager.rs:4:21
   |
4  | use qbit_rs::{Qbit, Credential};
   |                     ^^^^^^^^^^ private struct
   |
note: the struct `Credential` is defined here
  --> /cargo/registry/src/index.crates.io-6f17d22bba15001f/qbit-rs-0.3.7/src/lib.rs:26:21
   |
26 | use crate::{ext::*, model::*};
   |                     ^^^^^

Any ideas?

Try use qbit::model::Credential.

Seems to have done it, thanks :D


value-attribute not working, returning the full object

Version
@nuxthq/ui: v2.6.0
nuxt: v3.6.3
Reproduction Link
https://stackblitz.com/edit/nuxtlabs-ui-zqbvaf?file=app.vue
Steps to reproduce
Juste copy paste the doc exemple and show the data
What is Expected?
The value to be only the property specify in value-attribute props
What is actually happening?
The whole object is return

Sorry, the docs were missing the Edge badge on this feature: https://ui.nuxtlabs.com/forms/select-menu#objects
It hasn't been released yet but you can still use the Edge version: https://ui.nuxtlabs.com/getting-started/installation#edge

Thanks a lot!


[NIFI-13177] ensure consistent typography rendering

@rfellows thanks for the updates and the PR. These are great!


Processing Long Audioclips

Currently, in the documentation of ChangeSampleRate in the AudioUtils, it's noted that it currently causes an issue with really long audio Inputs.
I was wondering what, specifically, the root issue is, if it's known already? I'm probably gonna end up hacking together some sort of a solution for this problem for my own project, but it'd sure be nice to know where to start at least.

Not sure what you are referring to. I can't find such comment in ChangeSampleRate function.
https://github.com/Macoron/whisper.unity/blob/25c8d267cf219f6a6728c6b35d6566c4a4d1aefd/Packages/com.whisper.unity/Runtime/Utils/AudioUtils.cs#L43-L66

Ah, so it seems. That must have been my own comment. Whoops.
Regardless, I've made sure that my working code matches the project, and the issue persists.
When attempting to process a ~28minute .mp3 file, I end up with an 'out of bounds' error at:
dst[i] = Mathf.Lerp(src[low], src[low + 1], dif);
I've tested this with a few other files (All MP3 files, it should be noted), that length or longer, and it still has an issue. Not sure what the lower bound of the issue is, but it seems consistent on my end.
Might be me and my hardware, or it might not be. Either way, it might be worth a look.

I've reproduced this issue locally. Looks like some floating point calculation error.
I updated latest master with a fix. Clone latest version and check if it works for you.

Yep, the adjustment made perfectly addressed the issue.
Cheers!


[PL-52014] Update delegate docs on number of parallel executions

Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.
Description

Please describe your changes: Update delegate docs on the number of parallel executions
Jira/GitHub Issue numbers (if any): PL-52014
Preview links/images (Internal contributors only):

https://667b1819d506d3273137e8d9--harness-developer.netlify.app/docs/faqs/harness-delegate-faqs#what-are-the-delegate-system-requirements
https://667b1819d506d3273137e8d9--harness-developer.netlify.app/docs/platform/delegates/delegate-concepts/delegate-overview#delegate-sizes
https://667b1819d506d3273137e8d9--harness-developer.netlify.app/docs/platform/delegates/delegate-concepts/delegate-requirements

PR lifecycle
We aim to merge PRs within one week or less, but delays happen sometimes.
If your PR is open longer than two weeks without any human activity, please tag a code owner in a comment.
PRs must meet these requirements to be merged:

[x] Successful preview build.
[x] Code owner review.
[x] No merge conflicts.
[ ] Release notes/new features docs: Feature/version released to at least one prod environment.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://667b13899da3d05767f59e81--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://667b1819d506d3273137e8d9--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://669a6b4c9b863dee034ae1ed--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://669a70938ae55d4b8d925bb5--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://669a713ce2b4394ad6078296--harness-developer.netlify.app


'' character consumed but not used

Heyo! Thanks for library!
Found an issue while playing around; The \ character appears to be consumed in the background without actually printing/appending to the line editor.
Minimum example:
package main

import (
	"fmt"
	"log"

	"github.com/reeflective/readline"
)

func main() {
	rl := readline.NewShell()

	rl.Prompt.Primary(func() string {
		return " > "
	})

	for {
		line, err := rl.Readline()
		if err != nil {
			if err.Error() == "interrupt" {
				continue
			}
			log.Fatal(err)
		}

		if len(line) == 0 {
			continue
		}

		fmt.Println(line)
	}
}

When I type \, it just goes off into the ether. The final println doesn't contain it either.
Verified that every other key, including it's shifted character (pipe/| on US keyboard) is working as expected.
Let me know if you need any additional info!

Just to check, I printed out all the binds:
Mode : emacs
        Key : \
                Is Macro : false
                Action   : self-insert
Mode : emacs-standard
        Key : \
                Is Macro : false
                Action   : self-insert
Mode : emacs-meta
        Key : \
                Is Macro : false
                Action   : delete-horizontal-space
Mode : vi-insert
        Key : \
                Is Macro : false
                Action   : self-insert

Would the emacs-meta be the problem here?

Thanks a lot for the ouput and explanations.
Looking at this at the moment.

Are you using the latest release ?

I believe so, yes:
module codeberg.org/distek/testthingshere

go 1.17

require github.com/reeflective/readline v1.0.4

require (
	github.com/rivo/uniseg v0.4.4 // indirect
	golang.org/x/sys v0.8.0 // indirect
	golang.org/x/term v0.8.0 // indirect
)

This is bizarre. (I have another issue) but not this one.
Does the backspace key works fine ?
Testing this on your program, without any .inputrc file loaded.
What is your system/shell/terminal, if I may ?

Actually, no! Backspace is technically working but not updating the line editor with the changes, but the final result is as expected.
System (linux):
└[INS]─> uname -r
6.3.4-arch1-1

Shell:
└[INS]─> bash --version
GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

And terminal is foot: https://codeberg.org/dnkl
└[INS]─> foot --version
foot version: 1.14.0 +pgo +ime +graphemes -assertions

Just to check, I printed out all the binds:
Mode : emacs
        Key : \
                Is Macro : false
                Action   : self-insert
Mode : emacs-standard
        Key : \
                Is Macro : false
                Action   : self-insert
Mode : emacs-meta
        Key : \
                Is Macro : false
                Action   : delete-horizontal-space
Mode : vi-insert
        Key : \
                Is Macro : false
                Action   : self-insert

Would the emacs-meta be the problem here?

Sorry, forgot to answer to this.
No its likely not due to this, as the standard emacs and emacs-standard keyboards are the same (they are copies of each other, and emacs-ctlx and emacs-meta are subsets of the emacs one: `emacs is a combination of both.)

I'm facing a problem, I don't run Wayland on my machine, so I'm not able to solve this right now.
On Xterm, your program prints and returns the backslashes.

On all my terminal emulators, I get the same issue.
One moment.

My word that was rough.
So I ended up spinning up a docker container and throwing the code in there. The backslash works as expected, so it's something higher on my system that's causing the issue.
Thanks for the fast response and help!
The backspace is still not working properly, but I'm assuming you're looking into that. If not, lemme know and I can throw up another issue.

Yes backspace solved, its was a problem with clearing line. Pushing a fix and release for this.
If you end up finding the issue on your system and you deem it relevant, to hesitate to come back !
This project is rather young and not widespread/tested yet, it must be widely tested before being sure of everything (and maintainers sleeping at nights !)

Released with bug fix: https://github.com/reeflective/readline/releases/tag/v0.1.4

Yes backspace solved, its was a problem with clearing line. Pushing a fix and release for this. If you end up finding the issue on your system and you deem it relevant, to hesitate to come back !

Will do!

This project is rather young and not widespread/tested yet, it must be widely tested before being sure of everything (and maintainers sleeping at nights !)

I'll be testing the heck out of it: Writing my own shell for fun (and maybe prod use)! :)

I'll be testing the heck out of it: Writing my own shell for fun (and maybe prod use)! :)

Bold but great endeavour, good luck.


Better CodeQL analysis

Running experimental and custom queries from the advance-security repo to produce better code-scanning results.

The current version of the CodeQL setup is from GitHub staff member @NickLiffen, and I'm not eager to replace it with something that isn't explained and produces seeminly the same results in the report as the current scan settings. Please provide me with some background as to why this change should be merged, e.g. a blog post from GitHub or some other credible source.


Let ts-ignore ignore suggestions

Having checkJs on a JS file can potentially create many suggestions. One of the suggested codefixes is "add // @ts-ignore", but this does nothing. Making ts-ignore work with suggestions is one fix.
Two others are

Do not suggest ts-ignore for suggestions.
Allow (VS Code?) users to selectively turn off specific errors.

Of course, there is

Do nothing. The small suggestion … isn't that intrusive and (currently) is explicitly requested by checkJs users, who will not be bothered by the bogus ts-ignore suggestion.

Not suggesting ts-ignore looks pretty hard; I followed the trail back to CodeFixRequestArgs in protocol.ts; it only provides a list of errorCodes, but not whether they originated from a suggestion or an error.

Yep, after consulting with @sheetalkamat, it looks like changing CodeFixRequestArgs requires a change in VS Code as well. I'll bring this up next time we meet.

This should probably wait on #19139. We don't want people adding // @ts-ignore to disable a suggestion and missing out on actual errors.

I agree; in any case I think not suggesting ts-ignore is the better option since preliminary evidence [1] suggests that the noImplicitAny suggestions are not that obtrusive.
[1] that is, talking to @uniqueiniquity, who has been using the new suggestions.


proposal: x/sys/cpu: expose runtime AMD64 microarchitecture level

In package golang.org/x/sys/cpu add an int symbol [0-4] (0 if not AMD64) that exposes the AMD64 microarchitecture level of the machine running the program.
References:

https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels
https://go.dev/doc/go1.18#amd64
github.com/klauspost/cpuid/v2 CPUInfo.X64Level

Worth noting that this information is already available as a build tag, like //go:build amd64.v3. Are there cases where an integer value would help?
Also, would this be a constant or a variable? I imagine a constant would be better, given that it's known at build time.

@mvdan If I understand correctly the value is not known at build time.  At build time we know the minimum supported microarchitecture level, from the GOAMD64 environment variable.  But at run time we know the actual microarchitecture level, which must be at least as high but may be higher.  Similarly, a build tag doesn't help here.

Ah, this api would actually fetch the level of the machine running the program, which might well be higher than the one the binary was built for. I see the distinction now.

A use case for this is selecting one among multiple binaries compiled for different GOAMD64 values. I currently use klauspost/cpuid for this in https://github.com/CAFxX/mgo.


Remove temporary binding hack

I had to resort to private reflection in https://github.com/Azure/azure-webjobs-sdk-script/pull/75 to get access to the binding data we need. Need to figure out the right long term approach, whether to expose this info publically from the core SDK.

Fixed via https://github.com/Azure/azure-webjobs-sdk-script/pull/128.


Add option to sync blood pressure data only, without weight data

Is it possible to sync blood pressure data only?  I wish to import years of historic BP data from Withings to Garmin, but would rather not create duplicate weight readings if possible

Never mind, I hacked it to skip the weight data upload.  Not good enough for a PR as I'm not familiar with Python

Never mind, I hacked it to skip the weight data upload. Not good enough for a PR as I'm not familiar with Python

hello! can you please share how you managed to skup the weight data upload? thanks a lot


Bump version to 1.0.1

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) and found it was in an excellent condition.

@conda-forge-admin, please add noarch: python

Should we convert this to noarch: python?

Thanks @nehaljwani.


Feature Request : Use of Tokenizer without indexing

Hi,
Is it possible to just use tokenizer to tokenize a string? Currently, I have to first create an index and then use  index.tokenSet.toArray() to get a list of unique words in an array.
Thanks
Kapil

It is possible to use lunr.tokenizer without first creating an index:
var tokens = lunr.tokenizer("some string")

then use index.tokenSet.toArray() to get a list of unique words in an array

lunr.tokenizer does not return a unique list of words though, it just converts a string into tokens, there may be duplicates:
lunr.tokenizer("foo foo foo").length // 3

You could certainly use lunr.TokenSet to get a unique set of the tokens returned by lunr.tokenizer but I'm sure you can think of a simpler way without having to use Lunr.

Thank you Oliver.


hot : true and browser refreshing

With the current release, hot reloading didn't fully work for my setup (no automatic browser refreshing) until, after finding an old issue on webpack-dev-server, I removed the hot : true option from webpack.config.js. Apparently it conflicted somehow with webpack.HotModuleReplacementPlugin().
If hot reloading and browser refreshing currently works for you, could you please check if it still works after removing hot : true? If so, it may be better to remove it for compatibility with some setups.

/cc @maximemangel
Am 03.10.2017 13:01 schrieb "piaste"<EMAIL_ADDRESS>
With the current release, hot reloading didn't fully work for my setup (no
automatic browser refreshing) until, after finding an old issue on
webpack-dev-server
https://github.com/webpack/webpack-dev-server/issues/206, I removed the hot
: true option from webpack.config.js. Apparently it conflicted somehow
with webpack.HotModuleReplacementPlugin().
If hot reloading and browser refreshing currently works for you, could
you please check if it still works after removing hot : true? If so, it
may be better for compatibility to remove it.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/SAFE-Stack/SAFE-BookStore/issues/197, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AADgNL3jtt4pSL6nD5oaUAXIQO81lbAUks5sohQGgaJpZM4Pr75c
.

@piaste Do you have webpack-dev-server installed globally ?
Removing the hot: true do not work for me. Can you please, try with this version: https://github.com/SAFE-Stack/SAFE-BookStore/pull/198

@MangelMaxime

Do you have webpack-dev-server installed globally ?

No. I have an older version of webpack installed globally, but no webpack-dev-server.

Removing the hot: true do not work for me. Can you please, try with this version: #198

With those changes it doesn't work for me.

Can you please try to remove the global webpack ?
We need to launch the webpack-dev-server with the hot: true or -- hot option set. Otherwise, it will not start the HMR. You probably have something on your system that we don't have... I tested it on 3 computers, and several projects without problem... Don't really know how to debug it for you here.

@piaste Do you see [WDS] Hot Module Replacement enabled. in your console ?
And also, do you have any error in the network panel ?

@MangelMaxime
After uninstalling the global Webpack, the CLI parameter (from your PR) triggers refreshing; the original still won't refresh, however.
This is the output when it doesn't work (has been the same for every configuration I tried):
Initial state: Object
client?cd17:77 [WDS] Hot Module Replacement enabled.
program.fs:72 New message: Object
program.fs:74 Updated state: Object
program.fs:72 New message: Object
program.fs:74 Updated state: Object
2client?cd17:80 [WDS] App updated. Recompiling...
client?cd17:212 [WDS] App hot update...
log.js:23 [HMR] Checking for updates on the server...
log.js:23 [HMR] Updated modules:
log.js:23 [HMR]  - ./pages/WishList.fs
log.js:23 [HMR]  - ./App.fs
log.js:23 [HMR] App is up to date.

Honestly, after I fixed it on my end I sort of expected the hot = true option must have been redundant in the presence of HMR, and that removing it would only smooth things. Didn't think it would open a rabbit hole 🤷♂ and it's more of a webpack-dev-server issue in any case.

hot: true tell webpack-dev-server to serve file via HMR.
And the HMR plugin, tell webpack to add the plugin in the client so he know how to handle it. But yes, it's an issue with webpack-dev-server. Could you please open an issue on their repo explaining your situation, action etc. Perhaps, someone will be able to help

I belatedly realised something - deleting hot = true made autorefresh work on my end but it wasn't actually using HMR, just plain old full-page refresh, and I mistook it for HMR 🤦♂
With the fix in your pull request, and after removing the global Webpack, I get actual HMR, so I think merging it would be better.
Not quite related, but in the current repo App.fs places withDebugger before withReact, and as your documentation states that doesn't work properly with the Redux devtools - you can look at the state history but not rewind/replay the page. Should I submit a PR to change it to:
#if DEBUG
|> Program.withConsoleTrace
|> Program.withHMR
#endif
|> Program.withReact "elmish-app"
#if DEBUG
|> Program.withDebugger
#endif
|> Program.run

?

@piaste Can you please check that having hot = true without the global webpack work for you ?
I would prefer, keep hot = true instead of using the --hot cli to keep the configuration in one place.
And yes, you should send a PR to fix the debugger support.

I'm seeing the exact same behavior--with the latest version of this repo I can't get a page refresh until I remove hot = true (at which point, as you said, HMR does not work). I've only recently installed Node + npm and Yarn and am positive that I didn't install Webpack (or anything else) manually myself.

@kerams are you sure that you got HMR and live reload?
Can you please copy paste your browser console after doing an HMR update ?

Program.mkProgram init update view
|> Program.toNavigable (parseHash pageParser) urlUpdate
#if DEBUG
|> Program.withConsoleTrace
|> Program.withDebugger
|> Program.withHMR
#endif
|> Program.withReact "elmish-app"
|> Program.run

[WDS] App updated. Recompiling...
client?cd17:212 [WDS] App hot update...
log.js:23 [HMR] Checking for updates on the server...
log.js:23 [HMR] Updated modules:
log.js:23 [HMR]  - ./pages/WishList.fs
log.js:23 [HMR]  - ./App.fs
log.js:23 [HMR] App is up to date.

No refresh with hot = true.

@kerams Can you please tell me if you get HMR working with this version (take the hot_via_cli branch) ?

Your change makes no difference. However, I did find something curious. After I reload the page I get HMR and live reload on a menu item when logged out on the home page. When I go to the login page and change a menu item again, I no longer get a live reload on that page or home (!) until I type something in a field or navigate the menu.

If you remove this lines what's the result ?
|> Program.withConsoleTrace
|> Program.withDebugger

Still the same. After navigating away from the Home page, HMR only triggers after I force a render.

What's weirder is that if after all that I actually log in, I end up in some strange logged in/out state, where clicking on Wishlist takes me to the Home page and makes me appear logged out. Clicking on Login then makes me logged in instantly.

What's weirder is that if after all that I actually log in, I end up in some strange logged in/out state, where clicking on Wishlist takes me to the Home page and makes me appear logged out. Clicking on Login then makes me logged in instantly. I wonder if @piaste can reproduce any of this.

@kerams I'll try it this evening. I did all my attempts directly on the login page itself so didn't notice anything about that.

I have the same problem. I noticed that the views were not working were being rendered using the lazyView2 method and tried removing it. This fixed the HMR problem but I guess HMR should also work for lazy views?

@purkhusid HMR being lazyView, lazyView2, lazyView3 works too but because they are lazy their will not re-render directly. They are lazy so they only re-render if your model changed, trigger a change into the submodel you passed to the lazyView and you will see that's the change have been applied to your application. We can't really do anything for that.

still an issue? I tried new webpack.HotModuleReplacementPlugin() and also hot: true but none worked for me...
I use "webpack-dev-server": "^2.11.1" with "webpack": "^3.11.0"

@dgroh Are you using any of lazyView, lazyView2, lazyView3 in your application ?
Do you have a global version of webpack isntalled ?
If you use this project do you get HMR ?
Can you please show us your Program.mkProgram init update view part ?
Which version of Fable.Elmish, Fable.Elmish.HMR, etc. are you using ?

remove hot:true works for me.
I use "webpack": "^4.29.3"  and "webpack-dev-server": "^3.1.14"


Final App, Style and Test

Create and export api
Add styles to country component
Add styles to detaile section
Add detail component to app
Add detailReducer to store
Create reducer for detail page
Create home page component
Add reset style to app
Create App component
Create index.js file to render app component
Create filter component
Create country data component
Create counties component
Create aggregate data component
Add details page
Create app test
Create store data component
Create filter data component
Create country data component
Create aggregate data component
Add style to navigation section
Add style to body element
Create color and font variable
Create test for country data
Create test for aggregate data
Create test for home page

[ ] Kindly add a video presentation describing your project 🙌
[ ] Please be sure to add your video presentation to your PR description 🤓

Hi @mateo951 👋

Thank you very much for your effort
I make presentation video on loom
Add video link to README.md file


Hackathon: AMD support for XBlocks

Thanks for the pull request, @e-kolpakov! It looks like you're a member of a company that does contract work for edX. If you're doing this work as part of a paid contract with edX, you should talk to edX about who will review this pull request. If this work is not part of a paid contract with edX, then you should ensure that there is an OSPR issue to track this work in JIRA, so that we don't lose track of your pull request.
To automatically create an OSPR issue for this pull request, just visit this link: https://openedx-webhooks.herokuapp.com/github/process_pr?repo=edx%2Fxblock-sdk&number=75

@singingwolfboy you mentioned in IRC that you were interested in this feature. The build is currently failing, but I wanted to make sure that you knew this pull request was out there, in case you wanted to offer any commentary.


Feat: Improving the Landing Page

Describe the feature
The hero section could be redesigned to enhance the overall appearance of the landing page, providing a more polished and professional look.
Moreover it is not much responsive.
Add ScreenShots

Record

[X] I agree to follow this project's Contributing.md
[X] I'm a SWOC contributor
[X] I want to work on this issue

@vansh-000 what changes you would do to improve overall apperance??? . Responsive one has been done already


Feat: Added method to encrypt with RSA and public key

Hi @szkiba could you please take a look at this PR. My team is using this extension. However, we need to use the method encrypts with rsa.encryptpkcs1v15 to prepare a request payload

@mstoykov could you please take a look at this PR :)

Hi @mstoykov  and @szkiba  could you please take a look at this PR :(


New features

hello，Will adding and removing a consumer be considered in future releases

I can't understand what you mean.
Issues are generally used for bug reports and feature requests, so if you have any questions about     Apache  RocketMQ, it is recommended to discuss it on the mailing list first, the mailing list address. I will close the Issue first, but please feel free to reopen it if you have any other issues.


RFC: Path recognition to former locations of objects

rfcs/path-recognition-to-former-locations.md

From what I gather you want type-checking to include the source directory of the cloned instances. I think this would be a better request for the Roblox developer forum.
Long-term I think we should move away from the Starter* pattern entirely which would solve cases like this.

I am going to close this RFC since the Roblox developer forum would be a more suitable place for it.


Payment with PayPal.me could be labelled as paid without any payment issued from PayPal reported by @kerupuksambel

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed :

Open staging.new.expensify.com from an account (Account A)
Set a PayPal.me account in Account A
Request some amount of money to another account (Account B)
From Account B, pay the account with using PayPal.me
After the PayPal.me tab showed up, close the tab

Expected Result :
The money request shouldn't be labelled as paid, since there are no transaction occurred from PayPal side
Actual Result :
The money request labelled as paid
Workaround:
unknown
Platform:

Where is this issue occurring?

Web

Version Number: 1.2.27-3
Reproducible in staging?: y
**Reproducible in production?:**y
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:
https://user-images.githubusercontent.com/43996225/201694269-d0e72b59-252c-43d3-b4af-519e4438c4fb.mp4
https://user-images.githubusercontent.com/43996225/201694342-3e0e2eb2-3dbe-4df3-a34f-76aff27e768e.mp4
Expensify/Expensify Issue URL:
Issue reported by: @kerupuksambel
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1668300730482609
View all open jobs on GitHub

OK, so for the invoice to be marked immediately as paid is expected based on this Community article. At the bottom of the article:

Please note, the invoice will be marked as PAID as soon as you click the green button. Do not select Pay until you're ready to follow through with the payment!

I tested this flow and it works the same as OldDot — when payment is made, the user is sent to their PayPal.me link:
https://user-images.githubusercontent.com/38236554/201943407-49f92223-ef1a-4dc4-9715-3d45232b0c0a.mp4

When we created the PayPal integration, we did so knowing that it wasn't possible to bring across the payment status via PayPal. I don't think that's changed, so this is working as it should, going to close.

Agree with @bfitzexpensify. This is not a bug, it's the design as this is not an API integration.


k8gb crashes on malformed spec section in gslb custom resource

When gslb spec contains wrong path section for host: rule e.g:
spec:
  ingress:
    rules:
    - host: host.examle.com
       https: <==== should be http instead!
         paths:
...
  strategy:
    dnsTtlSeconds: 30
    splitBrainThresholdSeconds: 300
    type: roundRobin

this leads to panic and k8g controller crash.
Following can be seen in k8gb log
E0212 07:54:49.306061       1 runtime.go:78] Observed a panic: "invalid memory address or nil pointer dereference" (runtime error: invalid memory address or nil pointer dereference)

https://gist.github.com/somaritane/2b65ada535bfcf9d4008a92c194601f0

Also nil or empty http would be handled.

Shouldn't we actually handle https as well? Especially for annotated Ingress scenario

Shouldn't we actually handle https as well? Especially for annotated Ingress scenario
@ytsarev, are we talking about TLS handling? If yes, tls section of Ingress spec handles that, there's no such thing as https path rule.

@somaritane ok, let's not complicate it until it is really required :D

via https://github.com/AbsaOSS/k8gb/pull/313


Catch matching on an enum of the wrong type

If you have x = Signal(decoder=Foo) and try to do x.match(Bar.QUUX) or m.Switch(x)/m.Case(Bar.QUUX), there should be an exception (TypeError?) thrown to catch any potential bugs where an enum of the wrong type is being used.

We can do this on a best-effort basis with a lint (warning by default diagnostic), but Amaranth is an untyped language (in that all values belong to the same type and are mutually interoperable regardless of how they're constructed) and it is not feasible to add a type system to it even if it was desired.

This doesn't change the language and so doesn't need an RFC, someone can just implement it. @Ravenslofty?