Copy edit pass on style-guide page

Describe your changes
Copy edit pass on Style Guide page.
Related issue number or link (ex: resolves #issue-number)
n/a
Checklist before opening this PR (put x in the checkboxes)

[x] This PR does not contain plagiarism

don’t copy other people’s work unless you are quoting and contributing it to them.

[x] I have signed off on all commits

signing off (ex: git commit -s) is to affirm that commits comply DCO. If you are working locally, you could add an alias to your gitconfig by running git config --global alias.ci "commit -s".

Hi @nate-double-u
This PR looks good to me as is. :)
In addition to this PR, I just noticed that there is some misleading content related to the tag.
Could you help us to update it?
Currently, we are using the format tags: ["tag 1", "tag 2", ""], which is different from the current guide.
For example, you can refer to this line in the file: cloud-computing.md
-tags: ["tag 1"], ["tag 2"]
+tags: ["tag 1", "tag 2", ""]

Please update the following line:
Link to line: 115 in the PR

Thanks for pointing that out @seokho-son—updated.

Again, LGTM
Needs additional approval. :)


make lib failed

OS: OS X Sierra
GNU Make 3.81
this is output message:
kent:libsvm-3.21 kent$ make lib
if [ "Darwin" = "Darwin" ]; then \
		SHARED_LIB_FLAG="-dynamiclib -Wl,-install_name,libsvm.so.2"; \
	else \
		SHARED_LIB_FLAG="-shared -Wl,-soname,libsvm.so.2"; \
	fi; \
	c++ ${SHARED_LIB_FLAG} svm.o -o libsvm.so.2

as you can see, SHARED_LIB_FLAG can not be recognized
suggest:
lib: svm.o
	@if [ "$(OS)" = "Darwin" ]; then \
		SHARED_LIB_FLAG="-dynamiclib -Wl,-install_name,libsvm.so.$(SHVER)"; \
	else \
		SHARED_LIB_FLAG="-shared -Wl,-soname,libsvm.so.$(SHVER)"; \
	fi &&\
	$(CXX) $${SHARED_LIB_FLAG} svm.o -o libsvm.so.$(SHVER)

The original Makefile works on my Mac Machine. Could you please show the error message with the original Makefile? What's the shell used in your environment?

a mistake


Make the OS Places rate limit configurable.

Instead of hardcoding 3 per second, use the environment variable OS_PLACES_API_POSTCODES_PER_SECOND if it's set, otherwise default to 3.
This helps Replatforming to avoid overloading OS Places API while running in parallel with the existing EC2 deployments.

I approve, but... do we know why this was causing spikes? Our rate limit is 600 rpm, and 3 a second only comes out at 180 rpm - @ChrisBAshton does this job run on all environments (ie are we doing 540 rpm just on int/staging/prod, not counting the EKS envs?)

This isn't intended as a solution to whatever was (is?) behind the load spikes — this is just so that Replatforming doesn't add to the problem unnecessarily.

I approve, but... do we know why this was causing spikes? Our rate limit is 600 rpm, and 3 a second only comes out at 180 rpm - @ChrisBAshton does this job run on all environments (ie are we doing 540 rpm just on int/staging/prod, not counting the EKS envs?)

@KludgeKML the postcode-updating workers run in all environments, yes 👍

Ah, so we're actually running very close to our rate limit even on the non-EKS envs. Should we configure Int and Staging to have a lower limit? They're presumably getting overridden by production at each sync anyway, sow a much lower level would make little difference to data accuracy and would still alert us if the workers started having other problems.

Whatever your team feels is best 👍 I'd suggest it's worth keeping some activity in integration/staging to test that you don't accidentally break postcode-updating in production, but it doesn't have to be at the same rate as prod.


exception thrown: TypeError: Cannot read property 'from_js' of undefined,TypeError: Cannot read property 'from_js' of undefined

Thank you for the library, it looks very exiting! Unfortunately I am getting an error, trying to run a very simple example.
Here is my src/main.rs:
#[macro_use]
extern crate stdweb;

fn main() {
    let message = "Saluton";
    js! {
        alert( @{message} );
    };
}

