Feature installation order

As we are preparing to open up features to community contributions, we found that some features need to install after other features. This issue proposes to add support for soft-dependencies to arrive at a reproducible ordering following these ordering requirements:
A feature can declare a list of other features that should be installed first if they are configured to be installed. (The soft-dependency itself does not add another feature to the list of features to be installed.)
E.g., the NodeJS feature would list the Python feature because it has to install a system version of Python if no version of Python is already installed:
{
    "id": "node",
    "installAfter": [ "devcontainers/features/python" ],
    // ...
}

Features that an install in any order will be installed in a fixed order (e.g., ordered by id) to ensure the result is always the same.
The "features" map in the devcontainer.json will remain a map. See https://github.com/devcontainers/spec/pull/27/files#r869018039 for a discussion.
To allow for progress on user contributable features, we can use a stop-gap measure like an ordered list of features that depend on a specific installation order and either bake that into the CLI at build time or fetch it at runtime. This list will be temporary and documented as such.
/cc @Chuxel @jkeech @edgonmsft @joshspicer @bamurtaugh @alexdima

@chrmarti We'll still need some way to allow users ordering explicit in the feature object in devcontainer.json.
One way to do that could be to allow "installAfter" to also be explicitly mentioned by users in the object syntax as well.  e.g.
"features": {
    "common": "latest",
    "docker-in-docker": {
        "installAfter": "common"
    }
}

Explicit ordering allows end users to:

Have a well-known and predictable outcome as they add more features (given features need to adapt to the image contents). Reproducible image builds is a key best practice for creating container images.  An unordered dependency graph is not transparent or predictable over time since execution order influences what each feature does. Adding a new feature to the end of the list will not affect anything above it, while a random order can result in more material changes.

Examples include the relationship between the Node and Python features, and the Git from Source feature and most other features. Order can result in different behaviors in installing OS dependencies.
Similar problems can occur between features authored by multiple users that have no knowledge of one another – and thus no possible dependency graph.

Have a way for a developer to easily add a local script that runs as a part of this sequence, without getting into dependency management or complex conditional logic that adapts to different ordering or image scenarios.

Existing examples include installing the preview dev CLI into the Azure CLI, installing more go tools (via go install), adding desktop customization for the desktop-lite script, etc.
A local feature with a single script can be dropped into the ordered execution for this to happen.

Simplify image build debugging (and fixing) if something goes wrong – whether related to their own features, 3rd party ones, their Dockerfile, or base image. Reordering can reduce duplicate installation and work around bugs, but devs can also add local features as a workaround to install something missing, edit folder structures / add symlinks, etc at the exact right spot in the execution flow.

This is partially important when using features from multiple authors.
Any issues would otherwise be impossible to resolve. You’d have to abandon the features.

I believe we should provide some supported (ie permanent) mechanism for allow an end-user to control feature installation.  I think it is preferable that a user does not need to concern themselves with install order, but as a "break glass" solution it should be intuitive how to order when the need arises.

Not every feature will know about all other features - and there's other reasons below. Right now this is impossible, which has been problematic for early adopters.

I agree.  One solution to this is the array notation (proposed here).  I believe our tooling can (and should) implement some "ordering logic" that helps prevent a user from hitting obvious/identifiable error, but as a final solution a user should be given the tools to solve a problem themselves that could result from ordering.  I especially like @Chuxel 's point (2),  where users may want to prototype a feature locally or perform a simple extension via features.
The implementation of container features today is inherently ordered due to the programatic injection of Dockerfile RUN lines for each feature.  Preventing a user from altering (or at the very least overriding), will create situations where a user may need to fallback to manually editing their Dockerfile. In my view, the fundamental goal of features is to abstract away (for an end-user) the need to have any dockerfile at all in their project, i n lieu of a single .devcontainer.json.

The argumentation seems to have two sides

features are purposefully loosely specified and therefore messy situations will arise
by default, users should not have to worry about in what sequence features need to be listed

If this observation is correct, it seems to me that the syntax should explicitly express both of those aspects. I.e. the syntax should not suggest to me that by default I do have to worry about the sequence and when I look at a devcontainer file it should immediately be clear to me that it defines order to clean up a messy situation.
Thus, it would make sense to me that

features define their dependencies
the features of a dev container are defined as a map and are being installed based on 1.
the dev container file may contain a property overrideFeatureInstallOrder (or a different name along those lines) that allows a user to specify the installation order, and the value of this property takes precedence over 1.

A separate overrideFeatureInstallOrder may only work well if we make sure it is only rarely needed and we consider it a bug on the feature that requires the override.
On reproducible image builds: We will compute a fixed order based on the soft-dependencies (using a stable sorting where soft-dependencies do not require an order). We will also need a lockfile to make the build reproducible over time as feature scripts update.
On local feature scripts: We can install features that do not participate in the soft-dependencies graph last. They will not participate either on purpose or by accident, running them last should work in both cases. A local feature can then still choose to participate in the soft-dependencies.

My main worry with overrideFeatureInstallOrder is that it would break the feedback loop we would otherwise get from users and feature authors that would allow us to improve the implementation and API. We could show a warning on overrideFeatureInstallOrder in the editors to counter that.

The argumentation seems to have two sides

features are purposefully loosely specified and therefore messy situations will arise
by default, users should not have to worry about in what sequence features need to be listed

If this observation is correct, it seems to me that the syntax should explicitly express both of those aspects. I.e. the syntax should not suggest to me that by default I do have to worry about the sequence and when I look at a devcontainer file it should immediately be clear to me that it defines order to clean up a messy situation.
Thus, it would make sense to me that

features define their dependencies
the features of a dev container are defined as a map and are being installed based on 1.
the dev container file may contain a property overrideFeatureInstallOrder (or a different name along those lines) that allows a user to specify the installation order, and the value of this property takes precedence over 1.

@kieferrm 100%. I was thinking of a property inline in the object syntax - but something like an override property would work as well. Strict ordering should not be the default, but possible to do. I'd talked with @craiglpeters yesterday on the Codespaces team and we both were leaning towards the object semantic as the default with an override form for the reasons you mention.

My main worry with overrideFeatureInstallOrder is that it would break the feedback loop we would otherwise get from users and feature authors that would allow us to improve the implementation and API. We could show a warning on overrideFeatureInstallOrder in the editors to counter that.

I'm pretty confident that if people find out that they need to use this property frequently that we'll get feedback on something being wrong.  The idea really is that you shouldn't have to do this.
The core challenge is that, unlike a classic package or module system, we only have complete control of the "packaging" aspect of the overall process. How the installation itself affects other things is dictated by things like apt, npm, pip, nix, etc. So that inherently puts us in a spot where predictability is difficult.
However, I strongly believe we should look for ways to avoid these problems as well, so agree with that point.  I also agree with your thought that we should probably consider a way to make user creation something that can be done independent of features since its placement has a dramatic affect on ordering right now.

On reproducible image builds: We will compute a fixed order based on the soft-dependencies (using a stable sorting where soft-dependencies do not require an order). We will also need a lockfile to make the build reproducible over time as feature scripts update.

Yeah the specific issue is when you add one more thing, that can end up in a (to the user) random spot in the ordering and affect things in ways we cannot predict. In primary cases, that won't be a problem, but we'll need a way to handle exceptions.  We've seen enough already at this early stage that having some mechanism will help a lot.

On local feature scripts: We can install features that do not participate in the soft-dependencies graph last. They will not participate either on purpose or by accident, running them last should work in both cases. A local feature can then still choose to participate in the soft-dependencies.

This is a good idea - I like it!  The one thing it does not solve is where you need that to happen between two features as a fix, but with an override, this should reduce the number of incidents significantly.  Love that.

The core challenge is that, unlike a classic package or module system, we only have complete control of the "packaging" aspect of the overall process.

