Uses label when searching secrets in [Spring]VaultEnvironmentRepository

Like other EnvironmentRepositories, VaultEnvironmentRepository::findOne and SpringVaultEnvironmentRepository::findOne should use the label argument passed to them when searching for secrets in vault.
So calling findOne("my-app", "my-profile", "my-label") should search for secrets in vault in the following locations with the exact order:

secret/myapp,my-profile,my-label
secret/application,my-profile,my-label (Assuming application is the default-key)
secret/myapp,my-label
secret/application,my-label (Assuming application is the default-key)

Currently the search locations are the followings (note the missing label):

secret/myapp,my-profile
secret/application,my-profile (Assuming application is the default-key)
secret/myapp
secret/application (Assuming application is the default-key)

This PR fixes the above issue.
Breaking Change
Since this wrong behaviour has been there from the day one, based on my knowledge, everyone using the vault backend has been relying on it and they have been adding their vault secrets in the wrong location (without label). Fixing this behaviour is going to break all those applications using the vault backend.

So this will break existing apps since the location in vault will be different now?

Right, If we skip appending label to the key if it is same as default label (master or main?) for sure we will have less broken apps. But still apps with labels other than default one will be impacted. So as you pointed out this change might need to go to a major version.

master or main?

The default is main currently, but I believe there is a property which also controls the default label.

But still apps with labels other than default one will be impacted.

I guess I wonder if anyone is using a label and if so why if it was never actually used with Vault?

Default label is only configurable for some backends like git or jdbc.
CredHub uses master as default label which is not configurable.
Vault was not using the label therefore it had no default label. In this PR, following CredHub approach, I've set it to master which is again is not configurable.
Regarding your second point:
The client application can set spring.cloud.config.label together with profile and application name when calling the config-server. config-server uses those values to call all active environment repositories (including vault). So imagine a config-server with git and vault backend. client app can pass a git branch name as label intended for git backend but the same value will be used by vault backend too.

Got it.
After discussing with the team we think that this new functionality should be wrapped in a feature flag which is disabled by default and should only go into main.

@ryanjbaxter
I pushed a new commit with a feature flag (enableLabel) as suggested.  Let me know if the flag needs a better name.

@ryanjbaxter would you mind having a look at latest changes (feature flag) ?

Looks good, can you document the new property?

@ryanjbaxter while trying to update the documents, I just realised an ambiguity in the secret path which is introduced by my changes. A complete secret key would be something like myapp,myprofile,mylabel but a key like myapp,foo can be interpreted as application myapp and either profile foo or label foo.
That is because:

The default profile (default) is not included in the secret path. (existing behaviour)
In this PR, the profileSeparator (comma by default) is reused by me to separate the label from the rest of the secret key.

The simplest solution which I can think of is always including the profile (even if it is default) in the valut key. So that we have a fix key format consist of 3 separate segments (name,profile,label). What do you think?
Note: Since we have the feature flag for the changes in this PR, It should not break any existing functionality.

The simplest solution which I can think of is always including the profile (even if it is default) in the valut key. So that we have a fix key format consist of 3 separate segments (name,profile,label). What do you think?

I agree with this.  When making a request to the config server only the label is optional in the path, you must include the application name and profile even if that profile is default.  So it makes sense that we require the application name and profile in the key.

Note: Since we have the feature flag for the changes in this PR, It should not break any existing functionality.

Does that mean today that we don't require the profile when creating the key today?

Does that mean today that we don't require the profile when creating the key today?

yes, the profile part is optional. secrets can be stored in the following paths in valut:

myapp,my-profile         -> Both app and profile are provided
application,my-profile  -> Default app name(application) and profile are provided
myapp                            -> Only app  name is provided which means the profile is implicitly default.
application                    -> Default app name (application) and, implicitly, default profile (default).

To keep the backward compatibility, the behaviour should stay the same when the enableLabel flag is false.
But when flag is enabled the path should always have 3 segments. [app name | 'application'],[profile | 'default'],[label | 'master']

But I would say that it should always have 2 segments, application and profile, label being optional. Again much like the rest API label is the only optional part.

Label is optional in API level but when omitted a default label (currently master but can be configurable later) will be used. So in the vault path it is not optional, just like Git, CredHub or other backends.

@ryanjbaxter  I've updated the PR and I believe it is ready for the final review.

@kvmw one small this, I think the default label should be main instead of master.  We moved away from using master a while ago.

@kvmw one small this, I think the default label should be main instead of master. We moved away from using master a while ago.

Updated the PR with main as default label.


T1 - Activities

Overview of things to do:

Visual overhaul(each step needs a visual)
Even more hand-holding is needed during the setup phase(i.e more explanation and clarification)
OOP ease-in(class structure,and OOP mini tutorials need to be integrated within activites)
Term clarification(terms like OAuth,Streaming,etc. need clarification albeit somewhat basic versions)
Repetition in both activities in this module need to addressed and corrected

Weekly Goals:
Week of March 23nd: Get everyone acquainted with new work flow and adjustments to issues if needed.
Week of March 30th: Repetition should be taken care of and fixed. [Major issue]
Week of April 6th: Focus should be on the visual overhaul and re-clarification of things(in tandem). [Per-Activity Issue]
Week of April 13th: OOP mini tutorials should be taken care of during this week. [Minor Issue]
Remaining weeks till BitCamp: Ironing out issues and adding developer's ideas. [Transition to LMS & Power Point should have been started before and should at appropriate time before camp]

#1008

#1009

#989
#990

#991


Avoid use of Optional

With the recent (unreleased) change of how Sciline handled Optional, we need to find other solutions. This is an attempt to do this, while staying compatible to the released Sciline.
Cases:
Use default workflow param

