RFC: Provide pre-built version of this library

First off: thanks for a nice addition to the Rust ecosystem, it's really wonderful to see Microsoft actively try to support what is going on and provide support for the win32 apis.
However as a maintainer of several code-generation crates I've found that it's usually significantly nicer for the user of my crates to provide a pre-built version of the wrappers that I'm exposing. This has a few benefits

build.rs is a serial dependency and very slow for more complex projects since cargo has to stall building code further down the line, and it has to wait for code-gen crates like syn and quote to have been built before it can run a build.rs.
Right now the recommended workflow is for everybody else to create a pre-built version, however, this means making windows-rs types part of your public interface will lead to incompatibilities between crates, whereas before you could make sure that everything is on the same version through cargo deny for example.

To see the impact of building this crate, one can run cargo +nightly build -Ztimings to see the build dependency graph and this crate's impact on it (for example on the minesweeper-rs example that you've provided it looks like the vast majority of it's ~70s build time is spent in code-gen related things).
If a pre-generated version of this crate becomes available (or nicers: this crate switches into a pre-built library) please add feature toggles similar to how winapi-rs does things, this lets the cargo feature resolver make sure that the minimal set of features is built across the entire dependency tree.

I'm personally in favor of that. The API surface is huge though so it's not exactly clear how best one would offer a pre-built version. So, some additional questions:

Should it be a single crate or multiple crates?
If multiple, how should they be split?

I'm personally in favor of that. The API surface is huge though so it's not exactly clear how best one would offer a pre-built version. So, some additional questions:

Should it be a single crate or multiple crates?
If multiple, how should they be split?

I don't think it is terribly wrong to give an ability to pre-generate and include in crates just the bindings they need. As you mention it can lead to incompatibilities if these are exposed in the public interface of the crates, but in my experience the need to do so is pretty rare.

I don't think it is terribly wrong to give an ability to pre-generate and include in crates just the bindings they need. As you mention it can lead to incompatibilities if these are exposed in the public interface of the crates, but in my experience the need to do so is pretty rare.

The winapi 0.3 approach is proven to work well, single huge crate but with features for all areas/modules that are disabled by default so each crate using it has to opt in to the feature they do want to use. This compiles nicely and the cargo additive feature support makes sure winapi is built once with all the features that all dependencies have enabled.
In our codebase we have ~50 direct usages from our own and third party crates to winapi (0.3) and it builds really fast and is easy to use. Think almost none of those crates expose the winapi types as public symbols, but some may/could and it would still work well also.

The winapi 0.3 approach is proven to work well, single huge crate but with features for all areas/modules that are disabled by default so each crate using it has to opt in to the feature they do want to use. This compiles nicely and the cargo additive feature support makes sure winapi is built once with all the features that all dependencies have enabled.
In our codebase we have ~50 direct usages from our own and third party crates to winapi (0.3) and it builds really fast and is easy to use. Think almost none of those crates expose the winapi types as public symbols, but some may/could and it would still work well also.

In my experience the winapi 0.3 approach is proven to work well, single huge crate but with features for all areas/modules that are disabled by default so each crate using it has to opt in to the feature they do want to use. This compiles nicely and the cargo additive feature support makes sure winapi is built once with all the features that all dependencies have enabled.

IME it hurts in large workspaces, since cargo test -p <onecrate> and cargo test -p <anothercrate> will end up with different feature combos for winapi, which will result in rebuilding it and all dependencies (which in practice is a lot of your workspace dep tree) each time. You see things like https://searchfox.org/mozilla-central/source/build/workspace-hack/Cargo.toml sometimes that exist to mitigate it (which is only realistically viable if you're not on crates.io, so is not that common).
Personally I'd prefer to use it in a pre-generation context, which avoids all these issues.

In my experience the winapi 0.3 approach is proven to work well, single huge crate but with features for all areas/modules that are disabled by default so each crate using it has to opt in to the feature they do want to use. This compiles nicely and the cargo additive feature support makes sure winapi is built once with all the features that all dependencies have enabled.

IME it hurts in large workspaces, since cargo test -p <onecrate> and cargo test -p <anothercrate> will end up with different feature combos for winapi, which will result in rebuilding it and all dependencies (which in practice is a lot of your workspace dep tree) each time. You see things like https://searchfox.org/mozilla-central/source/build/workspace-hack/Cargo.toml sometimes that exist to mitigate it (which is only realistically viable if you're not on crates.io, so is not that common).
Personally I'd prefer to use it in a pre-generation context, which avoids all these issues.

IME it hurts in large workspaces, since cargo test -p <onecrate> and cargo test -p <anothercrate> will end up with different feature combos for winapi, which will result in rebuilding it and all dependencies

Yup that is true and a fair point, we do have a fairly large workspace (~550 crate dependencies) but less common to build and test subparts of it. But definitely does happen and is a common cargo workflow.

IME it hurts in large workspaces, since cargo test -p <onecrate> and cargo test -p <anothercrate> will end up with different feature combos for winapi, which will result in rebuilding it and all dependencies

Yup that is true and a fair point, we do have a fairly large workspace (~550 crate dependencies) but less common to build and test subparts of it. But definitely does happen and is a common cargo workflow.

What should probably happen is a generator / default-generated split.
The generator at work here is amazing work, and it's fine for it to just be a thing that exists on its own.
However, many people want to use a pre-generated form, chunked up by feature flags or whatever. Just offer that as a crate separate from the generator itself.
Hek, just run this generator and then use the output as the content of winapi (in a 0.4 version)

What should probably happen is a generator / default-generated split.
The generator at work here is amazing work, and it's fine for it to just be a thing that exists on its own.
However, many people want to use a pre-generated form, chunked up by feature flags or whatever. Just offer that as a crate separate from the generator itself.
Hek, just run this generator and then use the output as the content of winapi (in a 0.4 version)

less common to build and test subparts of it.

Yeah, there's a size of workspace where this becomes untenable.

less common to build and test subparts of it.

Yeah, there's a size of workspace where this becomes untenable.

IME it hurts in large workspaces, since cargo test -p  and cargo test -p  will end up with different feature combos for winapi, which will result in rebuilding it and all dependencies (which in practice is a lot of your workspace dep tree) each time.

This feels like something that could be fixed in cargo itself, e.g. through the deduplicate workspace information RFC eventually. Through this RFC, you could specify the features once in the workspace root, and all the packages in your workspace would end up using a common build.

IME it hurts in large workspaces, since cargo test -p  and cargo test -p  will end up with different feature combos for winapi, which will result in rebuilding it and all dependencies (which in practice is a lot of your workspace dep tree) each time.

This feels like something that could be fixed in cargo itself, e.g. through the deduplicate workspace information RFC eventually. Through this RFC, you could specify the features once in the workspace root, and all the packages in your workspace would end up using a common build.

This feels like something that could be fixed in cargo itself, e.g. through the deduplicate workspace information RFC eventually

It feels to me like without a major redesign, it will always be something of an issue, but perhaps I'm too pessimistic.

Having every single crate generate their own bindings through windows-rs feels like a recipe for disaster in terms of compile-time regressions compared to the current winapi-rs approach.

Yes, I agree here, unless the pregeneration approach is widely taken.

This feels like something that could be fixed in cargo itself, e.g. through the deduplicate workspace information RFC eventually

It feels to me like without a major redesign, it will always be something of an issue, but perhaps I'm too pessimistic.

Having every single crate generate their own bindings through windows-rs feels like a recipe for disaster in terms of compile-time regressions compared to the current winapi-rs approach.

Yes, I agree here, unless the pregeneration approach is widely taken.

Sorry for the delay in responding. This is an important issue to us. In fact, we had a meeting to discuss this topic just yesterday. This matters for some of our internal teams as well. We would like to provide pre-generated bindings as a collection of crates, but there are pros and cons to doing so today. Here are a few issues to consider:

The scope of the bindings that the windows crate can generate far exceed those of the hand-written winapi crate. Since we tap into metadata, we can generate bindings for the entire set of Win32, COM, and WinRT APIs. We thus have scalability issues that are not as obvious in a hand-written approach.
The Windows API developed over a number of decades and is very large but not well layered. The Windows API is organized as a set of logical namespaces. One approach is to model those individual namespaces as individual pre-generated crates. That would be roughly 540 crates.
One challenge with this approach is that Rust does not support the inherent dependencies implied by the Windows API. Crate A may depend on crate B that depends on crate A. We are exploring ways to improve the Rust language and toolchain to able to support this.
Another approach is to have one large crate that includes everything and use Rust features to limit what is compiled. The trouble is that "features" are pretty limited and we would end up with hundreds or even thousands of features. Again, we would need to explore ways to improve Rust to able to support this more effectively.
Another approach is to change the windows crate’s default model of greedy dependency tracking and replace it with a more conservative approach that elides any methods on COM and WinRT interfaces that refer to types not specifically mentioned in the build macro (#567). The vtable slots would be preserved but the projected methods would be omitted. This has the potential of generating far less code and thus speeding up builds considerably.
Another challenge is that the Rust compiler is very slow. It is many times slower than the C++ compiler. Part of the problem is the compiler’s single-threaded performance and part of it is the lack of multi-threading. We have people looking into improving the performance of the Rust compiler. @rylev has already had some success here.
Another approach is to introduce a binary crate model where cargo would not need to compile each dependency from source, akin to C++ modules.

So there are just a few challenges and ideas we're throwing around. The main benefit we see for pre-generated bindings is to allow crates to share common definitions of Windows types. This is something we would like to support, but there are technical hurdles to overcome. These are hard problems, and we look forward to working together to solve them.

I've been thinking more about this. I'd like to try to capture the pros and cons of pre-built crates as well as the dependencies. Some of this will be a repeat of what @kennykerr says above but hopefully this provides a bit more structure to think about this problem.
Pros

Possible compile time improvements

The lack of proc-macro code generation means less dependencies and and less work being done before main compilation happens.
The pre-generated crate can be shared among upstream dependencies meaning that the code needs to only be able to compiled once.

Common definitions

Not only can upstream dependencies rely on a single crate being compiled they can also share definitions meaning there won't be a case where two logically equal types can't interoperate since they are compiled by two different crates.

Cons

Hard to factor/organize

The Windows API surface is huge (much bigger than what winapi currently exposes) and only likely to get bigger as more definitions are added to the metadata. Deciding on how to break up the Windows API surface is not an easy problem.
You could separate by namespace but some namespaces are huge themselves and many depend on other namespaces in circular ways. We should do some analysis of the current metadata to understand the shape of this issue better, but this makes it unlikely that a many-pre-generated-crates solution would work.
Going down the single-crate path, we could use features like winapi does, but this is already pretty unwieldy in winapi and as I said above, a pre-generated crate would be much larger than winapi is.

Next steps

Try an experiment where we pre-generate the entire Windows API surface with each namespace being behind a feature flag.

We can then get feedback on how people thing using such a crate would be in practice, and we can do compilation tests to see how this affects compilation time.
We should also experiment with putting some things behind additional feature flags: e.g., Debug implementations should be behind a feature flag.

I definitely think no matter what happens we will keep on-demand generation as an option. It's extremely valuable in many situations. However, a pre-built crate may be an additional choice for those who want/need it.
More idea
Potentially, we might be able to let these different approaches work well together. For instance, we could provide a Win32 crate which only contains definitions in the Win32 namespace. Then when the user is generating bindings outside this namespace, they could optionally let the code generator know that they want to depend on the Win32 definitions in the win32 crate instead of generating those definitions. There are issues with version management, but this is certainly a possibility.

@Plecra this is something that we could explore, but it seems that namespaces often have circular dependencies which would not be served well by a separate crate model. Also, even if this is possible now, we would essentially be committing to this model forever. What happens when new APIs come along that break this model? The Windows APIs have a lot bigger concerns than if the break the Rust bindings, so it's unlikely we would be able to prevent such a thing from happening.
Like I said above, perhaps we might be able to build a model that handles both pre-generated and non-pre-generated bindings. Then for some select namespaces, we can pre-generate the bindings if we feel comfortable enough that those namespaces work well in such a model.

@Lokathor I don't have an example off the top of my head. I will try to do some spelunking and find some. For win32 specifically (i.e., the things in the metadata under the win32 namespace), it doesn't seem like there are any dependencies currently outside of Foundation and System namespaces. So hopefully we can provide a win32 crate. The next step is to create such a crate and see how bad compile times are for each sub-namespace of the win32 namespace.

It would be insightful to use the metadata reader to model the dependencies. I would however be quite reluctant to favor some APIs over others. Ideally, we can find a solution that works for all APIs and not just some blessed APIs that happen to not have cyclic issues.

Yeah. Not to try and diminish the work on the other APIs also being supported, but I think at this time that most people are only using Win32, particularly because that's where the winapi support is at the moment.
My suggestion would be to coordinate with @retep998 about possibly having the next semver break of winapi (0.4) be generated via this generation system, and having it focus on just the win32 part of things. I think this would produce the least overall churn in the ecosystem.

I did some analysis on the dependency output that Kenny posted.

315 total namespaces with at least one dependency.
76 depend on only Windows.Foundation.
Win32 depends on Windows.Foundation and Windows.System. It is the only namespace dependent on Windows.System.
55 namespaces depend only on Windows.Win32
There are a bunch on recursively dependent namespaces but they are always in the same top level namespace (e.g., Windows.Media.Core mutually recursively depends on Windows.Media.Playback)

We need the following two features to be able to experiment with this:

Add support for features in the build! macro
Add support for specifying that a namespace comes from a 3rd party crate and shouldn't be generated.

I see that there are three strategies:

If you are building a library which consumes or outputs WinAPI types, you should use pre-built windows-rs packages (this issue).
If you are building a library that merely uses WinAPI types but does not expose them, you could bundle pre-generated bindings without macro dependencies.
If you are building an application then you could use macro generated bindings.

Notice the case 2. If your library is merely using the bindings, it's wasteful to depend on macro generation because every user of the library would generate the same bindings. Thus it's cheaper for us all if the bindings are pre-generated and bundled as code for that kind of libraries.

To summarize, developers will then be able to choose between:

the build macro (like these samples)
the generate macro (like this PR and the windows crate itself)
the pre-built windows-api crate!

I just need the metadata folks to clean up the namespace dependencies to improve build performance.

"3" finally allows Windows types to be shared across crates in a stable way.
There are however still a lot of details to work out around how that will interoperate with code generated by build/generate for non-Windows APIs as well as with the implement macro for implementations.


default local development to Podman

Default development environment still Codespaces with VSC setup
Switch default local container runtime tool from Docker Desktop to Podman.
Now two instructed ways to work on local environments: Podman + Jupyterlab, and Docker + VSC

In addition:

fix problems with Prometheus container creation & connectivity to dev container.

Minikube mentioned in commit messages, but left for future work for now


Feature Request: MTR traceroute/ping functionality

Just wondering if you plan on extending the traceroute functionality to produce output similar to the popular MTR tool? This is already an awesome tool, but that would make it even more useful.
Thanks.

I've been wanting to update the traceroute functionality at some point, and the behavior of MTR looks easy to implement.  So yes, this will probably get added at some point.

I know this is old, but now that I look at MTR, how would this even be implemented in the user interface? It wouldn't really fit or display well in one of the probe windows. Would it be a separate window, kind of like how I currently have Trace Route and Flood Host?

a simple idea that might do what most people (and maybe ronjcu) need. Just extend tracert window a little bit. Add a Button to Ping the list in regular vmPing Window. Additionally you could add checkboxes and let the user select wich IPs he would like to ping but he might also remove the IP after normal ping window appears. Here is what i thought it could look like.

The lack of statistics would be a downside in your current state of vmPing, but hey "simply" make a new "Ping Statistics" Window that will always collect data when vmPing is running - independent of tracert. Just place it in menu right below "status history". It may look like this

all in all it's "just" another view of main vmPing window - you have a lot of data (6 Columns) there already.

Thanks for the suggestion, that looks pretty good. The ping statistics window you have is similar to what I've been wanting to do since I started this project. I've been planning a compact view bound to a keyboard shortcut like F4, where you can quickly toggle between the current ping view you see now and a more compact view that shows one host per line in a gird-like format. The approach with checkboxes on the traceroute window would make for a very easy MTR solution.


Document "build-info" information that we currently have to aid "reproducible" builds

Document what existing "build info" we have:
OpenJDK source being built:

OpenJ9:

https://github.com/eclipse/openj9/ : version, SHA
https://github.com/eclipse/omr : version, SHA
https://github.com/ibmruntimes/openj9-openjdk-jdkNN version, SHA
Freemarker version, downloadUrl

Hotspot:

OpenJDK source mirror : version, SHA

Build Platform:

OS
Architecture

Build Parameters:

NODE_LABEL
BUILD_CONFIGURATION

Build scripts:

https://github.com/AdoptOpenJDK/ci-jenkins-pipelines.git, SHA
https://github.com/AdoptOpenJDK/openjdk-build.git, SHA

OpenJDK Build Info:

Configure args
BootJDK
C/C++ Compiler
Release formMetadata() : https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/blob/b50b6ab0344d2c55c19863aca3c6e22e23f2db22/pipelines/build/common/openjdk_build_pipeline.groovy#L590

Tests run:

Test job: <job name>
Test job Scripts:

https://github.com/AdoptOpenJDK/openjdk-tests.git, SHA
https://github.com/AdoptOpenJDK/TKG.git, SHA
https://github.com/eclipse/openj9.git, SHA
Test MachineInfo:

GNU Make
Perl
Curl
JTreg

Test OpenJDK repo and SHA
Test Results Summary

Above info is the main build details at the moment.


Testcase for Exherbo Linux is missing

Exherbo Linux (ID: exherbo) is one of the distros with a reliable ID. A testcase should be added.
If you want to help, it is sufficient to post to this issue:

The content of the /etc/os-release file, if any.
The file names and content of the /etc/*release and /etc/*version files, if any.
The output of the command: lsb_release -a, if available.

Exherbo distro dev here.
/etc/os-release:
NAME="Exherbo"
PRETTY_NAME="Exherbo Linux"
ID="exherbo"
ANSI_COLOR="0;32"
HOME_URL="https://www.exherbo.org/"
SUPPORT_URL="irc://irc.freenode.net/#exherbo"
BUG_REPORT_URL="https://bugs.exherbo.org/"
We're a source-base rolling-release distro so there's no meaningful /etc/*release /etc/*version or lsb_release.

Great, thanks for the input!!

Created PR #93 that fixes this issue.


Adding staff roles

See the video carefully
Don't forget to create a staff group and add any user to this group for testing the code
🛠 Fixes Issue #294
https://user-images.githubusercontent.com/56798376/167368874-9b58f57c-e0f6-4888-8091-8b742941f4f0.mp4

👨💻 Changes proposed

✔ Check List (Check all the applicable boxes)

[ ] My code follows the code style of this project.
[ ] This PR does not contain plagiarized content.
[ ] The title of my pull request is a short description of the requested changes.

📄 Note to reviewers

📷 Screenshots

Please, review my PR @arpit456jain @singhmansi25 @KKhushhalR2405 @raghavTinker

@raghavTinker @KKhushhalR2405 review this PR


ImageEncoder::SaveToStreamAsync() crash when encoding MediaSample2D from a camera

The IMFMediaBuffer is unlocked right away instead of at the end of the scope. When the buffer is backed by a DirectX surface the byte pointer becomes invalid right when the buffer is unlocked, leading to a crash. When the buffer is backed by regular memory there is a race condition: the pointer is typically valid until the IMFMediaBuffer object gets destroyed.

Fixed by b669779bf113b4d3f922dc440145aecb08598bb8


Update API key for Smithsonian DAG

Description

We're missing an API key for the Smithsonian provider DAG. This causes the pull_data task to fail.
Reproduction

Attempt to run the Smithsonian provider DAG in Airflow. Observe that the pull_data task fails and no data is ingested.
Resolution

We need to:

Obtain a new API key
Configure the key in Airflow
Re-run the DAG to make sure it's working

[ ] 🙋 I would be interested in resolving this bug.

Retrieved a new API key for<EMAIL_ADDRESS>added it to our secrets manager and updated the list of API keys for Airflow.
I'm not able to log into Airflow though (the credentials in our secrets manager don't work for me) so pinging @stacimc and @AetherUnbound to feel free to update the Airflow variables with the one added in the secrets manager.

Confirming the API key has been updated in Airflow 😄 Thanks!


Default Rate Limit Labels should OR with labels applied to services

Currently, if you apply a default rate limit label in the Ambassador Module, this label is added as another level to the requests descriptor meaning the rate limit service will need to match both the default label AND any labels applied to a service instead of matching the default OR any labels applied to the service.
Example:
      ---
      apiVersion: ambassador/v1
      kind: Module
      name: ambassador
      config:
        use_remote_address: true
        default_label_domain: ambassador
        default_labels:
          ambassador:
            defaults:
            - remote_address

      ---
      apiVersion: ambassador/v1
      kind:  Mapping
      name:  qotm_mapping
      prefix: /qotm/
      service: qotm
      labels:
        ambassador:
          - request_label:
            - qotm

will configure the envoy route like this:
"rate_limits": [
    {
        "actions": [
            {
                "remote_address": {}
            },
            {
                "generic_key": {
                    "descriptor_value": "qotm"
                }
            }
        ],
        "stage": 0
    }
],

where the rate limit service will need to match the remote_address AND  the generic_key: qotm. If the rate limit service is only configured to ratelimit off of remote_address, the request will be permitted.
Rate limiting off remote_address OR generic_key: qotm behavior is possible if you configure two separate label groups in the Mapping.
      ---
      apiVersion: ambassador/v1
      kind:  Mapping
      name:  qotm_mapping
      prefix: /qotm/
      host_rewrite: qotm.demo.k736.net
      service: qotm.datawire
      labels:
        ambassador:
          - request_label:
            - qotm
          - request_label_:
            - remote_address

will configure the envoy route like this:
"rate_limits": [
    {
        "actions": [
            {
                "generic_key": {
                    "descriptor_value": "qotm"
                }
            }
        ],
        "stage": 0
    },
    {
        "actions": [
            {
                "remote_address": {}
            }
        ],
        "stage": 0
    }
],

Where remote_address and generic_key: qotm are separate rate limits and a request can be rate limited if it exceeds either the remote_address descriptor OR the generic_key.
If there was a way to configure the default_labels in the ambassador Module to be applied to an identified label_group, that would allow for both behaviors to be configurable.
e.g.
      ---
      apiVersion: ambassador/v1
      kind: Module
      name: ambassador
      config:
        use_remote_address: true
        default_label_domain: ambassador
        default_labels:
          ambassador:
            defaults:
            - default
            request_label:
            - remote_address

      ---
      apiVersion: ambassador/v1
      kind:  Mapping
      name:  qotm_mapping
      prefix: /qotm/
      host_rewrite: qotm.demo.k736.net
      service: qotm.datawire
      labels:
        ambassador:
          - request_label:
            - qotm

creating an envoy route like this:
"rate_limits": [
    {
        "actions": [
            {
                "generic_key": {
                    "descriptor_value": "default"
                }
            }
        ],
        "stage": 0
    },
    {
        "actions": [
            {
                "remote_address": {}
            },
            {
                "generic_key": {
                    "descriptor_value": "qotm"
                }
            }
        ],
        "stage": 0
    }
],

where all requests will be rate limited off of exceeding the generic_key: default limit from the ambassador Module OR the remote_address limit from the ambassador Module AND any limits in the request_label group in a Mapping.

@nbkrause  This would be a part of normal release too. Is that correct ?


did you mean 'compiling'?

I definitely did, thanks for catching that 👍
Could you please make the DCO bot happy by force pushing that commit with the sign off ? Otherwise I can't legally merge it in. Thanks !

I definitely did, thanks for catching that 👍
Could you please make the DCO bot happy by force pushing that commit with the sign off ? Otherwise I can't legally merge it in. Thanks !

done. :)


Fix segfault seen in hipMemcpy [SWDEV-224941]

Fix for segfault seen if invalid kind is passed to hipMemcpy.

This adds unnecessary overhead, what is the point, beyond "somebody filed a bug". I don't believe CUDA goes to similar lengths to guard against user error.

This adds unnecessary overhead, what is the point, beyond "somebody filed a bug". I don't believe CUDA goes to similar lengths to guard against user error.

I have verified and found CUDA returns error if invalid kind passed but HIP segfaults which is not a good user experience.
Regarding overhead we can always check if the overhead is significant enough of causing any perf regression.

What do you define as invalid kind? Have you actually measured (we can do many things)? Why are you duplicating the switch, and expensive pointer info checks? If you really want to do a thing, just changing the default case to throw an "Invalid copy kind" / or that gnarly ihipException thing we have for no good reason should be more than enough.

What do you define as invalid kind? Have you actually measured (we can do many things)? Why are you duplicating the switch, and expensive pointer info checks? If you really want to do a thing, just changing the default case to throw an "Invalid copy kind" / or that gnarly ihipException thing we have for no good reason should be more than enough.

I think error scenario is not very clear to you hence all these doubts, I added test cases along the change to make it more clear but let me try to explain it here again
Segfault happens if user calls hipMemcpy( device_ptr, host_ptr, size, hipMemcpyDeviceToHost); // notice src is a host pointer and dst is a device pointer but kind passed as D2H which will fail if system is not a large BAR
Same segfaults seen in other cases where
i) src = dev_ptr, dst=host_ptr, kind=hipMemcpyHostToDevice
....
CUDA can catch such scenario and returns invalid value.

This is not the desired behavior. If the user supplies an incorrect pointer / hipMemcpyKind combination, this should return an error code that they can check. We should not be "fixing" it for them.
Returning an error code lets a user know that there's something wrong with their code, this method will hide it until they try to run on (e.g.,) the NVCC backend.

NVCC does not catch all scenarios e.g. In D2D case if memkind passed is H2H, D2H, .... API will return success hence we can't match exact NVCC behavior.

@mangupta why did you merge this? @arghdos who is the original requester had issues with the fix, and I have issues with the overhead of needlessly invoking info.


Creating new item fails, gives error

Running the following code keeps giving me the error that is shown. The 400 error code appears to be indicating that writing to the library is not allowed, but this is for my personal Zotero library and I have allowed write permissions. What could be causing this error?
zlib = zotero.Zotero(<ID>, 'user', <API KEY>)

newitem = zlib.item_template('book')
newitem['creators'][0]['firstName'] = 'Monty'
newitem['creators'][0]['lastName'] = 'Cantsin'
newitem['title'] = 'Maris Kundzins: A Life'
newitem['relations'] = ''

resp = zlib.create_items([newitem])

HTTPError                                 Traceback (most recent call last)
/Users/[USER]/anaconda/lib/python3.5/site-packages/pyzotero/zotero.py in create_items(self, payload)
952         try:
--> 953             req.raise_for_status()
954         except requests.exceptions.HTTPError:
/Users/[USER]/anaconda/lib/python3.5/site-packages/requests/models.py in raise_for_status(self)
861         if http_error_msg:
--> 862             raise HTTPError(http_error_msg, response=self)
863
HTTPError: 400 Client Error: Bad Request for url: https://api.zotero.org/users/[ID]/items?key=[API KEY]
During handling of the above exception, another exception occurred:
UnsupportedParams                         Traceback (most recent call last)
 in ()
4 newitem['relations'] = ''
5
----> 6 resp = zlib.create_items([newitem])
/Users/[USER]/anaconda/lib/python3.5/site-packages/pyzotero/zotero.py in create_items(self, payload)
953             req.raise_for_status()
954         except requests.exceptions.HTTPError:
--> 955             error_handler(req)
956         return self._json_processor(feedparser.parse(data))
957
/Users/rclement/anaconda/lib/python3.5/site-packages/pyzotero/zotero.py in error_handler(req)
1236                 error_handler(new_req)
1237         else:
-> 1238             raise error_codes.get(req.status_code)(err_msg(req))
1239     else:
1240         raise ze.HTTPError(err_msg(req))
UnsupportedParams:
Code: 400
URL: https://api.zotero.org/users/[ID]/items?key=[API KEY]
Method: POST
Response: Uploaded data must be a JSON array

The problem is the relations key, which can't be an empty string. You don't have to specify it for object creation anyway – simply omitting it should allow you to create the item using the code above.

I put in the empty string for the relations key, because when I pulled the item template, that field was:
 'relations': {},
Is that what the field should be?
Removing the specification for relations still gives an error:

HTTPError                                 Traceback (most recent call last)
/Users/rclement/anaconda/lib/python3.5/site-packages/pyzotero/zotero.py in create_items(self, payload)
952         try:
--> 953             req.raise_for_status()
954         except requests.exceptions.HTTPError:
/Users/rclement/anaconda/lib/python3.5/site-packages/requests/models.py in raise_for_status(self)
861         if http_error_msg:
--> 862             raise HTTPError(http_error_msg, response=self)
863
HTTPError: 400 Client Error: Bad Request for url: https://api.zotero.org/users/[USER ID]/items?key=[API KEY]
During handling of the above exception, another exception occurred:
UnsupportedParams                         Traceback (most recent call last)
 in ()
4
5
----> 6 resp = zlib.create_items([newitem])
/Users/rclement/anaconda/lib/python3.5/site-packages/pyzotero/zotero.py in create_items(self, payload)
953             req.raise_for_status()
954         except requests.exceptions.HTTPError:
--> 955             error_handler(req)
956         return self._json_processor(feedparser.parse(data))
957
/Users/rclement/anaconda/lib/python3.5/site-packages/pyzotero/zotero.py in error_handler(req)
1236                 error_handler(new_req)
1237         else:
-> 1238             raise error_codes.get(req.status_code)(err_msg(req))
1239     else:
1240         raise ze.HTTPError(err_msg(req))
UnsupportedParams:
Code: 400
URL: https://api.zotero.org/users/[USER ID]/items?key=[API KEY]
Method: POST
Response: Uploaded data must be a JSON array

I have tried to change the item type and get the same error, and tried just specifying one key, e.g. just the title, and still get the same error. I can't seem to find any guidance on why, after setting one or more of the keys in the JSON array, it would now not be recognized as a JSON array.

So the following code doesn't work for you? I'm just double-checking because I can't replicate the problem on Python 3.4.1
zlib = zotero.Zotero(<ID>, 'user', <API KEY>)
newitem = zlib.item_template('book')
newitem['creators'][0]['firstName'] = 'Monty'
newitem['creators'][0]['lastName'] = 'Cantsin'
newitem['title'] = 'Maris Kundzins: A Life'
resp = zlib.create_items([newitem])

Also, could you confirm what version of Pyzotero you're running:
from pyzotero import zotero
print(zotero.__version__)

It should be version 1.1.19.

Aha! It was the version. I thought I had updated, but the previous update apparently didn't work. Now running 1.1.19 and the code works as it should. Thank you!


[BEAM-12548] Add examples of Equals and EqualsList to equals_test.go

Adds examples of the usages of Equals and EqualsList functions to equals_test.go. Covers successful usages with individual expected values, a PCollection of values, and an array/slice of values. Also shows the expected error message on a mismatch.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

R: @lostluck

Run GoPortable PreCommit


Bug : Minimized to tray requires 2 click to restore window

Using JWM V2.3.6,
I use hexchat with Settings > Preference > Alert > 'Enable system tray icon' and 'Minimized to tray"

If I start hexchat and i minimized to tray hexchat with a key (Key mask="4" key="Down"  minimize ), hexchat is minimized to tray but I need 2 click on tray to restore hexchat window.

Nota 1 : These 2 clicks are not necessary if hexchat is already minimized to tray. The bug happens only after the first action to minimize hexchat to tray
Nota 2 : I have the feeling that , when minimize action is requested, hexchat icon should appear in Dock AND task list, but icon does not appear in task list.
Nota 3 : When i choose "close to tray" option and i close hexchat window, the behavior is correct : hexchat icon on Dock only, only 1 click to restore the window
Nota 4 : Other applications, like sylpheed, does not have this problem.

This should be (partially) fixed as of snapshot 1593.  It should only take one click now.  I’m still not sure why it disappears from the task list when minimized.


Reduce image size

Inspect container for contents that can be removed during the build to reduce its size.

FYI you might also consider a multi-stage build where you're first building some dependencies, copy the build products into their expected locations, and then build the "real" container off of that. This can save space if  build dependencies that take up a considerable amount of space are not needed at runtime.


ChatCompletionOptions doesn't work in .NET Standard 2.0 due to init properties.

Library name and version
Azure.AI.OpenAI - 2.0.0-beta.2
Query/Question
The following does not work, when the package is used in a project that targets .NET Standard 2.0, because the ChatCompletionOptions type uses init-only properties, which are not supported by standard 2.0.
Example:
var options = new ChatCompletionOptions
{
    MaxTokens = 1000,
    Temperature = 0.7
};

If set MaxTokens or Temperature like this, I get the following error as soon as the method is entered (so NOT on the line where this executes, but on the first line of the containing method):
System.MissingMethodException
  HResult=0x80131513
  Message=Method not found: 'Void OpenAI.Chat.ChatCompletionOptions.set_MaxTokens(System.Nullable`1<Int32>)'.

This is because init-only properties simply aren't supported in standard 2.0. However, the package overall seems to be designed to work in standard 2.0 (and that seems to be a fairly important feature when retro-fitting older apps with AI).
Note: This also happens with beta1.
Environment
Class library project targeting .NET Standard 2.0

Thank you for the report; this is clearly incorrect and we're investigating.
The problem is present with just the official OpenAI library, too, and as you note it appears to be universal when using these accessors via an intermediate netstandard library.
It looks like this is a framework targeting issue: the OpenAI library internally defines the needed IsExternalInit attribute, but the multi-target to netstandard2.0;net6.0 is causing something to get mixed up; this is apparent when replacing it with a project reference to https://github.com/openai/openai-dotnet/src/OpenAI.csproj with AdditionalProperties="TargetFrameworks=netstandard2.0", which makes the dependency chain work correctly.
That's a poor but potentially viable temporary workaround (build against the project instead of the package and explicitly use netstandard2.0 as the target framework(s)); we'll get it fixed properly ASAP -- just need to confirm that we don't need the net6.0 target.

Yes, that seems to be exactly right.
And the scenario is pretty important, I would think, because we have quite a few customers who want to modernize old applications by adding AI features to them, without moving the whole project.
Thanks
Markus


Add press release to website

Signed-off-by: Kyle Mestery<EMAIL_ADDRESS>

no comment from Dell ?


Should azd unistall flow remove the user-data folder

The current approach is leaking some binaries and json files in ~/.azd after uninstall
Should the uninstall process ask user to keep/delete application data?

I think we should delete ~/.azd/bin automatically. We can delete the user configuration if requested.

We have several scenarios:

Windows MSI -- I think this could be accomplished with a custom action, per-machine installs could be difficult because we have to traverse user folders to find <user-folder>\.azd\bin ... There could be other failure scenarios here
MacOS brew -- Not sure but there's probably some uninstall function of which we can make use
Linux

Install scripts -- We'd have to traverse user folders to find <user-folder>\.azd\bin
Installed via package manager -- I think there are ways to run custom scripts on uninstall which could do this work but we'd have to traverse user folders to find <user-folder>\.azd\bin

Shallow immediate wonderings:
I wonder if we could have a per-machine "binary storage location" for all installs of azd. Something like /opt/Microsoft/azd/bin and c:\azd\bin or something that's writable by all users during a per-machine install. We'd have to do something to ensure that the executable files we're running is the right one (like checking a hash and then downloading/overwriting if the has doesn't match). It'd be much easier to remove that one folder.
In per-user installs I'd be more comfortable scrubbing out ~/.azd/bin

The best thing to do here is to document this behavior and not try to build all of this logic which has the potential to break the uninstall process in new ways.
To that end:

Update docs

Install/Uninstall README.md
Docs site

Add comments to the uninstall scripts
(possibly) add a message dialog in the uninstaller during an interactive uninstall


calibrate topic classifier

investigating temperature scaling for multilabel classification as per https://www.isca-archive.org/interspeech_2023/chou23_interspeech.pdf


Local Videochat uploading video:Expecting value: line 1 column 1 (char 0)

Hi, I want to build the videochat locally, but when I tried to upload my video through http://<IP_ADDRESS>:7860, there would be an error. And when I run app.py, it seems good. Thx!

Is there any error message in the terminal? Do you have a network proxy?

Is there any error message in the terminal? Do you have a network proxy?↳
If you are running a network proxy, it is recommended to disable it.↳

Thx! I'm using the proxy. I disabled it and it work out.
But I encountered another problem: can this project use gpt-35-turbo-16k? Thx!

Maybe you can change the https://github.com/OpenGVLab/Ask-Anything/blob/6e621d11f7714aa90d047decf6f037bd860598d8/video_chat_with_ChatGPT/chatbot.py#L70C64-L70C87 to  model_name='gpt-3.5-turbo-16k'

Maybe you can change the https://github.com/OpenGVLab/Ask-Anything/blob/6e621d11f7714aa90d047decf6f037bd860598d8/video_chat_with_ChatGPT/chatbot.py#L70C64-L70C87 to model_name='gpt-3.5-turbo-16k'↳
It works out now. I used the model_name='gpt-3.5-turbo-16k. and added an engine(gpt-35-turbo-16k) and a new define class. Really thx!


Music Plugin filters your own teleports with the tick box: "mute other players' area sounds"

Type
Incorrect behavior
Operating System
Windows
OS Version
windows 10
Bug description
If you have the tick box: "mute other players' area sounds" turned ON it fill wilter all the teleporting sounds from you as well, including in POH etc. this is clearly unintended behaviour since it filters your own teleports and not only other peoples teleports
Screenshots or videos
No response
RuneLite version
runelite version: <IP_ADDRESS>
launcher version: 2.6.9
Logs
No response

This happens because TELEPORT_VWOOP (SoundEffectID 200) is a sourceless sound and onAreaSoundEffectPlayed lumps those in with other players' sounds.
Issue #17111 for the dragon pickaxe special is similar.


DBZ-78 fix hero image

Looks good, but what about the "read more" indicator?

I saw that as well. I couldn't find anything in the other posts. How does it work? @gunnarmorling

E.g. see here: https://raw.githubusercontent.com/debezium/debezium.github.io/develop/blog/2020-03-19-integration-testing-for-change-data-capture-with-testcontainers.adoc. Look for "++++++"


RFC: dynamic resource allocation prototype

The purpose of this PR is to have a place where the https://github.com/pohly/kubernetes/commits/dynamic-resource-allocation branch can be discussed and commented upon. The PR itself will never get merged.
To try out the new feature, run a local cluster:
$ make
$ FEATURE_GATES=DynamicResourceAllocation=true  RUNTIME_CONFIG=cdi.k8s.io/v1alpha1 CONTAINER_RUNTIME_ENDPOINT=unix:///var/run/crio/crio.sock LOG_LEVEL=6 ENABLE_CSI_SNAPSHOTTER=false API_SECURE_PORT=6444 ALLOW_PRIVILEGED=1 hack/local-up-cluster.sh -O

Run the example resource driver controller:
$ export KUBECONFIG=/var/run/kubernetes/admin.kubeconfig
$ go run ./test/integration/cdi/example-driver -v5 controller

Create some objects:
$ kubectl create -f test/integration/cdi/example-driver/deploy/example/resourceclass.yaml
resourceclass.cdi.k8s.io/example created
$ kubectl create -f test/integration/cdi/example-driver/deploy/example/pod-inline.yaml
pod/pause created
$ kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
pause   1/1     Running   0          12s
$ kubectl get resourceclaims
NAME             CLASSNAME   ALLOCATIONMODE   PHASE       AGE
pause-resource   example     Delayed          Allocated   81s

At this point, resource allocation and scheduling are implemented. The kubelet support is missing.

There is now an official PR for this code which replaced this PR here: https://github.com/kubernetes/kubernetes/pull/111023


VM parameters for VMWare_Fusion

We allow user to set memory, cpu on VirtualBox.
It should be also available for VMWare.
config.vm.provider "vmware_fusion" do |v|
v.vmx["memsize"] = "1024"
v.vmx["numvcpus"] = "2"
end

It looks that there is no CPU capping, so only memory and cpus will be supported.
Ready on master, will be released with 0.26.0.


(DON'T MERGE) Add PPP

Codecov Report

Merging #187 (42b6022) into master (4f01662) will decrease coverage by 0.18%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #187      +/-   ##
============================================
- Coverage     67.14%   66.96%   -0.19%
- Complexity      709      710       +1
============================================
  Files           112      114       +2
  Lines          2420     2431      +11
  Branches        245      245
============================================
+ Hits           1625     1628       +3
- Misses          686      694       +8
  Partials        109      109

Impacted Files
Coverage Δ

src/main/java/teletubbies/model/ModelManager.java
79.23% <0.00%> (-3.17%)
:arrow_down:

...ava/teletubbies/logic/commands/ProfileCommand.java
86.66% <0.00%> (-0.84%)
:arrow_down:

...ies/logic/commands/uieffects/ImportUiConsumer.java
0.00% <0.00%> (ø)

...bies/logic/commands/uieffects/MergeUiConsumer.java
0.00% <0.00%> (ø)

...ies/logic/commands/uieffects/ExportUiConsumer.java
52.63% <0.00%> (ø)

...letubbies/logic/commands/ConfirmExportCommand.java
80.00% <0.00%> (+24.00%)
:arrow_up:

.../java/teletubbies/logic/commands/MergeCommand.java
87.50% <0.00%> (+59.50%)
:arrow_up:

Continue to review full report at Codecov.

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


Allow defining/overriding the name for the generated provider (and all helper types)

I wan my provider function to be private, but the generated provider to be public. (I don't want anybody try to call the function.) The generator derives the name of the provider and all of the generated helpers form the function name, so if it contains the _ prefix (making it private to the library), the generated stuff also has it (and so is also private).
It would be nice to be able to configure the generator more to allow somehow help it decide about the names.

Duplicate of https://github.com/rrousselGit/riverpod/issues/2244


Question: Multiple virtual hosts and ports in the same container

Is it at all possible to configure a single container to use two different domains, each mapped to a different port on the same container? E.g. api.test.com on port 9000 and test.com on port 8080

"Multiple hosts can be separated using commas." -- https://github.com/nginx-proxy/docker-letsencrypt-nginx-proxy-companion/blob/master/docs/Basic-usage.md#step-3---proxyed-containers
See also nginx-proxy regarding it's ability to specify ports. That's probably where you would want to open this issue to see if it is addressable.


Add Middleware to support CORS headers

fixes #287

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
3838

Relevant Lines:
3955

💛  - Coveralls


Disable AFD Backend Pool's Backend Host with Azure Cli

Im trying to update an existing backend host of a AFD backend pool to have its status from Enabled to Disabled.
Is there a way to update existing backend host using the Azure cli?
Currently, i can only see add, list and remove in the docs:

az network front-door backend-pool backend add
az network front-door backend-pool backend list
az network front-door backend-pool backend remove

Is there one for update?
FYI, im trying to toggle the below setting.

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

ID: d16042b8-fdcd-262b-64b4-7703e926db42
Version Independent ID: f9b55bda-90a5-40ed-f837-c0dee291693f
Content: az network front-door backend-pool backend
Content Source: latest/docs-ref-autogen/ext/front-door/network/front-door/backend-pool/backend.yml
GitHub Login: @rloutlaw
Microsoft Alias: routlaw

add to S172

@gaz91au Hi. Sorry that currently we can just add a rule and remove a rule. I checked this toggle. We haven't support it right now. I would mark this issue as feature request and plan for it. @aramesh-msft FYI as well.

thanks @yonzhan and @MyronFanQiu
i found that i can update the backend status by using the azure rest api.
We can use Rest API to set the backend pool backend status to Disabled for the backend pool using the below commands:
Firstly, run the GET command on Azure FrontDoor. Using that command we can see the properties for the backend pool backend status. In which, we can set the property – enabledState=Disabled to disable to backend pool and further on running the Create or update API command, the state of the backend pool will also be updated.

Example:
   "backends":[
            { "address":"web.azurewebsites.net","httpPort":80,"httpsPort":443,"priority":1,"weight":50,"backendHostHeader":"web.azurewebsites.net","enabledState":"Disabled"
Here are the articles for reference:

Get Command: https://docs.microsoft.com/en-us/rest/api/frontdoorservice/frontdoor/frontdoors/get
Create or Update: https://docs.microsoft.com/en-us/rest/api/frontdoorservice/frontdoor/frontdoors/createorupdate


feat: add instance_name field to plugin schema

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

Coverage data is based on head (0bb7366) compared to base (41237c5).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #280   +/-   ##
=======================================
  Coverage   53.52%   53.52%
=======================================
  Files          50       50
  Lines        4652     4652
=======================================
  Hits         2490     2490
  Misses       1634     1634
  Partials      528      528

Flag
Coverage Δ

2.1.4
36.45% <ø> (ø)

<IP_ADDRESS>
46.02% <ø> (ø)

2.2.2
36.45% <ø> (ø)

2.3.3
38.17% <ø> (ø)

<IP_ADDRESS>
46.02% <ø> (ø)

2.4.0
38.26% <ø> (ø)

<IP_ADDRESS>
46.02% <ø> (ø)

2.5.1
38.26% <ø> (ø)

<IP_ADDRESS>
46.02% <ø> (ø)

2.6.0
38.26% <ø> (ø)

<IP_ADDRESS>
46.02% <ø> (ø)

2.7.0
38.26% <ø> (ø)

<IP_ADDRESS>
47.69% <ø> (ø)

2.8.0
38.26% <ø> (ø)

<IP_ADDRESS>
47.69% <ø> (ø)

3.0.1
37.66% <ø> (ø)

<IP_ADDRESS>
48.19% <ø> (ø)

3.1.0
39.29% <ø> (ø)

<IP_ADDRESS>
49.82% <ø> (ø)

community
39.96% <ø> (ø)

enterprise
50.42% <ø> (ø)

enterprise-nightly
49.82% <ø> (ø)

integration
53.52% <ø> (ø)

nightly
39.35% <ø> (ø)

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

Impacted Files
Coverage Δ

kong/types.go
34.17% <ø> (ø)

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

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

@Kong/team-k8s Can we get this feature addition approved and generate a new release so that we can digest this field?

Ouch, I merged a bit too fast and forgot to request a changelog entry. Do you mind adding that and then we can create a new version with that change?

@pmalek  my bad: https://github.com/Kong/go-kong/pull/282


WIP: Add support for API keys

Description

Motivation and Context
https://github.com/cloudfoundry/stratos/issues/4504
How Has This Been Tested?

Tested manually, I haven't updated the test suite yet.
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] Docs update
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have followed the guidelines in CONTRIBUTING.md, including the required formatting of the commit message

Codecov Report

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

@@           Coverage Diff           @@
##           master    #4515   +/-   ##
=======================================
  Coverage   58.85%   58.85%
=======================================
  Files         897      897
  Lines       29248    29248
  Branches     4220     4220
=======================================
  Hits        17214    17214
  Misses      12034    12034


Emojify CDN broken?

When trying to add the emojify plugin it looks like the CDN is broken?
Screenshot: http://prntscr.com/hds52e

SVG:
https://cdnjs.cloudflare.com/ajax/libs/emojify.js/1.1.0/images/basic/bowtie.svg
^ seems to return "not found"

PNG
https://cdnjs.cloudflare.com/ajax/libs/emojify.js/1.1.0/images/basic/bowtie.png
^ seems to work

But the plugin is using SVG to load the emotes?

Then why doesn't it work for me? Also in my "inspect element" it shows svg stuff

@RwbyChan show your code

It's a whole app.js so I cut out the parts from the editor
emojify.setConfig({
        img_dir : 'https://cdnjs.cloudflare.com/ajax/libs/emojify.js/1.1.0/images/basic/',
    });

$(".wysiwyg-editor")[0] && $(".wysiwyg-editor").trumbowyg({
            autogrow: !0,
            btns: [
                ["viewHTML"], ['emoji'],
                ["formatting"],
                ["link"],
                ["insertImage"], "btnGrp-justify", "btnGrp-lists", ["horizontalRule"],
                ["removeformat"],
                ["fullscreen"]
            ]
        }) && emojify.run(), $('.trumbowyg-editor').on('input propertychange', function() {
            emojify.run()
        })

Try without the last Trailing Slash.
img_dir : '//cdnjs.cloudflare.com/ajax/libs/emojify.js/1.1.0/images/basic',
Did the trick for me.

We met the same issue!


PHP OCI8

Hi @davidalger
I would like to know if it would be possible to integrate OCI8 in Warden and how please.

@franz177 have you tried running pecl install oci8 in the php-fpm container?

Hello @tdgroot,
I accessed the container with the warden shell command but the pecl command is not found.
I also tried to install it but apt-get doesn't exist
Thanks in advance for the support

@franz177 pecl is not available in the container by default. You can install it using sudo dnf install php-pear.

I receive this error after executed pecl install oci8
Can't find PHP headers in /usr/include/php The php-devel package is required for use of this command. ERROR: 'phpize' failed

@tdgroot I installed php-delev that resolved phpize error. Now i'm receving the follow error:
configure: WARNING: OCI8 extension: ORACLE_HOME is not set, looking for default Oracle Instant Client instead checking Oracle Instant Client directory... configure: error: Oracle Instant Client directory /usr/lib/oracle/.../client64/lib libraries not found. Try --with-oci8=instantclient,DIR ERROR: '/tmp/pear/install/oci8/configure --with-php-config=/bin/php-config --with-oci8' failed

Please note this official Docker Image:
https://github.com/oracle/docker-images/tree/main/OracleInstantClient
Could it be added in the Warden configuration?

@franz177 apparently, the php-oci8 package is also available by the Remi repo: https://blog.remirepo.net/post/2020/05/18/Installation-of-Oracle-extensions-for-PHP.
Try installing it using dnf install php-oci8.

Hello @tdgroot,
I executed the following commands:
sudo dnf install php-pear
sudo dnf install php-oci8
sudo dnf install libaio
sudo sudo rpm -i oracle-instantclient-basic-<IP_ADDRESS>.0-1.x86_64.rpm.
The oci_connect function returns an error from the Nginx Web server while it is working correctly from the CLI.
This is the detail of the error in the Frontend: Fatal error: Uncaught Error: Call to undefined function oci_connect()
I look forward to hearing from you

Hi @tdgroot,
I resolved it.
I added the follow instructions on zz-config.ini: env[LD_LIBRARY_PATH]=/usr/lib/oracle/21/client64/lib clear_env = no
Thanks for support


NPE when --scrub option is used with support-diagnostics-6.2

Using the support-diagnostics-6.2 with --scrub option throws NullPointerException:
./diagnostics.sh --ssl -u elastic -p  --scrub --host node1.local
...
Password redaction: elasticsearch config.
Error redacting config passwords.
java.lang.NullPointerException: null
	at com.elastic.support.diagnostics.commands.ScrubPasswordsCmd.execute(ScrubPasswordsCmd.java:39) ~[support-diagnostics-6.2.jar:6.2]
	at com.elastic.support.diagnostics.commands.AbstractDiagnosticCmd.execute(AbstractDiagnosticCmd.java:15) [support-diagnostics-6.2.jar:6.2]
	at com.elastic.support.diagnostics.chain.Chain.execute(Chain.java:33) [support-diagnostics-6.2.jar:6.2]
	at com.elastic.support.diagnostics.chain.DiagnosticChainExec.runDiagnostic(DiagnosticChainExec.java:41) [support-diagnostics-6.2.jar:6.2]
	at com.elastic.support.diagnostics.DiagnosticApp.main(DiagnosticApp.java:66) [support-diagnostics-6.2.jar:6.2]
Password removal failed - please examine archive to ensure sensitive information is removed.
Finished processing logs and configuration files.
Scrubbing elasticsearch logs and configuration using scrub.yml.
Scrubbing was enabled but no substitutions were defined. Bypassing log and configuration file processing.
Writing diagnostic manifest.
Archiving diagnostic results.
Archive: /home/unmui/support-diagnostics-6.2/diagnostics-20171109-083154.tar.gz was created
Deleting temporary directories.

It appears this was run without sudo. if it's a package install the diagnostic will not be able to read the /etc folder and thus the config files. So it will fail. Please try again using sudo.

@nemonster you're perfectly right, it runs fine with sudo!! sorry for the noise!


RetryInterceptor for Websocket connection

Start by telling us what problem you’re trying to solve. Often a solution already exists!
I am using OkHttp to establish a WebSocket connection as below :
        try {
            request = new Request.Builder()
                    .url(getConnectionRequestUrl())
                    .addHeader("Sec-WebSocket-Protocol", "graphql-ws")
                    .build();
        } catch (JSONException e) {
            callback.onFailure(...);
        }
        listener = new AppSyncWebSocketListener(...);
        websocket = okHttpClient.newWebSocket(request, listener);

Adding retry interceptor to the okHttp client does not invoke retry interceptor for websocket connection failure due to network loss unlike http client. Is there a recommended way to deal with websocket connection retries?
Don’t send pull requests to implement new features without first getting our support. Sometimes we leave features out on purpose to keep the project small.

Nothing fancy built in. Try this? https://github.com/Tinder/Scarlet

Closing as low priority


Replace 1.e9 with HIGH_CHI2 throughout

It would be more robust to use the variable everywhere.

agreed.


Setup GitHub Actions CI

TO-DO

[ ] py
[ ] rb
[ ] js
[ ] java

@lonewolf3739 i can take up Java after the base commit is checked-in.


Prevents running the build workflow on draft PRs

This workflow is quite slow, due the need to download and package a real rootfs.
We need to figure out ways to make it faster, but in the meanwhile, let's skip it for draft PR's until they are marked as ready for review.

The screenshot shows it disabling the worflow:

And now, after marking as ready for review:


Opinionated and battle tested... on TypeScript

Intro
I am starting with Rust, but I am no beginner. I started writing code 40 years ago, in middle school. Then I graduated Computer Science with deep knowledge of K&R C, in a day and age where linters were not whiny bitches forcing every polygonal peg into round holes that fit no one but give the less enlighted a comfortable sense of belonging.
 Why?
In 1988, one of my first assignments in my freshman year at uni was to develop a text editor. In PASCAL! Well, believe it or not, after 2 weeks the whole thing worked, even justified text and, most of all, wrapped lines. Later that semester, we moved to UNIX and I found out VI, the still unchallenged superior editor. VS Code is not too bad, though.
Something common to both VI and VS Code is that shockingly they both wrap lines! Worse, still: both these break indented lines with the indentation of the first line! Can you imagine this? And all available for decades!
And still linters and so-called beautifiers insist on this crap! And, opinionated as they insist on being, there is no opting out. In fact, there is no configuration at all for this extension!
Do as I say, or } else {...
Another "battle tested" feature is the æternally disgusting decision that some avant garde visual artist took that else cannot be in a line of its own, but rather inline with if's closing }. As usual, the error is not one cretin putting this out, but rather millions of cretins following it and transforming it into Law. Thank God poor Dennis Ritchie did not live to see this, but Brian Kernighan is still around.
This is not a case where millions of people can't be wrong, because indeed they are. And if you need examples proving that the majority could be devastatingly wrong, here are a few:

Trump
Jair Bolsonaro
Java
C++

Opinionated... in a foreign language
The cherry on top — or, in this case, the fly atop the turd — is that the formatting has been battle tested by millions of people... from TypeScript! So, we go and take a shitty set of rules from another language and we just bring it into Rust! Why??? In order to atratc people from the other side of the fence? Yes, that went just great when JavaScript got its first half of the name from Java because there was the hope to attract people from_there_.
Rust has a golden chance to be its own new thingm no strings attached. And it is! You guys are trying to drag it through the mud, though. TypeScript linters actually produce an ERROR if you don't leave a space between the function name and the argument opening parenthesis, in the function definition. And this is the well from where you pulled your buckets of inspiration.
But should it all be anarchy?
Hell NO! We certainly all benefit from some measure of consistency, and it is true that people that don't leave a space after a comma should be taken outside, unceremoniously shot in the head and left for the scavenger beasts. But none of this actually addresses things that don't compile-and-run but still matter!
For instance, I'd much prefer a linter that whined about lack of docstrings, or even one that added these in template form. Just like breaking long lines, docstrings don't run, but do they add value to the development process! And this is all still within the scope of static analysis.
The way you seem to be wired, I can see the next generation of this producing docstrings... and breaking long lines on them!
Finally
Go read a book! I always suggest Salman Rushdie, because it's wonderful and requires absolutely no endorsement. But in your case, I'd have to recommend William Faulkner. After the first few 2-page-long SENTENCES, you might actually develop some reading ability beyond Twitter and you might actually realise how incredibly STUPID it is to break "long" lines in code.
If you read this far, good on you! There is hope, after all.

Hello @ricardo-reis-1970, thank you for sharing a glimpse of years of your experience. I do appreciate this sometimes.
I'm not a maintainer on any Prettier repositories, but I've been using Prettier for TS and JS for a long time and am accustomed to it. Furthermore, I even write code like how Prettier formats when I work on something that doesn't have a Prettier setup.
Personally, it's just a matter of perspective, and to me, snake case is blasphemy, an unorthodox invention, but for the sake of getting to learn and use Rust, I get along.
I've come across with some alternative plugins you can use to format a Rust file. Maybe you can try one of those?

rust-fmt (I believe it's configurable)
Trunk (uses rust-fmt under the hood)


Viewing differences just shows directory listing (without vifm)

When aurutils wants me to review a package’s contents, it opens less but just shows a list of files. I then need to manually use :e to examine them. I have neither PAGER nor AUR_PAGER set, but the problem persists even when I try different environment variable values. I do not have vifm installed.
Before filing a bug, check the following:

Do you use the latest release of aurutils and its dependencies? If so,
is the issue reproducible from the master branch?

I used the latest release; I’ll try on the master branch in a bit and post an update.

Does the package conform to

I believe so, but my issues is seen across a wide variety of packages and before that should be relevant.

Does the package provide the correct metadata on the

See above

Does the package build with makepkg -s or extra-x86_64-build ?

Yes, but see above

Is the problem reproducible, and not due to a misconfiguration of
pacman, makepkg, sudoers, gpg or others?

Yes
If yes to all, create a debug log:
Doing this created another problem: the pager wasn't used at all; I didn't get a chance to review the files (I had done so before running the command, in this case, but still that’s an issue). You can see at the top that it just lists the files, and does not show their contents.
AUR_DEBUG=1 AURDEST=${PWD} aur sync -c btrfs-snapshot > aurutil.log

aurutil.log

I think I had made that suggestion for less on IRC but it fell through the cracks of time.
But pagers in general are a poor interface for doing this kind of review.
We could preserve the behaviour of showing the file list, but also show the files themselves next. It works for less and more but might not work for others.
One thing I didn't like was that the review was too easily dismissed if you type q. You can argue this is an "Doctor, it hurts when I shoot my foot" , but I believe it would be a common mistake. I.e. looking at the first file, then dismissing the entire queue by pressing q.
less is being used as a simple fallback. We don't want to force users to install vifm when they intend to use something else via
AUR_PAGER.
We could take this the complete opposite direction as well, be opinionated and refuse to run if vifm is not installed or AUR_PAGER is not set. (renamed to something else) . And completely drop pager support. :smiling_imp:
This might be a harsh decision, but seems that the fact we fallback to less makes users miss the point they can use AUR_PAGER with anything they like. Including the alternatives mentioned in this issue.
related: #51

When you used $PAGER instead of $AUR_PAGER, the pressing q issue doesn’t appear; it has a fallback of asking you to press enter or ^D. If I set $AUR_PAGER as an attempted workaround here, I need to also handle that (with -+K some other solution).
(By the way, I did get around to testing this with the Git version and it still happened)

Yeah, let's just drop support for less.

In that case can we at least get an option to not trust $AUR_PAGER? Currently I’m using AUR_PAGER=atom -w (which has various problems long-term but I don’t want to install vifm and I haven’t written my own version yet), but I don’t think it has a way to change its exit status for approval.

Could you clarify what do you mean by "not trusting" and what do you propose? If there is no support to exit with code 1 in atom,  your review will be considered as "passed" and you will move on to building the packages.

Currently, if I set $PAGER instead of $AUR_PAGER or using vifm or using the less -K -+F fallback, https://github.com/AladW/aurutils/blob/master/lib/aur-sync#L359-L362 will run, and it will give me a chance to press ctrl+d instead of trusting the pager’s exit status.

In that case can't you just make a wrapper script with something like:
#!/bin/bash
atom -w $1
read -rp $'Press Return to continue or Ctrl+d to abort\n'

and use that as your $AUR_PAGER?

I don't think there's another way to make GUI file managers work with exit codes. Does this answer the question?

We could take this the complete opposite direction as well, be opinionated and refuse to run if vifm is not installed or AUR_PAGER is not set. (renamed to something else) . And completely drop pager support.

When would you check for  this? Right after option parsing, or let the code fail inside the view block?

Yeah, I’m using that as my AUR_PAGER. It isn’t ideal (atom thinks that all the files are writeable, but if I write to them I’d lose the changes with the next update so they shouldn’t be), but it’s good enough. My objection is that the code already exists in aur-sync, and I think aur-sync should let me use its version instead of making me copy the code to a shell script.


Kosli concepts on docs.kosli.com

Describe organizations, environments, pipelines

any additional pages that we may need to make Kosli easier to understand for newcomers

WiP on docs-refactoring


Provide artifact name in droplet download action

When an application crashes at the moment due to droplet download
failures, users just see Downloading failed in the crash reason
because the artifact name is not provided in the DownloadAction

[x] I have reviewed the contributing guide

[x] I have viewed, signed, and submitted the Contributor License Agreement

[x] I have made this pull request to the master branch

[x] I have run all the unit tests using bundle exec rake

[ ] I have run CF Acceptance Tests

Looks good @sunjayBhatia. One thing I noticed, though, was your commit was made by Diego. Was that intentional?

@tcdowney nope, I can fix that real quick


[cli-translator] Fix can't recognize ~ in path problem

This checklist is used to make sure that common guidelines for a pull request are followed.

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your PR is merged into master branch, a new PR will be created to update src/index.json automatically.
The precondition is to put your code inside this repo and upgrade the version in the PR but do not modify src/index.json.

If this PR is for a new extension or change to an existing extension, use the following to try out the changes in this PR:
docker run -it mcr.microsoft.com/azure-cli:latest
export EXT=<NAME>
pip install --upgrade --target ~/.azure/cliextensions/$EXT "git+https://github.com/arrownj/azure-cli-extensions.git@translator_fix#subdirectory=src/$EXT&egg=$EXT"


Unit Test case for SFM3019 Device

Unit Test case for SFM3019 Device file

@ethanjli  This pull request is ready to review.

@ethanjli This pull request is ready for review.

For records-keeping:
This project is licensed under Apache License v2.0 for any software, and Solderpad Hardware License v2.1 for any hardware - do you agree that your contributions to this project will be under these licenses, too? - Yes
Were any of these contributions also part of work you did for an employer or a client? - No
Does this work include, or is it based on, any third-party work which you did not create? - No


Raise a ResponseError for FedEx#find_tracking_info

In a couple of places we were raising an ActiveShipping::Error when we could raise/return a more informed ActiveShipping::TrackingResponse(false, ...) that has additional information (e..g, response, request) for clients of this gem.
The one point of discussion here is w.r.t. the semantics of ResponseError. Generally it means there was an issue in the response, but for these two cases I've changed aren't considered error responses by FedEx, and aren't given special status codes (i.e., /TrackReply/Notifications/Code is 0), so perhaps this doesn't make sense?
Also made a few small formatting changes on nearby code (separate commit).

Updated

Okay, I added one more commit which was the actual real issue that needed to be dealt with here, but we can keep the TrackingResponse code here too.
tl;dr we were only looking at the success status from the document root, and in a TrackDetails element, but forgetting to check CompleteTrackDetails. I've updated the test to capture this case.

^ Squashed it into two, cohesive commits that I'll merge (they don't make sense to merge together)


pytest temporary test directory should use __file__

Currently, we can only run pytest from the project root directory so that TMP_DIR is a valid path to the temporary test directory: https://github.com/CABLE-LSM/benchcab/blob/f7ba1f076f54750aade09686de48aefdaea44b45/tests/common.py#L3-L5
https://github.com/CABLE-LSM/benchcab/blob/f7ba1f076f54750aade09686de48aefdaea44b45/tests/test_task.py#L22-L27
Instead of using the current working directory, we should use __file__ to get the temporary test directory so that pytest runs correctly from any directory.

Good point, using $TMPDIR is probably the right way to do it


Dev

Checklist

[x] You have read the Contribution Guidlines before creating this PR.
[x] You created a branch from dev branch
[x] Blog follows Blog Guidelines.
[x] Checked for all grammatical errors in the blog.
[x] Checked for any duplicate blog entry.
[x] You PR is raised on dev branch and not onmaster.

Description of change

Author Details for Blog Post Entry

@shivaylamba  Please update the PR title to reflect your changes.


Docker: storefront and dashboard throw NPM errors, but others work fine

Installation
Followed installation guide by installing and running Docker Desktop (Windows 10) and executing these commands:
git clone https://github.com/mirumee/saleor-platform.git --recursive --jobs 3
cd saleor-platform
docker-compose build
docker-compose run --rm api python3 manage.py migrate
docker-compose run --rm api python3 manage.py collectstatic --noinput
docker-compose run --rm api python3 manage.py populatedb
docker-compose run --rm api python3 manage.py createsuperuser
docker-compose up

API (backend): good
Backend API works fine on port 8000:

Storefront and dashboard: NPM errors
But storefront and dashboard throw errors:

Storefront error log
storefront_1  |
storefront_1  | ><EMAIL_ADDRESS>start /app
storefront_1  | > cross-env NODE_ENV=develop webpack-dev-server --history-api-fallback --watch --port 3000 --mode development --hotOnly "--hostname" "<IP_ADDRESS>"
storefront_1  |
storefront_1  | sh: 1: cross-env: not found
storefront_1  | npm ERR! code ELIFECYCLE
storefront_1  | npm ERR! syscall spawn
storefront_1  | npm ERR! file sh
storefront_1  | npm ERR! errno ENOENT
storefront_1  | npm ERR<EMAIL_ADDRESS>start: `cross-env NODE_ENV=develop webpack-dev-server --history-api-fallback --watch --port 3000 --mode development --hotOnly "--hostname" "<IP_ADDRESS>"`
storefront_1  | npm ERR! spawn ENOENT
storefront_1  | npm ERR!
storefront_1  | npm ERR! Failed at the<EMAIL_ADDRESS>start script.
storefront_1  | npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
storefront_1  | npm WARN Local package.json exists, but node_modules missing, did you mean to install?
storefront_1  |
storefront_1  | npm ERR! A complete log of this run can be found in:
storefront_1  | npm ERR!     /root/.npm/_logs/2021-04-30T03_31_03_452Z-debug.log
saleor-platform_storefront_1 exited with code 1

Dashboard error log
dashboard_1   |
dashboard_1   | ><EMAIL_ADDRESS>start /app
dashboard_1   | > webpack-dev-server -d "--host" "<IP_ADDRESS>"
dashboard_1   |
dashboard_1   | sh: 1: webpack-dev-server: not found
dashboard_1   | npm ERR! code ELIFECYCLE
dashboard_1   | npm ERR! syscall spawn
dashboard_1   | npm ERR! file sh
dashboard_1   | npm ERR! errno ENOENT
dashboard_1   | npm ERR<EMAIL_ADDRESS>start: `webpack-dev-server -d "--host" "<IP_ADDRESS>"`
dashboard_1   | npm ERR! spawn ENOENT
dashboard_1   | npm ERR!
dashboard_1   | npm ERR! Failed at the<EMAIL_ADDRESS>start script.
dashboard_1   | npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
dashboard_1   | npm WARN Local package.json exists, but node_modules missing, did you mean to install?
dashboard_1   |
dashboard_1   | npm ERR! A complete log of this run can be found in:
dashboard_1   | npm ERR!     /root/.npm/_logs/2021-04-30T03_31_08_589Z-debug.log
saleor-platform_dashboard_1 exited with code 1

For me, frontend works but the website is not up I tried it 3 times after remove all volumes and images via docker system prune -a and docker system prune --volumes

@prashantidealittechno
Observations
Windows Docker tested a couple of days ago:

Backend API was fine
Dashboard threw NPM errors
Storefront threw NPM errors

Linux Docker tested yesterday:

Backend API is fine
Dashboard is fine
Storefront throws NPM warnings and doesn't load the storefront website

I also have a problem with my Linux. I found that changing the argument of the frontstore service in docker-compose.yaml from --hostname to --host resolve this problem.

As hinted by @ptmew , such a commit resolved the storefront issue on Linux:
diff --git a/docker-compose.yml b/docker-compose.yml
index c53b920..ac34d90 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -39,7 +39,9 @@ services:
     volumes:
       - ./saleor-storefront/:/app:cached
       - /app/node_modules/
-    command: npm start -- --hostname <IP_ADDRESS>
+    command: npm start -- --host <IP_ADDRESS>

Now the storefront is available at http://localhost:3000

I don't care about Windows anymore. So, I cannot test on the Windows platform.

@ptmew Just curious, how did you figure out to replace --hostname with --host? Did you just randomly do trial-and-error? Did you have any hint from somewhere? What was your research process? Thanks!

I got the same issue. I followed the exact steps in saleor-platform repo, the api and the dashboard were just working fine, but the storefront. I also changed from --hostname to --host and it worked. Actually in the docker-compose, it is also like this for the dashboard.

Issue resolved

hos

this is running via docker and configured on a domain.. but this api is running on a localhost on a server... any idea what wrong ?


SQL Editor: SQL Assist and Auto-Complete - Fail [D15]

Problem in:
Step 3: no identifiers are offered if to press Ctrl+Shift+Space
.(Another auto-complete function is search for completion only within already entered identifiers - press Ctrl+Shift+Space)
.

Created by TestQuality - Linked to TestQuality.com defect D15. Do not remove or edit. D15

Cannot reproduce in later versions


AB#4396

Proposed changes

Related issues

Checklist

[x] I consider the submitted work as finished
[x] I tested the code for its functionality
[ ] I wrote test cases for the relevant uses case
[ ] I added/update the relevant documentation (either on github or on notion)
[ ] Where necessary I refactored code to improve the overall quality

Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

I ran this PR locally and did not see the "Last Scanned" field or anything that resembled it on device or software assets


Module not found: Error : Can't rezolve 'nativescript-material-bottomsheet`

If I use only nativescript-material-ripple I got this warning.
WARNING in ../node_modules/nativescript-material-core/core.js
Module not found: Error: Can't resolve 'nativescript-material-bottomsheet' in '/Users/.../myApp/node_modules/nativescript-material-core'
 @ ../node_modules/nativescript-material-core/core.js
 @ ../node_modules/nativescript-material-ripple/ripple.js
 @ ./main.ts

@alexandruantonica indeed you get this warning. Will be removed in the next releases.

@alexandruantonica  should be fixed in 2.2.16

@farfromrefug Thanks for the change :) It solved the warning, indeed. I'm using 2.2.17 and no warning message from material-ripple but...  😄
WARNING in ../node_modules/nativescript-material-core/core.js
Module not found: Error: Can't resolve 'nativescript-material-bottomsheet' in '/Users/alexa/Workspace/Tappter/tappter-app/node_modules/nativescript-material-core'
 @ ../node_modules/nativescript-material-core/core.js
 @ ../node_modules/nativescript-material-button/button.js
 @ ./main.ts

I forgot to mention I use the nativescript-material-button as well.

Hi @alexandruantonica indeed the problem is that the button has nativescript-material-core as a dependency for theming purposes and right now the nativescript-material-core has a function called install() that requires de nativescript-material-bottomsheet module, as a workaround I suggest you install the nativescript-material-bottomsheet module to avoid that warning if you are getting problems in your app. Until a fix is released 😄

@henrychavez Cool. I will keep it like that, it's just a warning.
Your idea will make the size of my app a bit bigger and it is a bigger problem than just a warning.
Thanks ;)

#31

@alexandruantonica can we close this?

@farfromrefug Sure.


Test Issue created at Sun, 11 Jul 2021 02:16:29 GMT

Test issue body  Sun, 11 Jul 2021 02:16:29 GMT

Comment on issue at Sun, 11 Jul 2021 02:16:31 GMT


Libsvm with unordered features breaks gpu_hist

A libsvm file with a row such as below creates undefined behaviour
0 1:3400 0:170
The gpu_hist algorithm assumes that rows of data are ordered by feature. It uses binary search over sparse rows to find specific matrix elements, and the binary search fails due to incorrect ordering. There may be other cases of this assumption inside xgboost that I am not aware of.
The bug is very subtle and manifests in slightly incorrect training results where the algorithm designates elements as missing because the binary search can't find them.
We need some way to detect such cases and log a fatal error, preferably across all xgboost algorithms. We can modify the dmlc parser to check for this case, although it is not strictly wrong according to any specification, or we could detect it somewhere in xgboost constructors.

I think I may have seen this issue in one of the CPU algorithms (most probably approx) when I was creating libsvm files by hand to test out stuff.
The libsvm format assumes that features are order as well or is that only in XGBoost?

The libsvm format checker does seem to indicate that features should be ordered, see at the end of this readme: https://github.com/cjlin1/libsvm/tree/master/tools
I think we can do the validation directly in dmlc parser.


Example not working when creating Power BI Private Endpoint

Hello community and page owner,
I am trying to build a demo to one of the enterprise clients and I want to show Power BI Private Link solution and how Power BI can access resources privately in their tenant vNet.
I followed the whole exercise and I tried so many things. When reaching the step of provisioning the Private Endpoint, I get an error saying: No supported sub-resources
In brief, I created successfully the privateLinkServicesForPowerBI resource. I already have vNet and subnet all in the same Azure region as the Power BI service "West US 2".
When creating the private endpoint, I followed the same steps till I got the error "No supported sub-resources" at the point of selecting the created resource. The portal does not allow me to proceed to enter tenant at the field: Target sub-resource
I found a workaround by selecting "Connect to an Azure resource by resource ID or alias". When pasting the resource ID, I am able to proceed; however, the service is created with Pending approval and I couldn't proceed right after.
No web resources to help on this issue. I have been diligently trying for the past couple of days with no luck.
I am the global admin of my personal tenant and also my Power BI service.
Will you be able to comment on this issue, so I can proceed with my demo?
I also have screenshots if needed.
You can email me back to my work email address<EMAIL_ADDRESS>Regards,
Oussama
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 63c8b8f9-7455-6a1a-cf10-cfd6ae088484
Version Independent ID: d0a2380f-c19d-916a-1416-f9bc7fdc72bc
Content: Private endpoints for accessing Power BI - Power BI
Content Source: powerbi-docs/admin/service-security-private-links.md
Service: powerbi
Sub-service: pbi-security
GitHub Login: @davidiseminger
Microsoft Alias: davidi

Thanks for your comment, @oussama70. This looks like a support request rather than documentation feedback. You might find a solution in the Power BI Community, found at https://community.powerbi.com. If not, you can get support by going to https://support.powerbi.com.
If your support experience or outcome specifically says that we need to update the steps, we'll certainly do so.


_FoundationCShims: enable building on Android

The strncasecmp_l was added at API level 23. For now, simply abort on older releases, though we should consider shimming the path.

@swift-ci please test


Allow for naming of methods when generating interfaces by endpoint

Is your feature request related to a problem?
I think it would be nice if it were possible to choose naming for methods when interfaces are generated ByEndpoint. Right now it is only possible to customize method names when all endpoints are in a single interface. When doing it for a single interface the {operationName} is a requirement, but I do not think this should be a requirement since there will only be one method in each interface.
Describe the solution you'd like
Example of how this could work:
{
    "openApiPath": "./openapi.json",
    "namespace": "Your.Namespace.Of.Choice.GeneratedCode",
    "multipleInterfaces": "ByEndpoint",
    "operationNameTemplate": "ExecuteAsync" // Default is Execute
}

The .refitter file above results in the following code:
/// <summary>
/// Update an existing pet
/// </summary>
public partial interface IUpdatePetEndpoint
{
    /// <summary>
    /// Update an existing pet by Id
    /// </summary>
    [Put("/pet")]
    Task<Pet> Execute([Body] Pet body);
}

/// <summary>
/// Add a new pet to the store
/// </summary>
public partial interface IAddPetEndpoint
{
    /// <summary>
    /// Add a new pet to the store
    /// </summary>
    [Post("/pet")]
    Task<Pet> Execute([Body] Pet body);
}

...

@all-contributors please add @Noblix for ideas


compare selected does not work properly the first time

Steps to reproduce the issue:
1 Launch: https://ec2instances.info/?compare_on=true&selected=c5.4xlarge,m5.4xlarge
I would expect the comparison to be done immediately, but I have to press "end compare" and then do a "compare selected" to get it working. I think the function is broken for the first load/ first button press or something?

What OS + browser? Was unable to repro with Firefox on macOS.

@centic9 @yourssvk is this still happening for you guys?

Seems to work for me now.


Configuration#3:Step#1: simulating alpha_S=0.4, matter: q_0=1 | matterlbt: q_0=1.5: matter05

run the simulation with the above config by jetscape,
transfer the final state hadron to the related directory named as config-XX-final-state-hadrons
after doing step1 on all 12 simulations go to step 2 for the configurationX

ported into Excel for overleaf


Better NoZoom and Recoil crosshairs

maybe an option to change recoil crosshair sizes, thickness and color? if possible

@wemanzoz
This feature already exists, but when the thickness value is 1.0, you will see the black ring, not the color, because it is too small, the default thickness value should be increased. or set the tickness value to at least 2.0
Each time you increase the thickness value, you will see that the color you selected is inside the black ring.

@wemanzoz
This feature already exists, but when the thickness value is 1.0, you will see the black ring, not the color, because it is too small, the default thickness value should be increased. or set the tickness value to at least 2.0
Each time you increase the thickness value, you will see that the color you selected is inside the black ring.

how to change the thickness value if i may ask?

@blackMasterLord is it possible for you to make it like "toggle anti obs noscope crosshair, or engine crosshair (not anti obs)


[Enhancement] Allow dispatching of multiple jobs / batch.

I might drop a PR for this eventually, but it's something we'd love - the ability to drop a chain / batch of jobs or operations that would ALL need to run for the operation to be complete.
The use case:
We found that migrating 500k rows was timing out on a single job, and i don't like to have a single queue that has unlimited or a super-long timeout as it can cause problems with stuck jobs, so being able to create a "batch operation" would be cool as heck, even if it just was as simple as implemented a BatchOperation interface that defined a "singleOperation" function or similar.
Then those could be dispatched as callables on the queue using a custom job, OR dispatched as closures.
Then that would allow you to specify a "final" job that maybe does some tidying up with a "finally()" method or similar.
All defined within one file similar to how it is now, but gives more flexibility.
Will have a look at a PR if i can get some time IF you like the idea?

I don't think, that I'm going to implement this, because it would be too much overhead just to implement this specific use case.
The thought behind this package is just starting an operation automatically after deployment. What happens after this "jump start" shouldn't be the job of this package.
You can still use the package just to start the Batch process, and you basically have the same result, right?
// 2023_06_16_135513_start_batch_operation.php

return new class extends OneTimeOperation
{
    protected bool $async = false;

    public function process(): void
    {
        Bus::batch([
            //
        ])->then(function (Batch $batch) {
            //
        })->catch(function (Batch $batch, Throwable $e) {
            //
        })->finally(function (Batch $batch) {
            //
        })->dispatch();
    }
};

Yeah, and this is basically what we're doing now!
My idea is probably because of our use case, and that's not something you maybe want to cover with this package, but I basically see it as a way of:
"quickly running one-time operations, or small data migrations quickly on deployment."
but possibly also, imagine being able to run larger operations like larger data migrations using batches and ALSO being able to Feature-flag code behind if the batch/operation has completed.
So you:

Push your code to production ,it starts the migration queued operation.
You have some code in your application that relies on the "new" structure of data, so you have a guard statement like if (Operation::isComplete('operation-name')) { to prevent users from accessing it until the migration has been ran.
OR you could integrate with Laravel Pennant to define a feature that is true/false depending on the operation status, something like: Feature::enabled('operation:operation-name') ? true : false etc.

To be fair: you could also do this with Atomic Locks already, but the package bringing it together would provide a lot of convenience.
might be out of the scope of what you want to provide, but also potentially something very cool and convenient.

might be out of the scope of what you want to provide

Yes, exactly! :D
It's kinda cool, that all the users have so many creative ideas on how this package could be expanded. But I want to keep it simple and lean and focus on the USP of this package.
But feel free to create a fork and realize your idea ;)

No problem man, thanks for chatting it out with me. Will close this now.