I want to emphasize this point made by Chuck.  We currently are NOT building a package manager (we have no centralized database of features, there is no lock file, we have no proposal for a strict versioning schema other than "what makes sense" to an author).  We have also explored building on top of an existing package manager, but @edgonmsft 's investigations concluded it did not make sense given the specific case studies we investigated.
We indeed have control over packaging via our provided GitHub action (https://github.com/microsoft/publish-dev-container-features-action, soon to be migrated over to the devcontainers org following a revised packaging schema).  But at packaging time, we again only have a view into the immediate set of features - there is no central "features" database we can query to add metadata).

The argumentation seems to have two sides

features are purposefully loosely specified and therefore messy situations will arise
by default, users should not have to worry about in what sequence features need to be listed

I just want to voice that I don't think (2) is necessarily a hard requirement, although that is certainly the way the discussion is heading.  I think that our tooling should provide some sortof mechanism for detecting invalid orderings, but installing tools into a Docker image in inherently ordered and thus by us taking the ability to define an order away from a user, we're necessitating moving that complexity onto someone else (feature authors and ourselves as developers of the ordering algorithm).

I just want to voice that I don't think (2) is necessarily a hard requirement, although that is certainly the way the discussion is heading.

@joshspicer I think this is representative of our aspiration.  We have a checkbox UX right now with this in mind... pick your base, then add a few optional features and you are done.  Practically speaking we've found it is more complicated than just that, but this is also not an absolute either. Anything that's a straight CLI you curl and drops in /usr/local/bin works pretty well this way.  We may want to favor that acquisition path - particularly when signing is available to verify contents like there is for the Go install - since it will be less succeptible to the problem.
The core issue that tends to cause things like Go to need ordering is that it needs to set privs to enable a non-root user to access or install contents in folders it creates.  Given how common that is, I could totally see us going down the path where remoteUser supports creating said user rather than just referencing like it is now.  That would then happen first, and at that point the remaining challenges would be more exception based.
In fact, we could pass that user name into the features, which would simplify logic we have now to figure out what that user is. (e.g. it's there as a DEV_CONTAINERS_REMOTE_USER env var).

Although - if a user wanted to then utilize several "local" features, we run into the exact same problem as if a user wanted to utilize several "remote" features.

I was thinking that a local feature could also use the "installAfter" property to get in control of the order. We just order features without any dependencies or dependents last to increase the chances of success for features that are unaware of their dependencies (and need to be fixed).

I want to publicly share an example proposal of @Chuxel 's shared in a different medium.

There is then a “featureOrder” (or similar) property in devcontainer.json that dictates ordering behaviors. This has three possible values “auto” (the default), “strict”, and “manual”. This is used in conjunction with the array syntax.
In “auto” mode, the dev container CLI will tweak the order in the array based on what is in “runsAfter” for a given feature. Specifically:
For each feature in the array, see if any features listed in “runsAfter” are also in devcontainer.json.
If they are, change the actual ordering to be sure that the current feature runs after each item in this list.
In the event ordering is changed, output a warning that the order was changed in the logs with a note on how to stop this from happening. (e.g., “Change featureOrder to strict to disable this behavior”)
In “manual” mode, the execution order is forced to be exactly what is in the array in devcontainer.json – regardless of whether or not this is the recommended order. If something is out of order based on its “runsAfter” values, a warning is placed in the logs to aid debugging should the build fail unexpectedly due to a feature issue.
In “strict” mode, the execution order is also always based on what is in the array in devcontainer.json.  However, if something is out of order based on its “runsAfter” values, the build fails with an explicit error saying what is out of order.

This idea of "modes" auto (default), strict, and manual seems to provide the most power and flexibility to the end-user.  Users that want the "magic" experience don't tinker with the featureOrder, and those that identify unsolvable problems (or would prefer to iterate on a feature without worrying about the plethora of dependency models we have discussed), can then change their installation mode.
This seems like a nice compromise.  The "magic" dependency detection work can continue, while users today are not blocked from using features in a way that works for them.

I have put together a PR demonstrating an implementation of the proposal: https://github.com/devcontainers/cli/pull/56

Although - if a user wanted to then utilize several "local" features, we run into the exact same problem as if a user wanted to utilize several "remote" features.

I was thinking that a local feature could also use the "installAfter" property to get in control of the order. We just order features without any dependencies or dependents last to increase the chances of success for features that are unaware of their dependencies (and need to be fixed).

Makes sense! In isolation all the local features could then be completely controlled.

Another thing is that going with a map syntax doesn't allow features to be called multiple times, and for the cases where that makes sense then features and their parameters need to be more complicated.

Another thing is that going with a map syntax doesn't allow features to be called multiple times, and for the cases where that makes sense then features and their parameters need to be more complicated.

@edgonmsft This does not bother me - features have to be specifically designed to be invoked twice anyway, so supporting a list of things to install really isn't that difficult.  It does imply though that we should support an array option type. There's a spike in end user complexity to do this multiple times.
So recapping where we here:

✅ We agree installAfter should be available in features and this affects ordering.
✅ We agree local features should run last, unless otherwise dictated by a installAfter property.
✅ We agree that by default, ordering should be automatic.
✅ (I think) we agree that we should look into a semantic to create users automatically to avoid this common issue.
🟨 We seem to be agreeing it should be possible for the end user to force a specific order to resolve challenges.
🟨 We seem to agree that we need some way of a feature installing more than one thing. But have not yet settled on a form (array properties vs array for features)
🔴 We need to confirm our direction on the specific semantics.

We have two pending changes in this proposal:
1. The top-level installsAfter array property is introduced. This property is added by feature authors in devcontainer-feature.json definitions.
2. The implicit behavior that "local features" are automatically re-ordered and applied after all "remotely acquired" features.

I propose a third (3) optional, "break-glass" top-level setting: featureInstallOrder, that provides feature users the ability to override the "magic"/"inferred" installation order.
The property is an array of unversioned featureIDs. Those IDs must also be present in the features object.
These features will be applied to the underlying Dockerfile for installation in the specified order. Any features in the features object that are not mentioned in the array will be installed in an undefined/implicit order, as determined as optimal by the tooling.
NOTE: In this example, person/features/cool-azure-cli-extension does not specify an installsAfter property and thus would be ordered randomly before any "local features".  There are numerous reasons why this could be the case (i.e: (a) inactive maintainer, (b) disagreement on adding in the property by the maintainer, (c) proprietary/closed-source features, (d) this feature only needed to be re-ordered on particular base images, (e) this feature only needs to be re-order due to interactions with a different user-defined feature, etc).  In the example below, the installation only behaves properly with the prescribed order.
NOTE: "local features" are features referenced from the local filesystem.  They are part of the spec and are currently (as of Jun 17 2022) in PR to be added to the reference implementation.
Example
{
    "image": "azcr.io/joshspicer/my-debian",
    "features": {
        "person/features/cool-azure-cli-extension": "",
        "docker-in-docker": {
            "version": "20.01"
        },
        "devcontainers/features/azure-cli": {
            "version": "latest"
        },
        "/home/alice/localFeatures/setupDev": {
            "doComplicatedStep": true
        },
        "/home/alice/localFeatures/setupProxy": {
            "ipAddress": "<IP_ADDRESS>"
        },
        "homebrew": {
            "version": "latest"
        },
        "acmecorp/features/proprietaryCode": {
            "optionA": true,
            "optionB": false
        },
        "common": {
           "userUID": "1000"
        }
    },
    "featureInstallOrder": [
        "/home/alice/localFeatures/setupProxy",
        "common",
        "devcontainers/features/azure-cli",
        "person/features/cool-azure-cli-extension"
    ]
}

Thus the resulting Dockerfile will have RUN lines injected with features in the following order:
/home/alice/localFeatures/setupProxy
common
devcontainers/features/azure-cli
person/features/cool-azure-cli-extension
--------------------------------------------------
acmecorp/features/proprietaryCode
docker-in-docker
homebrew
--------------------------------------------------
/home/alice/localFeatures/setupDev

The three buckets above are:

Explicitly ordered by 'featureInstallOrder'
Default: Remote features randomly ordered by tooling in a smart way (may change over time)
Default: Local features install last by default , randomly ordered by tooling in a smart way (may change over time)

If no featureInstallOrder is provided in the devcontainer.json, just bucketing modes (2) and (3) are applied.

I like this proposal for featureInstallOrder @joshspicer. Do we have a use case where it is required in order to get the required outcome? Seems to me you could get the resulting Dockerfile RUN using installsAfter.

@craiglpeters  - We have many use-cases today that have arisen from using features in our own base images. I've also provided 5 generalized examples use cases in my first NOTE: above

We also identified four things to help here that we can split out as separate proposals:
High confidence proposals:

We agree that we should look into a semantic to create users automatically to avoid this common ordering issue.
We agree that we need some way for feature to enable users to specify more than one thing to be installed easily (e.g. an array option). But have not yet settled on a form - @joshspicer has a proposal in mind here.

Warrants further discussion:

It might be worth enabling a "lifecycle hook" concept for each feature e.g., _postFeatureCommand and _preFeatureCommand as options that are automatically available to end users. (You can already add these explicitly as options to your own feature... this is more of a convenience.) In concept this will reduce the need for local features, but we are not confident enough that is a must have to wrap into this proposal.
Long term we may need some sort of composite feature semantic - though we want to wait to see if this is needed. We do not have enough features implemented to have a clear picture of this particular need.

For completeness -- another approach is around providing metadata "hints" in the feature options.
These "hints" would start with a leading _, indicating that the property is reserved for the tooling as metadata, and is not to be injected as an environment variable in the script.
NOTE: My proposal above is most likely a better fit for the specification, but open for discussion.
Eg:
{
    "image": "azcr.io/joshspicer/my-crazy-complicated-docker-image",
    "features": {
        "person/features/cool-azure-cli-extension": {
            "_installPriority": 105
        },
        "docker-in-docker": {
            "version": "20.01"
        },
        "devcontainers/features/azure-cli": {
            "_installPriority": 100
        },
    },
    "overrideFeatureInstallationMode": "manual"  // (manual|auto) Default: auto
}

When in manual mode, all features with _installPriority will be installed first in ascending order.  If more than one feature indicates the same priority, the tooling will throw a validation error.
For all remaining features, or if we are in the default auto mode, the tooling will auto-select a build order based on internal heuristics.
For this example, the build order would be:
devcontainers/features/azure-cli
person/features/cool-azure-cli-extension
docker-in-docker

I'm missing a way to ensure we or the feature author will learn when users need to use featureInstallOrder. When users have no indication that the use of featureInstallOrder should be the exception, they might never report it and continue to use it even after it is no longer needed (e.g., because the feature updated the installAfter list).

@chrmarti I don't think we should drop featureInstallOrder, but I think overrideFeatureInstallOrder is a good idea since it is indeed an override.  Not sure we need the warning with that TBH.  Generally if we do not get feedback, I think that means we've solved the problem TBH.  But, we can also do outreach to verify once we've got more people using.

overrideFeatureInstallOrder sounds good to me as the name of the property.

@chrmarti I don't think we should drop featureInstallOrder, but I think overrideFeatureInstallOrder is a good idea since it is indeed an override. Not sure we need the warning with that TBH. Generally if we do not get feedback, I think that means we've solved the problem TBH.
But, we can also do outreach to verify once we've got more people using it to understand why they are using the property - if they do. For feature authors, I'd be surprised if people did not complain given the use of the property means that default behaviors wouldn't work - and enough people will not read docs that they'll raise issues on it.

Sounds good to me.

Yep I like the name.


Use pre-configured RestClient.Builder by Spring Boot

This pull request updates the API client, which is auto-configured, to utilize a RestClient.Builder that is pre-configured by Spring Boot. This change allows for customization through RestClientCustomizer, enabling the addition of interceptors (such as logging and retry processing) and changing to the underlying request factory.
https://docs.spring.io/spring-boot/docs/current/reference/html/io.html#io.rest-client.restclient.customization

Thanks @making , this makes sense.
Will review it soon.

@making , Since we introduce an auto-conf dependency on RestClientAutoConfiguration.class in the Ollama, OpenAi, Stability and Vertex AutoConfiguration classes i think we need to add the after e.g.: @AutoConfiguration(after = RestClientAutoConfiguration.class,...) ?

@tzolov I missed that point. fixed!

Thanks. LGTM. Will merge it shortly.

Rebased, squashed and merged at 7b58f426ec7bb12feac0f40dbdf0955202ba4799
@making , fyi, I had to add few missing AutoConfigurations.of(RestClientAutoConfiguration.class,  before the merge.


Remove failovermethod for 8 as option has been removed in DNF

Pull Request (PR) description
Changes failovermethod to absent for RHEL 8 and derivatives so that this is removed from any EPEL repo definitions.
The failovermethod setting is not implemented in DNF as used in RHEL 8 and recent updates to the DNF package now flag the presence of this setting as an error.
This Pull Request (PR) fixes the following issues
Fixes #108

@msalway Thanks!

Do you already have a plan when this will be released? I'm waiting for the fix as it gives errors at the recently updated servers.


Issue while sending JSON from react native to web by webview-bridge

Hello,
I am using your plugin from start. Previously it was working very fine but when I updated your latest version then I am facing below issues.
Issue1: If we send some simple json from react native to weView then it is working fine. But when I tried below JOSN (some dummy JSON) then it is not sending message to webView.
var data = {
            content:'
Story: https://www.google.com\n
\n
1.For - Close (i.e by \'X\') does not change to hyper-link - Delivered.\n
'
		}

Issue 2: I sent message as object but when I got this from web then it is showing as string.
Please can you check above issues?
Thanks in advance.

So you are sending data and the content that you are receiving is in string?
Can't you apply JSON.parse on the received data to convert to JSON object?

Can't you apply JSON.parse on the received data to convert to JSON object?
Yes I am using this function to convert to JSON object. I have fixed fixed both issues at my end(with some patches). But this should not convert to string.
I have fixed previous issue as well but with patch.
First of all I converted my object into string and then call JavaScript function escape(jsonstring) and send to webView and in webView again I am doing revert on webView, In this way this is working.
But with previous version I was not using any kind of patch, I was sending JSON and getting JSON as well at webView side

data must be stringified before sending to React-Native component or WebView. I don't want to enforce user to use JSON. in your case, it is your responsibility to handle what type of data you are sending. I'm just handling the transfer.

@tazmattaz please re-open this issue if you still have that!


add CMakeLists.txt

A simple cmake file for c++11

It is always better to clean all the blank lines at the end of file.

yes it's my mistake
------------------ 原始邮件 ------------------
发件人: @.>;
发送时间: 2022年3月12日(星期六) 晚上9:28
收件人: @.>;
抄送: @.>; @.>;
主题: Re: [progschj/ThreadPool] add CMakeLists.txt (PR #95)
It is always better to clean all the blank lines at the end of file.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you authored the thread.Message ID: @.***>

maybe you are right , I just want to make it easy to run ...

maybe you are right , I just want to make it easy to run ...

You can just type once and then use something like Ctrl-r for your shell to reuse the command from the shell history.

So sad that the last update was 8 years ago.. It is unnecessary to talk about the detail now.  : (

cmake_minimum_required (VERSION 3.2)
project (threadpool)

add_library (ThreadPool INTERFACE)
target_include_directories (ThreadPool INTERFACE "${CMAKE_CURRENT_SOURCE_DIR}")
target_compile_features (ThreadPool INTERFACE cxx_std_11)

if (BUILD_TESTING)
    enable_testing ()
    add_executable (test-ThreadPool example.cpp)
    target_link_libraries (test-ThreadPool PRIVATE ThreadPool)
    add_test (NAME ThreadPool-test COMMAND $<TARGET_FILE:test-ThreadPool>)
endif ()

This is more of a complete CMake file for this project FWIW.


propshaft + ViewComponents + Stimulus

Is there a way to configure propshaft with Stimulus controllers in the ViewComponents (https://viewcomponent.org/) components folder instead of the javascript folder? I try the assets pipline aproach (https://github.com/github/view_component/issues/1064) but didn't work.

I’ll need more information on what’s going wrong to help you. Are the files you need not placed in the public folder? Are files there but not found?
Propshaft is only responsible for moving files from their source directories to the public folder. This means that as long as all folders containing files you need are in the paths array, they will be moved too.

@edugonch
https://github.com/github/view_component/issues/168
https://github.com/palkan/view_component-contrib
I think that your faced problem isn’t related to propshaft.
What about using sprockets instead of propshaft?

@asip you are right, I'm complicated too much just to handle the assets, I'll just continue with sprockets.

@edugonch
I'm using Stimulus + ViewComponents in my study.
The study uses sprockets or propshaft  to handle the assets.
For your reference.
sprockets:
https://github.com/asip/easel
propshaft:
https://github.com/asip/easel/tree/switch_from_sprockets_to_propshaft

@asip thank you, I apreciate it, I'll take a look.

I can describe something that works. With the asset pipeline approach with sprockets, the solutions generally seem to be working around an issue with assets being collected without preserving the components prefix.  With propshaft and importmap, you avoid the issue when you use relocate components to an "app/frontend/" directory and look for assets starting there. You can change config.view_component.view_component_path as well so that generators place new files there. I tested this with Rails 7 and the sidecar and stimulus options for view_component generation. The following shows what lines need to be added to existing or new files.
config/application.rb
    config.autoload_paths << Rails.root.join("app/frontend/components")
    config.importmap.cache_sweepers << Rails.root.join("app/frontend")
    config.assets.paths << Rails.root.join("app/frontend")
    config.view_component.view_component_path = "app/frontend/components"

config/importmap.rb
pin_all_from "app/frontend/components", under: "components"

app/frontend/components/index.js
import { application } from "controllers/application"

import { lazyLoadControllersFrom } from "@hotwired/stimulus-loading"
lazyLoadControllersFrom("components", application)

app/javascript/application.js
import "components"

I can describe something that works with propshaft and importmap in Rails 7. I think it's best to have propshaft pick up assets stimulus controllers with the components directory / prefix still intact. This should be done without starting to look for assets at the app directory. Stimulus controllers all need to end up under the controllers prefix after they are mapped by importmap so that they can be eager or lazy loaded them together as is normally done in controllers/index.js. I include the config option that tells the view_component generator of the new app/frontend/components location. I think more tweaking could be done to make the controller reference in data-controller shorter when pointing to a controller in a sidecar. I tested this with Rails 7 with and without the sidecar and stimulus options on view_component generation. The following shows what lines need to be added to existing or new files.
config/application.rb
    config.autoload_paths << Rails.root.join("app/frontend/components")
    config.importmap.cache_sweepers << Rails.root.join("app/frontend")
    config.assets.paths << Rails.root.join("app/frontend")
    config.view_component.view_component_path = "app/frontend/components"

config/importmap.rb
pin_all_from "app/frontend/components", under: "controllers", to: "components"

Reminder: The entire app/components directory needs to be moved to app/frontend/components.

@lockemx Your approach worked for me. It's more straightforward than rake approach from ViewComponent/view_component#1064.
But cannot figure out why just app/components didn't work here.


fix(ergo) Add documentation for Ergo 'as' expression

Signed-off-by: Jerome Simeon<EMAIL_ADDRESS>Changes

Fixes wrong link in Ergo "Template Literal" section
Add new section for Ergo formatting using as

Related Issues

Issue https://github.com/accordproject/cicero/issues/599

CC: @martinhalford


threatest: 1.2.1 -> 1.2.4

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/DataDog/threatest/releases.
meta.description for threatest is: Framework for end-to-end testing threat detection rules
meta.homepage for threatest is: https://github.com/DataDog/threatest
meta.changelog for threatest is: https://github.com/DataDog/threatest/releases/tag/v1.2.4
Updates performed

Golang update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.2.4 with grep in /nix/store/ffaylrnxcnc220qzrdsz8hqmayg5lw03-threatest-1.2.4
found 1.2.4 in filename of file in /nix/store/ffaylrnxcnc220qzrdsz8hqmayg5lw03-threatest-1.2.4

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
threatest

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/ffaylrnxcnc220qzrdsz8hqmayg5lw03-threatest-1.2.4 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A threatest https://github.com/r-ryantm/nixpkgs/archive/799d0c89cd2b2f439ddcaf6f7884a9de81608326.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/ffaylrnxcnc220qzrdsz8hqmayg5lw03-threatest-1.2.4
ls -la /nix/store/ffaylrnxcnc220qzrdsz8hqmayg5lw03-threatest-1.2.4/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

threatest

Maintainer pings
cc @fabaff for testing.

Diff: https://github.com/DataDog/threatest/compare/v1.2.1...v1.2.4


Add python 3.10 to test suite for github actions

Looking ahead, it makes sense to include this in our test suite to preemptively catch any issues

This PR now seems good to go to me. The only problem is that pytorch, which is a requirement in our [dev] build does not support python3.10 yet. As such, a call to pip install -e .[dev] would currently fail in python3.10.
I'm not sure if the above failure mode should keep us from updating to support python 3.10 though.

Codecov Report

Merging #101 (5c307fe) into main (1c180ae) will not change coverage.
The diff coverage is n/a.

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

@@           Coverage Diff           @@
##             main     #101   +/-   ##
=======================================
  Coverage   98.72%   98.72%
=======================================
  Files          41       41
  Lines        1571     1571
=======================================
  Hits         1551     1551
  Misses         20       20

Flag
Coverage Δ

unittests
98.72% <ø> (ø)

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

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 1c180ae...eb41bc8. Read the comment docs.


Add timezone scalar function

Summary of the changes / Why this improves CrateDB
This is a draft, to check that I understood the requirements so far and to continue
the specification of the At TIME ZONE parser syntax, which will be built atop
Checklist

[x] User relevant changes are recorded in CHANGES.txt
[x] Touched code is covered by tests
[x] Documentation has been updated if necessary
[x] CLA is signed
[x] This does not contain breaking changes, or if it does:

It is released within a major release
It is recorded in CHANGES.txt
It was marked as deprecated in an earlier release if possible
You've thought about the consequences and other components are adapted
(E.g. AdminUI)

I believe the tests will fail when we transition to DST, I am looking into it.

The function outputs in ISO8601 which I am not certain it is acceptable.
I notice that DateFormatFunction formats by default as in:
DEFAULT_FORMAT = "%Y-%m-%dT%H:%i:%s.%fZ";
with no timezone, which is similar, EXCEPT in the rounding of the fraction of seconds

I have squashed

I will use the branch to push the AT TIME ZONE parser feature


Fix formatting issues with headers

Codecov Report

Merging #311 (790f6a0) into master (580141c) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #311   +/-   ##
=========================================
  Coverage     76.40%   76.40%
  Complexity      642      642
=========================================
  Files            99       99
  Lines          1886     1886
  Branches        195      195
=========================================
  Hits           1441     1441
  Misses          379      379
  Partials         66       66

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 580141c...790f6a0. Read the comment docs.


Partial Streaming FFTs

I will be implementing partial streaming the same way spiral does: Instantiating a set number of stages and reusing them (I.E. a 4 stage FFT using 1 stage total). In this way the latency will be NStages/NInstantiated where NInstantiated is the number of actual butterfly units.
If time permits, I might look into partial streaming FFTs using iterative stages but I'm not sure whether that would be worth it, depends on what design space results we can get.

[ ] Partial Streaming FFT
[ ] Iterative Stages in partial streaming (?)

Awesome! I think the primary goals are:

Matching the throughput of Spiral FFTs
Minimizing the use of assume to only "algebraic properties" that Filament's encoding cannot reason about. We have a bunch of assume that actually encode circuit properties that we should get rid of (and implement features needed to get rid of them)

Iterative streaming would be weird because the throughput would be terrible; we already have this problem because we have to flush the butterfly pipelines when doing stage reuse.

What do you mean by "circuit properties"? Are we talking about the assume statements used to speed up compilation?

Nope, I mean assumes that state that a particular module's output parameter is equal to one or equal to another output parameter. Those kinds of properties should not be encoded using assume statements.


Cannot resolve 'fs' when loading

repo
When loading the <ListView /> component like so:
if (Header) {
  return <ListView />;
}

I keep getting the error below..

Hey @ahmetskilinc, this is because you are attempting to import a server component into a client component, breaking the rules of React Server Components. The ListView component performs server-side logic, including the use of the fs module as your error indicates. Your MediaGrid component, however, is marked with the use client directive. Once you are past the client boundary, you cannot use server-only paradigms. You have two options you can take here:

Write your component as a server component, so you can render the List View as needed. You can still interleave client components as needed.
The pattern that Payload follows for cases like this is to pre-render those components on the server, and simply return them from client components. To do this, get the pre-rendered List View from the useComponentMap hook, and simply return it from your client component:'use client'
import { useComponentMap } from '@payloadcms/ui'

export const MyComponent = () => {
  const { ListView } = useComponentMap()
  return ListView
}

@jacobsfletch Gettin this now - Property 'ListView' does not exist on type 'IComponentMapContext'.

@ahmetskilinc ok must be because you are attempting to use this hook outside the admin panel. I will add a disclaimer to my comment above indicating how this is not possible. For cases like this, you will need to use option 1: import and render the ListView  within a Server Component.

@jacobsfletch  The hook works in the same file to get getComponentMap.
Doesn't this count as rendering it in the AdminPanel?

Ah ok, looking now at the types and it appears to be called Edit instead of EditView.


Add timeout to pod waiting function

What is the purpose of this change? What does it change?
Fix #852
Was the change discussed in an issue?
#852
PR #855 also attempted to address the issue, but the tests were failing which lead me to open this PR
How to test changes?
It's difficult to actually verify the timeout is working. You could always reduce it (to like 5 second) and test

@cdrage I am guessing that the timeout should be configurable.
What do you propose in order to achieve that?

@cdrage I am guessing that the timeout should be configurable.
What do you propose in order to achieve that?

@geoand +1 for it to be configurable with a safe default(if not configured)

@anmolbabu How do you propose this value be configurable? Some global flag?

@anmolbabu How do you propose this value be configurable? Some global flag?

@geoand Yes, something like cmd_timeout in the configuration file . ..

@geoand Yes, something like CmdTimeout in the configuration file . ..
But I would like to take @kadel @jorgemoralespou @cdrage opinion before starting on it

I think that for now it is ok to have this in code.
Lets add is as config option only if it is really needed.

@anmolbabu @kadel Code updated with the latest fixes to the comments

One more review on this would be much appreciated :)
Thanks

@anmolbabu I'll wait until you have verified it :)

@cdrage I'll look into it. Does the PR work as expected with more sane timeouts?

@geoand Yes, more sane timeout's it works fine! I'm just trying to purposely break things haha.

@cdrage Actually it's great that you uncovered this!
This is indeed a bug and seems to have to do with the way the channel is being closed. I need to look into this further

@cdrage Pushed a fix. Can you please try again?

:white_check_mark: Build odo 17 completed and artifacts can be found here (for commit https://github.com/redhat-developer/odo/commit/d4bdd0c933 by @geoand)

:white_check_mark: Build odo 18 completed and artifacts can be found here (for commit https://github.com/redhat-developer/odo/commit/5eab9e434f by @geoand)

@geoand Yup! This LGTM.

Thanks @cdrage!


Add dynamic command, embedded form command, and navigate option on app form

Can we please merge given another approval? 🙂


Last can now be used as any step in a PATH_SPEC. Of course, if it's not the last, it will fail, but that seems fine to me!


FIX regexp for KIT systems

Looks like the regexp for KIT systems was still broken in the validator. I added some test cases (copied from the specification) now to make sure that it is indeed the right search pattern.

@chrisfilo : on reading the BIDS specification carefully, I see the following phrase for KIT/KRISS/BTi/ITAB systems:

One   SHOULD   rename/create   a   father   run   specific   directory  and keep the original files for each run inside.

So, we cannot really check the extensions of the files or the files inside the father directory. Accordingly, I added more test cases and changed the regexp. It's good to go on my end.

@guiomar and @robertoostenveld know better this part of the spec

maybe @teonbrooks can help? He's a KIT systems expert :-)

Yes, we agreed that for systems that return more than one file (i.e. KIT, 4D/BTi, etc.) The best option was to create a father directory and include all of them inside. Sorry, I can't help more with this, I mainly work with Elekta and CTF.
There were also some comments (by Matt Sanderson) about homogenizing the folder structure for all the systems, creating always a father directory, even though the content inside will be sometimes just one file (.fif) or a folder with the exact same name (.ds), which may be a bit redundant, I don't have a strong opinion. However, if this helps for consistency, we may go for it.


ObservationFromDiscreteCell and ObservationFromGrid mutually inconsistent

I am interested in using ObservationFromDiscreteCell and ObservationFromGrid as described here and mentioned in the tutorial. My understanding is that, if we are in a flat world, and if no changes to the world occur except for the agent moving around, the ObservationFromGrid should be the same whenever ObservationFromDiscreteCell is the same.
For example, if I see that ObservationFromDiscreteCell is (0, 1) and ObservationFromGrid is ('stone', 'cobblestone', 'cobblestone', 'cobblestone', 'cobblestone', 'cobblestone', 'cobblestone', 'cobblestone', 'cobblestone'), then I would expect in the future to see the same grid observation anytime I end up back in the same (0, 1) discrete cell. Is my understanding correct?
I ask because I am seeing outputs inconsistent with this understanding. Here is a minimal example:
import malmoenv

port = 9000
episodemaxsteps = 0

# Adapted from findthegoal.xml
xml = '''<Mission xmlns="http://ProjectMalmo.microsoft.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <About>
    <Summary>Grid Observation Test</Summary>
    </About>

    <ModSettings>
      <MsPerTick>50</MsPerTick>
    </ModSettings>

    <ServerSection>
      <ServerInitialConditions>
        <Time>
          <StartTime>6000</StartTime>
          <AllowPassageOfTime>false</AllowPassageOfTime>
        </Time>
        <Weather>clear</Weather>
        <AllowSpawning>false</AllowSpawning>
       </ServerInitialConditions>
    <ServerHandlers>
      <FlatWorldGenerator generatorString="3;7,220*1,5*3,2;3;,biome_1" />
      <ClassroomDecorator seed="4711">
        <specification>
          <width>7</width>
          <height>7</height>
          <length>7</length>
          <pathLength>0</pathLength>
          <divisions>
            <southNorth>0</southNorth>
            <eastWest>0</eastWest>
            <aboveBelow>0</aboveBelow>
          </divisions>
          <horizontalObstacles>
            <gap>0</gap>
            <bridge>0</bridge>
            <door>0</door>
            <puzzle>0</puzzle>
            <jump>0</jump>
          </horizontalObstacles>
          <verticalObstacles>
            <stairs>0</stairs>
            <ladder>0</ladder>
            <jump>0</jump>
          </verticalObstacles>
          <hintLikelihood>1</hintLikelihood>
        </specification>
      </ClassroomDecorator>
      <ServerQuitFromTimeUp timeLimitMs="1200000" description="out_of_time"/>
      <ServerQuitWhenAnyAgentFinishes />
    </ServerHandlers>
    </ServerSection>

    <AgentSection mode="Survival">
    <Name>Agent1</Name>
    <AgentStart>
      <Placement x="-203.5" y="81.0" z="217.5"/>
    </AgentStart>
    <AgentHandlers>
      <VideoProducer want_depth="false">
        <Width>320</Width>
        <Height>240</Height>
      </VideoProducer>

      <ObservationFromGrid>
        <Grid name="grid_observation">
            <min x="-1" y="-1" z="-1"/>
            <max x="1" y="-1" z="1"/>
        </Grid>
      </ObservationFromGrid>
      <ObservationFromDiscreteCell />

      <ContinuousMovementCommands turnSpeedDegs="180">
        <ModifierList type="allow-list">
          <command>move</command>
          <command>turn</command>
        </ModifierList>
      </ContinuousMovementCommands>
      <MissionQuitCommands/>
      <RewardForSendingCommand reward="-0.01" />
      <RewardForMissionEnd rewardForDeath="-1">
        <Reward description="found_goal" reward="0.5" />
        <Reward description="out_of_time" reward="-0.1" />
      </RewardForMissionEnd>
      <RewardForTouchingBlockType>
        <Block type="gold_ore diamond_ore redstone_ore" reward="0.5" />
      </RewardForTouchingBlockType>
      <AgentQuitFromTouchingBlockType>
        <Block type="gold_block diamond_block redstone_block" description="found_goal" />
      </AgentQuitFromTouchingBlockType>
      <AgentQuitFromReachingCommandQuota description="command_quota_reached" total="1000"/>
    </AgentHandlers>
    </AgentSection>
    </Mission>'''

env = malmoenv.make()

env.init(xml, port)
obs = env.reset()

cell_to_grid = {}

steps = 0
done = False
while not done and (episodemaxsteps <= 0 or steps < episodemaxsteps):
    action = env.action_space.sample()

    obs, reward, done, info_str = env.step(action)
    steps += 1

    if len(info_str) > 0:
        info = eval(info_str)
        cell = info['cell']
        grid = tuple(info['grid_observation'])

        if cell in cell_to_grid:
            if cell_to_grid[cell] != grid:
                print("Inconsistent grid observations!")
                print("Cell:", cell)
                print("Old grid:", cell_to_grid[cell])
                print("New grid:", grid)
                import pdb; pdb.set_trace()
        else:
            cell_to_grid[cell] = grid

env.close()

The output is
Inconsistent grid observations!
Cell: (0,1)
Old grid: ('stone', 'cobblestone', 'cobblestone', 'cobblestone', 'cobblestone', 'cobblestone', 'cobblestone', 'cobblestone', 'cobblestone')
New grid: ('cobblestone', 'cobblestone', 'cobblestone', 'cobblestone', 'cobblestone', 'cobblestone', 'cobblestone', 'cobblestone', 'cobblestone')

Thanks for your help!

Ah, I think the inconsistency arises due to a change in vertical position (YPos) between cell readings. (I thought all of these would be the same in this flat world, but the agent does drop from a small height above the ground at the beginning of the episode.) I am closing the issue for now.


Click in to scrub while music is playing

In the original iPods, I remember while in the now playing screen you could click in once on the main button to switch between volume controls and scrub through a song. It'd be nice if this functionality could be added! :)

this already exists in the app (somewhat)
if you're on the now playing screen and start panning on the wheel, the volume controls will show up. if you hold down on the fast forward/rewind buttons it'll skip ahead/back respectively.


Logarithmic mean

I'm working with sound data at the moment and I'm using the dB values in my database right now. I would like to switch to InfluxDB, but I don't see a way to get the mean of (logarithmic) dB values in a way with InfluxDB. Would it be possible for InfluxDB to add an average log function, like avglog(column)?
Or would I have to create it myself with user defined functions?

As mentioned in my post to the mailing list we are experimenting with simplifying our open GitHub Issues. This feature request has been rolled into an aggregate issue for all function requests, so that we can close this issue until we are ready to work on it.
You may continue to make comments here. Closing the issue does not mean we are rejecting this idea.


Card

Went with a "data" approach for this version…
So card uses a data file for heading, body, button label, and optional image.
Breakpoint/width is set as part of the include statement.
Optionally add classes to the image (for repositioning if necessary).

Note: may need to update image paths in data file after merging/publishing.

Note button label is automated at this point: (View TITLE).


add new version to solve return_value, still hard code. (may have better way if time allowed, decouple the structures)

Change Description

Start 9261 description ......
End 9261 description...
Change Type
Select ONE

[ ] Documentation

[ ] Stability bug fix

[x] Other

[ ] Other - special case

Consensus Changes

[ ] Consensus Changes

API Changes

[ ] API Changes

Documentation Additions

[ ] Documentation Additions

Is this related to #9251?

Is this related to #9251?

It was a duplicate, I just closed it

Yes,  9251 is already closed, currently still use 9261.  From: emorybarlowSent: Friday, July 10, 2020 11:05 AMTo: EOSIO/eosCc: softprofe; AuthorSubject: Re: [EOSIO/eos] add new version to solve return_value, still hard code. (may have better way if time allowed, decouple the structures) (#9261) Is this related to #9251?It was a duplicate, I just closed it—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.

Is this related to #9251?

Yes, sorry for the late response because I didn't see a reply button : -)

@b1bart Can you please review this PR? Thank you!

EPE84 is DONE.


Build failure with 3.1.1 on macOS

Trying to build 3.1.1 on macOS Catalina (10.15.7), I ran into an error:

[:~/src/speech-rule-engine-3.1.1] $ make
sed: 1: "/Users/klobetime/src/sp ...": invalid command code k
make: *** [/Users/klobetime/src/speech-rule-engine-3.1.1/node_modules/google-closure-library/sre_cleaned] Error 1

Turns out on mac the sed command expects an argument for the -i flag causing a line in the Makefile update introduced in #374 to fail. I changed it to read @sed -i '' -e s/"^.*@deprecated Use ES6.*"// $(GOOG_BASE) and everything went smoothly.
I didn't create a pull request because I'm assuming this will break a bunch of other platforms, but thought I'd share.

Thanks for reporting this.
I've copied a suggestion from stackoverflow, which provides a solution that works under both Mac and Linux.
The real issue is, that closure throws an error on it's own library. While moving to a newer version might solve this, it would also require to rewrite classes into ES6 notation. Instead of doing this, I am hoping to eventually move the codebase to Typescript altogether.

Because you are now creating a backup file with the sed command, seems like you could set GOOG_BASE_CLEAN to be something like $(GOOG_BASE).bak and skip the touch and creation of the marker file entirely. But glad this'll be fixed regardless. :)
Thanks!


Price gun cartridge

About the PR
Added Space Vendors cartridge. Which stores the "PriceGun" component. When the cartridge is installed in the PDA, the "PriceGun" component is transferred to the PDA.
Installed from the start in the PDA: QuartermasterPDA, CargoPDA, SalvagePDA.
Cargo workers must always know the price of the goods, even when appraisal tool is not with them.

[x] I have added screenshots/videos to this PR showcasing its changes ingame.

Changelog
:cl: Lomcastar

add: added new cartridge Space Vendors
tweak: NanoTrasen Corporation has equipped all Cargo PDAs with a Space Vendors cartridge!

https://user-images.githubusercontent.com/129697969/234926685-08b08371-9918-4da2-924a-c68ab847f1b0.mp4

you should test this:

get cartridge
put in pda
go to programs, press install
eject > cartridge
see if the valuegun still works on your pda

the following is true for netprobe, might be possible for this too

cartridge

No c#

lmao

Thanks for the quick response. I'll try to do it right.

@Lomcastar you coming back to this?

@AJCM-git Not sure

re-open when you have time then


[BUG] optimize #3165  Gets the value of this property “resource.storage.type”， Comparison with enumerated types

By looking at the ResourcesService  code, I found a potential problem.
Enumeration type comparisons are used in both classes ：HadoopUtils.java ,CommonUtils.java
I don't think this submission  is perfect
All comparisons of ResUploadType need to be optimized.
I'm going to modify this part
中文：
通过阅读ResourcesService代码，发现了潜在隐患。
在HadoopUtils和CommonUtils,资源中心类型，都是通过枚举类型比较。
所以感觉到submission 这个提交是不完备的。
需要优化所有的ResUploadType类型比较部分的代码。

Hi,
Please modify the issue content according to the template specification when creating the issue, it can help us locate the problem more quickly.
And can you describe
1.what kind of bug will it lead to at present
2.what kind of potential problem exist
Issue content template as follow:
*For better global communication, please give priority to using English description, thx! *

**Describe the bug**
A clear and concise description of what the bug is.

**To Reproduce**
Steps to reproduce the behavior, for example:
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

**Expected behavior**
A clear and concise description of what you expected to happen.

**Screenshots**
If applicable, add screenshots to help explain your problem.

**Which version of Dolphin Scheduler:**
 -[1.1.0-preview]

**Additional context**
Add any other context about the problem here.

**Requirement or improvement
- Please describe about your requirements or improvement suggestions.


cannot use cs (type cascadia.Selector) as type Matcher in return argument

hi, there's a problem while I was run go build:
./type.go:127: cannot use cs (type cascadia.Selector) as type Matcher in return argument:
	cascadia.Selector does not implement Matcher (wrong type for Filter method)
		have Filter([]*"golang.org/x/net/html".Node) []*"golang.org/x/net/html".Node
		want Filter([]*"github.com/menduo/itlepub/vendor/golang.org/x/net/html".Node) []*"github.com/menduo/itlepub/vendor/golang.org/x/net/html".Node

env
$ go version
go version go1.8 darwin/amd64

$ git log
commit ed7d758e9a34ba1f55e8084e0d731448b46921a8
Author: Martin Angers<EMAIL_ADDRESS>Date:   Fri Mar 24 09:54:48 2017 -0400

    add 1.8, test on latest patches

commit c641b87978a16588afa9ab1a02e02c8b8e05b314

file strcut
├── project_file.go
├── makefile
└── vendor
    ├── github.com
    │   ├── PuerkitoBio
    │   │   └── goquery
    │   └── sourcegraph
    │       └── syntaxhighlight
    └── golang.org
        └── x
            └── net

But, it can be built successful on 417cce822c7b9a379df5824be95228d177c5698b.
What's wrong?
Thanks

fixed.... sorry

@menduo Can you cut a new release? This fix isn't in the latest release, and package managers are trying to use the broken release.


Downloading attachments in gmail not behaving correctly

Bug description:

Downloading attachments from gmail does not work properly. The dialogue box comes up correctly but the files are not actually downloaded.
Watching what's happening on the network, two requests are made, one returns 302 the other returns 200, no errors are produced.
The same gmail account in firefox is working fine, saving to the same filesystem
Possibly related to #321, also can't open links without control clicking (recipe is the same as in the corrected version from that issue but issue persists)
Steps to reproduce:

Download an attachment in gmail
Expected behavior

Attachment is saved to filesystem
Environment:

Operating System: Linux Pop!_OS 20.04 (Ubuntu)

Ferdi Version: 5.5.0

Server: Ferdi

Debug information:

I am also having a similar issue with shared files in Skype. When I click the link to download, the file does not get downloaded, but my (external) browser, Firefox, opens with a blank page. So the problem might be connected to handling link opening in external browsers. Does Ferdi get confused whether it should download the attachment or open a new browser window?

@kris7t The behaviour your described with Skype has been reported at #676 so maybe these two issues are related.

I think is necessary to create a feature in recipe to handle open link behavior.
Something like overrideUserAgent:
openExternalLink(link) {
  return link.indexOf("https://eus1-api.asm.skype.com") === -1;// file dowload open in ferdi
}

Would the same for gmail be
openExternalLink(link) {
return link.indexOf("https://mail-attachment.googleusercontent.com") ===
-1;// file dowload open in ferdi
}
? Thanks!
On Thu, 14 May 2020 at 13:01, Leandro Gehlen<EMAIL_ADDRESS>wrote:

I think is necessary to create a feature in recipe to handle open link
behavior.
Something like overrideUserAgent:
openExternalLink(link) {
return link.indexOf("https://eus1-api.asm.skype.com") === -1;// file dowload open in ferdi}
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/getferdi/ferdi/issues/743#issuecomment-628558993, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABXYBYBR3LNAJYU55AEU5DLRRPFQNANCNFSM4M7RGTOA
.


[BEAM-12164]: Add sad path tests for Cloud Spanner's ReadChangeStream

Add sad path unit tests for the Cloud Spanner's ReadChangeStream, including testing for errors from the Spanner backend.

You should change the title to match the JIRA ticket [BEAM-12164]: <title>

Hey @pabloem could you please review this PR?

@thiagotnunes I've made a PR (https://github.com/apache/beam/pull/16879) with the javadocs which I'll rebase once this PR is merged.

once again I'm sorry about the delay. Taking a look now!


S3 config should not stomp local secret config

Cluster S3 configuration should not stomp user configuration

Checks for a user supplied S3 configuration to use
If user config is not found, use the system configuration
Add a test to ensure that a user provided configuration will override the sytem provided one
Add image-registry-private-configuration-user to the README.md
Finalize S3 storage (remove bucket if managed by us)
Don't fail on S3 bucket tagging and encryption, just set the appropriate conditions to false

Fixes #79
Fixes #99

/retest

/retest

/retest

Blocked by https://github.com/openshift/cluster-image-registry-operator/issues/75

@bparees ptal

@bparees ptal
I refactored a bunch of stuff and addressed your comments.
I also merged in my other PR since I needed a few things from it in this one.
I am still working on the test, but I believe everything else is ready for another look.

@bparees ptal
This should be ready for another look.  I separated the aws-sdk-go bump into it's own commit for ease of review.

@bparees bump

/retest

/lgtm


Add src/Generator test coverage

Added tests for the rest of the classes in the Generator namespace.
Added AspectMock to create test doubles of php methods, uses a namespacing trick to create doubles. This only works on methods that aren't specified as in global namespace (ie: \random_bytes() instead of random_bytes() - fortunately this worked on all of these.
Added some checks for HHVM because AspectMock does not work on HHVM. Talked to @ramsey who said we could exclude those tests on HHVM.
Increased coverage to 96% according to coveralls

Changes Unknown when pulling 420d570ac7790ff6dc9f718c0d79eb2f4a75926e on jmauerhan:add-generator-test-coverage into ** on ramsey:master**.

This is all great. Thanks!
I'm going to start using AspectMock myself, after seeing it here. Awesome stuff!


add back certs and option to call nodeagent through TLS

https://github.com/istio/istio/issues/5903
before envoy/gRPC support local_credentials change is ready, to unblock local testing envoy->nodeagent, we have to workaround by deploying envoy/nodeagent in same node + apply TLS , so add back TLS option and cert/key

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: quanjielin
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: incfly
If they are not already assigned, you can assign the PR to them by writing /assign @incfly in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

security/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/cc @qiwzhang @wattli @JimmyCYJ


Add "today" command to view today tuition classes

fixed #96

Merge and resolve CI failures first.

Codecov Report

Merging #103 (52499c8) into master (c953120) will decrease coverage by 0.11%.
The diff coverage is 10.00%.

@@             Coverage Diff              @@
##             master     #103      +/-   ##
============================================
- Coverage     49.40%   49.28%   -0.12%
- Complexity      504      505       +1
============================================
  Files           111      113       +2
  Lines          2445     2455      +10
  Branches        293      293
============================================
+ Hits           1208     1210       +2
- Misses         1158     1166       +8
  Partials         79       79

Impacted Files
Coverage Δ

...ddress/logic/commands/ViewTodayTuitionCommand.java
0.00% <0.00%> (ø)

.../seedu/address/logic/parser/AddressBookParser.java
55.17% <0.00%> (-1.98%)
:arrow_down:

...ss/logic/parser/ViewTodayTuitionCommandParser.java
0.00% <0.00%> (ø)

src/main/java/seedu/address/ui/MainWindow.java
0.00% <0.00%> (ø)

...va/seedu/address/logic/commands/CommandResult.java
92.30% <100.00%> (+0.30%)
:arrow_up:

...java/seedu/address/model/tuition/TuitionClass.java
56.96% <0.00%> (+1.26%)
: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 c953120...52499c8. Read the comment docs.


TAS: reduce friction for setting the PodSet annotations

What would you like to be added:
Allow scheduling workloads without TAS annotations  (kueue.x-k8s.io/podset-required-topology or kueue.x-k8s.io/podset-preferred-topology) on every PodSet.
The idea is to default the annotations, but we need to decide where is the configuration.
Why is this needed:
Currently, users of TAS need to set annotations on every PodTemplate. While this gives control, it also creates friction and room for error, because users may forget to set the annotation. Also, most users want to use the "preferred" mode, and they don't need to control the topology level.
Completion requirements:
This enhancement requires the following artifacts:

[ ] Design doc (KEP update)
[ ] API change
[ ] Docs update

The artifacts should be linked in subsequent comments.

cc @mwielgus @mwysokin @tenzen-y


Release asset not found

When attempting to install from Logseq plugins marketplace I get this message:
[Error]<logseq-chartrender-plugin> :release-asset-not-found "null"]

This is on Logseq version 0.10.9 revision c67b8b5.

Same situation. First I thought it’s some problem with the old version. I uninstalled the old version then found out unable to install again.


Vls server start 4 times while open changes in VSCode

I think this might be a bug for the Vala Language Server.


Wmts getFeatureInfo with REST functionality

This is based on #3142, it builds on #3026 and #2373 which address issues #2721 and #2368 and adds functionality to allow for REST encoded WMTS getFeatureInfo requests and creating these from the capabilities document.
It adds a getFeatureInfoOptions object to the WMTS source constructor which allows the preferred request encoding, info format and url to be set.

This build failed in Travis due to a proj4 variable not being found. Running ./build.py ci works for me locally, but I don't have permission to restart the build on Travis.

I just restarted it

I haven't looked at the code yet, but it'd be good to squash the commits into fewer commits. And commit messages should always start with a capital letter, as indicated in the CONTRIBUTING.md file.

@sarametz would you be able to update the examples to use the new template structure we introduced this week at the code sprint? See: https://github.com/openlayers/ol3/tree/master/examples_src for more info and let us know if you have any questions.

@bartvde I have updated the examples in this PR. Please let me know if there is anything else I need to do before this is reviewed

@bartvde I have updated the PR with your comments. With regards to the optional params, I had a read of the spec and it looked like the only other parameters that may be required are style, format and dimensions. Have updated so that these are populated from the wmts source definition and only info format can be optionally specified in the function call. I did add a typedef for the getFeatureInfoOptions, let me know if this is ok.

@sarametz you will need to add getFeatureInfoOptions here as well: https://github.com/openlayers/ol3/blob/master/externs/olx.js otherwise you cannot pass it in from client code (or example). E.g. I'm pretty sure your example will not work in hosted mode right now (try with ./build.py host-examples and run the example from build/hosted/[branch name]/examples

I have updated this PR locally, however I'm unable to check it as the update from build.py to make has caused something to go wrong with my setup.
After running make host-examples and then make serve on the latest master, every example at http://localhost:3000/build/hosted/master/examples/.html gives me an alert saying "Main script not in manager paths: "
I've checked that the example is at the path specified and that it has read permissions. @bartvde do you have any idea how to fix this?

I have updated this PR locally, however I'm unable to check it as the update from build.py to make has caused something to go wrong with my setup.
After running make host-examples and then make serve on the latest master, every example at http://localhost:3000/build/hosted/master/examples/.html gives me an alert saying "Main script not in manager paths: "
I've checked that the example is at the path specified and that it has read permissions. @bartvde do you have any idea how to fix this?

I've got the same error, investigating now…

In the mean time you can use another web server to serve the examples in the hosted directory. For example python -m SimpleHTTPServer.

I've got the same error, investigating now…

I've created a PR for that issue: https://github.com/openlayers/ol3/pull/3649.

Thanks @elemoine. I'm now having trouble running make test-rendering. I'm getting this output:
node tasks/test-rendering.js
Error getting the exit status of SlimerJS
Error: ENOENT, open '/Users/smetz/dev/ol3/build/slimerjs-profile/exitstatus'
make: *** [test-rendering] Error 1

I tried the make serve option at /test_rendering/index.html but that gave me a lot of
Error: Uncaught Error: The dimensions of the reference image and the test canvas are not the same. (http://localhost:3000/node_modules/expect.js/index.js:102)
    at process.on.global.onerror (http://localhost:3000/node_modules/mocha/mocha.js:5990:10)

It seems to work in Travis fine. Do you have this problem?

@sarametz On OSX, make test-rendering only works through make server, as you tried. But there the problem is that it will only work on devices with a pixel ratio of 1, so not on Retina displays. We're currently not able to fix the former issue, but we may be able to work around the latter. For now, you'll have to let Travis run these tests.

Removing the milestone due to build failures.

I have updated this PR, it now has a typedef in externs/olx.js and works in hosted mode on my machine.

Unfortunately we never finished this review, and in the meantime too much has changed to make the build pass again with a simple merge. @sarametz, any chance you'd be able/willing to finalize this work? I'm closing the pull request for now, but please reopen if you continue working on it.

@ahocevar I will try and pick it back up in the next week or two.


Dockerfile needs to be updated

The Dockerfile needs to be up to date. Currently, we run docker environments using deis/go-dev image through Makefile. (check https://github.com/Azure/acs-engine/blob/8592e491e203bdf941a92b9383ebb35fa5de4a5b/Makefile#L44).
The Dockerfile needs to reflect the process followed here.

We are asking for the Dockerfile to be changed. Right now, we are essentially running the deis/go-dev containers with parameters to containerize acs-engine (check make dev in the Makefile)
That docker run command can be converted into an equivalent Dockerfile.

Yes. Right now, the only way to spin up a working and a good docker
container is via Makefile. Some of the acs-engine users have already
attempted to create containers from our outdated Dockerfile and are running
into issues. It would be nice to have a Dockerfile which reflects exactly
what make dev is doing. The docker run command flags used have Dockerfile
primitive equivalents. That's what I had in mind when I created this issue.
On Wed, Sep 5, 2018, 08:24 Matt Boersma<EMAIL_ADDRESS>wrote:

I don't understand which Dockerfile needs to be updated, or why. Do you
mean the deis/go-dev image should be replaced with a container created from
a local Dockerfile?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Azure/acs-engine/issues/3770#issuecomment-418772257,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACiPsB2Dwz1lA8NqjW3mqwVCRoqPeVYDks5uX-y0gaJpZM4WUGAb
.


Bad links in sitemap.xml when config variable "url" not ending in "/"

The system mis-generates the links i nthe sitemap.xml when the website config variable "url" does not end in a "/".
I believe that this is something which can be easily checked for and fixed either when the variable is used, or when it read.

Verified, ssg now throws an error when the closing "/" is missing.
Seeing the validate-config in the commit reminds that I wanted to file an enhancement, a "check" command which simply check the website.conf. Not just what is in validate-config now, but also things like finding deprecated settings and telling the user how to fix them, i.e. tell the new name of the setting. Stuff like that.

A "check" command is a good idea. Warnings could be introduced in
validate-config to provide the functionality you describe. However, with
version 1.0 on (or 1.1 the latest) I intend to have Tclssg follow SemVer,
so hopefully setting deprecation will be less of an issue.
--
Sent from my mobile device.


Enhance: Ui of the testimonial section.

I would like to change the UI of the testimonial section to make it more attractive by improving its vards and adding some cool effects.

So, please assign this issue to me under GSSOC'23.

assigned @Pragati-3003
Make sure on creating PR branch name should be of specific format,
VOVOCA-issueNumber
e.g for this issue number is 14 so
VOVOCA-14

assigned @Pragati-3003
Make sure on creating PR branch name should be of specific format, VOVOCA-issueNumber
e.g for this issue number is 14 so VOVOCA-14

Okie
And , Thanks for assigning this to me.


Internal loop timestamps break filtering inside loop

Problem
The BeginLoopCalculator makes its own timestamp for items within the loop, which is completely divorced from the actual timestamps that it receives.
  // Fake timestamps generated per element in collection.
  Timestamp loop_internal_timestamp_ = Timestamp(0);

Other calculators use cc->InputTimestamp() to determine how much time has passed since previous packets, such as mediapipe\util\filtering\one_euro_filter.cc and mediapipe\util\filtering\relative_velocity_filter.cc.
If any of these calculators are used within a loop, they will not work as intended because the cc->InputTimestamp() call will read the fake timestamp generated by BeginLoopCalculator.
My proposed solution
I've solved this problem for my solution by making loop_internal_timestamp_ jump up to the value of cc->InputTimestamp() in the Process() call of BeginLoopCalculator. The change is an addition of 1 line.
mediapipe\lounge\calculators\lounge_begin_loop_calculator.h:
  absl::Status Process(CalculatorContext* cc) final {
++    loop_internal_timestamp_ = std::max(cc->InputTimestamp(), loop_internal_timestamp_);
    Timestamp last_timestamp = loop_internal_timestamp_;

This solution could stretch out the timestamps undesirably if a system is able to process an average of more than 1 loop per microsecond, but I think that's very unlikely.
Side note
I know that implementing stateful filters within a loop can be problematic because we then need a separate state for each item in the loop, but that's a separate issue.

Hello @DeanIsMe,
We are upgrading the MediaPipe Legacy Solutions to new MediaPipe solutions However, the libraries, documentation, and source code for all the MediaPipe Legacy Solutions will continue to be available in our GitHub repository and through library distribution services, such as Maven and NPM.
You can continue to use those legacy solutions in your applications if you choose. Though, we would request you to check new MediaPipe solutions which can help you more easily build and customize ML solutions for your applications. These new solutions will provide a superset of capabilities available in the legacy solutions.


fix: fixed typo and removed the ignore file entry

Description
Fixed the typo for service_endpoints
Types of changes in this PR
Changes that affect the core Terraform module or submodules

[x] Bug fix
[ ] New feature
[ ] Dependency update

Changes that don't affect the core Terraform module or submodules

[ ] Examples or tests (addition or updates of examples or tests)
[ ] Documentation update
[ ] CI-related update (pipeline, etc.)
[ ] Other

Release required?
Identify the type of release. For information about the changes in a semantic versioning release, see Release versioning.

[ ] No release
[x] Patch release (x.x.X)
[ ] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content
If a release is required, replace this text with information that users need to know about the release. Write the release notes to help users understand the changes, and include information about how to update from the previous version.
Your notes help the merger write the commit message for the PR that is published in the release notes for the module.
Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

Merge actions for mergers

Use a relevant conventional commit message that is based on the PR contents and any release notes provided by the PR author. The commit message determines whether a new version of the module is needed, and if so, which semver increment to use (major, minor, or patch).
Merge by using "Squash and merge".

/run pipeline

/run pipeline

/run pipeline

@Ak-sky This PR seems to be missing any code changes?

/run pipeline

/run pipeline

@Ak-sky We need to remove the KMS encryption from the complete example since it doesn't provision an enterprise plan. We will also have to skip the upgrade test, so I suggest you do that in a separate PR, and then re-base this once its merged

/run pipeline

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


Question about extra_args

Hi,
I am using this collection and it is working very well, thanks.
I am calling your collection from my own playbook with this:
- name: Import the k3s playbook with flannel
  ansible.builtin.import_playbook: "/Users/xxxxx/.ansible/collections/ansible_collections/techno_tim/k3s_ansible/site.yml"
  vars:
    k3s_version: "{{ hostvars['localhost']['k3s_version'] }}"
    k3s_token: "{{ hostvars['localhost']['k3s_token'] }}"
    apiserver_endpoint: "{{ hostvars['localhost']['apiserver_endpoint'] }}"
    k3s_master_taint: "{{ hostvars['localhost']['k3s_master_taint'] }}"
    kube_vip_lb_ip_range: "{{ hostvars['localhost']['kube_vip_lb_ip_range'] }}"
    k3s_cni: "{{ hostvars['localhost']['k3s_cni'] }}"
    install_k3s: "{{ hostvars['localhost']['install_k3s'] }}"
    flannel_iface: "{{ hostvars['localhost']['k8s_interface'] }}"
    extra_args: "--disable local-storage"
  when:
    - install_k3s | default (false) | bool
    - k3s_cni == "flannel"```

and all is working, except the extra_args. Can you tell me how I should have the extra argument stated?
It is failing like this and when I remove the complete extra_args line all is working again.

I have also tried
extra_args: >-
  "--disable local-storage"

and
extra_args: >-
  --disable local-storage

Thanks!

Found it, this was the fix:
    extra_args:
      - "--disable local-storage"


stock and crypto price display bug

Describe the bug
I've managed to enter the names of the crytpo and stocks I want the course to change but it's not the right course nor the right marketcap. How can I solve this problem?

Link to the Bolt URL that caused the error
https://bolt.new/~/sb1-lqaz3y
Steps to reproduce
go to the chat and scroll to the 2 last messages
Expected behavior
I wanted to know the real price of shares and cryptos
Screen Recording / Screenshot

Platform
Browser name = Chrome
Full version = <IP_ADDRESS>
Major version = 131
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36 Edg/<IP_ADDRESS>
performance.memory = {
  "totalJSHeapSize": 105467131,
  "usedJSHeapSize": 101856639,
  "jsHeapSizeLimit":<PHONE_NUMBER>
}
Username = ozaii33
Chat ID = b303622841af

Additional context
No response

Unfortunately we don't have the resources to offer programming assistance for individual projects. You can read more about continuing to develop your project here.


Fix built-in LSP

Fix https://github.com/ncm2/ncm2/issues/180 caused by https://github.com/neovim/neovim/pull/11895.

@roxma this fixes some bugs

This has fixed #180 for me, also :)

Does context.base work for the issue? I would prefer to use context.base

@roxma, yes, context.base works. Thanks.