There are some simple cases where Optional is not really needed
Example: Instead of Optional[MonitorOffset], use MonitorOffset and define a default of [0,0,0] m
Example: Instead of Optional[CorrectForGravity] (i.e., Optional[bool], define default of False.

Good switch to using a class instead of an alias
Main examples is #98, where I removed QxyBins and added a QBins class, which does both. The users needs to wrap the variable in QBins, which is a bit annoying. Biggest concern is that this is not raised early, due to scipp/sciline#160, so maybe this needs to be reconsidered?
Awkward switch to using a class instead of an alias
I am "faking" an optional by having a wrapping dataclass in many cases. I do not like this, since the caller needs to be aware, and we need to access the properties of those classes in several places, including in computed intermediate results (like DirectBeam).
Better ideas wanted!
More notes
Risk of bugs
I ran into a concerning case with both the old and new behavior: We previously implicitly (via depending on Optional[DirectBeam] pruned the DirectBeam branch of DirectBeamFilename was not set. However, the DirectBeam is also set manually in other cases. This will then silently ignore the DirectBeamFilename. This is particularly concerning since one might be tempted (in other words: I did this during refactor) to set a default of params[DirectBeam] = DirectBeam().
My thought is that with the Sciline rewrite we may avoid this by composing the pipeline via __setitem__, using something like
# Option 1: pipeline from file (currently: set DirectBeamFilename)
direct_beam = sans.load_direct_beam_pipeline(db_file)
# Option 2: from a in-memory direct beam (currently: set DirectBeam)
direct_beam = compute_direct_beam_pipeline.compute(DirectBeam)
# Option 3: no direct beam (currently set neither)
direct_beam = DirectBeam()
pipeline[DirectBeam] = direct_beam

Time will tell, I hope?
Is Sciline/ADR0001 (remove isinstance checks) a bad idea?
When adding those wrappers, the isinstance checks from the current Sciline told me where I forgot to use the wrapper. In the unreleased Sciline we get a more confusing compute-time error.
To do

Some things in the ISIS/Mantid case not working yet.
Beam center finder notebook

Some suggestion, to improve at least some parts:

Change WavelengthMask not to a wrapping class but redefine it as a dict[str, sc.Variable]. Having named masks may be better anyway, and the user could specify multiple (or we can use map/reduce, once available).
Consider moving the content of the provider for ProcessedWavelengthBands into the constructor of WavelengthBands. Apart from the special case of not setting bands (then they are defined via the WavelengthBins) I think this looks cleaner? Not sure how best to handle this fallback case though.

I'm overall not too happy with how this impacts both usability and implementation.

Yes, my point exactly. But would you be happy with it if we ignore backward-compat, and just use Optional[Param] as keys? Or do you still have concerns then?

Handling default params explicitly is fine. I think the problem only comes in when there are alternatives to a parameter (optionals or variants like QBins). A user has to know which parameters need to be wrapped and which don't. The same goes for implementers of providers.

For the optionals, that is why the next Sciline will let you do pipeline[Optional[Param]] = param. For the QBins I do not have an answer, but in that particular case I don't think there is really a way around this, and you suggested something similar in https://github.com/scipp/esssans/issues/98#issuecomment-1965976198.

This is just a suggestion and we should talk about it in person: How about all parameters must be wrapped in a special class? Sciline could provide a base class to help. Then there would be no confusion about whether parameters need to be wrapped/unwrapped or not. When constructing a pipeline, all param values that are not wrapped get automatically wrapped by their key type, e.g., this

Not sure what exactly one would gain with such a wrapper? Basically, you suggest to add something like
self._params = param if isinstance(sciline.Param) else key(param)

in Pipeline.__getitem__? That seems worse than a simple isinstance check (prior to ADR 0001). Wouldn't we get a similar benefit with a (non-broken) version of our old isinstance check?

params = {
  Period: 3,
  NonBackgroundWavelengthRange = NonBackgroundWavelengthRange(...)
}

becomes
params = {
  Period: Period(3),
  NonBackgroundWavelengthRange = NonBackgroundWavelengthRange(...)
}

The param type could even, for non-variants, inherit from the underlying type so that consumers can use it directly like the underlying type.

Not sure what exactly one would gain with such a wrapper? Basically, you suggest to add something like

self._params = param if isinstance(sciline.Param) else key(param)

in Pipeline.getitem? That seems worse than a simple isinstance check (prior to ADR 0001). Wouldn't we get a similar benefit with a (non-broken) version of our old isinstance check?

I don't understand. Why would this be worse? All params would be classes. SO there would be no issues with type aliases.
Essentially, the suggestion is about having a uniform interface. All parameters can be defined as
params = {A: A(2)}

regardless of whether it is strictly needed to wrap the value or not. And the same goes for consumers. A plain parameter is always accessed as a.value. Variants need special properties and maybe constructors.
The suggestion about auto wrapping and deriving from the the underlying param type are about avoiding the explicit wrapping and unwrapping but are less relevant in my opinion.

This will be replaced.


Fix InitializationTest

:+1:
It passed on Travis because extension directory doesn't exist on travis machine, it failed on local machine because extension directory exists, probably due to a previous mvn install.

:+1:


vscode-extensions.alexdima.copy-relative-path: init at 0.0.2

Motivation for this change
Add support for Visual Studio Code extension Copy Relative Path
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 109016 run on x86_64-linux 1

1 package built:

vscode-extensions.alexdima.copy-relative-path

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 109016 run on x86_64-linux 1

1 package built:

vscode-extensions.alexdima.copy-relative-path


Restyle the explanation slides

The explanation slides look a bit odd with the text on the top left.

A little better, but still some space for improvement.


Fix Form Recognizer tests

API change check for com.azure:azure-ai-formrecognizer
API changes are not detected in this pull request for com.azure:azure-ai-formrecognizer

/azp run java - formrecognizer - tests

/azp run java - formrecognizer - tests

API change check for com.azure:azure-core
API changes are not detected in this pull request for com.azure:azure-core

https://dev.azure.com/azure-sdk/internal/_build/results?buildId=1483576&view=results

/check-enforcer override

/azp run java - formrecognizer - tests


Feat/home explore contribute

Fix https://github.com/ecolabdata/ecospheres/issues/393

Pull request move to https://github.com/opendatateam/udata-front-kit/pull/574


Add general metacyclic stage

Request came up in context of https://github.com/geneontology/go-ontology/issues/17941

Added and available in the latest release


Hide table and show message when a sample has 0 files

What does this PR do and why?
When a sample has no files, shows a message instead of rendering an empty table.
Fixes #152
Screenshots or screen recordings
Sample with an attachment

Sample without any attachments

How to set up and validate locally

pull branch, run, run tailwind to update ui
create a new project
create 2 samples
add an attachment to one of the samples
verify that the appropriate table or message is rendered depending on if the sample has attachments or not.

PR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

[ ] I have evaluated the PR acceptance checklist for this PR.

When there are attachments on a sample, and they are all deleted, the table stays on page empty. Refreshing shows the message as intended.
Should we be redrawing the cards on sample delete for this edge case?

Try a more centred layout.  A good reference you might want to take a look at is https://tailwindui.com/components/application-ui/feedback/empty-states#component-42930c785190e14c24b53ba822f4a92c

Can you update the screenshots for this PR?

Can you update the screenshots for this PR?
Updated

Can you add a test that ensures the empty state is displayed when there are no attachments?
I have added asserts to the existing test 'user with role >= Maintainer should be able to attach a file to a Sample' which checks if the text/files are showing or not in the #attachments element before and after adding the file.


DOCUMENT() function does not return values in guaranteed order

My Environment

ArangoDB Version:        3.8.6
Deployment Mode:       Single Server
Deployment Strategy:   Manual Start in Docker
Configuration:
Infrastructure:               own
Operating System:        Windows 10
Total RAM in your machine:        32Gb
Disks in use:        SSD
Used Package:              Docker

Component, Query & Data
Affected feature:
Document() function
AQL query (if applicable):
RETURN DOCUMENT( persons, [ "persons/alice", "persons/bob" ] )

Problem:
As per (possibly) misleading documentation, the DOCUMENT() function can take an array of _id or _key as the second parameter.  The documentation does not specify outright, but hints by way of example that the returned array of documents will be in the same order as the values stipulated in the input array:
[
  [
    {
      "_key": "alice",
      "_id": "persons/alice",
      "_rev": "_eLYV6Te---",
      "name": "Alice"
    },
    {
      "_key": "bob",
      "_id": "persons/bob",
      "_rev": "_eLYV6Te--_",
      "name": "Bob"
    }
  ]
]

However, this is not the case.  I am finding that the returned values are either in reverse order or in no guaranteed order at all.
RETURN DOCUMENT( persons, [ "persons/alice", "persons/bob" ] )

Appears to yield:
[
  [
    {
      "_key": "bob",
      "_id": "persons/bob",
      "_rev": "_eLYV6Te--_",
      "name": "Bob"
    },
    {
      "_key": "alice",
      "_id": "persons/alice",
      "_rev": "_eLYV6Te---",
      "name": "Alice"
    }
  ]
]

This is either a straight-up bug or the documentation needs to make clear that there is no guaranteed order to the results.
Expected result:
I expected the resulting mapping of _id or _key to found documents to be returned in the same order as the the array of input parameters.  The function would be infinitely more useful if the order was guaranteed so we know that index 1 of the input values equates to index 1 in the provided results.

Alternatively, the problem may be that null are not included as placeholders in the response for failed mappings, which shifts the values around.  So, for example, if persons/alice does not exist and we do this:
RETURN DOCUMENT( persons, [ "persons/alice", "persons/bob" ] )

One would expect the response to be:
[
  [
    null,
    {
      "_key": "bob",
      "_id": "persons/bob",
      "_rev": "_eLYV6Te--_",
      "name": "Bob"
    }
  ]
]

However, the response appears to be:
[
  [
    {
      "_key": "bob",
      "_id": "persons/bob",
      "_rev": "_eLYV6Te--_",
      "name": "Bob"
    }
  ]
]

It would be good to have any notes such as this in the official documentation.

The DOCUMENT() function does use the primary index, but the index usage is not reported in the query explain output.
The function performs single operations for every lookup anyway, so it doesn't make much of a difference whether you call it a thousand times to retrieve one document at a time or call it once to look up thousands of documents at once.
To sort the documents, you can do this:
LET keys = [ "alice", "bob" ]
LET orderMap = ZIP(keys, 1..LENGTH(keys))
FOR person in persons
   FILTER person._key IN keys
   SORT orderMap[person._key]
   RETURN person

Documentation adjustments to clarify the behavior: https://github.com/arangodb/docs/pull/1016
Labeling this issue as a feature for possible behavior improvements to the DOCUMENT() function.


Adds Spectra and KSPRC (terrain) textures.

btw if this is merged, ya might wanna squash it

@Olympic1 why is the KSPRC-Textures failing wtf

btw if this is merged, ya might wanna squash it

We always squash the commits.

why is the KSPRC-Textures failing wtf

Add "author": "Proot",

@Olympic1 ok done, can it be merged if it compiles successfully?

reeee
CKAN.InvalidKSPInstanceKraken

Reee it nearly works now, except Spectra uses a TRR .dds file that TRR also installs

You'll need to add a "filter": [ "files", "that", "should", "be", "ignored" ] into the install instructions so that you aren't over-writing the dependency's files.

YESSS IT WORKS NOW

@Olympic1 can you merge?

thx


Missing files

missing form ts.scx/sct
missing class phbxbasecontrols.vcx/vct
doesn't compile unless you ignore errors. compiled file doesn't work.
Compiled executable is available for downloaded however from the owners site?
http://leafe.com/dls/vfp
Great utility otherwise, many thanks for putting it together.

Wonder if these files are available anywhere? Trying to recompile against VFP Advanced with large file support.

My team has fixed it up. Working repo located here: https://github.com/AnnonAU/vRunFox


Design Transaction Structure and Execution Rules

Create the conversion transaction that allows a user to convert assets from one pegged token to another.
CoS:

A design is produced that is able to be implemented
Tickets are created for all work items needed to execute the design

related discussion that should be considered during design #190

So that a user can try to convert X (at most) PNT into Y pXBT. If they overestimated the amount of PNT needed, I don't think they should be punished for that and have the difference burned

I think the reverse logic could be made though. If BTC is currently $10,000, and I say
10,000 pUSD -> 1 pBTC

If the BTC price goes down, then I get a cheaper price and more BTC. How do we know the user wants ONLY 1 BTC? What if they want >= 1BTC, but nothing less?

"type": <TOKEN TICKER (no "p" prefix): string>,

Are we gaining anything from not including the "p" prefix? Unless there is significant gain, we should include it. The tx/conversion is not of USD but of pUSD.

@Cahl-Dee :  Are we gaining anything from not including the "p" prefix?

We get transaction payload portability across mainnet and testnets. Is that worth it? Maybe maybe not. Just makes things easier so we don't have to be putting conditionals all over the place saying "if testnet, use t. else use p"

Just makes things easier so we don't have to be putting conditionals all over the place saying "if testnet, use t. else use p"

that's something we need to rip out of the code anyway. repost from discord:

Complete, broken into #283 #287


refactor: pnpm-workspaces based setup

Summary
Reworked the project structure to use pnpm-workspaces as the foundation.
Details

Removed the symlinks because I don't like them
Removed a lot of the root configuration files because those should be local to projects
The new app is in apps/zotmeal
Preserved the majority of the legacy stuff in the apps

App Details

Uses NativeWind, i.e. TailwindCSS for React-Native
Uses expo router and src/app directory
https://docs.expo.dev/routing/introduction/
https://docs.expo.dev/router/reference/src-directory/
Uses shared packages, e.g. the ui package at packages/ui
Babel doesn't actually transpile anything from workspace packages for some reason.
This is typical behavior tbh; you're expected to build the package's outputs and import those.
But Vite's able to import and transpile on the fly just fine :shrug:
Works on my laptop and my iPhone

Would you guys like to do some more work on this branch? Or do you want to merge it in and just append adjustments via new branches and PRs to main?

I think we can go ahead and merge it in and append other adjustments through new branches. But I would like to hear Bryan's opinions as well.

I just linked the netlify here as well.


query: add Stores UI page

Signed-off-by: Adrien Fillon<EMAIL_ADDRESS>
Changes

Pass the query.StoreSet to the UI
Create a storeStatuses to track the status of stores
New Web Page Stores
Typo fix

Verification

I hoped to be able to write some e2e tests on the UI. Is that something possible ?
Also code might be terribad, sorry in advance

I hoped to be able to write some e2e tests on the UI. Is that something possible ?

Do you mean literally in-browser tests, or UI go package?

I hoped to be able to write some e2e tests on the UI. Is that something possible ?

Do you mean literally in-browser tests, or UI go package?

Well I'd love to generate multiple cases where I could check how the UI would look like (with the min/max for example). Might not be worth it though ?

how the UI would look like (with the min/max for example).

Still not sure how would you like to assert things (: So I think it's is alright to leave it without the templating generation tests. (I guess that's what you wanted?)

Might also be worth splitting Min / Max into two separate columns

Thanks for the feedback, indeed, putting the struct in the function is a much better way of doing those things !
Here's how it looks like now:

Could someone else try it out ?

Is it possible to distinguish what Node type it is? To see if it's Query, Rule, Store or Sidecar?
I'm not sure if the API returns this metadata.

@FUSAKLA sadly it doesn't look like it: https://github.com/improbable-eng/thanos/blob/fce2f6e28c68b0b57b05c8f4dcdfeb21fc144d1f/pkg/store/storepb/rpc.proto#L28
This might be quite helpful and be part of another PR later ? What do you think @bwplotka ?

And yea @FUSAKLA we can add node types in separate PR

But we need to add this to changelog (: in next prs.


local deployment without bluemix account?!

Just curious whether this could be deployed as a local instance without bluemix account?
Appreciate if somebody point it to documentation of the kind. Thanks!

Hi @zenny
At this point in time, the Watson APIs are only accessible through Bluemix - so you can deploy the app locally, but you still have to have a Bluemix account to get service credentials.


[CORE] Remove static modifier on TreeMemoryConsumers.Factory.map

The factory objects are already globally static. Its inner map doesn't need to be static. Make it non-static to take better encapsulation.
Also add some basic tests for TreeMemoryConsumer.

cc @marin-ma @JkSelf


Add helpful info to README about GOPATH for the installation

Added helpful steps that aren't mentioned in the Installation section.
This caused me some headache and I'd like to save the next developer some time!

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Allocation optimisations & Clippy cleanup

Proposed Changes
I started trying to get the Clippy lints to pass and then I got a bit carried away. I ended up removing all indexing (which could panic) and unwraps. And I found a way to get rid of some intermediate collects by messing with the validity filters (making them safe to share between threads).
I also reversed the polarity of the hash_set_filter predicate, so that it matches Iterator::filter.

I always forget about clippy until the end sorry. Making validity_filter Fn and Sync makes the get_cliques function so much nicer. The AtomicUsize is a new one for me so I'll have to remember that.


Add project to Grafana Dashboards page

Hi @anryko
Thank you for the Docker plugin addition (issue #71)! Now this dashboard is really powerful! That's why I think you should add it to the page https://grafana.net/dashboards, where the Grafana project is collecting various and useful dashboards for different data sources.
What do you think? If I'm not wrong, this dashboard would be the only one with Docker monitoring from Collectd sources. At the moment the only Docker monitoring dashboards are using Prometheus as source.
Another cool addition would be to make the server selection more user friendly and useful, maybe with autocompletion. There's an issue already opened for this: #67: can I help implementing it?
Looking forward to your reply and to improve even further this dashboard!

Hi @oli-g
Thanks for your interest in the project.
Regarding Grafana Dashboards list:
I think the list is for static dashboards only. The idea there (as far as I understand) is to import JSON and get ready dashboard working. Getdash works on a lower level. It generates this JSON for you. So in theory you could query something like:
http://localhost:3000/dashboard/script/getdash.js?host=dev-kafka-1&metric=kafka&span=6&legend=false

Save it and export as a JSON. Then suggest it as a dashboard for https://grafana.net/dashboards.
Regarding  #67:
Any help is really welcome here :). Here you can find a javascript string where this functionality should be added.


Add metadata to annotation-derived l7 policy

This change adds metadata labels to L7 DNS allow-all visibility policies derived from pod annotation in order to inform user about which pod annotations caused policy creation.
Fixes: #31359
Added source pod metadata to generated L7 DNS visibility policies.

/test

/test

/test


Unable to subscribe to equity option quotes

The api quote token only has equities market data available to it. Subscribing to other instruments types via dxLink (equity options, future options, futures) doesn't return any data.
We are aware of the issue and are working with DxFeed to resolve it. Any developments will be posted here.

How's the progress going on this front?

@dirkdirk Unfortunately there is no progress to report yet. We are still working on it. Distributing quote data is something that puts tastytrade at some risk of breeching licensing agreements, especially if they were to make it available to all users with API access. tastytrade has no control over what API users do with those quotes, which poses a real possibility that abusers could use the data to source their own proprietary projects.
For the time being, I recommend sourcing quote data elsewhere if you absolutely need it.

@dmoss18  Thanks for the quick reply and the clear explanation.
I'm an individual trader and am only using a small amount of data to manage my trades.  Can you or anyone recommend a reasonably priced quote data source for a small fry like me?
(I'm currently using MarketData but their "real-time" data differs wildly from what ToS reports.  I was hoping switching to Tasty's API would solve this issue.  At least with Tasty I can stream my orders and positions ... so that solves the manual data input pain point.  As of this post, Schwab has yet to turn back on ToS's API and they have no time horizon of when that will happen.)
So if anyone can recommend a realtime quote streamer I would highly appreciate it.

@dmoss18 What if quote data via the API for equity options, future options, futures are limited to only positions the user is in?  That way the quote data is severely limited and really only useful to the user.

@dirkdirk It's a good idea, but tastytrade's market data vendor, DxFeed, doesn't have any notion of tastytrade account positions, so they wouldn't be able to enforce that on their end.
Open interest and greeks are both part of specific market events (Greeks and Summary, respectively). The licensing/distribution concerns still apply to those. Sorry I don't have a better answer for you at the moment.

This issue mentions using a delayed quotes endpoint (wss://tasty-demo-ws.dxfeed.com/delayed). Is this a viable, intermittent workaround? How delayed are these quotes?

Quote for index (e.g., SPX, NDX) does not work either.

Good news, you should now be able to subscribe to equity option quotes using the token returned from the GET /api-quote-tokens endpoint.

@dmoss18 The original comment of this issue says

Subscribing to other instruments types via dxLink (equity options, future options, futures) doesn't return any data.

Does the resolution of this issue mean futures options are now available via dxLink?

Good news, you should now be able to subscribe to equity option quotes using the token returned from the GET /api-quote-tokens endpoint.

same as previous. can we get futures options data now? i dont want to go through the trouble of working through it if it doesn't work.

I tested it and can get equity option quotes and future options quotes.
interestingly, I can get option quotes for SPX, but not for SPX itself.
greeks seem not to work

interestingly, I can get option quotes for SPX, but not for SPX itself.

Try SPXW ... ?
https://www.marketdata.app/education/options/spx-vs-spxw-options/

Good news, you should now be able to subscribe to equity option quotes using the token returned from the GET /api-quote-tokens endpoint.

will this endpoint ever have futures options greeks on it?

@IV2KBMoFxYIA Still working on greeks for this. I'll post here with more info when I have it.


Make GH Issues notifier configurable per check

Overview
In addition to per accreditation config, the GH notifier should also be configurable per check.
Requirements

Update the GHE notifier to be configurable per check.

Approach
TBD
Security and Privacy
N/A
Test Plan
TBD

@alfinkel (Dec 12, 2018): I think that it would be useful to add an additional layer of granularity to the GH notifier specifically so that we can create a GH issue per check rather than forcing notifications to fire off for all of an accreditation.
The GH notifier is slightly different from the Slack notifier in that the Slack notifier sends a single notification message (for all checks) per accreditation whereas the GH notifier sends multiple notifications (in the form of GH issues) for every check in an accreditation. So my thought here was that if you have multiple checks that are part of an accreditation you'd want the flexibility to be able to manage whether a GH issue is created for a check in that accreditation. To be clear I don't plan to change the current behavior of notifying per accreditation, I just want to add the flexibility via configuration to manage the GH notifications in a more granular way. If no configuration is provided then the GH notifier will behave exactly the same way as the Slack notifier and will notify for each check in the accreditation.

@drsm79 (Mar 4, 2019): I wonder if it's useful to introduce the idea of a a check family (which is probably some part of the module structure the check lives in?) for this kind of thing. We'd then be able to say "Send test_inventory_listing to GH but don't send test_vulnerability_scan". When we've got a lot of checks configuring individuals is not going to be fun...


What xcode version is used to build jdk8 on OSX?

The OpenJ9 project wants to update their builds for OSX, to use similar machines and tools as Adopt.
https://github.com/eclipse/openj9/issues/9806
We've determined 10.14 as the build machine, but haven't been able to confirm the xcode version used.
Apparently xcodebuild -version can work to find the version, unless xcode is installed via old cmdln tools. Which apparently OpenJ9 and perhaps Adopt use since it requires a smaller footprint to install this way.

@jdekonin @keithc-ca @sxa

/usr/bin/xcodebuild -version should work

Perhaps all we can do is confirm the gcc/clang version? Which Stewart already provided.
Using clang C compiler version 10.0.1 [Apple LLVM version 10.0.1 (clang-1<IP_ADDRESS>) Target: x86_64-apple-darwin18.7.0 Thread model: posix

Pls try xcodebuild -version on an Adopt jdk8 build machine.

ping @gdams

This is the Xcode version we use to build JDK8u. Note it is full Xcode rather than the command line tools:
build-macstadium-macos1014-x64-1:~ administrator$ xcodebuild -version
Xcode 10.3
Build version 10G8

@gdams what Xcode is used for the other Java versions?

I think we're building all on the same level now but will defer to @gdams

@gdams what Xcode is used for the other Java versions?

for all other Java versions we use Xcode command-line build tools:
$ clang --version
Apple LLVM version 10.0.1 (clang-1<IP_ADDRESS>)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

I am a little confused as to why the newer releases are on a slightly older version?  Whats the reason behind using too different versions?  Is there any plan on unifying for system setup simplicity?

jdk8u currently requires the full fat Xcode installation so we are pinned to whatever we can get on the machine at the time of setup. The other versions all use command-line tools which gives us a lot more flexibility.


Shared upload

Q
A

Bug fix?
No

New feature?
Yes

BC breaks?
No

Deprecations?
No

Fixed tickets
N/A

This small feature resolve situations with first time deploy to new server, when shared files (.env for laravel for example) is empty.
Example:

Put production copy of .env file to folder shared
set('shared_use_bootstrap', true);

I think different approach required. Using got instead of upload.

Git for store file with access to db and other passes?

I think @jonnott is right.

Coz when recipe will tried to exec migrations for example, it will fail, coz no right DB connections params present.

That’s a good point - there a tasks for Laravel which get skipped if there’s no .env file present - and for good reason!

So, close PR and delete branch?

I think it needs further thought by those more knowledgable that me!


cf services shows upgrade available incorrectly

Please fill out the issue checklist below and provide ALL the requested information.

[x] I reviewed open and closed github issues that may be related to my problem.
[x] I tried updating to the latest version of the CF CLI to see if it fixed my problem.
[ ] I attempted to run the command with CF_TRACE=1 to help debug the issue.
[x] I am reporting a bug that others will be able to reproduce.

To Reproduce
update a service broker so that a service upgrade is available.
run cf s
verify that an upgrade is available
example:
Getting services in org test_org / space test_space as admin...

name                  service        plan          bound apps   last operation     broker              upgrade available
extra-small-service   p-cloudcache   extra-small                update succeeded   cloudcache-broker   yes
test1                 p-cloudcache   dev-plan                   update succeeded   cloudcache-broker   yes

run cf upgrade-service <service_name> -c '{<some json here>}'
watch the service update watch --color cf s
when the service finishes updating run cf s
Expected:
either an upgrade should no longer be available, or the cf cli should have never allowed the -c option to succeed without the --upgrade flag
Actual:
the cf s command shows that the service that was just updated has an upgrade available.
Provide more context

platform and shell details ( e.g. Mac OS X 10.11 iTerm)
Mac OS X

version of the CLI you are running
cf version 6.46.0+29d6257f1.2019-07-09

version of the CC API Release you are on

Note: As of January 2019, we no longer support API versions older than CF Release v284/CF Deployment v1.7.0 (CAPI Release: 1.46.0 (APIs 2.100.0 and 3.35.0).

@pnikonowicz
Hey, thank you for reporting this issue!
I’m curious, could you explain in more detail, why you’re expecting to see upgrade happen if you’re not providing the --upgrade flag?
To my knowledge, the upgrade-one feature is designed in a way, that --upgrade and -c are independent, and if --upgrade is not provided, then Cloud Controller is not going to tell the broker to update the version of maintenance_info. (see the OSBAPI spec here: https://github.com/openservicebrokerapi/servicebroker/blob/v2.15/spec.md#body-6)

That appears to be what happens. But because there is only one broker at any time, when a service instance is updated, the service instance is using the new broker and not an older broker. Therefore the service instance is updated to the newest broker.
For our service broker (PCC), we have each broker contain a static version number that is stored in maintenance_info that appears to be returned to the cli.
To be clear, we are not expecting an upgrade to happen, but we are expecting the cli to represent accurately the state of our cf foundation. In this case, the cli is stating that there is an upgrade available when there is not.

If I understand you correctly, this wouldn't be a bug in the cli because the cli just tells the Cloud Controller what was entered. It's up to the service broker to interpret that message correctly. Is this correct? If so, we can close this issue.

I’m afraid that in the CLI, right now, there is logic specifically preventing -c (or -p) and --upgrade combination of arguments.
In the Cloud Controller, it is possible to pass parameters and maintenance_info at the same time.
Is your situation that the broker will automatically update the maintenance_info if any kind of parameters are passed (even if maintenance_info is not provided) in the PATCH request? (perhaps because it does a new bosh deployment and that just upgrades to latest release?)
Because if it is true, then to support that we’d need a way for CF to be informed of this change, or the broker should make parameters change without maintenance_info update not possible. Otherwise, information in CF and service broker will get out of sync. Of course, in this scenario, CLI should allow combination of -c and --upgrade.
What are your thoughts or questions given the information above?

I double-checked the behaviour of ODB and it’s going to reject the request to update the parameters if the maintenance_info of the service instance is outdated. In your scenario, the CLI user will have to perform cf update-service my-service --upgrade before they can do cf update-service my-service -c '...'.
So, here is what I’d expect to happen:
1. run `cf upgrade-service <service_name> -c '{<some json here>}'`
2. watch the service update `watch --color cf s`
3. when the service finishes updating run `cf s`

Expected:
4. the service still has an update available
5. the service last operation status is `update failed`
6. when looking at the details of the failure with `cf service <service_name>`
7. it has a descriptive message that the service instance need to be upgraded first

Does it sound right to you? From this perspective, is that what’s happening or there is a difference between Expected and Actual?

Here is the result of the steps that you outlined. Notice at the end that the update succeeded but there is still a service update marked as available.
initial status:
└─▪ cf s
Getting services in org test_org / space test_space as admin...

name                  service        plan          bound apps   last operation     broker              upgrade available
extra-small-service   p-cloudcache   extra-small                create succeeded   cloudcache-broker   yes

run cf upgrade-service <service_name> -c '{<some json here>}'

└─▪ cf update-service extra-small-service -c '{"restart":true}'
Updating service instance extra-small-service as admin...
OK

Getting services in org test_org / space test_space as admin...

name                  service        plan          bound apps   last operation       broker              upgrade available
extra-small-service   p-cloudcache   extra-small                update in progress   cloudcache-broker   yes

watch the service update watch --color cf s
when the service finishes updating run cf s

Getting services in org test_org / space test_space as admin...

name                  service        plan          bound apps   last operation     broker              upgrade available
extra-small-service   p-cloudcache   extra-small                update succeeded   cloudcache-broker   yes

Expected:
4. the service still has an update available

It does, but it should not because the service was just updated

the service last operation status is update failed

Service update succeeded

when looking at the details of the failure with cf service <service_name>

there is no error listed
Showing available upgrade details for this service...

upgrade description:

TIP: You can upgrade using 'cf update-service extra-small-service --upgrade'

Expected:
4. the service still has an update available

It does, but it should not because the service was just updated

@pnikonowicz
I don’t understand why do you think so…
"Update" and "Upgrade" are slightly different concepts.
While the service was "updated" (its "-c" parameters changed), the service shouldn’t have been "upgraded" (because "--upgrade") wasn’t passed. Only by passing "--upgrade" shall "maintenance_info" version be updated.
If your broker is doing an maintenance upgrade when one passes "-c"—this is an unexpected behaviour.

PCC uses the ODB broker so most of this is handled for us. But in order to get the upgrade available to show as yes, we need to register a new broker with cf.
This means that any activity with the broker from that point on is essentially an upgrade.
I suppose another way to verify this is:

do the cf update-service without the upgrade flag.
download the service instance manifest
do the cf update-service with the upgrade flag
download the service instance manifest again.

I would expect the two manifests to be equal. That's because they are using the new broker both times.

I think another way to look at it is this:

A service instance is created when the ODB adapter is a v1
The ODB adapter is updated to v2, and the broker is re-registered
cf s shows that an update is available
cf update-service s1 -c .... is run
The ODB adapter is asked to generate a new manifest with the new -c ... config. Because the adapter is a v2 adapter, the service instance is updated to v2. Why? Because adapters always generate a manifest of the latest version.
The service instance shows that an update is still available, but in reality it is not

Subsequently, if cf update-service s1 --upgrade is run, it will update the Cloud Controller database, but the service instance will not be upgraded, because this has already happened as a side-effect of (4)
I think there is agreement here that step (4) should not have succeeded. Changes to the service instance should be blocked until the service instance is upgraded. Otherwise the results of any changes are hard to reason about, and leave the Cloud Controller database inconsistent with the state of the world.

@blgm @pnikonowicz
To make the step (4) fail, we’d have to modify logic on ODB side, wouldn’t we?

Not necessarily.
The -c flag is a flag for the cf-cli. I suppose the logic follows:
if cliFlag.contains('-c') AND cloudControllerService.getStatus().isUpdateAvailable() {
    panic("you cannot do a -c flag when and update is available. please update your service first with the --upgrade cli flag")
}

Hmm, in that case it’d be better if Cloud Controller had that check during the execution of the update action. That is because we want to keep the CLI command to never check whether update is available or not, and just defer the decision to CloudController. At least, that was the original plan when implementing the update-one feature, architecture-wise.

@pnikonowicz
We have initially made this change in CAPI, but after more thinking, and taking OSBAPI and other brokers (non-ODB) in consideration, we decided to make that decision in ODB instead, and only add all relevant information to the PATCH request from CAPI to broker, so that the broker can make a decision to accept or reject it.
Here is the tracker story: https://www.pivotaltracker.com/story/show/169087442

Here is the story for ODB side: https://www.pivotaltracker.com/story/show/169123444

Closing this issue because it was implemented on the API side. Thanks.


MAINT: Change imports from q2-types-genomics to q2-types.

q2-types-genomics will be deprecated with the next qiime distro.
All imports from q2-types-genomics have to be changed to q2-types.
https://github.com/qiime2/q2-types/pull/309#issuecomment-1943152077

Should this issue be closed @VinzentRisch?


FLOW Proposed change: From create to send, not main menu -- Discuss

Does this refer to the async work queue?


Update integration sample - Shopify

Motivation
Fixes #144
Checklist

[ ] Code follows coding conventions held in this repo
[ ] Automated tests have been added
[ ] Tests are passing
[ ] Docs have been updated (if applicable)
[ ] Temporary settings (e.g. variables used during development and testing) have been reverted to defaults

How to test
If manual testing is required, what are the steps?

Could you also include these changes from #140

Removal of /examples/* and /docs/*
Adjust the value property (i.e. like in https://github.com/Kentico/kontent-sample-app-react/pull/140/files#diff-32f4f85fc84ccaf9e994c43c71ec13bcR76)

Hi @Simply007 , The src/Pages/Home.js for the samples/shopify branch is different from the master branch and does not have a homevariable defined. Should this be changed to match the src/Pages/Home.js in the master?

May I ask you, how did you find this issue? Repo? Is that part of Hacktoberfest challenge? 😄

May I ask you, how did you find this issue? Repo? Is that part of Hacktoberfest challenge? 😄

Yes it is


Menu items in a menu list shake up when opened in chrome

Description and steps to reproduce:
I noticed menu items in my app were shaking little bit when opening. I did some debugging on chrome, changed a few styles etc but nothing could fix it. I then tested on firefox and safari and found them working correctly, which means the bug is atleast in chrome.
I've verified the same bug is on docs site as well, please go to material-ui menus, open the first simple menu and look "very closely". "My account" item shakes up everytime list is opened, sometime more when done quickly.
I can say that this issues comes up in newer versions of chrome because I've not updated material-ui in last 6 months and it worked well before 1-2 months.
I believe docs site is using the latest release and thus not trying to update to newest release and test it.
Checklist:

[ ] The issue is present in the latest release (I've not checked with latest release locally as bug could be seen in docs site, my material-ui core version is 4.11.0)
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
One of the menu item in menu list shake up on opening
Expected Behavior 🤔
menu items should remain at their positions on opening
Steps to Reproduce 🕹
Please see description for reproducing.
Your Environment 🌎
macOS 11.1
chrome 87.0.4280.88
Not posting material-ui environment details as the bug could be seen in material-ui docs site. Please let me know if more information is required.

@praveen4463 I believe this is related to the rasterization of your environment. The browser might trade some of the quality of the rendering for maintaining 60 FPS during the transition. Once the transition is over, the optimization kicks back, like anti-aliasing. We have seen similar reports in the past, like #17397. I personally can't reproduce on macOS 10.15 and Chrome 87.

Menus_shaking.mov.zip
@oliviertassinari Thanks for looking into this, would you advice some fixes in my environment to fix this? Btw, I recorded a video of what I'm seeing on chrome. Please unzip and watch.

@oliviertassinari I think I found where the problem is. I've chrome setup at 110% zoom. When I changed it to 100%, there is no shaking. If I set firefox to 110%, menus start to shake up there as well.
If this is not a bug, would you advice what should I tell if some of my end user ask shows me this happening to them?

I could reproduce too with a different zoom level. I think that we should close as we have no leverages to fix it. You could try using a different transition, see if it's smoother.

@oliviertassinari I think I found where the problem is. I've chrome setup at 110% zoom. When I changed it to 100%, there is no shaking. If I set firefox to 110%, menus start to shake up there as well. I checked at material design menu demo that is stays well at 110% zoom whereas in material-ui docs site it shakes up.

i still think it's a little issue😂thank you let me know how to fix it

Hello everyone!
I found out that the following css rule allows you to solve this problem with the tooltip and menu
.MuiTooltip-tooltip, .MuiPaper-root { 	backface-visibility: hidden; }


Launch drop down no longer updates

VSCode Version: Code - Insiders 1.8.0-insider (e0871329738682651367be4e8a618912ad693e03, 2016-12-08T07:05:13.731Z)
OS Version: Darwin x64 15.6.0
Extensions:

Extension
Author
Version

EditorConfig
EditorConfig
0.3.4

autofilename
JerryHong
0.1.3

vscode-docker
PeterJausovec
0.0.7

regex
chrmarti
0.0.7

vscode-eslint
dbaeumer
1.1.0

ghlink
dt
0.0.4

tslint
eg2
0.6.0

vscode-scss
mrmlnc
0.6.0

PowerShell
ms-vscode
0.7.2

debugger-for-chrome
msjsdiag
2.2.2

diff
rafaelmaiolla
0.0.1

vscode-open-in-github
sysoev
1.2.1

This was working in yesterdays insiders:

Also when adding a launch config manually.

@chrmarti I cannot reproduce with latest insider

Can not reproduce.
@chrmarti for some reason you were probably missing file event. If you are still in that broken state do you see git status updating when you are making changes to a file for instance,
@weinand can you also please try.

I cannot reproduce this in Version 1.8.0-insider, df6fcbe12a000a62fb526fe6953405e28c6e6fc3, 2016-12-09T09:00:32.682Z

This is because he is running the workspace with lowercase path due to hot exit bug. in that case all file events are broken.

So dup of https://github.com/Microsoft/vscode/issues/16829


cluster edition report error

amazon-s3-resumable-upload/cluster/cdk-cluster/app.py

There is additional * in  init function parameter
def __init__(self, scope: core.Construct, _id: str, *, vpc, bucket_para,  # key_name,
                 ddb_file_list, sqs_queue, sqs_queue_DLQ, ssm_bucket_para, ssm_credential_para, s3bucket, s3_deploy,
                 **kwargs) -> None:
        super().__init__(scope, _id, **kwargs)


Impossible to load VCRT Forwarders if strict Control Flow Guard is enabled

int main()
{
#ifdef _CONTROL_FLOW_GUARD
	PROCESS_MITIGATION_CONTROL_FLOW_GUARD_POLICY cfg_policy;
	if (GetProcessMitigationPolicy(GetCurrentProcess(), ProcessControlFlowGuardPolicy, &cfg_policy, sizeof(cfg_policy)))
	{
		cfg_policy.StrictMode = true;
		SetProcessMitigationPolicy(ProcessControlFlowGuardPolicy, &cfg_policy, sizeof(cfg_policy));
	}
#endif

    // do something that requires loading the VCRT forwarders, like initializing WinUI.
}

When building the above code with /cf:guard, the following error occurs when trying to load the forwarder DLLs.
Exception thrown at 0x00007FFC0160467C (KernelBase.dll) in TranslucentTB.exe: WinRT originate error - 0x80070679 : 'The specified image file was blocked from loading because it does not enable a feature required by the process: Control Flow Guard.'.

Note that I use Control Flow Guard in both debug and release builds of my apps, the VCRT Forwarders should build both debug and release forwarders with Control Flow Guard enabled


Remove warning about user gesture propagation through Promises

crbug.com/404161 has been resolved so the following code will now work
as of Chrome 72:
let devices = await navigator.usb.getDevices();
// See if |devices| contains the device you are interested in. If not,
let device = await navigator.usb.requestDevice();

[ ] This has been reviewed and approved by (NAME)
[x] I have run npm test locally and all tests pass.
[ ] I have added the appropriate type-something label.
[x] I've staged the site and manually verified that my content displays correctly.

CC: @petele

:tada: This has been pushed live to https://developers.google.com/web/


Missing impl's in Integer, Char, Long and String

As mentioned in #1549, the following are missing from javalib:

Integer toString(i: scala.Int, radix: scala.Int): String, Integer highestOneBit(i: Int): Int
Char forDigit(digit: Int): Char , def forDigit(digit: Int, radix: Int): Char
Long toString(value: Long, intRadix: Int): String
String  regionMatches(s: String, ignoreCase: Boolean, toffset: Int, other: String, ooffset: Int, len: Int): Boolean
 def regionMatches(s: String, toffset: Int, other: String, ooffset: Int, en: Int): Boolean

This are/were implemented as part of  #1549, I can lift them as a new PR

If not a new PR, they should at least be in separate commits. Each in a separate commit, actually, except related ones. So {Integer,Long}.toString would go together, and for regionMatches together.

I'm happy to do separate PR's as you suggest, as it's easier to squash changes later on. I'll proceed like this, if that's OK

Ok - will add as separate commits in #1549


⚠ Jenkins Plugins Artifactory has degraded performance

In 5c6184c, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1249 ms

Resolved: Jenkins Plugins Artifactory performance has improved in 7ea5d7f after 21 minutes.


Pre-allocated interpolation

I am using AffineTransform to transform a large number of volumes and the interpolation process allocated a huge amount of memory. I know there is a interpolate! function. However interpolate! would destroy the input matrix. Also it looks like it can only be used with BSpline(Quadratic(InPlace())). Is there a way to output the interpolation to a pre-allocated matrix but also keep the input matrix?  Thanks!

Would it work to call copy on your input matrix before passing it to interpolate!?

Yes, I can make a copy of the input matrix before interpolate! , which would allocate the same amount of memory as interpolate. However, since I have tens of thousands of volumes whose size are fixed, I can pre-allocate a volume with the right size and use copy!() to copy the input matrix to the pre-allocated volume before interpolate! to limit the memory allocation, which is an improvement. But that is still tens of thousands additional copies of large 3d matrices, e.g. 250x250x250.

Can you get away with Linear? The reason I ask is that Linear does not require prefiltering; if you don't need to do prefiltering, then it does not destroy the input.
If you do need Quadratic, and can use InPlace, then you can copy to a reusable buffer as you say. I don't think there's an alternative to copying if you want to use the current infrastructure: interpolate! uses the input to store the interpolation coefficients, and those are not equal to the input data for anything higher than Linear.

Thanks! I did find out that when using Linear the output was not destroyed and was puzzled. Now I know why. Yes, right now I can go with Linear, but eventually I need to move to Quadratic and even Cubic. I didn't find an InPlace for Cubic though. Will this be implemented?

Somebody probably needs to work out the mathematics. If you're interested in tackling that, there was once some PDF documentation on InPlace but it seems to have been removed. Perhaps you could try checking out older versions of this package to find it.


Language attribute in html tag

Recommend you add the lang attribute to the html tag
<html lang="en">
So search engines and apps will know what language your page is

Fixed in ccccb63549955f29f2351a90dd80aa767715e6d1


There is a newer vessel

Re-point the link to a newer vessel release.
Please also consider supporting a newer dfx:
diff --git a/dfx.json b/dfx.json
index 1d47d6e..2606913 100644
--- a/dfx.json
+++ b/dfx.json
@@ -17,7 +17,7 @@
       "packtool": "vessel sources"
     }
   },
-  "dfx": "0.6.4",
+  "dfx": "0.6.7",
   "networks": {
     "local": {
       "bind": "<IP_ADDRESS>:8000",
@@ -31,4 +31,4 @@
     }
   },
   "version": 1
-}
\ No newline at end of file
+}

Please also consider supporting a newer dfx

Done


”Sânzieni” is listed in the drop-down menu

Description:
"Sânzieni" is listed in the drop-down menu alongside its corresponding county and commune, according to the law.
Precondition:
The website is up an running.

Step 1
Type "Sânzieni" in the search bar.

Expected results
The location is listed in the drop-down menu as "Comuna Sânzieni, COVASNA".


Package subpath './plugin' is not defined by "exports" in

Description
Hello
I am trying to Localize pathnames but I am getting this error when modifying next.config.js
DOC URL I am following: https://next-intl-docs.vercel.app/docs/next-13/middleware#localizing-pathnames
- error Failed to load next.config.js, see more info here https://nextjs.org/docs/messages/next-config-error Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './plugin' is not defined by "exports" in /Users/alex/Downloads/next-intl-feat-next-13-rsc/examples/example-next-13-named-routes/node_modules/next-intl/package.json     at new NodeError (node:internal/errors:399:5)     at exportsNotFound (node:internal/modules/esm/resolve:261:10)     at packageExportsResolve (node:internal/modules/esm/resolve:591:9)     at resolveExports (node:internal/modules/cjs/loader:569:36)     at Module._findPath (node:internal/modules/cjs/loader:643:31)     at Module._resolveFilename (node:internal/modules/cjs/loader:1056:27)     at /Users/alex/Downloads/next-intl-feat-next-13-rsc/examples/example-next-13-named-routes/node_modules/next/dist/server/require-hook.js:188:36     at Module._load (node:internal/modules/cjs/loader:923:27)     at Module.require (node:internal/modules/cjs/loader:1137:19)     at require (node:internal/modules/helpers:121:18) {   type: 'Error',   code: 'ERR_PACKAGE_PATH_NOT_EXPORTED'
Mandatory reproduction URL (CodeSandbox or GitHub repository)
https://github.com/amannn/next-intl/tree/feat/next-13-rsc/examples/example-next-13-named-routes
Reproduction description
Steps to reproduce:

Open terminal in folder, do npm install next, then npm run dev
Server won't run

Expected behaviour
Expected to work.

I tried other packages with next 13.4.0 and same problem.

next.config.js

Maybe you didn't realize that the doc has a code similar to the one in my print below. However, when I went to implement it following the doc, it shows that the "next-intl/server" module does not have any "getRequestConfig" function being exported.

Actually this module has several bugs. :/

I managed to fix it as follows:
npm install<EMAIL_ADDRESS>or
yarn add<EMAIL_ADDRESS>

I managed to fix it as follows:
npm install<EMAIL_ADDRESS>or yarn add<EMAIL_ADDRESS>
Yes, the same, I had to going back to this version<EMAIL_ADDRESS>

<EMAIL_ADDRESS>is the latest beta version that contains RSC support, so it is required to use as mentioned above.
Since the original bug report mentioned the example contained in this repo: As mentioned in the contributors guide, you need to use pnpm to link a local build of next-intl.

<EMAIL_ADDRESS>is the latest beta version that contains RSC support, so it is required to use as mentioned above.
Since the original bug report mentioned the example contained in this repo: As mentioned in the contributors guide, you need to use pnpm to link a local build of next-intl.

If we want to use 2.19 version, will there be server components?
Can you please provide info how can we use 2.19 version with getRequestConfig and server components as in early versions
And can you please provide a migration plan?
!!! Important !!!
An Error Module ‘“next-intl/server”’ has no exported member ‘getRequestConfig’.ts  still exists in 2.19.0 / 2.19.1 versions

RSC support is only available in the RSC beta version referenced here: https://next-intl-docs.vercel.app/docs/getting-started/app-router-server-components
See also https://github.com/amannn/next-intl/issues/286#issuecomment-1543617410


Nomenclature grid Openlayers

Hello! I work on a project where I use OpenLears v4 . There was an interesting task where it is necessary to implement a nomenclature grid. Something similar I found written on Leaflet. http://nakarte.tk/#m=5/46.25585/41.08887&l=O/Ng . I want to know how to implement this grid on Openlayers? Maybe someone has already done the same?

You can probably hack it out of https://openlayers.org/en/latest/examples/graticule.html

Or overriding https://github.com/openlayers/openlayers/blob/master/src/ol/source/TileDebug.js

It's not so easy to do. Can you help me with this?

https://codesandbox.io/s/mqn3wj5qkp
go to the custom.js and in the last function, change the text value

https://jsfiddle.net/andrii555/setmtbsq/ my resoult. But I need to display the coordinates inside the cell


[HTML] Multi-line comment issues

VSCode Version: Code 1.13.1
OS Version: Windows_NT ia32 10.0.15063

Steps to Reproduce:

Comment a line or two of HTML out.

Select a group of lines including the already commented lines, and press Ctrl+/

I believe the -- should be replaced with - - on the inner comments.

VSCode comment feature is a simple coding assistance and does not make any changes inside the commented text. You have to make these yourself.


Cleanup stylesheets directory structure

As we are releasing the Polaris v12 changes as a breaking 2.0 version, we can go ahead and re-organize the stylesheet directories and files to keep it consistent.

Not sure if it makes sense to spend time on this since we'll remove these customization with new Polaris release anyway. @forsbergplustwo maybe let's keep it as is, what do you think?

@kirillplatonov  I can do today 😊 My plan was just moving files from stylesheets/polaris_v12_overrides into the normal stylesheets/polaris_view_components folder and updating imports in polaris_view_components.pcss.

Okay 👍 Otherwise I think #330 is ready to be merged to main. I upgraded both of my apps and everything looks great. Once we merge it I will upgrade icons too and we can publish v2.0 this week.

Awesome, also have it running nicely on a couple of mine.. so cool with having this as the released version 🎉 I've pushed up https://github.com/baoagency/polaris_view_components/issues/385 now with the file re-organization.

Closed by https://github.com/baoagency/polaris_view_components/pull/398


⚠ GreatPosterWall has degraded performance

In db97e6f, GreatPosterWall ($GPW) experienced degraded performance:

HTTP code: 200
Response time: 2214 ms

Resolved: GreatPosterWall performance has improved in 1b50b19 after 22 minutes.


Use a 00 prefix on eth and sep tasks to ensure correct ordering for up to 999

This prefixes the eth and sep task dirs with 00, and fixes the ordering of the ceremonies so that the delta upgrade is finalized first.
Note: this PR builds on #83 and should be merged second.

@zchn's review was dismissed when the base branch was merged to main in #83. However nothing else has changed, so I will bypass the review requirement.


[FEATURE] Added SYNC producer functionality

Motivation
For my masters thesis project, i selected this library as a best candidate, deciding by code clarity, use of static allocation, API simplicity and documentation. Unfortunately it only supports slave functionality while for my project it is required that CANOpen stack used supports SYNC producer and SDO client (i work on ECU handling three CANOpen motor controllers using torque vectoring, for experimental student e-car). Because i know canopen-stack API and configuration well, i have decided to extend current functionality with the required one. First step is to implement SYNC producer.
Definition of done

[x] periodic SYNC frame transmission based on 1005h and 1006h entry values [CiA 301]
[x] 1005h entry value update allowing activation and deactivation of sync producer [CiA 301]
[x] 1006h entry value update should change SYNC frame transmission cycle time [CiA 301]
[ ] fill in the gap if i forgot something :)

Testing of implementation
All tests of new feature have been carried out on STM32H723 nucleo evaluation board using initial configuration:
    {CO_KEY(0x1005, 0, CO_UNSIGNED32|CO_OBJ_D__RW), CO_TSYNCID,     (uintptr_t)0x40000080},
    {CO_KEY(0x1006, 0, CO_UNSIGNED32|CO_OBJ_D__R_), 0,              (uintptr_t)20000},

and during runtime using following sequence:
    /* Different COB-ID when SYNC producer is active    -> ERROR   */
    CODictWrLong(&CoNode.Dict, CO_DEV(0x1005, 0), 0x40000081);

    vTaskDelay((500 / portTICK_RATE_MS));

    /* Same COB-ID but deactivate SYNC producer         -> SUCCESS */
    CODictWrLong(&CoNode.Dict, CO_DEV(0x1005, 0), 0x00000080);

    vTaskDelay((500 / portTICK_RATE_MS));

    /* Different COB-ID while SYNC producer is inactive -> SUCCESS */
    CODictWrLong(&CoNode.Dict, CO_DEV(0x1005, 0), 0x00000081);

    vTaskDelay((500 / portTICK_RATE_MS));

    /* Different COB-ID and SYNC producer activation    -> SUCCESS */
    CODictWrLong(&CoNode.Dict, CO_DEV(0x1005, 0), 0x40000080);

Conclussion
As i will be using one-time set static configuration in object dictionary most of the time, it is not required to implement full functionality for me. But i though that maybe someone could run into same problem and profit from my contribution, so i am sharing this with you. Please provide me some feedback, thanks in advance.

First of all: thank you for adding the new feature to the CANopen stack! I'm happy, that the stack is useful for you.
My first impression of your changes are very good. I will dive into your changes during this week (just some limited time today).

Update

edited original comment adding DOD list and checked finished entries
added 1006h entry access type function allowing on-fly update of SYNC producer communication period

Tested on the same target using initial configuration:
    {CO_KEY(0x1005, 0, CO_UNSIGNED32|CO_OBJ_D__RW), CO_TSYNCID,     (uintptr_t)0x40000080},
    /* new access type "sync cycle time" + entry is writable now */
    {CO_KEY(0x1006, 0, CO_UNSIGNED32|CO_OBJ_D__RW), CO_TSYNCCT,     (uintptr_t)20000},

and runtime sequence:
    /* Update SYNC producer cycle to 40 ms          -> SUCCESS  */
    CODictWrLong(&CoNode.Dict, CO_DEV(0x1006, 0), 40000);

    vTaskDelay((500 / portTICK_RATE_MS));

    /* Used timer resolution is 1 ms, values under are declined */

    /*
     * Update SYNC producer cycle to 100 us         -> ERROR
     * Cycle time stays at 40 ms
     */
    CODictWrLong(&CoNode.Dict, CO_DEV(0x1006, 0), 100);

    /* Update SYNC producer cycle back to 20 ms     -> SUCCESS  */
    CODictWrLong(&CoNode.Dict, CO_DEV(0x1006, 0), 20000);

I guess, your focus is your masters thesis project. If you need support, I can imagine to write some tests in the testsuite and explain the usage in documentation. This just needs some time, because I'm very busy until April (maybe I can find some spare time on weekends).

Great work!
What SYNC cycle periods are you using? I'm asking, because you limit the resolution to 1ms instead of 1us. In my oppinion, it is ok to limit the resolution. I personally have no experience, which periods are commonly used for SYNC messages. Nevertheless, we should include a statement about this limitation into the documentation.

You are right, as CoTmr api allows only 1 ms or 100 us resolution, it is reasonable to use highest one, 100us then. I limited it simply because during my short experience with CANopen devices, i have never met any that required timing lower than 1 ms (i can not possibly imagine spamming the bus with sync frame every for example 50 us 😮 ). Motor controllers i work with require 20 ms sync. I think for correct integration into canopen-stack we should utilize 100 us timer resolution and restrict it in this range. Higher resolution would require CoTmr refactoring anyway.

I separate tests and website documentation into a issue.


consider making cmd/prometheus config defaults as package-level vars

in ./cmd/prometheus/config.go, the default directories for assets such as consoles are inline in the cli flag declarations.
if these defaults were moved out into package level string vars, they could be set with go's -ldflags -X, which would allow a packaging system to set the defaults appropriate to where these files will be installed.

That seems like a good idea and in a main package having that inlined and unexported struct probably has little value.

I don't like the idea of making it harder to figure out what the defaults are from the code in the general case.

Mh, but the defaults would still be clear in the help text.

Thinking a bit more, I'm against this. Flags should be spread liberally throughout the codebase, and adding a 2nd way to configure our flags that all flags usage had to follow would be an additional burden that'd result in fewer flags in a codebase that's already hardcoding a bit much.

No, flags should not be spread throughout the code base. This was
consciously removed long time ago and we had this discussions multiple
times over the last few months. Flags are fine, they are passed down as
configuration options but are all defined in one place. Regardless of other
arguments against this issue, this is not one of them.
On Tue, Sep 20, 2016 at 7:49 PM Brian Brazil<EMAIL_ADDRESS>wrote:

Thinking a bit more, I'm against this. Flags should be spread liberally
throughout the codebase, and adding a 2nd way to configure our flags that
all flags usage had to follow would be an additional burden that'd result
in fewer flags in a codebase that's already hardcoding a bit much.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/prometheus/prometheus/issues/1976#issuecomment-248378123,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEuA8rXQyRWTir5qSXwCK3lPJvnzZdTQks5qsByygaJpZM4J52cL
.

This is an argument against it, as I continue to believe we're using flags in an incorrect fashion (basically we're pre-maturely optimising for every single flag being relevant to users using Prometheus as a series of modules; rather than the more common case of them being rarely altered values by operators).

Without implying anything for what's suggested in this issue:
In our given situation (and even more so now that more and more people use packages from the Prometheus codebase as libraries), I am firmly in the camp of restricting flags to the main package and pass down configuration options as parameters of type constructors. (Option structs are a well established way to provide reasonable defaults on the package level and thus avoid parameter sprawl.) Reasons have been discussed elsewhere, I'm not repeating them here. I just wanted to cast my vote, in case there were any doubts.

If we're going to discuss this particular issue, why should we accept this additional method of configuring flags and not environment variables, files or via http which we have all previously rejected?

It would be different as it doesn't configure directly but just adjusts the
defaults and this at build time.
But I think we should have a more direct use case than thinking that it
would be useful.
On Thu, Sep 22, 2016, 12:41 PM Brian Brazil<EMAIL_ADDRESS>wrote:

If we're going to discuss this particular issue, why should we accept this
additional method of configuring flags and not environment variables, files
or via http which we have all previously rejected?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/prometheus/prometheus/issues/1976#issuecomment-248867063,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEuA8lctrd4mP3WAwxSs0scwarrNYLqsks5qsltpgaJpZM4J52cL
.

That brings many of the same challenges as the others: it's an additional way to do things, and it's no longer sufficient to look at the command line to know what is being passed which will make debugging and support harder (imagine someone getting one of these binaries and being confused when we tell them e.g. the default retention is 15 days if you haven't changed anything).
This use case could be handled by a shell script wrapper, or more likely as this would be for use in a packaging system via a /etc/defaults file.

I think setting default as build time is established thing for long time. At least stuff like changing a prefix and defaulting to a path within that prefix to find config files etc.
But I see @brian-brazil's point and spend too much time figuring out which config/directories a binary uses.
All in all I agree with @fabxc, we should wait for a specific requirement and then can see how to solve that.

It's established in C-ish binaries built via automake/autoconfigure, it's not established in Go.

Voting :+1: on having all flags in main only, unsure about the build-time default value injection though.
@TheTincho - is this something that would be useful for Debian packages, for examples?

If you move the flags definitions somewhere else, without being configurable via linker options, does not change much for me. I still need to patch the source to conform to Debian standards (only it is simpler to keep track of them if they are in a single file).
Now, if these were configurable via -ldflags, then I could drop those patches. No big deal, but it makes things tidier and simpler for me.

@TheTincho So you will/need to change the defaults anyway, right? In that case I think something settable via ldflags is preferable over downstream having to ship patched versions..

@discordianfish That argument can be applied to every other way we've been asked to support configuring these.

@brian-brazil That's right, the question is do we want to support configuring the defaults or not. If we don't, people who need to change this will patch Prometheus which I would say is worse.

It's their choice to patch, rather than adding a wrapper which is what everyone else seems to do.

@TheTincho Do you know what Debian is patching those things instead of using wrapper scripts (or just specify flags on startup)?

We do both:

Patching the source to set defaults for paths that match what is installed. This is useful for example if the user runs prometheus without the system wrapper.
Adding a wrapper to allow the user to change the defaults: paths and anything else.

Doesn't look like we'll be changing this.


chore: refactor onedal interaction with backend and policies

Description

Refactor how and where methods are loaded from backend.

All functions are now explicitly declared as @abstractmethod and then populated using a decorator loaded from _backend.py.
It is now explicit where the functionality comes from.
We can start using the functions with self.infer(...) rather than the convoluted self._get_backend("X", "Y", "infer" , ...).

All dependencies from standard compute functions (compute(), infer(), ...) on backend are unified in _backend.py.
Backend wrapper class around the backend export in onedal/__init__.py to reduce the use of global variables.
More wrapper classes BackendManager, PolicyManager, BackendFunction that simplify interfacing with pybind/C++ backend functionality.
I removed unused imports because there were so many in the files I touched. I didn't stop at the files I modified and did the entire repo, which messed up the diff a little. Sorry.

PR should start as a draft, then move to ready for review state after CI is passed and all applicable checkboxes are closed.
This approach ensures that reviewers don't spend extra time asking for regular requirements.
You can remove a checkbox as not applicable only if it doesn't relate to this PR in any way.
For example, PR with docs update doesn't require checkboxes for performance while PR with any change in actual code should have checkboxes and justify how this code change is expected to affect performance (or justification should be self-evident).
Checklist to comply with before moving PR from draft:
PR completeness and readability

[x] I have reviewed my changes thoroughly before submitting this pull request.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have updated the documentation to reflect the changes or created a separate PR with update and provided its number in the description, if necessary.
[x] Git commit message contains an appropriate signed-off-by string (see CONTRIBUTING.md for details).
[x] I have added a respective label(s) to PR if I have a permission for that.
[x] I have resolved any merge conflicts that might occur with the base branch.

Testing

[x] I have run it locally and tested the changes extensively.
[x] All CI jobs are green or I have provided justification why they aren't.
[x] I have extended testing suite if new functionality was introduced in this PR.

Performance

[ ] I have measured performance for affected algorithms using scikit-learn_bench and provided at least summary table with measured data, if performance change is expected.
[ ] I have provided justification why performance has changed or why changes are not expected.
[ ] I have provided justification why quality metrics have changed or why changes are not expected.
[ ] I have extended benchmarking suite and provided corresponding scikit-learn_bench PR if new measurable functionality was introduced in this PR.

i guess this contrasts the approach i wanted to take in #2158 . what i had not liked about _get_backend was the indirection it was inducing in accessing the pybind11 generated package, and hoped to bring native syntax back. maybe worth further discussion?

/intelci: run

/intelci: run

/intelci: run

Check PR Checklist / Close all checkboxes before moving from draft (pull_request)

Performance and accuracy are not affected

Reviewers, the performance regression in LogReg fit is reproducible and meaningful. I will investigate.

More checks required for SPMD changes, converting back to draft. But the non-SPMD contributions are still ready for review

/intelci: run

/intelci: run

Working on removing _get_policy() and cleaning up dependencies on SYCL queues

/intelci: run

/intelci: run


add a timestamp for gcc_bootstrap_ patching

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

This is a good change. I double-checked and the rest of the compiler related patches have timestamps already. LGTM!

Thanks. This should also fix issues in https://github.com/conda-forge/ctng-compilers-feedstock/pull/53


use with setTimeout not working

i use request to download a picture,it always works well util i use setTimeout, the problem looks like this
const request = require("request");
const fs = require("fs");
let wt1 = fs.createWriteStream("ge.jpg");
let url = "http://<IP_ADDRESS>:8888/test.jpg";
request(url).on('response', (res) => {
        setTimeout(() => {
            res.pipe(wt1);
        })
        // process.nextTick(() => {
        //     res.pipe(wt1);
        // })
        // setImmediate(() => {
        //     console.log("我将开始")
        //     res.pipe(wt1);
        // })
    })

as i try with the nextTick Func and setImmediate Func, only nextTick works。
i do not know the reason. can anyone explain it?

Try changing line 5 to this:
request(url).on('res', (res) => {

I'm sorry to reply so long ago. I use timeout to test whether it can work with asynchronous operation,such as  detecting whether the file exists or creating a new  file. it seems that with the nodejs native interface the asynchronous operation can work, but here not work.

Ok. If I understand you correctly, this issue can then be closed?

ok,thank you


enable_ssl to use_tls

Fixes #3357

interop tests are unhappy:
START: build
WAITING: 1 jobs running, 0 complete, 0 failed
PASSED: build [time=917.0sec]
START: large_unary
START: empty_unary
START: ping_pong
START: client_streaming
START: server_streaming
WAITING: 5 jobs running, 0 complete, 0 failed
ERROR: unknown command line flag 'use_tls'

I imagine it might be picking up some old docker image at some point, which is why we are working on revamping the interop tests.

Please update https://github.com/grpc/grpc/blob/master/src/objective-c/tests/run_tests.sh#L40 too.

Now that #3373  has been merged, can you pls try to rebase -i upstream/master and update the run_interop_tests.py script accordingly? After that the unknown command line flag problem should be gone.

Btw, the spec explicitly requires supporting --use_tls=true (and not just --use_tls), does that work for C++?

Tests seems to pass locally.


Reformat files using new script

I noticed that many of the data files were longer than 20 quotes or had different levels of indentation.  I made a script that fixes that and reformats the files, and ran it.

I have now also optimized the cover image.  This keeps the same resolution and detail, just reduces the file size.


HomeKit-like square object

Is it possible to have a square object like in HomeKit?
Similar to what you see on the right side on image below (Sofa left and Shapes):

duplicate of https://github.com/matt8707/ha-fusion/issues/28


Csse pyd2 warnings

Description

[x] add docs for v1/v2 conversion
[x] handle a lot of warnings

Changelog description

Status

[x] Code base linted
[x] Ready to go

Requesting review @davidbrownell, @krachwal, @rfievet, @ketanbj, @varun646, @jyoung3131


Breadcrumbs | Change Recommended breadcrumb to Reviewed |1|

https://trello.com/c/xCbhUjJU/659-breadcrumbs-change-recommended-breadcrumb-to-reviewed-1
Task:
Change the 'Recommended' breadcrumb on the Credit Transfer View screen to 'Reviewed' for all users. The breadcrumb should remain as Reviewed regardless of whether or not the Credit Transfer Proposal is Recommended or Not Recommended.
Demo:

Show that the breadcrumb says Reviewed
Show that the breadcrumb remains Reviewed when the Proposal is Recommended
Show that the breadcrumb remains Reviewed when the Proposal is Not Recommended

 Breadcrumbs | Change Recommended breadcrumb to Reviewed |1|

 Credit Transfer | Create Information text boxes for non-clickable Sign 1/2 and Sign 2/2 buttons |2|


Add new account managers to expojucier

Adem Özkara
<EMAIL_ADDRESS>+49 30 2555 9875

Marianna Bachanek
<EMAIL_ADDRESS>+49 30 2555 9875 (j.w - czekam za nowym numerem Zadarmy)

moved to the correct project (exhibitors)

I think that we can close this task as well @az @peterecommberlin

@klaudia2209 not yet....currently displaying AM in account.ecommerceberlin.com is hidden (in the development) and this issue is just about it...


Display when an app is utilizing google / apple technology

Related to #72

User story
As a [type of user], I would like to [achieve what goal].
Impact
Describe the impact this has on the product.
Background
Describe the pertinent information related to the feature, bug, story, etc.
Acceptance Criteria

[ ] Prototype mockup of how we would display whether or not it uses google / apple exposure notification framework (@JDBnhs )


[FLINK-20475][doc] Fix the broken links in gettingStarted.zh.md

What is the purpose of the change
This pull request will fix the broken links in gettingStarted.zh.md
Brief change log

Fix the broken links in gettingStarted.zh.md

Verifying this change

Executing the script build_docs.sh

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

@dianfu Could you help review it? Thanks.

This was my fault, thank you for fixing it @HuangXingBo!
Looks good, I'll go ahead and merge.

It seems someone already merged in a fix. I'll go ahead and close this. thank you again.


[BUG] Can't log in

Summary:
When logging in on my phone, I reach a blank screen and can't progress.
Steps to reproduce:
I signed in via Wikipedia, logged in to my account, clicked Allow, and then ended up at the screenshot below. If I close the app and re-open it, I'm prompted to log in again.
Device and Android version:
Huawei P10, EMUI 9.0.1 (Android 9)
Screen-shots:

Hi Sam, can you share the place from which you installed the app? Did you
installed it from Google Play store?
On Thu 5 Sep, 2019, 6:27 PM Sam Walton<EMAIL_ADDRESS>wrote:

Summary:
When logging in on my phone, I reach a blank screen and can't progress.
Steps to reproduce:
I signed in via Wikipedia, logged in to my account, clicked Allow, and
then ended up at the screenshot below.
Device and Android version:
Huawei P10, EMUI 9.0.1 (Android 9)
Screen-shots:
[image: Wiki Ed app]
https://user-images.githubusercontent.com/12038840/64343754-06335a80-cfe5-11e9-9643-f202809a483b.jpg
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/WikiEducationFoundation/apps-android-wikiedudashboard/issues/52?email_source=notifications&email_token=AEVTAAZZSOPQV3QYJQEQ4JDQID6Z3A5CNFSM4IT5QL32YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HJQYCIQ,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEVTAAYH7HWGXC3VYXE5NE3QID6Z3ANCNFSM4IT5QL3Q
.

Yes, the Google Play Store.

seems to be a device specific issue. I tried it in 2 different devices, seems to work fine. Will try to look into it soon.

Hi Ujjwal, I would like to work on this issue, Melissa

Hi @melissasny1 , are you able to reproduce the issue? If yes, feel free to start working on the issue.

Yes, I am able to reproduce the issue and will work on it.

Okay. I am assigning this issue to you then.

Hi.. I've had the same experience. I'm currently using an Asus smartphone.


update systemd bpf mount unit file to be more secure

How to reproduce the issue
The example systemd unit file found here: https://cilium.readthedocs.io/en/stable/kubernetes/configuration/#bpffs-systemd
resulted in (what I think) are pretty insecure permissions for the /sys/fs/bpf directory for me on a centos7 install (don't have it in front of me directly right now but it was essentially 777 with some tmp mode set).
I updated it to the following to lock it down a bit tighter:
[Unit]
Description=Cilium BPF mounts
Documentation=http://docs.cilium.io/
DefaultDependencies=no
Before=local-fs.target umount.target
After=swap.target

[Mount]
What=bpffs
Where=/sys/fs/bpf
Type=bpf
Options=rw,nosuid,nodev,noexec,relatime,mode=700

[Install]
WantedBy=multi-user.target

I don't know enough about bpf to say if it was truly dangerous but by the little that I do know of the nature of bpf I'd rather be safe than sorry :)

cc @borkmann

thanks for opening the issue @travisghansen!

@travisghansen, by default it's 777 that is correct, though everything Cilium related gets pinned with 600. From your above options, rw,nosuid,nodev,noexec,relatime,mode=700, it should really be rw,relatime,mode=700. BPF is a special file system and only allows BPF progs or maps to be pinned there, so no executables and such and thus these options do not apply. Could you send a patch updating to rw,relatime,mode=700 or do you prefer to to submit a PR? Thanks

Ok not sure where arch got those options... might be good to see what it is on centos8 or Ubuntu as well.
I will say the options above at least crudely work with cilium as that's what I used and initial testing shows files in the dir and traffic flowing at a basic level.

I may have misunderstood the context of the earlier comment as well. I'm less concerned about cilium rules as I am foreign stuff being created in the fs due to so permissive options.
Here's a fresh centos 8 install where support for bpf appears to be 'native' in some shape or form...notice the options are exactly the same as what I proposed as used by arch as well:
mount | grep bpf
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
[root@centos-8 ~]# ls -l /sys/fs/
total 0
drwx-----T.  2 root root   0 Mar 31 21:14 bpf
drwxr-xr-x. 14 root root 360 Mar 31 21:14 cgroup
drwxr-xr-x.  4 root root   0 Mar 31 21:25 ext4
drwxr-xr-x.  3 root root   0 Mar 31 21:15 fuse
drwxr-x---.  2 root root   0 Mar 31 21:14 pstore
drwxr-xr-x.  7 root root   0 Mar 31 21:14 selinux
drwxr-xr-x.  4 root root   0 Mar 31 21:25 xfs

I may have misunderstood the context of the earlier comment as well. I'm less concerned about cilium rules as I am foreign stuff being created in the fs due to so permissive options.
Here's a fresh centos 8 install where support for bpf appears to be 'native' in some shape or form...notice the options are exactly the same as what I proposed as used by arch as well:
mount | grep bpf
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)

Ok, fair enough, I presume newer systemd is auto-mounting in this case. bpffs only takes the mode into account (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/bpf/inode.c#n606), but having the rest doesn't hurt. Could you send a PR to update the Cilium Unit file? Thanks

For the record, on a quick grep I see at least three locations where we have this systemd snippet:
Documentation/kubernetes/configuration.rst
contrib/systemd/sys-fs-bpf.mount
install/kubernetes/cilium/charts/nodeinit/templates/daemonset.yaml

Yeah I assumed the same thing regarding newer versions of systemd auto-detecting and mounting.
I'm pretty strapped for time (and I'm pretty weak with go) ATM so probably best if someone else runs with this. Thanks!

Ok, no problem, I'll look into it.


Add custom  commands accessible from makejdk-any-platform

Add the command line --make-args, similar to --config-args but for make
Fix for #1283

/cc: @johnoliver, @gdams


[docs] Update Es6ClassMocks.md

Summary
Motivation is described in this issue: https://github.com/facebook/jest/issues/6065
basically, I think it is helpful to be explicit about the behavior of jest's automock on objects that have arrow functions on them.

Codecov Report

Merging #6083 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #6083      +/-   ##
==========================================
- Coverage   64.13%   64.12%   -0.02%
==========================================
  Files         217      217
  Lines        8335     8332       -3
  Branches        3        3
==========================================
- Hits         5346     5343       -3
  Misses       2988     2988
  Partials        1        1

Impacted Files
Coverage Δ

packages/jest-worker/src/index.js
86.25% <0%> (-0.34%)
:arrow_down:

packages/jest-worker/src/worker.js
98.27% <0%> (-0.03%)
:arrow_down:

Continue to review full report at Codecov.

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

Thanks!


Bar spacing is now dynamic at small sizes.

Closes #1468

I'm adding the same functionality for the time scale.  Don't merge yet.


New prior: (weakly) convex ridge regularizers

Add weakly convex regularizers
Checks to be done before submitting your PR

[x] python3 -m pytest tests/ runs successfully.
[x] black . runs successfully.
[x] make html runs successfully (in the docs/ directory).
[x] Updated docstrings related to the changes (as applicable).
[x] Added an entry to the CHANGELOG.rst.

The automatic loading of the weights does not work so far, since they don't exist in Huggingface. It is in the repo deepinv/saved_model/weights.pt Once they are in the huggingface, we delete them.


Example showcase

Hi @Dave136 ! Awesome job porting React-email to Vue! It looks good!
I think adding a Example page would really help devs to visually understand how to use it, and interested in using this package!
Cheers!

Thanks for your suggestion, I'll work with some real examples using the library

Absolutely beatiful @Dave136 !


Create a contribution documentation

As a developer I want to have a guideline to create a contribution ;)
Seriously would be nice to have such a thing to make it easier for everybody to contribute to this nice project.

Hey @Jumace!
Cool, that you are contributing to Alva. We are currently working on the contribution guide, so stay tuned!
Tilman

Looking forward to it :D


Possible order bug

Expected behavior
Each line (and bar) should represent their values on their respective y axis
Current behavior
One of the line charts acts weird (the blue one - "data2"), it seems like its not bound to any axis, but rather follows the shape of the one underneath it, regardless of its own value
Reproducible sample
https://codepen.io/szezs97/pen/ExozePY
Optional extra steps/info to reproduce
No response
Possible solution
Altough I did resolve this by changing the order (the solution is that data2's order must be lower than data3's), I don't think that this is the expected behaviour; I guess order should be independent from everything but the other orders, so I tought I might share this with you. The CodePen example might contain a bit more information than needed; but I wanted to share it as it is, just in case it's useful
Context
No response
chart.js version
v3.7.1
Browser name and version
No response
Link to your project
No response

It is working as designed. The order property behavious like a weight as described here so the higher the number the sooner its drawn  on the canvas and since your axis is stacked and the blue line consisits of only the same number it will follow the yellow line with the offset that is the number in your data

My bad, I missed that I set the y axis as stacked. Thank you for your quick reply :)