In browser (both Chromium and the latest Firefox) I am getting the following errors:
http://[::1]:8000/js/app.js:190 exception thrown: TypeError: Cannot read property 'from_js' of undefined,TypeError: Cannot read property 'from_js' of undefined
    at Array.ASM_CONSTS (http://[::1]:8000/js/app.js:1602:35)
    at _emscripten_asm_const_iii (http://[::1]:8000/js/app.js:1609:26)
    at Array.__ZN6tryweb4main17he5640be6c1e443adE (http://[::1]:8000/js/app.js:8108:11)
    at __ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17hf69b2510974d151bE (http://[::1]:8000/js/app.js:17305:28)
    at Array.__ZN3std9panicking3try7do_call17hc7f54292c4f8bc7dE_llvm_E2C4E477 (http://[::1]:8000/js/app.js:15004:2)
    at Object.dynCall_vi (http://[::1]:8000/js/app.js:37926:31)
    at invoke_vi (http://[::1]:8000/js/app.js:5322:25)
    at ___rust_maybe_catch_panic (http://[::1]:8000/js/app.js:24679:2)
    at __ZN3std2rt10lang_start17h24169098a28de597E (http://[::1]:8000/js/app.js:12472:9)
    at _main (http://[::1]:8000/js/app.js:8032:8)

However println!("message") results into normal console log message.
Extra details:

browser - the latest firefox
I run the app with cargo web start
rustc 1.24.0-nightly (dc39c3169 2017-12-17)

You are missing a call to event_loop at the end of your main which is required under Emscripten backends. (:
Either add a call to event_loop or pass --target-webasm argument to cargo-web to use Rust's native webassembly backend which doesn't use Emscripten.

@koute thank you!
I guess I also missed stdweb::initialize(); (based on the example]
Would it make sense to add this to the first example in README? (I can open PR if necessary)

Would it make sense to add this to the first example in README? (I can open PR if necessary)

Hmmmm.... I'm not sure! The examples section is meant to be more of a demo of the library's capabilities rather than actual documentation, and technically we do have examples/minimal where the correct usage is shown. Perhaps a remark which urged the reader to take a look at that example would be more appropriate?

@koute I just ran into this. I personally think it would be a good idea to show calling stdweb::initialize() in the README, but of course that's because I hit the same bug. Thankfully searching the GitHub brought me right to this issue. :)


Crash in notebook accumulated_local_effects_tutorial.ipynb

I also took a look at your tutorial notebook accumulated_local_effects_tutorial.ipynb again, using the following Python module versions:

pandas: 1.1.5
scikit-learn: 1.0.2
shap: 0.40.0
py-mint: 0.2.6

The current scikit-learn version 1.1 would need additional adaptions.
The function plot_importance() now needs an additional parameter panels. The description in the source code main/interpret_toolkit.py also needs an update.
In cell [17] the parameter plot_correlated_features must be kept at its default value False. I just commented it out.
The function main_effect_complexity() prints out a long warning and no result. The remedy suggested in the warning seems to work. I patched the file main/global_interpret.py as follows:
--- global_interpret.py.orig	2022-07-12 21:21:48.297214577 +0200
+++ global_interpret.py	2022-07-21 12:16:23.558855096 +0200
@@ -14,6 +14,8 @@
 from joblib import delayed, Parallel

+from sklearn.pipeline import make_pipeline
+from sklearn.preprocessing import StandardScaler
 from sklearn.linear_model import LinearRegression
 from sklearn import cluster
 from sklearn.metrics import (
@@ -1959,7 +1961,7 @@
                                [range(temp_breaks[i], temp_breaks[i+1]+1) for i in range(len(temp_breaks)-1)] +\
                                [range(temp_breaks[-1], b_max)]

-                        estimator_set = [LinearRegression(normalize=True) for _ in range(len(idxs_set))]
+                        estimator_set = [make_pipeline(StandardScaler(with_mean=False), LinearRegression()) for _ in range(len(idxs_set))]

                         estimator_fit_set_tmp = [estimator_set[i].fit(x[idxs,:], ale[idxs])
                                              for i, idxs in enumerate(idxs_set)

What do you think?. I'm thankful for your efforts and progress with this project.
Regards,
Jörg.

I'm glad that you are finding this package useful! Yes, including that pipeline with StandardScaler addresses this issue. I will note that py-mint has been re-branded as scikit-explain (https://github.com/monte-flora/scikit-explain). New changes to the package will be made there. If you have any questions, feel free to ask!


Update

Hey @Jovial248,
Something went wrong with the build.
TravisCI finished with status errored, which means the build failed because of something unrelated to the tests, such as a problem with a dependency or the build process itself.
View build log
TravisBuddy Request Identifier: 0564c1a0-abcf-11e9-b158-b5ca4a0ddf5e


Add dispatcher permission to PeeringRequest related identity

Description
With this PR ForeignClusterOperator will add the dispatcher ClusterRole to created ServiceAccount assigned to each PeeringRequest created on a remote cluster
For each ServiceAccount a new ClusterRoleBinding is created to the same ClusterRole. This ClusterRole is managed and updated by the cluster config watcher, so when the config is updated also this role will be

/rebase


[$500] Wallet - Input in Activate card page has BNP and also allows device keypad

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

Version Number: 1.4.34-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
Issue found when executing PR https://github.com/Expensify/App/pull/35303
Action Performed:

Log in with account that has Expensify card (virtual<EMAIL_ADDRESS>).
Go to Settings > Wallet.
Tap Expensify card.
Tap Activate physical card.
Note that

Expected Result:
The page will either show BNP and disable device keypad input, or disable BNP and allow device keypad input
Actual Result:
The page shows BNP and the digit input also allows device keypad at the same time
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[ ] Android: mWeb Chrome
[x] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/741cf918-f734-4c0b-9a1b-48ec0998e69b
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~019ec1c0f677740061
Upwork Job ID:<PHONE_NUMBER>879559680
Last Price Increase: 2024-01-31

We think that this bug might be related to #wave.
CC @dylanexpensify

Proposal
Please re-state the problem that we are trying to solve in this issue.
A keyboard is shown alongside with the big number pad on the activate card page.
What is the root cause of that problem?
We didn't disable the keyboard to show. We pass a isDisableKeyboard props to the magic code input,
https://github.com/Expensify/App/blob/d0e8e2a355ebd09b1cbb035ca1a3f6369950e5d4/src/pages/settings/Wallet/ActivatePhysicalCardPage.js#L144-L145
but we didn't disable the keyboard when isDisableKeyboard is true.
What changes do you think we should make in order to solve the problem?

We need to disable the keyboard when isDisableKeyboard is true.
https://github.com/Expensify/App/blob/d0e8e2a355ebd09b1cbb035ca1a3f6369950e5d4/src/components/MagicCodeInput.tsx#L368-L369
disableKeyboard={isDisableKeyboard}

@bernhardoj looks like we don't have this issue on SignIn page is there any reason behind that? and looks like the prop was intentionally avoided to pass as disableKeyboard https://github.com/Expensify/App/commit/4bf0243197ae413d0e0c55fe9539c563c2d41b08#diff-ecae0b82a8a72087e4f45a15da40053c9b9addf7e830c5ba2975f24956bb9eaaR142

Sign in page doesn't have a BNP, so it's different. From the commit you gave, you can see that we previously passed the props here https://github.com/Expensify/App/commit/4bf0243197ae413d0e0c55fe9539c563c2d41b08#diff-913e8c5633c454fc244676c3b1bb09d85b256cc5b65763a9b02b58c58fab31bbR297
But somehow it's gone now and probably because of some conflict with the TS PR?

You're right i got confused.

Sounds good, assigning @bernhardoj!

PR is ready
cc: @getusha

Payment summary:
@bernhardoj requires payment automatic offer (Contributor) paid$500
@getusha requires payment automatic offer (Reviewer) paid $500.


Add node/kind assertion to the schema entry for name nodes
Addresses #1259 [phab:D939]

Created by zarko at 2016-06-22 00:28:41:

fromberger accepted this revision at 2016-06-22 01:29:33

zarko closed via commit db07d60c80774a3ef406bc9a790033dd233bc8a5 at 2016-06-22 04:21:37


[SPARK-10012][ML] Missing test case for Params#arrayLengthGt

Currently there is no test case for Params#arrayLengthGt.

Merged build triggered.

Merged build started.

Test build #40981 has started for   PR 8223 at commit 5da7c34.

Test build #40981 has finished for   PR 8223 at commit 5da7c34.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/40981/
Test PASSed.

LGTM, but I'll wait to merge with master until after the RC is cut

@jkbradley OK, thanks!

@jkbradley do we need to wait for something here? things can go into master safely; this looks safe for branch-1.5 too regardless of whether it makes this RC or another release. Did I miss some email about an RC and not merging?

No, just trying not merge stuff which isn't critical, but sure, I'll merge it with master and branch-1.5

I like the caution on 1.5; master should be safe in any event. It's my impression that in the QA period new tests (which pass) are pretty freely mergeable. Maybe I should send around an email about the consensus on that to make sure we're operating similarly. +1


add Parameters to ClientCredentialsClient for sending 'audience' parameter

What issue does this PR address?
Auth0 requires sending the audience parameter with a client credentials token request. This adds a Parameters property to ClientCredentialsClient that allows specifying any arbitrary parameters with a token request. Fixes #9. I know there Dominick said "we will look into it", but I figured if I wrote the PR it might make it into 1.0 😄  If there's some reason not to merge this, I understand.
I initialized Parameters automatically to follow the same pattern as ProtocolRequest in IdentityModel.Client.
Important: Any code or remarks in your Pull Request are under the following terms:
If You provide us with any comments, bug reports, feedback, enhancements, or modifications proposed or suggested by You for the Software, such Feedback is provided on a non-confidential basis (notwithstanding any notice to the contrary You may include in any accompanying communication), and Licensor shall have the right to use such Feedback at its discretion, including, but not limited to the incorporation of such suggested changes into the Software. You hereby grant Licensor a perpetual, irrevocable, transferable, sublicensable, nonexclusive license under all rights necessary to incorporate and use your Feedback for any purpose, including to make and sell any products and services.
(see our license, section 7)

Thanks! That does indeed save us some time. 1.0 is very soon.


Fix German translations

This fixes a few things and assumes das wallet and der seed.
I would recommend releasing an update with this PR since some of the current translations make the app a bit awkward to use (For example the word "stornieren" on popups means "(to) cancel a booking/reservation").
Some things I would like to bring up for discussion (without blocking this PR though):

Moving from formal+uppercase "Sie/Ihr" to informal+lowercase "du/dein" which is more common in personal use apps
Uppercase "Wallet" and "Seed" feels a bit weird although they are nouns, if other people agree I would lowercase them

The following need better translations, but I'm having trouble coming up with anything good:
"view_key_(private)" = "Ansichtsschlüssel (geheim)";
"spend_key_(private)" = "Ausgaben-Schlüssel (geheim)";

@lastleon hey, thanks for helping out! Unfortunately I don't think this repo is active anymore and I'm not sure where the actual CakeWallet source code is located nowadays, I'm not working on this PR anymore.

@kpcyrd Hi, to be honest I did not check the the date of the last commit of this repo or your PR, and only after submitting this realized this isn't active anymore. I believe this is the new official repo, if you are still interested.
Thanks for replying though :)


Refactor schema graph class collections

Coverage decreased (-0.2%) to 93.64% when pulling b71023bc059f8bb85785c5b9d9b657b82c40a739 on refactor-schema-graph-class-collections into 7c5fcb7a901afd5d3a1a2feb1976fef5af20ea4d on refactor-schema-graph.


[RFC] Dynamically enable concurrent search on search requests at runtime

Is your feature request related to a problem? Please describe
TL;DR
I am proposing a mechanism to increase the adoption of concurrent segment search by dynamically enabling it for user at runtime on a per request basis based on certain factors --- such as request type and resource availability; currently starting off with CPU utilization and with ability to add more deciding parameters in the future.
Background Overview
With the introduction of Concurrent Segment Search we have seen good improvement in search performance.
However, currently the feature is disabled by default and users have to go and enable the feature manually by enabling one of cluster level setting or index level setting. ref
This means that users need to take manual action to enable concurrent search for their workloads in OpenSearch.
However, based on the performance benchmarking done, we have the following observations -

For certain type of queries such as aggregation queries we generally see improvement in search latency
short running queries with latency in single digit ms, concurrent search doesn't show much improvement.
CPU utilization increases with concurrent search, and increases linearly with slice count

Given these observations, we can enable concurrent segment search whenever possible to efficiently utilize resource and get performance benefits.
Any overrides that user has set will be honored. This feature is catered more towards the cases where concurrent search feature has not been explicitly set by the user.
Describe the solution you'd like
At a high level, introduce an additional decision layer that runs as a separate component and monitors the metrics such that it can be retrieved as a simple in-memory lookup at runtime during a search request. This will be done with the tenets that dynamic decision making needs to be fast and not add additional latency to the search request.
Each search request will query this decision layer to get a decision of whether to execute the search request via concurrent search path or not. The decision making happens at a node level, which means each shard search request has an independent decision.
The decision layer would be a composite decision similar to AllocationDecider for example, with multiple factors providing their decision. The initial version would probably have a request type decider and a resource utilization based decider. The request type decider is to initially target specific type of requests such as aggs with possibility to expand to more requests in the future. This provides us some initial control over enabling this feature.
However, for the rest of this proposal, I will focus on the non-trivial logic of resource based decision making.
Given this abstraction, I am proposing the following algorithm for dynamic decision making
The decider monitors CPU utilization as well as overall search latency and concurrent search latency over a sliding window of size N.
Along with this, the decider will also have an initial percentage X% to control how many reqests in a time window will be allowed to be executed with concurrent segment search.  This initial percentage can be set based on the SearchRate metric on the cluster, with starting value close to min SearchRate
The decision algorithm would look like this:
If the CPU_max over window is below a threshold CPU_high, then there is sufficient resource availability to enable concurrent search. By default, the slice_count will be set to 2.
We can start by enabling concurrent search for X% of the requests and continue monitoring CPU as well as search latencies (both overall search latency and concurrent search latency).
Decider will continue to monitor the metrics and if CPU_max is still lower than CPU_high, increase the X% by enabling factor E. However, if the CPU_max is greater than or equal to CPU_high, then decrease the X% by decreasing factor D. To react faster to resource constraints, we can set D = 1.5*E.
The decider also monitors concurrent search latency and overall search latency over the window N and if average concurrent search latency is greater than overall average search latency by a difference threshold diff_threshold, then concurrent search might not be providing performance benefits so we can reduce the percentage X% by a factor of D again.
In this way, we penalize both performance degradation as well as resource constraints and we enable in scenarios when CPU is available and performance improvements are seen.
The algorithm can also be smart to increase slice count (up to a max value MAX_SLICE) once most of the queries are being run in concurrent mode, determined by X going over a threshold percentage and we still have available CPU to further improve performance. MAX_SLICE can be set based on the instance type. Similarly, slice_count can be decreased (up to min value MIN_SLICE=2) if X goes below a certain threshold.

Decision loop:
    if CPU_max < CPU_high:
        #increase percentage by factor E
        X = X + (X * E)
    else:
        #decrease percentage by factor D
        X = X - (X * D)

    if avg_concurrent_search_latency > avg_overall_search_latency:
        if diff > diff_threshold:
            X = X - (X * D)

    if X > T:
        #increase slice count
        slice_count = max(MAX_SLICE, slice_count * 2)
    if X < B:
        # decrease slice count
        slice_count = min(MIN_SLICE=2, slice_count / 2)

All of the variables in the above algorithm can be configurable via cluster settings.
Related component
Search:Performance
Describe alternatives you've considered
Multi-armed bandit approach
https://en.wikipedia.org/wiki/Multi-armed_bandit
In Multi-armed bandit approach (in our case it is 2-armed Bandit), we try to balance exploration (sometimes explore concurrent_search path) and exploitation (exploit scenarios where we see good benefit with enabling concurrent search)

Monitor CPU and latency metrics similar to approach above over sliding window of size N to keep track of CPU_max for the window.
Have a  threshold for CPU utilization  CPU_high
Now the bandit algorithm will make decision based on 2 factors

Exploration: randomly route some requests to concurrent_search path based on random probability
Exploitation: Have a reward trade-off factor comparing concurrent_search efficiency vs non-concurrent search efficiency.
In this case we use the ε - greedy approach of balancing exploration vs exploitation.

Initial Reward is 0 for both concurrent search and non-concurrent search.
Then based on how search requests are performing, we will provide rewards to either of the 2 paths (concurrent vs non-concurrent).
The reward is calculated as follows
a. Concurrent search reward:  total reward received for concurrent search over total request executed in concurrent path.
b. non-concurrent search reward: total reward received for non-concurrent search over total requests executed in non concurrent path.
Upon request completion, based on the metrics being monitored, the rewards are updated as follows - if CPU_max < CPU_high, then grant a reward E . However, if CPU_max >= CPU_high then grant negative reward D. Non-concurrent path always gets positive reward E. Once again, we can have D = 1.5*E . Also, penalize the concurrent search reward if the avg concurrent search latency becomes greater than overall average latency by a diff_threshold.
Slice count can also be adaptively modified based on rewards.

# Initial rewards will be 0 for both
total_reward_non_concurrent=0
total_reward_concurrent=0

function select_path():
    # explore
    if random < some_arbitrary_threshold:
        return concurrent_path
    else:
        # exploitation
        return (total_reward_concurrent / concurrent_count) > (total_reward_non_concurrent / non_concurrent_count)
        ## whichever was giving more rewards, i.e. better performance, we will take that path.

Decider logic:
	path = select_path()
	return path

Post decision update:
## post path selection, we can update variables for subsequent requests
if path == concurrent_path:
	concurrent_count += 1
	if CPU_max < CPU_high:
		reward_concurrent += E
	else:
		reward_concurrent -= D
	if avg_concurrent_search_latency > avg_overall_search_latency:
        if diff > diff_threshold:
            reward_concurrent -= D
else:
	reward_non_concurrent += E

On comparing the proposed approach and the current version of the multi-armed bandit approach; it seems to me that the two are quite similar but multi-armed bandit approach has ability to take concurrent path even at times when CPU is under duress.  Also, in the first approach, we can think of looking at CPU_max as exploration and increasing the request percentage X% by E or decreasing by factor D as a form of reward and by extension, a form of exploitation.
Reinforcement learning approaches work better when the state of the system is well represented, and in the current version, we don’t have more fine-grained representations of the state, one such example being a detailed representation of the request. Furthermore, the efficiency of the multi-armed bandit strongly comes down to how robust the reward function is.
Additional context
Co-Author: @sohami

Thanks @Gankris96 for the RFC!
The way I see it we're trying to address a few different things at once here:

Increase adoption of concurrent segment search (ElasticSearch comes with their version enabled by default for example: https://www.elastic.co/search-labs/blog/elasticsearch-opensearch-vector-search-performance-comparison#out-of-the-box-and-concurrent-segment-search)
Do so in a way that does not lead to performance regressions for users, whether it be due to query type or due to resource utilization.

I think something like #9491 will be a great first step in terms of adoption to let users more easily try out concurrent segment search on their existing workloads.
Some specific questions:

At a high level, introduce an additional decision layer that runs as a separate component and monitors the metrics such that it can be retrieved as a simple in-memory lookup at runtime during a search request. This will be done with the tenets that dynamic decision making needs to be fast and not add additional latency to the search request.

Are you thinking this decision layer would be provided as a plugin or as a part of core? Or could it even be implemented by something like adding plugin hooks to the existing search backpressure interfaces
It would be great to get a list of the tuning knobs that you are thinking would be available to the user. As it is search backpressure has so many tuning knobs that aren't super clear what each knob even does so it would be best to be as concise and precise as possible with those.

@reta I know you had some thoughts you shared during the weekly search meeting as well, would be great if you could share again here too

@reta I know you had some thoughts you shared during the weekly search meeting as well, would be great if you could share again here too

Thankls @jed326 , you have perfectly outlined the same concerns I have, +1 to start with https://github.com/opensearch-project/OpenSearch/issues/9491 as low hanging fruit.

Thank @jed326 and @reta
I agree that request level parameter #9491  would be helpful as a first step. However, my thoughts on this is to minimize user level involvement as much as possible.
I see this helping in cases where the user doesn't have access to modify cluster settings for example. However, the user has to identify the right category of requests to use this parameter with, if not could potentially lead to resource utilization spiking.
In terms of the decision layer itself - I envisioned it to be within core itself, probably similar to search backpressure service for example, because I dont know that there would be use of this outside of the search flow. We can provide capability to have pluggable deciders to add onto existing deciders.

I agree that request level parameter https://github.com/opensearch-project/OpenSearch/issues/9491 would be helpful as a first step. However, my thoughts on this is to minimize user level involvement as much as possible.

+1 to this, the goal here is to reduce user involvement in deciding whether to use concurrent vs sequential execution path. OpenSearch execution layer should be able to make that choice for the user instead of user driving it (which is what index, cluster or request level option provides)

We can provide capability to have pluggable deciders to add onto existing deciders.

We will need to provide pluggable mechanism such that for different use cases, some other decision logic can be integrated by plugins. We can keep the generic decision making components like cpu utilization in core deciders. For example: In case of KNN, it can look into native memory usage to decide on when to not enable concurrent search on more requests. It will be separate from SearchBackPressureService, as this is specific to choosing a query execution mechanism.

I still think that building the capability to work independent of user intervention or with minimal user intervention is what we should aim for. Providing a request level capability means we anyway rely on user sending in requests with this parameter which defeats the purpose. I am going to be looking into the low level design for this so please let me know if you have further thoughts/concerns on this.
The decision layer would be within core with a pluggable interface for external plugins to add their own decision layers and the combination of these deciders will result in dynamically toggling on/off concurrent search.
@jed326 @reta @sohami

I still think that building the capability to work independent of user intervention or with minimal user intervention is what we should aim for.

I don't think anyone is arguing with that. I think the concern is - there are no clear metrics / measurements / signals to build that right now. Fe., I see only CPU mentioned here, but I think it far from being sufficient: we don't look at the thread pool utilization that concurrent search is using (it may just queue all the work). This is just one of the examples.
What I think is missed here is:

computational model for concurrent search
index geometry (size, number of segments, https://github.com/apache/lucene/pull/13542 may change that)
from the above, which factors has to be taken into account for decision making

I am sure there is much more to that.

Thanks @reta. I did think about the thread pool utilization too but I don't think there is a direct correlation in terms of the performance or at least a visible one. Do we need to care about thread_pool queue increasing if the search latency is still improving anyway?  If there really is a hit in performance i guess it would consequently show up in the concurrent search avg latency becoming worse and the decider would have a way to detect that and reduce the number of requests getting run with concurrent segment search so that there is no performance degradation due to queuing.  Do you see other issues because of this?
Currently, the major limiting factor for concurrent search based on our benchmarking in resource availability and specifically CPU.
Anyway, I was thinking of this in terms of making an initial step towards having concurrent search dynamically enabled under certain conditions to increase the feature adoption. Additional decision parameters can be added to make the decision making more comprehensive.
Let me think more on the computational model for concurrent search and index geometry points you brought up as well.

Fe., I see only CPU mentioned here, but I think it is far from being sufficient: we don't look at the thread pool utilization that concurrent search is using (it may just queue all the work).

I think this is fine for now since it's called out that we will expose pluggable deciders so we can keep refining this system with additional parameters in the future.

Create a sub issue that tracks part of the changes described in this Issue here: https://github.com/opensearch-project/OpenSearch/issues/15259


Add a method to the Simulation class to display model

It could be helpful to both developers and users to have a way to quickly visualize the various PhysicsModules and Diagnostics that have been added to a Simulation (an instance of the Simulation class).
This could be achieved by creating a method for the Simulation class that loops over the physics_module list and prints the name (or class name) of each item in the list. And then does something similar for the diagnostics.
Perhaps better would be to also add a method to the PhysicsModule and Diagnostic classes, which prints specifics about the module/diagnostic. For example, each module could also print the values of its settings, and a list of variables that it is sharing.
There are many possibilities for more advanced versions of such functionality. Perhaps a tool that takes a Simulation instance and creates a flowchart (use html/js, perhaps flowchart.js) that shows the Modules, Diagnostics, and the connections between the variables.
Thoughts?

I'd like to see this feature support causal model graphs that are useful in visualizing UQ and sensitivity studies. Something like this (but not powerpoint engineering but a real interactive diagram with all the details of the simulation):

Related to this, could we add metadata to the data objects? For example, a good first metadata object would be a descriptive string.

That's exactly the kind of thing I'm thinking about. It would be really useful, and it would be cool if it could tie into UQ.
Regarding adding metadata to the shared data objects, that is totally possible. I've been thinking about various ways to do that. Need to balance increased functionality with possible increased complexity.
Rethinking the data objects might actually help with other things though... e.g. it could help with #10, and also with a rewrite of the sharing algorithm that I've been mulling over.

So, don't judge... I've been reading python documentation, and searching for options for an annotated data type like you describe. I finally got around to reading about xarray. I had heard it described as N-dim pandas, or an easier/more powerful NumPy array. Reading the page linked above makes me think we should explore using it for turboPy. If nothing else, it looks like adding arbitrary metadata would be easy.

No judgement here!  (But I'm not good litmus.)
They had me at "you’ll understand what you were thinking when you come back to look at it weeks or months later."
I had been looking at netCDF already for nepc. On its face, this seems perfect for our whole UQ/chemistry/turboPy toolchain.

Going along with the no judgment theme, what is UQ? I've heard it referred to in the theory division MMM but haven't spoken up about it.

UQ is short for uncertainty quantification. At the most basic level it is a field of study which tries to answer the question "how do uncertainties in inputs to a model affect the model outputs (both value of the output, and uncertainty in the output)?"
At least that's my understanding of what it means.

On a separate note, xarray looks great. See the recent push to the example app. I'm going to open a separate issue to discuss using xarray more extensively.

I think I’ll start a similar issue to look at using xarray in nepc, too.
--
Paul Adamson, PhD
Naval Research Laboratory, Code 6770.1
4555 Overlook Ave. SW
Washington, DC 20375-5320
(o)<PHONE_NUMBER>
(c)<PHONE_NUMBER>
From: Steve Richardson<EMAIL_ADDRESS>Reply-To: NRL-Plasma-Physics-Division/turbopy<EMAIL_ADDRESS>Date: Monday, July 20, 2020 at 4:13 PM
To: NRL-Plasma-Physics-Division/turbopy<EMAIL_ADDRESS>Cc: Paul Adamson<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [NRL-Plasma-Physics-Division/turbopy] Add a method to the Simulation class to display model (#9)
On a separate note, xarray looks great. See the recent push to the example app. I'm going to open a separate issue to discuss using xarray more extensively.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.


method for stream measurements estimated for Valle is ground estimate

cover and other parameters can also be filled in wiht a caveat added to the comments

closing with a point to #30


addComponents does not compile @screen directive

I have the following windicss.config.js:
const plugin = require("windicss/plugin");

module.exports = {
  plugins: [
    plugin(({ addComponents, theme }) => {
      const screens = theme("screens");
      components = {}
      Object.entries(screens).forEach(([screen]) => {
        components[`@screen ${screen}`] = {
          "test-utility": {
            color: `'red'`,
          },
        };
      });
      addComponents(components);
    }),
  ],
};

And I have HTML as follows:
<div class="test-utility">Hello world!</dev>

I expect the plugin to generate the following CSS:
@media (min-width: 640px) {
  .test-utility {
    color: red;
  }
}
/* and so on... */

But the CSS generated looks like this:

Am I doing something wrong here or is this a bug?

Bump, I'm trying to replicate the bootstrap responsive container using screens, but windi generates the same "classes" as above and doesn't apply a max-width
Repo: https://github.com/NicolaSpadari/windicss-plugin-bsgrid


Include parent headings in anchor links

Follow up of https://github.com/crystal-lang/crystal/pull/8344.
This factors in parent headings within the generated anchor links.  E.x. If you have a structure like
# Parent

## Child One

### Sub Child

## Child Two

### Sub Child

You can now link directly to both Sub Child headings, whereas before you could only link to the first.

IICR this would mean links to #child-one no longer and you'd need the fully qualified anchor #parent-child-one. I don't like that because it breaks existing behaviour. This could probably be worked around, though.
Still, I don't think this is a great idea. It encapsulates contextual information into an anchor, which would lead to broken links to subsections whenever the structure is reorganized or a parent heading gets renamed. IMO that's not acceptable. I'd rather keep the status quo and ask writers to use unique headings to make them linkable.
Did you do any research on other solutions to this problem?

@straight-shoota Fair point.  I just checked out what Github does, and they add a -# where # is a number uniquely identifying that subheading.  E.x.
https://gist.github.com/Blacksmoke16/ed3e8aeb073ea05e71720792be9a9e4c
You get both #sub-child and #sub-child-1 anchors.  Thoughts on that approach?

This is good for another look @straight-shoota.

@straight-shoota First one is #sub-child then #sub-child-1 then #sub-child-2 to #sub-child-n.

This is good for another review.

This is good for another review.

Bump.

Bump.

Ok, it was still our code adding the anchors so I just applied the code to the new renderer type.

For completness, Would it be possible to add specs to this @Blacksmoke16 ? Thanks!

@beta-ziliani Done.


Broken identifier import for TimePicker

The content of identifiers.js:
export const TIMEPICKER = 'RTTimePicker';

and here is what /timepicker/index.js and timepicker/TimePicker.js imports
import { TIME_PICKER } from '../identifiers.js';

Missing underscore and broken import :)

🙉 Thanks!! 💃


fix: audit should exit based on success

No ticket

📦 Published PR as canary version: Canary Versions

:sparkles: Test out this PR locally via:
npm install<EMAIL_ADDRESS># or
yarn add<EMAIL_ADDRESS>

:rocket: PR was released in<EMAIL_ADDRESS>:rocket:


bugfixes - 647 - node multifield panel

xtype selection doesnt work (values not saved) in node multifield
loadcontent event not fired on items in node multifield

@schoudry does this fix #647?

yes

great. in the future, can you put "fixes #" somewhere in the commit comment? then it automatically marks the corresponding issue as fixed when the PR is merged.

@justinedelson sure, actually it was a mistake - i remember putting in comment relates the commit to bug


query dns from consul without port,upstream_url will be wrong!

Summary
I register my service to Consul, and Kong query dns from Consul , but Kong just get IP of the service from consul.
so the upstream_url will be like this: http://ip_from_consul:80/request_path.
the port will always be 80, any help here?

Kong version (0.9.7)

Kong does not support SRV records, hence it will not even get the port from Consul.
That said, the next branch already has SRV support, which is scheduled to be released shortly.


Clarification on sync_with_catalog behavior in provider v0.57.0

Hi,
Regarding provider version v0.57.0, does the sync_with_catalog attribute apply when a property is added, modified, or removed from the Global Catalog during the next terraform apply execution?
From what I've observed, after adding, modifying, or removing a property from an existing Property Set in the Global Catalog, the subsequent terraform apply updates the Property Set in the Global Catalog but does not reimport the updated version into the Blueprint. It is only upon running a second terraform apply that the Property Set is re-imported.
Is this the expected behavior?
Additionally, I have verified in the terraform plan that the Global Catalog apstra_property_set resource is evaluated before the Blueprint apstra_datacenter_property_set resource. To ensure that all actions on the apstra_property_set resource are completed before performing actions on the apstra_datacenter_property_set resource, I have included a depends_on meta-argument in the apstra_datacenter_property_set resource, but I am still seeing the same results.
Thanks in advance.

I think what you're experiencing is a side-effect of when terraform generates the plan vs. when terraform changes things in the global catalog.
If the apstra_datacenter_property_set resource matches the currently-deployed apstra_property_set (global catalog) resource when Terraform creates a plan, it will not calculate a diff because they're properly synced at the moment the plan is generated.
Only after the plan is applied (the global catalog item has been changed) will terraform recognize a deficiency in the  apstra_datacenter_property_set.
This is the same sort of issue which causes a blueprint commit to lag blueprint changes: At the time the plan was generated, the blueprint was up-to-date!
You can force replacement with lifecycle { replace_triggered_by = [<something related to the global catalog item>] }, but that might be disruptive to the fabric.
I don't know of a update_triggered_by meta-argument, but it seems like that would be ideal.

This is kind of interesting. Maybe update_triggered_by is a real feature?

Hello
This is expected. The global catalog item resource and the imported resource do not have a relationship in terraform.
So, your first apply makes the change to the global property set. that change results in the

Hi Chris,
Thanks for your explanation, it's clear that, as you pointed out, this behavior is intrinsic to Terraform. At the time of generating the plan, the apstra_datacenter_property_set resource matches the currently deployed apstra_property_set.
However, this creates issues when users need to perform the following actions in a single terraform apply:

Create a new property in the global catalog as part of an existing property set (or modify the value of an existing property).
Create a new configlet in the global catalog that invokes the new property (or modify an existing configlet to reference the new property).
Re-import the property set into the blueprint to include the new property (or updated property value).
Import the new configlet into the blueprint, which invokes the new property (or re-import an existing configlet that now references the new property).

This is a common scenario for our customer, so we can't ask them to keep splitting these actions into multiple terraform apply runs.
We looked into the update_triggered_by meta-argument you suggested, but it doesn't seem to exist in the Terraform version we're using (we couldn’t find any reference to it in the Terraform documentation either).
We ended up solving the issue by using replace_triggered_by and splitting the apstra_datacenter_property_set resource into two distinct resources:

same_project_property_sets → to import property sets created within the same Terraform project.
other_project_property_sets → to import property sets created in a parent separate Terraform project.

The key difference is that the replace_triggered_by clause exists only in the same_project_property_sets resource. This triggers a full property set replacement if its contents change in the global catalog for sets created within the same Terraform project.
For property sets created in other projects, this replacement isn't necessary, so the other_project_property_sets resource doesn't include that clause.
This approach allows us to manage both locally and remotely created property sets efficiently, each with the right conditions and lifecycle management.
Thanks again for your input!
# ----- Local variables // Module: blueprints

locals {

  # Mapping of each property set name with its corresponding ID
  # for those property sets created within the local project
  property_set_ids_from_local_project = {
    for property_set_name, property_set_data in module.design.property_sets :
    property_set_name => property_set_data.id
  }

  # Mapping of each property set name with its corresponding ID
  # for those property sets received from the parent projects
  property_set_ids_from_parent_project = merge([
    for project, project_data in var.parent_project_outputs : {
      for property_set_name, property_set_data in try(project_data.outputs.property_sets, {}) :
      property_set_name => property_set_data.id
    }
  ]...)

  property_set_ids = merge(
    local.property_set_ids_from_local_project,
    local.property_set_ids_from_parent_project
  )

  # Combine all the "imported_property_set" lists from every <bp>.yml file, and append the corresponding bp name to each list member.
  flattened_property_sets = flatten([
    for blueprint_key, blueprint_data in local.blueprints : [
      for property_set in try(blueprint_data.import_property_sets, []) :
      merge(
        { bp = blueprint_key },
        property_set
      )
    ]
  ])

}

# ----- Porperty set resources // Module: blueprints

resource "terraform_data" "update_property_sets_trigger" {
  # local.flattened_property_sets is a list, so we must now project it into a map
  # where each key is unique. We'll combine the bp and ps_name keys to
  # produce a single unique key per instance.
  for_each = can(local.flattened_property_sets) ? {
    for property_set in try(local.flattened_property_sets, null) :
    "${property_set.bp}.${property_set.name}" => module.design.property_sets[property_set.name]
    if contains(keys(local.property_set_ids_from_local_project), property_set.name)
  } : null
  input = each.value.data
}

resource "apstra_datacenter_property_set" "same_project_property_sets" {
  # local.flattened_property_sets is a list, so we must now project it into a map
  # where each key is unique. We'll combine the bp and ps_name keys to
  # produce a single unique key per instance.
  for_each = can(local.flattened_property_sets) ? {
    for property_set in try(local.flattened_property_sets, null) :
    "${property_set.bp}.${property_set.name}" => property_set
    if contains(keys(local.property_set_ids_from_local_project), property_set.name)
  } : null
  lifecycle {
    # Replace only if the contents of this specific property_set changes
    replace_triggered_by = [
      terraform_data.update_property_sets_trigger[each.key]
    ]
  }
  # blueprint_id      = apstra_datacenter_blueprint.blueprints[each.value.bp].id
  blueprint_id      = local.blueprint_ids[each.value.bp]
  id                = local.property_set_ids["${each.value.name}"]
  sync_with_catalog = try(each.value.sync_with_catalog, false)
}

resource "apstra_datacenter_property_set" "other_project_property_sets" {
  # local.flattened_property_sets is a list, so we must now project it into a map
  # where each key is unique. We'll combine the bp and ps_name keys to
  # produce a single unique key per instance.
  for_each = can(local.flattened_property_sets) ? {
    for property_set in try(local.flattened_property_sets, null) :
    "${property_set.bp}.${property_set.name}" => property_set
    if contains(keys(local.property_set_ids_from_parent_project), property_set.name)
  } : null
  # blueprint_id      = apstra_datacenter_blueprint.blueprints[each.value.bp].id
  blueprint_id      = local.blueprint_ids[each.value.bp]
  id                = local.property_set_ids["${each.value.name}"]
  sync_with_catalog = try(each.value.sync_with_catalog, false)
}


Add keymaps for Turkish Q and F layouts

This PR adds keymaps for Turkish Q and F layouts. A bit info:
Turkish Q layout adds Turkish letters to where the punctuation and brackets are, therefore not very uncomfortable to use with Vim. / is behind a Shift key as well, super inconvenient.
Turkish F layout is a totally different layout designed with Turkish language in mind. It's the best layout to type Turkish on, but Vim navigation keys are spread across the layout. I am using this layout, and already got used to using Vim as such, but a keymap would be much better.
Both keymaps work as expected, except one issue on Q version, see below.

Both keymaps work as expected, except one issue on Q version, see below.

Er, see what where below? I don't see anything at the end of this post, nor do I see any comment about any issue in the proposed turkish_q.vim keymap.
Best regards,
Tony.

Both keymaps work as expected, except one issue on Q version, see below.

Er, see what where below? I don't see anything at the end of this post, nor do I see any comment about any issue in the proposed turkish_q.vim keymap.

Apparently forgot to press "Submit Review". Sorry about that.

Thanks.  I'll include them, please send updates when you have them.

@brammool, thank you. Any ideas about the SECTION SIGN mapping problem indicated above?

Please apply below patch for the fix. It looks like OPT+§ is messing with the version without the modifier. Since < and > are available elsewhere as well, there is no need to keep them.
diff --git a/runtime/keymap/turkish-q.vim b/runtime/keymap/turkish-q.vim
index 038351f00..900c10eb9 100644
--- a/runtime/keymap/turkish-q.vim
+++ b/runtime/keymap/turkish-q.vim
@@ -43,8 +43,6 @@ i ı LATIN SMALL LETTER DOTLESS I
/ . FULL STOP
` < LESS-THAN SIGN
-§ < LESS-THAN SIGN
-¡ > GREATER-THAN SIGN
™ £ POUND SIGN
£ # NUMBER SIGN
¢ $ DOLLAR SIGN

Emir Sari wrote:

Please apply below patch for the fix. It looks like OPT+§ is messing
with the version without the modifier. Since < and > are available
elsewhere as well, there is no need to keep them.

I'll include the patch.
--
Would you care for a drink?   I mean, if it were, like,
disabled and you had to look after it?
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///


Wrap transaction with new struct to include ISRs

Closes: #880

@Manav-Aggarwal can you rebase with main again? looks like it is showing lots of changes from your previous PR.

@Manav-Aggarwal can you rebase with main again? looks like it is showing lots of changes from your previous PR.

done

@Manav-Aggarwal
ignore the CI/CD data race failure, as i am working on resolving it.
for math/rand to crypto/rand, you can make the changes.

@Manav-Aggarwal
ignore the CI/CD data race failure, as i am working on resolving it.
for math/rand to crypto/rand, you can make the changes.

Created issue for it here: https://github.com/rollkit/rollkit/issues/911


not able to get LLVM IR for rust and D

wanted to compare the LLVM IR for c++, rust and D but was only able to get the IR for c++.

for Rust when I add the argument " --emit=llvm-ir" I get the assembler  and a warning: "due to multiple output types requested, the explicitly specified output file name will be adapted for each output type"
for ldc when I add the argument "-output-ll" I only get the assembler

I guess that the IR is not shown due to other file name is generated for the IR files.
is it maybe possible to add a "show LLVM IR output" button like the "show ast output"?

Good idea; I've been wanting to add syntax colouring for LLVM IR too. Should support all of these things.

I have pushed a fix for this for rust :)

That fix is merged, and will deploy this weekend.

@jaredwy To help you: for LDC, specifying -output-s -output-ll will generate both an .s file with assembly, and .ll with LLVM IR. If you don't specify an output file (-of <filename>), LDC will use the input filename minus the .d: example.d --> example.s (for -output-s) or example.ll (for -output-ll). You can override that with e.g. ldc2 example.d -output-ll -of example.s, which will write LLVM IR to example.s.

Great Ill take a look over this later. Shouldn't be too hard to wire up.

much obliged, it is very useful functionality

Btw, does anyone know how to get clang to show the LLVM IR before it went through the optimization passes. With rustc, I can just pass -C no-prepopulate-passes but I couldn‘t figure out how to get clang to do the same.

In the meanwhile, for LDC you can use these flags to see LLVM IR: -output-s=false -output-ll and then I like to add -gline-tables-only to get rid of all the llvm.dbg.declare clutter.

@mattgodbolt How shall I go about implementing LLVM IR support? Shall I make a new view (similar to e.g. the AST view), or a toggle inside the assembly view (similar to binary view)?
The LLVM IR view would need some specific filter buttons, such as filtering comdat specification (lots of cluttering), removing debug declarations (terrible cluttering), ... So perhaps better to do this in a separate view at first?

@JohanEngelen I think a new view is probably best; as you say. I'm not quite sure how the UI will work, but in my experience the best thing to do is to start somewhere and see how it comes out!

Thanks @JohanEngelen . Ideally we'd roll it into the asm view; but sketching it as a separate view is a good start. We can take a look. You're absolutely right about the public API -- any "view" is effectively part of the public API. So, finding a way to make it part of the regular asm view is probably best. Thanks!


Fix repo tmp path for running as non-root user

Summary

I had the problem that I need to run the TUF server as nonroot on Kubernetes. This tiny change fixes some permission issues.
Release Note

Documentation

Thank you!


Embedding Custom Link

I want to make an application where a link would be displayed with every image in modal window . On clicking it another page should open which will have details on that image? Can you please guide how to implement it

From the top of my head, you can pass a link to the subtitle and work from there. More help than that, just by changing the source to trigger a difference action on tap on the image

That comes very hand, thanks. I tried putting the link in subtitle in the below format
sub: 'Divine Jewel'
but no I think, I am not able to understand how to pass a unique value for every image, for example in above code,3 is passed with first image..

You just need to construct the content of sub for every image and pass it to the directive


Auto-generate changelogs

Describe the solution you'd like
Use conventional commt messages to auto-generate changelogs

Has to be tested yet.


Technical design decisions and ideas that are not present in ClickHouse

Please list some novel and interesting ideas that are not already present in ClickHouse.

@alexey-milovidov Alexey, there is a paper about Velox in the upcoming VLDB.
Velox: Meta’s Unified Execution Engine - https://vldb.org/2022/?papers-industrial

@mbasmanova there is no link to read the paper.

@alexey-milovidov Alexey, I assume the paper will become available after the conference in a month or so. Would you like to join our Slack? Maybe we could provide a draft of the paper there. CC: @pedroerp @jijufb

@alexey-milovidov if you send me an email at<EMAIL_ADDRESS>I can share the current camera ready.

@alexey-milovidov I have studied both clickhouse and velox project for a long time. From high level, velox is native unified execution engine which is a library(not managing data) which may accelerate upper application execution like Spark(intel/gluten) or Presto(c++ worker using velox), even Flink and ML. It provides lots of things
in the doc: https://facebookincubator.github.io/velox/
While Clickhouse is world class analytics database, but not suitable for complex SQL for now(lacks exchange operator and CBO optimization).
From low level, they both use modern computing techniques, like SIMD, batch/vector processing, expression compiling(velox not use LLVM IR for now), etc.
We use clickhouse in our company for OLAP business need and you know we also contribute lots of features back to community, and we also want to use and contribute spark+velox(like photon in databricks, see https://cs.stanford.edu/~matei/papers/2022/sigmod_photon.pdf) and presto+velox for performance and cost.
We also are very glad to see that clickhouse can processing complex and big SQL which is now the bottleneck for widely use scope, but it seems you don't have the plan to enhance this feature.

That's a great summary, thanks @zhanglistar . Converting this to a github Discussion.


Refactoring issue/#5. Finalization after yesterday's conversation.

Refactoring issue/#5. Change condition in DateTimeProccessor. Appliedguard block.

import_me/processors.py: Change typing. Add guard block.
tests/test_processors.py: Add tests.

👍


Socket address issue?

I THINK I have followed all the steps to set this up correctly, but when I run "ollama serve" it says, "Error: listen tcp <IP_ADDRESS>:11434: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted."
I have no idea what to do to solve this. I've tried restarting Ollama and restarting my computer and playing around with the config, but I can't get it to work. I am on windows 11.

This likely means you already have Ollama running or another process is using that socket.
Run in a command line (may need to be admin)
netstat -ano | findstr :11434
The last value in the output will be the process ID, something like this:
TCP    <IP_ADDRESS>:11434    <IP_ADDRESS>:0    LISTENING    <PID>
(If it is blank that means that there is no process running there)
Use that value in tasklist | findstr <PID> to show what is being run on that socket.
It will probably show Ollama but if does not you can kill the other process running there:
taskkill /PID <PID> /F
Here's a screenshot:

An easier way is to also check your taskbar in the bottom right:

I just tried it again today and here is what my Terminal looks like

It basically gets stuck here forever and never updates. So, when I try a 2nd time to run it, it does get past this screen and shows the error message about socket addresses.
When I tried the netstat PID thing, the process that was running was indeed Ollama. I'm still clueless on how to use this thing.
It's kind of a complicated setup for a beginner. I've spent over 3 hours on this already.

Your screenshot shows that Ollama started and the server is running. That's all it's supposed to show.
Open a new terminal and run ollama list for example and you'll see the ping in your first terminal.
Here's my two terminals:

But this is just Ollama stuff. To run AI Web Researcher on Windows check out this repo (the one you're commenting on is only for Unix systems right now):
github.com/hafeezhmha/Automated-AI-Web-Researcher-Ollama
Cheers.

@leapingturtlefrog Shouldn't they be able to get this working on Windows using WSL either way?

@synth-mania Yeah you're right; it was more of an Ollama question that would have happened on WSL or Windows. I'll edit my response to point towards WSL instead.

Thank you all. I was finally able to get it running. Now to figure out what the heck I am doing with it. It only seems to want to give me quick summaries instead of detailed answers. Hmmmmm...........
I'll mark this as closed.


Is there a breaking change in v4.0.0?

Hi @niftylettuce , thank you working on this project ❤
I see you cut a new version 4.0.0 instead of 3.1.0 (#483), is there a breaking change in this release?

please defer to https://github.com/form-data/form-data/releases for changelog

Does this follow Semantic Versioning?


Return effective_url as string (without port details)

This is an attempted fix for this issue https://github.com/bblimke/webmock/issues/552

Thank you @tbrammar. Looks good but I believe only the default port should be omitted?

@bblimke good catch 👍 - have updated to only remove standard ports


[Feature]: Adjust hold time duration

Requirements

[X] I have updated Mushroom to the latest available version
[X] I did a search to see if there is a similar issue or if a pull request is open.

Is your feature request related to a problem?
Too many times I don't quite hold long enough, and end up turning off the device
Describe the solution you'd like
I'd like to be able to adjust the hold time to customize
Describe alternatives you've considered
Button-card can do it, but I prefer mushroom-card
Additional context
No response

It's a built-it feature from Home Assistant so there is no way for a custom card to override this behavior.


Use actions/setup-go@v2 in all workflows

Closes #2514
Changes actions/setup-go@v1 to actions/setup-go@v2 in all workflows.

Codecov Report

Merging #2517 (96ef23c) into main (8980bd2) will decrease coverage by 21.19%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             main    #2517       +/-   ##
===========================================
- Coverage   59.81%   38.61%   -21.20%
===========================================
  Files         284      278        -6
  Lines       22267    21444      -823
===========================================
- Hits        13319     8281     -5038
- Misses       7529    11981     +4452
+ Partials     1419     1182      -237

Flag
Coverage Δ

kind-e2e-tests
38.61% <ø> (-8.26%)
:arrow_down:

unit-tests
?

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


Clarify use case for last_affected / Should last_affected be used for unpatched vulnerabilities?

Could you please clarify the expected use case for last_affected?
Currently the GitHub advisory database seems to use it (in some cases?) for unpatched vulnerabilities to describe the currently latest version when the vulnerability was discovered. Is that the intended use case, or was it rather intended for situations where the exact fix version is unknown but the vulnerability cannot be reproduced starting with a certain version, respectively can only be reproduced up to version last_affected?
My concern is that, especially when advisories are created without proper communication with the maintainers (which sadly still happens), new versions after last_affected are released which still contain the vulnerability but the advisory is not adjusted. In that case users believe they are safe even though they are not.
Examples for this usage of last_affected might be https://github.com/advisories/GHSA-22wj-vf5f-wrvj (and corresponding discussion in https://github.com/h2database/h2database/issues/3686) and https://github.com/advisories/GHSA-p8p7-x288-28g6. Both seem to just contain the back then latest version as last_affected. There are probably more cases of this, maybe even some where indeed the version after last_affected still contained the vulnerability, but finding such advisories might be tedious.

Hi,
We're going to review the clarity of the text at https://ossf.github.io/osv-schema/#affectedrangesevents-fields
In a nutshell, last_affected sets a ceiling on known to be vulnerable versions, i.e. versions "less than or equal to" this version are to be considered vulnerable and everything after this version is not vulnerable.
We've flagged this issue with GitHub to bring it to their attention. It's quite possible they're erring on the side of false negatives in favour of false positives.

I'm not sure I quite follow how this could be claimed, but perhaps I am not up to date in how this things get reported? In my understanding there is the situation where a vulnerability was found and the maintainer of the package issues a fix which in not part of any release (yet), but will be in the next one. In which case this is correct, the last version affected version will be the one noted in last_affected.
But I don't believe the assumption that the next release will necessarily contain the fix holds? How then does one mark a vulnerability which has no known fix, where each subsequent release should be vulnerable?
This would imply that advisories are kept up to date as new release come out, I didn't quite get the impression they are that well maintained though (understandably so I should add, this also depends on the transparency of the maintainer).

Hello! I work on that team that owns the vulnerability publication work flow, including encoding to OSV, and I have contributed to the OSV spec as part of that work. I wanted to respond about how GitHub uses this attribute when publishing OSV data to our Advisory Database repo.
I am seeing two questions here:

Are GHSAs using that field correctly?
What does that field mean when new versions have been released?

Regarding the first question, we use last_affected when an affected product's range specification includes the <= operator AND there is no known fix. This aligns with the reasoning for its introduction that was outlined in https://github.com/ossf/osv-schema/issues/35. Before that event existed the only way to encode those types of version ranges was with "introduced": 0 combined with a database_specific field that recorded the upper limit for our internal use, but that meant that any automation following the OSV spec would read it as every version was impacted even if a fixed version was eventually released. In order to avoid this scenario last_affected was proposed as a way to encode any known upper limit at the time of publication in the absence of a known fixed version, which we felt was preferable to an unbounded upper limit. Both of the advisories noted in the description above use a <= operator and a version based on the vulnerability as it was described at the time of the import from NVD, neither of which had a known fixed version at the time.
As to the second question, I verified with our curation team that a general assumption is that once a vulnerability has been published it would be unlikely that future versions would continue to be released which still include the vulnerability except in rare circumstances, such as where the advisory is disputed (in which case if wouldn't matter how it was encoded in OSV) or the project was being maintained by a bad actor (in which case there are other steps to follow to remove the package altogether). Our standing is that it is better to flag the versions we know about rather than the ones we don't and then rely on updates from the source (e.g. NVD) or community feedback via our improvement suggestion form if new data becomes available.
I hope this provides some clarification to your questions. Thanks for bringing up your concerns!

Hey, thanks for the clarification! Your answer does define and answer this quite nicely, and it verifies what at least I thought was happening.
I am curious about

...a general assumption is that once a vulnerability has been published it would be unlikely that future versions would continue to be released which still include the vulnerability except in rare circumstances

as not all vulnerabilities are high severity and not all packages are that security focused. I wouldn't be surprised if a not insignificant number of them choose not to address a specific vulnerability until a later release if it is deemed not critical. This is just my hunch though, but I'll will try and dig up some examples.
Once a fixed version does get assigned having both the last_affected and fixed entry could lead to some confusion in the presumably rare case when they are not sequential. At that point the last_affected is better assumed to relate to when the issue was discovered, as I see it.

Thanks for the clarification!
Would it then make sense to adjust the OSV schema documentation to say something like the following for last_affected:

last_affected is usually set to the latest affected version when an advisory is published and no fixed version exists yet. However, unlike the fixed field it is possible that versions newer than last_affected are actually affected by the vulnerability as well.

And maybe also add a comment in the evaluation pseudocode which currently sets vulnerable = false for v > evt.last_affected, to mention that it might be possible that the application is vulnerable nonetheless?

@Marcono1234, yup agreed. Hat tip to @hayleycd for getting the documentation part started and merged in https://github.com/ossf/osv-schema/pull/159. If you'd like to update the pseudocode, that would be a helpful contribution.

I think we can close this given #174 and #159


Unclear why "amd64" appears in the binaries for eth2.0-deposit-cli v1.0.0

"macOS amd64", "Linux amd64", and "Windows amd64" appear as the description for each of the three available binaries for the  v1.0.0 (hash:  9310de0...) version of the Eth2 deposit contract CLI.
Whatever limitation is expressed or implied by the adjective "amd64" ought to be made more explicit; else the Ethereum newbie or non-technical Ethereum user will be confused.
Does it mean that "only AMD64 chipsets are supported"?
... only Advanced Micro Devices processors?
Or would these binaries be expected to run successfully on, say, a standard Intel PC chipset that is common in the Win PC world?

Hi @A2be, sorry for the very late reply!
Currently, we use pyinstaller to build the binaries. But unfortunately, pyinstaller doesn't support cross-compile, so the binary built on amd64 machine doesn't work on arm64 machine.
Closing this issue now. Let me know if you want to re-open it.


Bluetooth: L2CAP tester application is missing preprocessor flags for ECFC function call

Compiling the L2CAP tester application with CONFIG_BT_L2CAP_ECRED=n produces a bug since there is a function call not guarded by ifdefs here: https://github.com/zephyrproject-rtos/zephyr/blob/main/tests/bluetooth/tester/src/l2cap.c#L322

Fixed by #40498


export karma version as prometheus metric

As many other prometheus tools it would be cool to export the karma version as metric.
For example prometheus exports:
prometheus_build_info{branch="HEAD", goversion="go1.18.5",revision="818d6e60888b2a3ea363aee8a9828c7bafd73699", version="2.38.0"}
The build_info metric is helpful if you want to create a dashboard which visualizes all running versions of your prometheus components.

Added build_info via #4771


[VS Code] Joining collaboration session: Unable to connect to the host. Verify both you and the host are online.

Error:
Joining collaboration session: Unable to connect to the host. Verify both you and the host are online.
Steps to Reproduce:

Version Data

extensionName
VSLS

extensionVersion
0.3.1182

protocolVersion
2.2

applicationName
VSCode

applicationVersion
1.31.1

platformName
MacOS

platformVersion
16.7.0

It seems like you had a connectivity issue, do you remember the exact scenario? Can you please attach your logs here or email them to<EMAIL_ADDRESS>so that we can investigate this issue? You can get your logs by running "Live Share: Export Logs" in the command palette in VS Code.

Closing due to inactivity. Please re-Open if you’re still encountering this issue. Thanks!


[Google Bard] - The extension won't connect to my __Secure-1PSID

Extension
http://www.raycast.com/EvanZhouDev/raycast-bard-ai
Description
Hi there !
I have a little problem with this extension : no matter how much I try, the __Secure-1PSID won't work and the extension keeps saying that it can't connect to Bard ...
Steps To Reproduce

add the  __Secure-1PSID
Launch the Raycast extension
Wait a few seconds

Current Behaviour
No response
Expected Behaviour
No response

I'm experiencing the same issue with this extension found here - https://www.raycast.com/EvanZhouDev/raycast-bard-ai
The cookie it asks you to copy does not allow for connection to the BardAI.


added feature for relative path

Addresses #2993

Sorry, I didn't get it. I replicated the error as described in the issue #2993 and tried to fix it, then I tested it as well and it worked. The thing is that the command worked in the root directory of any project created using anchor but if its executed in some other directory it gave the error.


[PORT] Add support for SSO to parent and child bot projects for manual testing

Port this change from botbuilder-dotnet/master branch:
https://github.com/microsoft/botbuilder-dotnet/pull/3489

Add support for SSO to parent and child bot projects for manual testing
Fixed  a minor bug in oauthprompt

Changed projects

Skills

note parent and child are test projects

Hi @axelsrz, can you see if we really need this port? just close this issue if it doesn't apply


Install failure on Debian-based/Arm system

I installed node using the following instructions: http://www.armhf.com/node-js-for-the-beaglebone-black/
I've tried installing serialport on three versions of node including v0.10.5, v0.10.41 and v0.12.x (latest), and consistently have the following installation error.
I've been able to npm install every other module I use - but serialport fails.
Wasn't sure if this was the same issue that others with similar reports are seeing, so I created a separate issue - sorry if this is a duplication.
root@debian-armhf:/home/debian/peakgps# npm install serialport --save
npm WARN deprecated This version of npm lacks support for important features,
npm WARN deprecated such as scoped packages, offered by the primary npm
npm WARN deprecated registry. Consider upgrading to at least npm@2, if not the
npm WARN deprecated latest stable version. To upgrade to npm@2, run:
npm WARN deprecated
npm WARN deprecated   npm -g install npm@latest-2
npm WARN deprecated
npm WARN deprecated To upgrade to the latest stable version, run:
npm WARN deprecated
npm WARN deprecated   npm -g install npm@latest
npm WARN deprecated
npm WARN deprecated (Depending on how Node.js was installed on your system, you
npm WARN deprecated may need to prefix the preceding commands with `sudo`, or if
npm WARN deprecated on Windows, run them from an Administrator prompt.)
npm WARN deprecated
npm WARN deprecated If you're running the version of npm bundled with
npm WARN deprecated Node.js 0.10 LTS, be aware that the next version of 0.10 LTS
npm WARN deprecated will be bundled with a version of npm@2, which has some small
npm WARN deprecated backwards-incompatible changes made to `npm run-script` and
npm WARN deprecated semver behavior.
npm WARN package.json<EMAIL_ADDRESS>No repository field.
npm WARN package.json<EMAIL_ADDRESS>No README data

><EMAIL_ADDRESS>install /home/debian/peakgps/node_modules/serialport
> node-pre-gyp install --fallback-to-build

gyp WARN EACCES user "root" does not have permission to access the dev dir "/root/.node-gyp/0.10.41"
gyp WARN EACCES attempting to reinstall using temporary dev dir "/home/debian/peakgps/node_modules/serialport/.node-gyp"
make: Entering directory `/home/debian/peakgps/node_modules/serialport/build'
make: *** No rule to make target `../.node-gyp/0.10.41/common.gypi', needed by `Makefile'.   System Linux 3.14.1_001-peak
gyp ERR! command "/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "build" "--fallback-to-build" "--module=/home/debian/peakgps/node_modules/serialport/build/Release/node-v11-linux-arm/serialport.node" "--module_name=serialport" "--module_path=/home/debian/peakgps/node_modules/serialport/build/Release/node-v11-linux-arm"
gyp ERR! cwd /home/debian/peakgps/node_modules/serialport
gyp ERR! node -v v0.10.41
gyp ERR! node-gyp -v v1.0.1
gyp ERR! not ok
node-pre-gyp ERR! build error
node-pre-gyp ERR! stack Error: Failed to execute '/usr/local/bin/node /usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js build --fallback-to-build --module=/home/debian/peakgps/node_modules/serialport/build/Release/node-v11-linux-arm/serialport.node --module_name=serialport --module_path=/home/debian/peakgps/node_modules/serialport/build/Release/node-v11-linux-arm' (1)
node-pre-gyp ERR! stack     at ChildProcess.<anonymous> (/home/debian/peakgps/node_modules/serialport/node_modules/node-pre-gyp/lib/util/compile.js:83:29)
node-pre-gyp ERR! stack     at ChildProcess.emit (events.js:98:17)
node-pre-gyp ERR! stack     at maybeClose (child_process.js:766:16)
node-pre-gyp ERR! stack     at Process.ChildProcess._handle.onexit (child_process.js:833:5)
node-pre-gyp ERR! System Linux 3.14.1_001-peak
node-pre-gyp ERR! command "node" "/home/debian/peakgps/node_modules/serialport/node_modules/.bin/node-pre-gyp" "install" "--fallback-to-build"
node-pre-gyp ERR! cwd /home/debian/peakgps/node_modules/serialport
node-pre-gyp ERR! node -v v0.10.41
node-pre-gyp ERR! node-pre-gyp -v v0.6.18
node-pre-gyp ERR! not ok
Failed to execute '/usr/local/bin/node /usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js build --fallback-to-build --module=/home/debian/peakgps/node_modules/serialport/build/Release/node-v11-linux-arm/serialport.node --module_name=serialport --module_path=/home/debian/peakgps/node_modules/serialport/build/Release/node-v11-linux-arm' (1)

npm ERR<EMAIL_ADDRESS>install: `node-pre-gyp install --fallback-to-build`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script.
npm ERR! This is most likely a problem with the serialport package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-pre-gyp install --fallback-to-build
npm ERR! You can get their info via:
npm ERR!     npm owner ls serialport
npm ERR! There is likely additional logging output above.
npm ERR! System Linux 3.14.1_001-peak
npm ERR! command "/usr/local/bin/node" "/usr/local/bin/npm" "install" "serialport" "--save"
npm ERR! cwd /home/debian/peakgps
npm ERR! node -v v0.10.41
npm ERR! npm -v 1.4.29
npm ERR! code ELIFECYCLE
npm ERR! not ok code 0

Looks like I was able to install this using the following guidelines provided by jywarren (2nd comment) here: https://github.com/mapbox/node-pre-gyp/issues/165
He says:
Those errors look related to permissions only. Are you perhaps running as root? If so can you run as a normal user? I'm aware that npm does not work correctly when run as root unless you also pass --unsafe-perm npm/npm#3497.

That said if this is not the issue happy to try to help more. Basically node-pre-gyp and node-gyp both need to be callable as command line tools. So if permissions are off they often break, but the underlying problem can only be fixed by fixing permissions.

How exactly you were able to install serialport? Did you use a normal user or you used the --unsafe-perm npm/nom#3497 lines in the instalation?

I installed node-gyp and node-pre-gyp first, then installed serialport with the --unsafe-perm option. I also installed using sudo.
In retrospect, I'm not sure if I needed to install node-gyp or node-pre-gyp, but the combination allowed it to install. I think the key was the --unsafe-perm option.

Had the same problem. Turned out i had to install nodejs-legacy

Ffor me the solution was installing nodejs-legacy +  --unsafe-perm option for npm. Thanks guys!


Clarification on 'Warning: To many values of z. Using 2D polygons'

Hello,
I'm running baysor v0.6.2 to get a 3D segmentation for CosMx data, where I provide as prior the cells identified by CosMx. I am getting the below warning and therefore I only get joint polygons.
Can you clarify what causes this?
Thank you
Info: Estimating boundary polygons
[22:40:52] Warning: To many values of z. Using 2D polygons
└ Baysor.Processing /home/viktor_petukhov/.julia/dev/Baysor/src/processing/data_processing/boundary_estimation.jl:143

Hello,
While estimating polygons, Baysor splits the data by z-stacks. However, it requires z-variable to be discrete. So the pipeline checks if length(unique(df.z)) is large or not. It's possible that you have some decimals there, which lead to too many slices. To avoid that you could round the z values.

Thank you for your response. I had checked previously on this and the z values in my file are discrete, precisely they are all integers from 0 to 8.

Hello,
I am running into the same issue when using Baysor on Xenium data.  I have mapped the continuous Z-axis values to their respective Z-stack number,  which I use as input and totals to 34 stacks.
I recieve the following warning though:
[16:37:02] Info: Run Rc3b19685b
[16:37:02] Info: (2024-02-28) Run Baysor v0.6.2
[16:37:02] Info: Loading data...
[16:37:10] Info: Loaded 3736159 transcripts
[16:37:18] Info: Estimating noise level
[16:38:09] Info: Done
[16:38:42] Info: Initializing algorithm. Scale: 2.6691342692757773, scale std: 0.729571709294326, initial #components: 2490772, #molecules: 3736159.
[16:39:48] Info: Using the following additional information about molecules: [:confidence, :prior_segmentation]
[16:39:48] Info: Using 3D coordinates
[19:59:19] Info: Processing complete.
[19:59:35] Info: Estimating local colors
[20:03:45] Info: Estimating boundary polygons
[20:08:28] Warning: To many values of z. Using 2D polygons
└ Baysor.Processing /home/viktor_petukhov/.julia/dev/Baysor/src/processing/data_processing/boundary_estimation.jl:143

I was wondering now about two things:

Does this only affect the polygon output and is the segmentation still happening in 3D space?
Does it make more sense to use number of the z-stack as input, or would it be better to just use the integer rounded Z-location as input to keep the scale on the same distance metric (microns) as input?

I also  had a quick look at the logical check that is performed before raising the warning if length(z_vals) > (size(pos_data, 1) / 100) and it wasnt quite clear to me what it actually does and why this is performed. From this this line, which is called a bit before, it seems that size(pos_data, 1) will the number of dimensions of the data (2D, or 3D)? So if I am not mistaken the logical check compares the number or z-stacks against the number of dimensions divided by 100? Wouldn't that always default to false?
Best wishes & many thanks!
Falko

Hi,
I'm experiencing the same issue, and my z-stack ranges from 1 to 13. Please let me know if there are any updates on this issue.

This is a bug with polygon outputs. The segmentation is still done in 3D, but the polygons are not estimated properly. It will be fixed in the next release.

This is fixed in v0.7.0. Please, see the changelog for more details.

Thank you!


[Appium logs]: taking invalid path

ERROR: An unknown server-side error occurred while processing the command. Original error: Error executing adbExec. Original error: 'Command 'C:\Users\Fran\AppData\Local\Android\Sdk\platform-tools\adb.exe -P 5037 -s ZY322C865Q shell pm install /data/local/tmp/appium_cache/e1ccbc83780504f65017e742eeecb064dedbeba7.apk' exited with code 1'; Stderr: 'Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES: Failed to collect certificates
from /data/app/vmdl2145678506.tmp/base.apk: File res/drawable-sw360dp-xxhdpi-v13/calculator_advanced_btn_multi_functions_popup_tan1_normal.png in manifest does not exist]'; Code: '1'
zy322c865q.android.8_1_0.c:\users\fran\desktop\mobile\appium-webdriverio-typescript\app\lgcalculator_apk
Cannot upgrade 'io.appium.settings' because of 'Error executing adbExec. Original error: 'Command 'C:\Users\Fran\AppData\Local\Android\Sdk\platform-tools\adb.exe -P 5037 -s ZY322C865Q shell pm install -r -g /data/local/tmp/appium_cache/728413456b86856a2003edeb524d6bd577ca6418.apk'
I think its taking worng plateformTools path  means that starting of path with "c:" this one is wrong but i m not getting why its taking such type of path

@ajitqait sorry for late reply , have you figured out this path issue? its more or less configuration issue and not the issue from the framework itself, do let me know so that I could close the issue.


Create breaking change release messaging for updated Card and Stepper components

As the card component is being updated with breaking changes, a release message to inform users will be required
✅ Definition of Done / Outcomes

[ ] Release messaging written and reviewed by engagement and devs
[ ] Message is reviewed by technical team
[ ] Message has been translated
[ ] Message has been sent out

📜  Acceptance criteria:

[ ] Message is drafted covering what is changing, why, and how it will affect users
[ ] Message is available in EN and FR
[ ] Published (published where?)

More info:
We're releasing updates to the Card component (see Changes from V1 to V2) which includes some breaking changes. We need to remind our users to use a pinned version if they do not have the capacity to implement the changes immediately.

Work on this is on pause pending decision from @abdul regarding the changes on the Card and Stepper slots (giving users option to add HTML formatting but also potentially opening up the component to be misused)

Reviewed the card and stepper message and proposed changes for plain language and to increase clarity. I've added the document to the Writer safelist and done a review using the tool. You can always re-rerun it if you make any more changes. Note: you need to accept suggestions/track changes for Writer to work properly.

Meeting with Amy this week for a final review (as well brainstorming on creating a template for them) before sending these documents off for translation

Amy approved the documents last Friday, I sent them to translation through the slack channel today.

Translation completed, documents shared in Slack channel and here:
-Card and Stepper breaking change messaging
-React Canary release messaging

The messages were sent through the mailing list on August 12th, this ticket can now be closed.


Unable to configure HTTPS using wild card certificate

My company uses a domain wild card certificate from GoDaddy. This allows HTTPS on our main domain and any second level domains with the same certificate.
I'm very new to Perfect, so I may have made an error. That said, I followed the example code here almost to the letter:
https://github.com/PerfectExamples/HTTPS-Configuration/blob/master/Sources/main.swift
Here is my altered version:
import PerfectLib
import PerfectHTTP
import PerfectHTTPServer

// This 'handler' function serves port 80.
func handler80(data: [String:Any]) throws -> RequestHandler {
    return {
        request, response in
        response.appendBody(string: "<title>Hello, world!</title>Hello, world! Port 80")
        // Ensure that response.completed() is called when your processing is done.
        response.completed()
    }
}

// This 'handler' function serves port 443.
func handler443(data: [String:Any]) throws -> RequestHandler {
    return {
        request, response in
        response.appendBody(string: "<title>Hello, world!</title>Hello, world! Port 443")
        response.completed()
    }
}

let confData = [
    "servers": [
        // Serves Port 80
        [
            "name":"bushland.logicalbuilding.net",
            "port":80,
            "routes":[
                ["method":"get", "uri":"/", "handler":handler80],
                ["method":"get", "uri":"/**", "handler":PerfectHTTPServer.HTTPHandler.staticFiles,
                 "documentRoot":"./webroot",
                 "allowResponseFilters":true]
            ],
            "filters":[
                [
                    "type":"response",
                    "priority":"high",
                    "name":PerfectHTTPServer.HTTPFilter.contentCompression,
                    ]
            ]
        ],
        // Serves Port 443.
        [
            "name":"bushland.logicalbuilding.net",
            "port":443,
            "routes":[
                ["method":"get", "uri":"/", "handler":handler443],
                ["method":"get", "uri":"/**", "handler":PerfectHTTPServer.HTTPHandler.staticFiles,
                 "documentRoot":"./webroot",
                 "allowResponseFilters":true]
            ],
            "filters":[
                [
                    "type":"response",
                    "priority":"high",
                    "name":PerfectHTTPServer.HTTPFilter.contentCompression,
                    ]
            ],
            "tlsConfig":[
                "certPath": "/Users/Radagan/Development/Perfect/Certs/167af3a72faa08c9.crt",
                "verifyMode": "peer",
                "caCertPath": "/Users/Radagan/Development/Perfect/Certs/gd_bundle-g2-g1.crt"
            ]
        ]
    ]
]

do {
    // Launch the servers based on the configuration data.
    try HTTPServer.launch(configurationData: confData)
}
catch {
    fatalError("\(error)") // fatal error launching one of the servers
}

And the error:
Thread 1: Fatal error: LaunchFailure(message: "Server bushland.logicalbuilding.net:443 - networkError(0, \"Error setting clientCA : error:00000000:lib(0):func(0):reason(0)\")", configuration: PerfectHTTPServer.HTTPServer.Server(name: "bushland.logicalbuilding.net", port: 443, address: "<IP_ADDRESS>", routes: PerfectHTTP.Routes(routes: [PerfectHTTP.Route(methods: [GET], uri: "/", handler: (Function)), PerfectHTTP.Route(methods: [GET], uri: "/**", handler: (Function))], moreRoutes: [], baseUri: "", handler: nil), requestFi...

I've checked that DNS has the correct IP and that sort of thing. This appears to me to be an issue with the certificate being a wild card. Unfortunately, that's the cert I have to use. I really want to use Perfect and Swift for our test server, any Ideas?

Nothing but crickets here...


Empty snippets so that they don't get overridden by inheritance

Description
I want to remove the content of a snippet as it should not be displayed at all. When I have it empty the placeholder is shown. I assume it will fallback to the value from the file. So put in there a space to make it sort-of empty. But the administration does not allow me to save it.
Possible Solution
Allow saving empty snippets and differ between empty and null snippets.

Hello,
Within our company roadmap and work capacity, we try to address each bug or improvement request but admit that not each one will be resolved. To continue our culture of honesty and openness, we are closing this issue to focus on our roadmap on behalf of all Shopware users.
If you feel like this issue is still impacting you, please create a new issue and let us know.
Thank you again for your valuable feedback.


How to Force a Reconnection

I've got a bulb that seems to be working fine, I can send commands to it, turn it on/off etc. However after around 24/48 hours it stops responding, and in node-red it has the red icon and disconnected.
How can I send a command to the node to get it reconnect?
Currently I reconnect it by going into node-red and pressing the "Deploy" button, but I would like to be able to initiate a reconnection automatically.

@grahamf72 The reconnect is already part of the Tuya device node logic. I am not familiar with the malfunction you describe. Without further information, I cannot see what exactly is happening with the connection. In a subsequent version, I can add commands that can be used to manually disconnect and reconnect the devices. I will also investigate in more detail what happens when the IP address of the device is changed by the router during an existing connection.

In this case, the device I am testing with has a static IP assigned by the router, so the IP address hasn't changed.  I have a debug node attached to the device node, and based on when error messages started appearing, last night it went for about 8 hours before disconnecting.  There's no other error messages though that would indicate the cause.  As soon as I re-deployed the flow in Node-Red, the device connected again, so there must be some difference in the way it connects when a flow is deployed, and how it reconnects when in operation.  Is there some way of increasing debug level so I can give more information of what is happening?

@grahamf72 Which version of "node-red-contrib-tuya-devices" are you using? In the current version (1.3.5) it is not possible to change the trace level via the GUI. I have planned this for the next version. Currently, extended outputs in the console (not NodeRed Debug window) are possible if the two lines (approx. 12-13) in the script file ".node-red/node_modules/tuya-devices/lib/device.js" are changed as follows:
const DEBUG = true
const TUYA_DEBUG = true
and restarts NodeRed
I run several NodeRed servers and have several dozen Tuya devices with many device types and have not had this problem. If I can reproduce it or analyze the cause, I will be able to offer a solution.


"User added to Azure Active Directory Privileged Groups" needs additional parsing

Rule Description
This will alert when a user is added to any of the Privileged Groups.
Problem
This Analytical rule is parsing from the AuditLogs for one use case only, leaving necessary rows empty.
Rule KQL
let timeframe = 1h; let OperationList = dynamic(["Add member to role", "Add member to role in PIM requested (permanent)"]); let PrivilegedGroups = dynamic(["UserAccountAdmins", "PrivilegedRoleAdmins", "TenantAdmins"]); AuditLogs | where TimeGenerated >= ago(timeframe) | where LoggedByService =~ "Core Directory" | where Category =~ "RoleManagement" | where OperationName in~ (OperationList) | mv-expand TargetResources | extend modifiedProperties = parse_json(TargetResources).modifiedProperties | mv-expand modifiedProperties | extend DisplayName = tostring(parse_json(modifiedProperties).displayName), GroupName =  trim(@'"', tostring(parse_json(modifiedProperties).newValue)) | extend AppId = tostring(parse_json(parse_json(InitiatedBy).app).appId), InitiatedByDisplayName = tostring(parse_json(parse_json(InitiatedBy).app).displayName), ServicePrincipalId = tostring(parse_json(parse_json(InitiatedBy).app).servicePrincipalId), ServicePrincipalName = tostring(parse_json(parse_json(InitiatedBy).app).servicePrincipalName) | where DisplayName =~ "Role.WellKnownObjectName" | where GroupName in~ (PrivilegedGroups) // If you want to still alert for operations from PIM, remove below filtering for MS-PIM. | where InitiatedByDisplayName != "MS-PIM" | project TimeGenerated, AADOperationType, Category, OperationName, AADTenantId, AppId, InitiatedByDisplayName, ServicePrincipalId, ServicePrincipalName, DisplayName, GroupName | extend timestamp = TimeGenerated, AccountCustomEntity = ServicePrincipalName
Screenshots
Event

Performed by

The problem in my specific example is that the "InitatedyDisplayName" query is parsing for an app, but the action was performed by a user. Thus leaving me with no relevant info when opening the event from the Incidents page. (See lines 14-17)
Example
InitiatedByDisplayName = tostring(parse_json(parse_json(InitiatedBy).app).displayName)
vs
InitiatedByDisplayName = tostring(parse_json(parse_json(InitiatedBy).user).displayName)
also add
IntiatedBy = tostring(parse_json(parse_json(InitiatedBy).user).userPrincipalName)
TargetName = tostring(TargetResources.userPrincipalName)
By simply changing the .app to .user this query is fixed.
Iff() statements needs to be added to this query for every resource type capable of adding a user to a privileged group.
Different info also gets sent through depending on who performed the action, in the case of a user performing the action the user affected's data is also sent through, this also needs to be added.

@Lodewyk-Git - we would be happy for you to contribute any updates and we can review them via PR.  The detection is here - https://github.com/Azure/Azure-Sentinel/blob/master/Detections/AuditLogs/UseraddedtoPrivilgedGroups.yaml.

Thanks @shainw for assisting with this. I'm closing this issue as the parsing issue is fixed, now we just need to continue with the clean code methodology.