Correct Level 8 metadata length

It seems level 8 metadata can have a variable length, thus it can contain more trim controls.
Example:
  |  Extension block 8, Level 8, Length 13
     | target_display_index 1
     | trim_slope           2036
     | trim_offset          2060
     | trim_power           1987
     | trim_chroma_weight   2048
     | trim_saturation_gain 1985
     | ms_weight            2048
     | target_mid_contrast 2048
     | clip_trim 2011

Wouldn't be surprised if the 6-color trims for saturation/hue can also be in there.

I have an imcomplete impl for variable blocks, and other things, it's in my fork now, could you take a look?

Looks like a lot of changes.
I started fixing L8 but your approach is probably more complete.
I'll have a deeper look later.

For now there are 3 variable blocks (L8 / L9 / L10), the L8 is the most complicated one, so I wrote some new functions about detecting length for these blocks, and keep the other code unchanged. Also the xml version is a number now. Parsing L11 and L254 is still incomplete. I'm not sure should I keep the L10 generation from json available with using the default_metadata_blocks or use new syntax for it.

Your required_bits logic looks pretty complicated.
I'd rather store the block length and with that assume what fields were parsed and should be written.
It does increase the complexity for the end user and generate, but it already requires understanding the block structures.

I see, that makes sense, so should I remove that parts and follow your style (to add a length struct, etc) and make a PR of these blocks, or let you do it?

I'm pulling your changes and adjusting right now, will keep you as co-author.

Thanks. Since there is no ext block with id 0 (just so-called L0 metadata), I changed the reserved block id to 0 because I found that L255 does exist, maybe for DM debugging (fields are similar to L254), although I think it will not appear in official contents. Should we add it later?

Reserved blocks automatically fail the parsing anyways, so it doesn't really matter.
The idea is to be able to support all possible blocks, and implement new ones when they're found.
Have you tried writing a level 255 block and get it recognized by the verifier?

It seems level 8 metadata can have a variable length, thus it can contain more trim controls. Example:
  |  Extension block 8, Level 8, Length 13
     | target_display_index 1
     | trim_slope           2036
     | trim_offset          2060
     | trim_power           1987
     | trim_chroma_weight   2048
     | trim_saturation_gain 1985
     | ms_weight            2048
     | target_mid_contrast 2048
     | clip_trim 2011

Wouldn't be surprised if the 6-color trims for saturation/hue can also be in there.

What does this mean exactly?
You mean level 8 metadata might contain more information than is currently being processed?
In this case, then is it possible that some of the RPU metadata was lost when processed with current versions of dovi_tool?

In this case, then is it possible that some of the RPU metadata was lost when processed with current versions of dovi_tool?

No, otherwise the parsing would have errored.

In this case, then is it possible that some of the RPU metadata was lost when processed with current versions of dovi_tool?

No, otherwise the parsing would have errored.

Okay, so if dovi_tool has not shown errors it means that everything is fine, correct?
That is, if the situation that you mention occurs, dovi_tool would show an error instead of losing that part of the metadata, correct?

Yes that's correct.
The reason I've noticed a problem is because someone got an error on a recent UHD disc and could provide the sample RPU.
For example in 1.4.3, when using mode=0 the extraction would fail with this:

Error: CM v4.0: Invalid metadata block. Block level 8 should have length 10

For example in 1.4.3, when using mode=0 the extraction would fail with this:

Error: CM v4.0: Invalid metadata block. Block level 8 should have length 10

I usually use mode 3 (to inject RPU WEB-DL in UHD), and I also use the editor to adjust the RPU (without specifying mode).
In these 2 cases would the result also be the same? (that error would be displayed and nothing from the metadata would ever be lost)

In these 2 cases would the result also be the same?

Yes.

In these 2 cases would the result also be the same?

Yes.

Ok, thanks for all your help as always!

AFAICT the 6-color trims go there too, but I don't know what format they're specified in.  I'd assume each TID gets an array of 6 trims.
I've yet to see a V4 disc IRL though, and something seems bizarre about specifying a display with custom primaries as a target in the consumer versions since all consumer UHD devices that support DolbyVision also support one of the standard color spaces...   unless one of those manufacturers of $50k multi-color laser projector with required $20k cooling systems has decided to start producing a DolbyVision add-on streaming box ($30k + $5k for required special toroidal power supply for the streaming box and paid Dolby some of the $95k in profit they're making on each sale to add it in for them so they can produce a super-impressive looking demo that matches something or another with the laser primaries (and which will never be included in any other video, from them or otherwise).
Then again, I'm not entirely sure how all of that data gets applied.   I found at least one thing that said only two L2 targets are allowed / processed, and most commercial disks seem to have either BT.709/100 nit-only (and once again I lose the plot on why sRGB trims are included unless some severely terrible 4k screens somehow got DV certification)  or that and either the 600 D65 or an unknown colorspace (not sure since TIDs aren't shown) 1000 nit target that's probably P3 because let's face it, nobody is going to include target trims for BT.2020...   I found one website that mentioned something about TID 48 being P3 D65 and TID 49 being BT.2020, both @ 1000 nit though.


content

Grilled Salmon with Chipotle Cream Sauce
over Potato Poblano Hash and Broccolini
Korean Barbecue Beef with Sesame Rice Noodles
and Spicy Pickled Cucumbers and Carrots
Saucy Grilled Shrimp
and a Corn and Radish Salad with Avocado Dressing
Pork Schnitzel
with German Spaetzle and Green Beans
Chipotle Cream Skillet Chicken
over Rice and Snap Peas
Bahn Mi Meatball Skewers

file: src/display/displayContent.js

https://user-images.githubusercontent.com/1469198/180643766-f7c92d92-161e-445c-8e70-ed175829c11b.mp4

cc @Olgalex


add Controller() method to Client interface

Sometimes we need to know the controller broker of a kafka cluster to do something, such as creating or deleting topics.

um. The unit test issue is not introduced by this  PR.

OK. I fixed all issues and added an unit test.

@eapache  any update on when this pull request will be merged ,  that would unblock the ClusterAdmin pull request.

Thanks for your review!
I have fixed the spelling and logging issue. Sorry for that :(

Thanks!


Curl requests not working

Hi there,
I had a question regarding working with the API Server from the instructions here.
I am running this after running the docker command
Pull the Docker image with CUDA 11.8.
docker run --gpus all -it --rm --shm-size=8g nvcr.io/nvidia/pytorch:22.12-py3
and running these commands within the workspace
pip uninstall torch
pip install vllm

When running the default command python -m vllm.entrypoints.api_server, the server doesn't connect, returning
INFO:     Started server process [3820]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
ERROR:    [Errno 99] error while attempting to bind on address ('::1', 8000, 0, 0): cannot assign requested address
INFO:     Waiting for application shutdown.
INFO:     Application shutdown complete.
I try different ports and it still doesn't work.
However, when I try a different host like <IP_ADDRESS> for instance through the --host parameter, it connects to the server and runs on Uvicorn but I am unable to curl requests to this server.
I try to do this by opening a 2nd terminal, running the docker image and the rest of the commands above again and then trying to run both of these curl requests but both are unable to connect returning: curl: (7) Failed to connect to <IP_ADDRESS> port 8000: Connection refused. I also tried them outside of the workspace and the requests still fail.
curl -X POST http://<IP_ADDRESS>:8000/generate   -H "Content-Type: application/json"   -d '{     "prompt": "San Francisco is a",     "use_beam_search": true,     "n": 4,     "temperature": 0   }'
and
curl -X POST http://localhost:8000/generate   -H "Content-Type: application/json"   -d '{
"prompt": "San Francisco is a",
"use_beam_search": true,
"n": 4,
"temperature": 0
}'
This also applies to the OpenAI server, so it would be great to receive some support on this to send requests to the server. Appreciate the help!

This looks like a docker port exporting issue. Can you check whether you exposed port 8000 of your docker to your host? Reference. Or can you try to run curl within the docker?

Hi,
Thanks for your response. Yeah so port 8000 was exposed and I tried running the curl commands with the docker but it still was not able to find the host.
I'm wondering if this command python -m vllm.entrypoints.api_server is working as expected as it was not for me.
Thanks!

Hi,
This worked for me:
python -m vllm.entrypoints.api_server --host <IP_ADDRESS> --port 8000
And when you run the image, add the port as well:
docker run --gpus all -it --rm -p 8000:8000 --shm-size=8g nvcr.io/nvidia/pytorch:22.12-py3

Hi Carlos,
Thanks for the help! I was able to connect to the server. However, I noticed that despite setting --gpus all, when I ran nvidia-smi on another terminal, it wasn't using all the gpus. is there another arg to pass in for ensuring the models on the vllm server use all gpus?

Glad it helped. Sorry, I only have 1 GPU, so I cannot run that test.

Close this issue since it's a docker issue instead of a vLLM issue. Feel free to re-open if there any further issues.


Forecast field in ConcreteSystem should be indexed with integers

When the forecasts are generated and parsed into System or Concrete System the keys in the dictionary are :DA or :RTS, defined from a
const SystemForecasts = Dict{Symbol, Forecasts}
However, this would generate a System with forecasts that use two different time-scales. I propose we use
const SystemForecasts = Dict{Int64, Forecasts}
Where every entry in the SystemForecasts Dict corresponds to a consistent collection of forecasting time series with the same resolution and initialtime fields that later can be lopped over.
Moreover, there no reason to make :DA the default type of forecast.

This will be fixed by PR #233.  However, the solution will be different that what is described here.  Forecast will be stored in the System like this:
const Forecasts = Vector{<:Forecast}
const IssueTime = NamedTuple{(:resolution, :initialtime),
Tuple{Dates.Period, Dates.DateTime}}
const SystemForecasts = Dict{IssueTime, Forecasts}

fixed via #233


Design COVID-19 Icons

Problem
The COVID-19 response requires unique recurring cases, and needs icons for these cases
Solution
Please design icons for the following concepts:

Meal (Bowl, sandwich?)
Wellness Check (includes emotional wellness, as well as medical)
Prescription Pickup (pill, "Rx" bag)
Shopping (Shopping cart)
Oxygen (Oxygen tank, oxygen mask)
Water Bottles

Additional context and instructions
Add any other context or screenshots about the feature request here.

Approved and implemented.


Apparent typo in nvim-dev-container url

Hi, as a diehard doom (and emacs) lover this project looks really promising given neovim's current superior support (IMO) for stuff like DAP and multi-language files with tree-sitter (web-mode is a horrible horrible hack that should and will hopefully die when emacs 29 comes out with built-in tree-sitter support but I digress).
When running nyoom sync for the first time it asked me for credentials for codeberg, which I think might be because of this typo:
https://github.com/nyoom-engineering/nyoom.nvim/blob/b3423c22445f86188db5ccd966d94eb722a8df0b/fnl/modules/tools/docker/init.fnl#L3
s/containe/container, no?

Yup, thanks and fixed


Packaging this dataset

Hi, thanks for contributing this dataset as open source. Motivated by "Understanding Deep Learning", I'd love to start playing with it.
I saw that the repo is not ready for packaging. As the code is rather straight forward, I was wondering if any PRs would be appreciated to package this as a python module.
This would also make it more easier to use more broadly than by using the requests package. People could just go: pip install mnist1d and have the code for augmenting and changing under their fingers. Just a thought!
Right now, I get the following:
python -m pip install git+https://github.com/greydanus/mnist1d.git@master

Collecting git+https://github.com/greydanus/mnist1d.git@master
  Cloning https://github.com/greydanus/mnist1d.git (to revision master) to /tmp/pip-req-build-eg1a_6cu
  Running command git clone --filter=blob:none --quiet https://github.com/greydanus/mnist1d.git /tmp/pip-req-build-eg1a_6cu
  Resolved https://github.com/greydanus/mnist1d.git to commit 39dd6c03785eefe60f349af94e61f864fc449644
ERROR: git+https://github.com/greydanus/mnist1d.git@master does not appear to be a Python project: neither 'setup.py' nor 'pyproject.toml' found.

Peter, this is a great suggestion. I haven never packaged a library before - can you help me set this up? I'm all ears.


Instructions to build Docker image for AWS EFS ?

The Dockerfile here is as follows
FROM alpine:3.6
RUN apk update --no-cache && apk add ca-certificates
COPY efs-provisioner /
ENTRYPOINT ["/efs-provisioner"]

Seems like it's unclear where to run this from. When does the efs-provisioner.go file even run ?
I am building a custom docker image to support custom domains for the EFS instead of hardcoded aws assigned domain names for EFS.

Please see the makefile: https://github.com/kubernetes-incubator/external-storage/blob/master/aws/efs/Makefile
We go build ./cmd/efs-provisioner and then copy the result efs-provisioner into the container root
Btw, patches to allow custom domains are welcome...a lot of people have been asking

Perhaps it would be easier to make use of a multi-stage build file, so building the image doesn't rely on having Go installed and in a specific version?

yes, although multi-stage would be a lot less complicated, so I will leave this issue open to track getting that done. Also, @bholagabbar-mt , re: the root issue here, support for a custom dns.name/DNS_NAME was added so that you don't have to use hardcoded aws assigned domain names.

Great! Yeah, the custom DNS is much needed. The ‘AWS assigned domain name resolution’ option was switched off in my VPC because of which the EFS DNS couldn’t be resolved. I ended up switching to the IP address but ran into another problem.
Finally ended up enabling the option (hoping it wouldn’t break anything, which it did not) and then used the AWS assigned DNS for the EFS file system as normal.
With custom DNS support, I could have assigned the IP addresses of the EFS to a custom domain in my route53 and life would’ve been easier then, but I guess it’s sorted for now!

On 19-Dec-2018, at 10:13 PM, Matthew Wong<EMAIL_ADDRESS>wrote:
yes, although multi-stage would be a lot less complicated, so I will leave this issue open to track getting that done. Also, @bholagabbar-mt https://github.com/bholagabbar-mt , re: the root issue here, support for a custom dns.name/DNS_NAME was added so that you don't have to use hardcoded aws assigned domain names.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/kubernetes-incubator/external-storage/issues/1043#issuecomment-448662882, or mute the thread https://github.com/notifications/unsubscribe-auth/AmDOoc4wwX5FU4NQKkae97JcDjtdTMuNks5u6mzFgaJpZM4YF__y.

I had a go at changing the Dockerfile to be a multi stage one in https://github.com/kubernetes-incubator/external-storage/pull/1088.


Collapsed code shows misc characters

Type: Bug
When using the down arrow to collapse nestings of code, odd characters appear at the end of line.
To repro, take any indented chunk of code and collapse it, the same charactes will always appear at EOL. Images attached.
Only occurs when running inside OSS, cannot repro in stable or insiders.

 We suspect it's related to the dev tools being open. Did you have the dev tools open?
Duplicate of https://github.com/microsoft/vscode/issues/145897

Yep, I was using the dev tools. I did notice that I couldn't repro on OSS a couple minutes later, I might've closed dev tools by then. Let me see about using dev tools and seeing if it happens again


release: use a consistent naming across release artifacts

Sounds good; where you able to test it?

Yep, an experimental release is temporarily available on my fork.


DS-2872 Speed up builds; drop unnecessary repos

https://jira.duraspace.org/browse/DS-2872
To test this, move your current ~/.m2 aside temporarily, then initiate a full DSpace build. Notice how all necessary dependencies are loaded correctly.
I tested with and without this change, and a fresh build with a clean local .m2 dir took 7min 16sec without, and 5min 18sec with. Mainly because it didn't have to hammer on sonatype oss and the restlet repo before checking central for most dependencies.

I can confirm that this PR builds just fine, and does shave a bit off the full source build time. Half of my build time (3 minutes of 6 minutes total) is spent in building Mirage2, which has it's own exuberant dependency management (see DS-2643, among others). But build time alone is not the only concern here, dropping the un-needed repos is a solid change. +1

+1, I ran multiple builds on a PC. It reduced the build times from ~16 minutes (when did we get this high?) to ~10 minutes.

+1 makes perfect sense.  The Sonatype repo. was in there due to long delays in promotion to Central which, I'm told, have greatly improved.

A few notes on why the Sonatype Releases Repository was added into our POMs.
In the past, we had experiences where after cutting a new release, it'd take anywhere from 4-8 hours for that release to show up in Maven Central. It delayed our ability to do anything with the release itself (e.g. install it on demo.dspace.org, announce it, even just test it). Since the release appears immediately in the Sonatype Releases Repository, we could use it immediately without having to wait until it appeared in Maven Central.
However, these days, it seems like the process is much quicker. From my recent experiences, it seems like new releases now show up in Maven Central within an hour.
If we ever notice major delays in getting our releases to Maven Central, we may want to add the Sonatype Release Repository back in. However, at this time, it seems OK to accept this PR.
+1


Centered Manifesto section below header

Description
Centered Manifesto section below header. If you see in the current version of the site, there is a difference in space from left and right side, which is making that section unappealing to eyes
Fixes # (issue)
Type of change

[ ] New feature (non-breaking change which adds functionality)

How Has This Been Tested?
-> This can be tested by visiting the manifesto section
Additional Context (Please include any Screenshots/gifs if relevant)
 The section below the header was not centered. In this pull request, I have centered that section.
There is a difference in space from the left and right side.

After change:

...
Checklist:

[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.

We already had an issue that raised the same problem. Please avoid raising duplicate PRs.


Install command "rails generate react_on_rails:install --help" is hung.

Whenever I try and run the command, I always get hung. When I ctrl-c I get the following:
/Users/ernestlandrito/.rvm/gems/ruby-2.2.1/gems/spring-1.6.4/lib/spring/client/run.rb:98:ingets': Interrupt
from /Users/ernestlandrito/.rvm/gems/ruby-2.2.1/gems/spring-1.6.4/lib/spring/client/run.rb:98:in verify_server_version'     from /Users/ernestlandrito/.rvm/gems/ruby-2.2.1/gems/spring-1.6.4/lib/spring/client/run.rb:56:inrun'
from /Users/ernestlandrito/.rvm/gems/ruby-2.2.1/gems/spring-1.6.4/lib/spring/client/run.rb:37:in warm_run'     from /Users/ernestlandrito/.rvm/gems/ruby-2.2.1/gems/spring-1.6.4/lib/spring/client/run.rb:26:incall'
from /Users/ernestlandrito/.rvm/gems/ruby-2.2.1/gems/spring-1.6.4/lib/spring/client/command.rb:7:in call'     from /Users/ernestlandrito/.rvm/gems/ruby-2.2.1/gems/spring-1.6.4/lib/spring/client/rails.rb:24:incall'
from /Users/ernestlandrito/.rvm/gems/ruby-2.2.1/gems/spring-1.6.4/lib/spring/client/command.rb:7:in call'     from /Users/ernestlandrito/.rvm/gems/ruby-2.2.1/gems/spring-1.6.4/lib/spring/client.rb:28:inrun'
from /Users/ernestlandrito/.rvm/gems/ruby-2.2.1/gems/spring-1.6.4/bin/spring:49:in <top (required)>'     from /Users/ernestlandrito/.rvm/gems/ruby-2.2.1/gems/spring-1.6.4/lib/spring/binstub.rb:11:inload'
from /Users/ernestlandrito/.rvm/gems/ruby-2.2.1/gems/spring-1.6.4/lib/spring/binstub.rb:11:in <top (required)>'     from /Users/ernestlandrito/Documents/com/Landrito/bin/spring:13:inrequire'
from /Users/ernestlandrito/Documents/com/Landrito/bin/spring:13:in <top (required)>'     from bin/rails:3:inload'
from bin/rails:3:in <main>'

spring stop might work


Engine should restart and block more restarts

Describe your changes
Block rapid restarts in succession for 3s.
Issue ticket number and link
Possible fix for #2196 #2011
Checklist

[x] Is it a bug fix
[ ] Is a typo/documentation fix
[ ] Is a feature enhancement
[ ] It is a refactor
[ ] Created tests that fail without the change (if possible)
[ ] Extended the README / documentation, if necessary

What problem is this solving? Would increasing the timeout suffice?

What problem is this solving? Would increasing the timeout suffice?

Increasing the timeout might. The only difference between your approach and this approach is that engine restart is initiate and then blocked, meanwhile the current code base waits to restart. Either way as long as utun100 resource busy is no longer happening this can be closed
We should wait until @christian-schlichtherle or @fadyHemaya have responded to the issues to confirm 28.5+ and the current code base doesn't result in utun100 resource busy.

What problem is this solving? Would increasing the timeout suffice?

The only difference between your approach and this approach is that engine restart is initiate and then blocked, meanwhile the current code base waits to restart.

We need to pick up the latest network state (routes), that's why we cannot just ignore changes for X seconds.
If we miss the latest change in a row of route changes we might set up routes pointing to the wrong thing and netbird might be broken. I don't might increasing the timeout, though.

Good point, thank you for the clarification
Get Outlook for iOShttps://aka.ms/o0ukef

From: Viktor Liu @.>
Sent: Friday, August 9, 2024 11:01:35 AM
To: netbirdio/netbird @.>
Cc: Carlos Hernandez @.>; Author @.>
Subject: Re: [netbirdio/netbird] Engine should restart and block more restarts (PR #2406)
What problem is this solving? Would increasing the timeout suffice?
The only difference between your approach and this approach is that engine restart is initiate and then blocked, meanwhile the current code base waits to restart.
We need to pick up the latest network state (routes), that's why we cannot just ignore changes for X seconds.
If we miss the latest change in a row of route changes we might set up routes pointing to the wrong thing and netbird might be broken. I don't might increasing the timeout, though.
—
Reply to this email directly, view it on GitHubhttps://github.com/netbirdio/netbird/pull/2406#issuecomment-2278370316, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABMJBTJ3PYG62BU5FVPPNVDZQTYW7AVCNFSM6AAAAABMEURTTOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZYGM3TAMZRGY.
You are receiving this because you authored the thread.Message ID: @.***>


Add support to SSH Config and sudo mode

Hello Michael,
First of all, I would like to thank you for pushing online this very nice tool.
I like its simplicity, and immediately found a daily usage in it.
I quickly realized I was missing few features (mostly related to my own development environment):

Ability to connect using an SSH Config entry (in such case, no password is required when a private key is used).
If the user used to SSH connect is not member of the group docker, but is a sudoers, then running the Docker command prefixed with sudo is required.

I added support to both features, which involved a bit of refactoring.
I allowed myself to increase the version number (but it is in a separate commit, so it can be easily reversed).
I hope the coding style used matches your own standards.
Best regards.
Michel

I realize I only increased the version number in the __init__.py file, but I forgot to do so in the file pyproject.toml.

Hi @michelcaradec Thank you. Quick glance this looks great. Let me dig into it a bit when I'm at my desk and I'll get it merged.

This looks good, thank you @michelcaradec. I'd like to update the --ssh-config help message. How does this look?
help='Pass this flag to treat the host as a ssh config entry (e.g. {username}@{host})'

This looks good, thank you @michelcaradec. I'd like to update the --ssh-config help message. How does this look?
help='Pass this flag to treat the host as a ssh config entry (e.g. {username}@{host})'

Oh yes, this is much better than my original explanation, which was more like a docstring thing. :-)
Thank you.


Wordnet via SQLite

Are you aware that wordnet is readily available in various database formats? ( http://wnsql.sourceforge.net/ ) Sqlite seems an idea one for this application, and may make the job much easier. Would you be open to a pull request that replaces the current implementation with an sqlite-based one?

Russell

think we're going to stick with the file based implementation for now so im going to close this.


integer overflow in stoui64.hpp row 68

The following test:
   "integer overflow in stoui64.hpp:68"_test = [] {
      std::string buffer{R"({"arr":[e5555511116]})"};
      my_struct value{};
      glz::context ctx{};
      [[maybe_unused]] const auto ec = glz::read<glz::opts{.force_conformance = false}>(value, buffer, ctx);
   };

causes an integer overflow in https://github.com/stephenberry/glaze/blob/d7bb0069053ba2b77b3e5bcec48cc6109331316b/include/glaze/util/stoui64.hpp#L68
This is the error message:

/home/paul/code/glaze/include/glaze/util/stoui64.hpp:68:22: runtime error: signed integer overflow: 10 * 555551111 cannot be represented in type 'int'

Test added and fixed in #379


[nri-infrastructure] Modify the helm chart to support the new architecture

Arch changed, we would need a daemonset and two deployments. Moreover the processed are long-running and sending data to a sidecar
Take care of reducing breaking changes, in case are 100% needed document those. Moreover:

[ ] Provide a document explaining how to perform the migration if it is too complex.
[ ] modify requested memory and CPU advising customer in docs to notice the improvement
[ ] Provide a way to modify the scraping interval
This configuration was requested multiple times, we could expose easily a parameter to manage that varning that cluster explorer experience might break

We should provide -if possible- a way to map the old config to the new one easily.
Old config should take precedence over the default values of the new one:
@alvarocabanas tentative in https://github.com/newrelic/nri-kubernetes/pull/267

{{- define "newrelic.deprecatedKubeStateMetrics" -}}
ksm:
  discovery:
      scheme: {{  $.Values.kubeStateMetricsScheme | quote }}
      port: {{  $.Values.kubeStateMetricsPort | quote }}
      static:
        url: {{  $.Values.kubeStateMetricsUrl | quote }}
      endpoints:
          label_selector: {{  $.Values.kubeStateMetricsPodLabel | quote }}
          namespace: {{  $.Values.kubeStateMetricsNamespace | quote }}
{{- end -}}

{{- define "config" -}}
{{ toYaml (merge (include "newrelic.deprecatedKubeStateMetrics" . | fromYaml) .Values.config) }}
{{- end }}

With the preceding solution if, for example,  $.Values.kubeStateMetricsScheme is empty, will be set as "" and the one from the .Values.config will be the one taken into account.
The only problem is understanding if the user really wants all and new values mixed, so we will have to discuss it further to understand which way we want to go.

I do not like in the current proposal how the current config of the scraper is shared among all components. How someone would be able to change any shared config as the interval?
Moreover, since the config is shared now the ksm.enabled/kubelet.enable/... config is shared as well and therefore we need to do this weird workaround. Discussing with @acabanas a solution would be to add commands through args. But I would still prefer to split the three configs for each component having in the values instead of scraperConfig:
ksmConfig:
  interval: 15s
  verbose: true
  timeout: 30s
  enabled: true

controlPlaneConfig:
  enabled: true
  interval: 15s
  verbose: true
  timeout: 30s
  apiServer:
    staticEndpoint:
      url: "https://localhost:8443"
  scheduler:
    staticEndpoint:
      url: "https://localhost:10259"
  controllerManager:
    staticEndpoint:
      url: "https://localhost:10257"
...

Yes, on my opinion, one thing is the configuration file and another is the execution mode of the binary.
The config file is common (it can have anyway split sections as Paolo suggests), but the binary should be executed with an argument, like :
nri-kubernetes kubelet
nri-kubernetes control-plane
or whatever, and then the code will be the one discarding what is not for that config, instead of having to set env vars to disable each one, because we don't want an execution doing more than one of the tasks.
This argument would not be handled by Viper but just with the standard library flag or whatever and is defined in an enum matching the config section.

Closed as per https://github.com/newrelic/helm-charts/pull/624
Killer job everyone!


[HUDI-8498] Fix the async compaction task configuration error in CompactOperator

Change Logs
In the CompactOperator, the Async Compaction configuration was mistakenly used for executing Compaction Task configurations, resulting in Compaction Tasks only being executed asynchronously when using Async Compaction.
Impact
none
Risk level (write none, low medium or high below)
none
Documentation Update
none
Contributor's checklist

[x] Read through contributor's guide
[x] Change Logs and Impact were stated clearly
[x] Adequate tests were added if applicable
[x] CI passed

@danny0405 hello, Danny. Could you please help review this?

Background of Flink Compaction
Inline Compaction: Will block writing, sequentially execute Write and Compaction.
Async Compaction: Will not block writing, and not block the checkpoint by executing in thread pool
Why is this PR no longer needed?
This PR implements async compaction + blocking checkpoint (executed in a single thread). In real-world scenarios, users won't use it this way; its only purpose is for CI testing. CC @danny0405 @voonhous


Extended graph_op IRGen to support calling C APIs directly.

In this PR, we call the TF C API TFE_RunConstOp() instead of the previous
compiler runtime entry point @_silgen_name("_swift_tfc_RunEagerConstTest"), and
then call compiler runtime entry point
@_silgen_name("_swift_tfc_CreateFloatTensorHandleFromCTensorHandle")to wrap it
into a TensorHandle.
The main changes are:

To create an llvm::Function object based on a function name such as
"_swift_tfc_GetGlobalEagerContext", we first call silModule.findFunction() to
get the SILFunction, and then call IGM.getAddrOfSILFunction() to get the
llvm::Function.

To make this work, we fixed a bug in SILDeserializer::readSILFunctionChecked(),
which pervious a function decl (not body) from being deserialized in the IRGen stage.

We obtain from llvm::Function objects the LLVM type objects for C data types
TFE_Context* and TFE_TensorHandle*, and then generate bitcast instructions to
put the function params into the right types, before issuing the relevant
function call.

Next steps:

Replace the TFE_RunConstOp() call with a sequence of TF eager C API calls.
Generalize the graph_op decoding logic to handle graph_op's other than
Const.
Support generic tf datatype T instead of the hard-coded Float.
Figure out a way to call do scalar promotion even in the case of -Onone,
since Tensor(1.0) becomes a pseudo graph_op "tfc.scalarToTensor", which
gets should be turn into a "Const" graph_op.

@swift-ci please test tensorflow

From PR description:

which pervious a function decl

Did you mean "prevents"?

Correct "pervious" to "prevents". Thanks.


libpango-1.0.so.0: undefined symbol: hb_ot_layout_get_horizontal_baseline_tag_for_script

I recently updated Gaphor to build an AppImage of with GTK4 and libadwaita at https://github.com/gaphor/gaphor/pull/1857. I built GTK from source using JHBuild.
Using the default excludeslist, I was getting a libpango-1.0.so.0: undefined symbol: hb_ot_layout_get_horizontal_baseline_tag_for_script error when launching Gaphor using the AppImage.
Removing libharfbuzz.so.0 from excludes list fixes the issue.
The AppImage is built using Ubuntu 18.04 docker image which comes with HarfBuzz 1.7.6, Pango requires HarfBuzz >= 2.6.0. When building an app with the latest Pango for GTK4, it looks like it depends on this newer version of HarfBuzz and should be removed from the excludelist.

Can your application be built on Ubuntu bionic?

Hi @probonopd, yes, it is being built with Bionic and works great with the HarfBuzz library packaged.

Thanks for confirming. I am a bit hesitant to make this change because I remember this as a problematic library to be privately bundled. Possbly the issues arise when HarfBuzz is "too new" in the system; need to do more testing.
Anyway, thanks for letting me know! Let's keep this open for a while for others to comment. @TheAssassin wdyt?

In addition to the Bionic docker image, we also tested the AppImage with Ubuntu 20.04, Fedora 35, and OpenSUSE Tumbleweed. :+1:

This wasn't merged in a timely manner, so I am going to go ahead and close this.

So I am deploying on Ubuntu 20.04 and running on 22.04 and the missing libharfbuzz causes this issue.
Can we update the excludelist to remove libharfbuzz or is there any reason why we should keep it?

The solution is rather to add libpango, isn't it? libharfbuzz causes issues with other libraries, too.

Also seems like a possible solution.
In that case,
libpango-1.0.so.0
libpangoft2-1.0.so.0

have to be added to the excludelist.
libpangocairo-1.0.so.0

seems to not cause trouble and can be deployed.
But removing pango might mean it will not run on an older system if the software requires newer pango.

I improved the excludelist formatting and put all information about GLib and libraries that are (not) bundled due to it being bundled in one block in #555. As libpango needs to be bundled because we bundle GLib, I don't see how this can be resolved (at least not without reopening other issues).
However, to gather all information about it in one place, I added this problem as a note to this block.
On the bright side, Ubuntu 18 is no longer supported, so hopefully this issue will eventually stop being relevant.

Looks like we arrived at the conclusion that Glib/Gdk/Gtk/Pango/Cairo from the operating system usually can't be used and the whole stack of these and other closely related (e.g., libhai and possibly harfbuzz) libraries all need to be privately bundled.
An interesting question is what happens if you try to run such an application on an operating system that natively comes with a newer version than what we privately bundle with the application.


Batch script

I'm trying to cron an elisp script that will run elfeed-update periodically. Right now it looks like this:
#!/usr/local/bin/emacs --script

(package-initialize)

(elfeed-org)
(elfeed-update)

But it exits almost immediately with only the following output:
ad-handle-definition: `ido-completing-read' got redefined
elfeed-org is set up to handle elfeed configuration.

I'm guessing that maybe because of the way that elfeed calls out to external processes, it is not possible to write a batch script. Is this the case?

I don't know what would cause an error with ido-completing-read, since
neither elfeed nor elfeed-org do anything with ido. Perhaps it has
something to do with your config?
That said, this probably wouldn't work like you expect anyway. If Emacs
is already open, it won't update the index within Emacs, and Emacs would
clobber whatever updates you did when closed. When Elfeed loads, it
reads the index into memory and operates entirely from there. When it
saves, it just dumps an s-expression of the index to the filesystem.
I did spend some time investigating the possibility of using
write-region and insert-file-contents to behave more like a shared-file
database. However, I determined this would be far too slow (in pure
Elisp), incredibly complex, and not portable. It would only be
reasonable to do this through an external program (e.g. like notmuch),
but I don't really want to maintain something like that just for Elfeed.
I made EmacSQL to fill this role, but I don't think it's worth the
overhead. My own Elfeed index currently has over 30,000 entries with a
very small performance impact, so a heavier solution hasn't been needed.


Fix HEADERS_RECEIVED const typo

AWS SDK fail due to HEADERS_RECEIVED cont typo in polyfill

Thanks for your PR. We don't accept PR's, we would be rather fixing this issue with our next release.


feat(amazonaurora): merge amazon aurora vector stores

Fixes #373, #695
Features of this PR:

AmazonAuroraDefaultVector is removed to simplify the construct consumption.
fromExistingAuroraVectorStore() method is added inside AmazonAuroraVectorStore to allow usage of existing Amazon Aurora database.
Fixed pgvector issue from #695 by substituting pgvector Python module for pg8000 (necessary for Python PostgreSQL connection implementation)
Created additional foundationmodel and moved models.ts outside of bedrock construct to remove potential circular dependencies. This has given a few issues in the past and would be beneficial to have a standalone module for future additions to Knowledge Base sources.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.

Closed due to yarn.lock issues. Updated in PR #724


Add OWNERS.md file

Summary
It's good practice to have an OWNERS.md file for others to easily spot who's part of the project.

@tobru can this be merged? Or do you want to wait until all the "we'll do laters" are resolved?


[FR]: 'fixup' command

What is the current behavior?
Tools like compilers, formatters, linters, gazelle/buildifier, or "golden file tests" often propose a suggested fix.
Currently developers have to find the message and do what it says. It can be hard because:

the CI system is slow to report it
there is no "just run this command to apply fix"
the CI system makes it hard to find that command
you have to reproduce the same failure locally first in order to get the matching fix offered, and for big tests that's just slow.

Describe the feature
bazel fixup as a new command, which is named after git commit --fixup HEAD
MVP (minimal viable product) should hook into Aspect Workflows and one particular tool, probably https://docs.aspect.build/rules/aspect_bazel_lib/docs/write_source_files/.
User story is:
"As a developer with a red PR, I see the CI system has proposed a mechanical fix for my write_source_files rule. I run bazel fixup. It queries remotely (with some assumptions about local username matching) to find the patch content on CI and fetch it.  My PR then turns green"

Help me understand this better.
I thought the mechanical fix should be either:

Direct result of running a command, e.g., clang-format, rustfmt, bazel build with a repin flag, etc.. In this case, no other actions are needed. The files are modified in-source.
Calling bazel build to build a new version of the golden file, and copy it from bazel-bin back to the source tree, and then chmod 644 on the copied file.

Per this understanding, I don't quite get why bazel fixup needs to query remotely. Also, what patch content needs to be fetched?
Thanks for helping me understand.

I see a different scenario:
gazelle with update-repos command could lead to merge conflicts in the .bzl file it writes to. In this case, the fix is rather tedious:

checkout branch A, and query branch B on what go packages it updated, perform the go get and gazelle update-repos on the same branch, and push to A.

If so, there has to be some contract between the remote (eg CI) and the bazel fixup command?

This proposal is largely thinking about the use case where you have a red status on CI and a message there that says "apply this patch to your sources". It's slow to re-run the tool that produced the patch. You really want CI to just supply the patch file itself as an artifact and be able to run patch on it automatically.


Add :xcodeproj param to set_build_number_repository action

Thanks for contributing to fastlane! Before you submit your pull request, please make sure to check the following boxes:

[ ] Run bundle exec rspec from the subdirectory of each tool you modified. Alternatively, run rake test_all from the root directory.
[x] Run bundle exec rubocop -a to ensure the code style is valid
[x] Read the Contribution Guidelines
[x] We currently don't accept new actions, please publish a plugin instead, more information in Plugins.md

Before submitting a pull request, we appreciate if you create an issue first to discuss the change :+1:

It would be good to get the set_build_number_repository_spec.rb updated to test the new possibility. Would you be interested in giving that a try?

Also, I'm not sure whats causing CI to fail, it doesn't look as if I've touched the newly failing tests

@AndrewSB We try to avoid this as much as possible, but sometimes failing tests make it into master (e.g. after merging two PRs without rebasing that break each other's tests, but not their own ones).
Could you try rebasing your branch to the most current version of master to see if that fixes anything?

Continued in #7860 to rebase on master and fix the test.


TC- DROPDOWN "personale nr. joburi (desc)" is visible

Description : Verify if in the dropdown menu "Personale nr. joburi (desc)" is visible.
Precondition : Page https://admin.peviitor.ro/ is opened.

Step 1: Open the dropdown menu from validator.
Expected result: The button "personale nr.joburi(desc)" is visible and can be selected.


quoted_date doesn't work for Type::DateTime

https://github.com/rails-sqlserver/activerecord-sqlserver-adapter/pull/720 opened to master repo too


Update azure-vm-image-test.md

Changed date in header.

@v-jrushing : Thanks for your contribution! The author(s) have been notified to review your proposed change. @github-2407

Changed date in header. #sign-off

@v-jrushing: I'm sorry - only the author of this article, @github-2407, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

@ktoliver : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off


RCON Passthrough failing (Bad password with token)

Bug Report
System Information

OS: Any
Version: 1820
Stream: Dev

I confirm:

[x] that I have searched for an existing bug report for this issue.
[x] that I am using the latest available version of AMP.
[x] that my operating system is up-to-date.

Symptoms
RCON passthru always returns 'bad password' when trying to login using a service token.
Reproduction

Enable RCON passthru in RCONPlugin.kvp
Create a service login in AMP
Try and login using token via picorcon
Failed - Bad Password

This has been fixed as of the latest commit. It'll be available in Nightly starting tomorrow and will be in the next release.


tests: subsys/shell: move to new ztest API

Move test subsys/shell to use new ztest API.
Signed-off-by: Yinfang Wang<EMAIL_ADDRESS>

@yinfangw
In the previous implementation, I had to wait sometime (20ms) for the backend to initialize before running ztest. Otherwise, there were problems. Please tell me how, with this change, to guarantee that ztests run late to give the shell backend time to initialize?

@yinfangw In the previous implementation, I had to wait sometime (20ms) for the backend to initialize before running ztest. Otherwise, there were problems. Please tell me how, with this change, to guarantee that ztests run late to give the shell backend time to initialize?

The suite's setup function which is called before the suite is run, It can ensure that.


proxy: remove connections on shutdown

Problem
On shutdown, proxy connections are staying open.
Summary of changes
Remove the connections on shutdown
Checklist before requesting a review

[X] I have performed a self-review of my code.
[ ] If it is a core feature, I have added thorough tests.
[ ] Do we need to implement analytics? if so did you add the relevant metrics to the dashboard?
[ ] If this PR requires public announcement, mark it with /release-notes label and add several sentences in this section.

Checklist before merging

[ ] Do not forget to reformat commit message to not include the above checklist

Maybe let's also update MAX_CONNS_PER_ENDPOINT to 10? The reasoning is that 20*6 > 100 (default max_connections).

Also, we'll need to kill all existing staging proxies after deploying this PR. @conradludgate can you do it? Other than that, LGTM.


[GCI] Improve performance by using cache, bootsnap and compressing assets

Describe the changes you have made in this pr -

Change 3 instances of find_by to exists? in project policy

GCI task
Please review @tachyons

Coverage remained the same at 83.264% when pulling c077e575dded0af4dbf84da265f5b1023234119f on junron:performance-improvements into 6f6dfff8fae733634c375b33e74d5232147c7452 on CircuitVerse:master.

Task was to make 3 changes, so that others can also claim the task and fix some

Please have a look @tachyons


[Loadout] v10 proper integration

Closed with: https://github.com/thatlonelybugbear/FoundryMacros/blob/main/5e/InventoryManagement/loadout_v10.0.1.js


[v2.3] Catalog log fix

Problems:
The count for catalog templates was increasing after create or update was called even if they threw an error. TemplateSpec value "UpgradeVersionLinks" was being set prior to DeepEquals being called during update causing the template to indicate that it needed updating when no values had changed. Long label name was erring after template was being created.
Solution:
Increment count only where there is not an error. Move "UpgradeVersionLinks" to be set only when it is needed. Add log to indicate files had a failure. Make errors indicate when the error occurred instead of being generic. Check for label length before allowing template to create. Delete template during delete if template version doesn't exist to ensure catalog delete occurs successfully. Reduce the number of times update is called on the catalog to reduce logging. UI no longer displays the individual templates that are syncing, but that the catalog is syncing.
Issue:
#23368
#19724
Master PR
https://github.com/rancher/rancher/pull/24176

LGTM


Do not fork word-count repo, instead generate from a template

In my opinion the generation from a template is nicer than searching for the importer and manually filling it out.
One controversial change can be the removal of my own exercise (fix the central repo by sending PRs), but I have now seen a couple of workshops where this lesson went overtime and we have not even attempted that exercise.
I think this exercise is cleaner without a fork relation. It is also easier for us since we don't have to clean up and set up anything for future workshops.

What if instead of fully removing the exercise, we leave a small discussion point about fixing someone else's documentation?  Well, that actually is removing the exercise, but by connecting to previous lessons we can get better understanding.
I didn't quite get the "importer" part, I didn't see it mentioned anywhere.
I agree that the simplicity is probably better here.  But... it is sort of a capstone lesson that connects many things we have learned, and one of the first things I liked about CR.  But I think we can justify that by moving more towards the real/JOSS project examples.
I approve but recommend asking others, too.

We can also keep the exercise and make it more "real". What I want to definitely fix is that we do not have to "reset" examples before a workshop but that we are also not cluttering a repo with demo changes.
Also I really liked that exercise (and I introduced it), but one criticism I got is that it required also forking (I thought that was a good thing) but which diluted a bit the focus. So I would be happy to keep a real exercise.
Another point is that at least in 2019 to my knowledge we always jumped over this exercise.

Those are all good reasons, and I'm more for this now.  Especially the "design for less manual work" part.

It sounds good to me and you are right. We never really have time to do this exercise. I also like the clarification about the exercise as forking was definitely confusing.

it's always a shame to remove good content, but i think it's justified here due to time reasons, and also that the improve-existing-documentation exercise was an atypical use case for most researchers. Getting up and running with documentation of own projects should be main focus.
I also approve of the copy instead of forking since it makes it simpler to set up workshop, and we want it to be as simple as possible for future workshops and new instructors.
So i approve! great work


router.base affecting proxy  behaviour in 2.11.1 and above

Version
2.11.1-26376495.084a1ca
Reproduction link
https://github.com/nuxt/nuxt.js/pull/6999
Steps to reproduce
It affects proxy behavior when  router.base is defined.
The behavior changed somewhere between 2.11.0-26277131.7af9ec8c and
2.11.1-26376495.084a1ca
Before for the following configuration
 proxy: {
    "/api": {
      target: "http://myserver.com",
      pathRewrite: {
        "^/api": "/alpha"
      },
      changeOrigin: false,
      prependPath: false
    }
 },
 router: {
     base: "/alpha/"
 }

I would have /api pointing to http://myserver.com/alpha e.g. /api/user would  call http://myserver.com/alpha/user. But after the change  I can't access /api.
Without router.base defined it works as before, with router.base defined one only can define proxies starting with base
What is expected ?
I would have /api pointing to http://myserver.com/alpha e.g. /api/user would  call http://myserver.com/alpha/user.
What is actually happening?
After the change  I can't access /api.

This bug report is available on Nuxt community (#c10333)

This is effectively a breaking change affecting 2.12.0 release.

Hi, @husayt Thanks for the heads up. Regression fixed by 5a6cde3ebc23f04e89c30a4196a9b7d116b6d675. Proxy module was using an undocumented way to disable router.base (https://github.com/nuxt-community/proxy-module/blob/v1.3.3/lib/module.js#L64)

Excellent. Thanks
On Thu, 12 Mar 2020, 17:35 Pooya Parsa<EMAIL_ADDRESS>wrote:

Hi, @husayt https://github.com/husayt Thanks for the heads up.
Regression fixed by 5a6cde3
https://github.com/nuxt/nuxt.js/commit/5a6cde3ebc23f04e89c30a4196a9b7d116b6d675.
Proxy module was using an undocumented way to disable router.base (
https://github.com/nuxt-community/proxy-module/blob/v1.3.3/lib/module.js#L64
)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nuxt/nuxt.js/issues/7028#issuecomment-598318524, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAI5PLACCNCTIX6NUMDNMB3RHEMNNANCNFSM4K5UZBZQ
.


Perf hot spots

This is all the reports with new thresholds of 20s for page and 10s for query. Obviously eventually we'd like those to be more like 10s/1s or (super ambitiously) 1-2s/sub-1s.
== Jun 23-Jul 17
= Pages

/seasons/{id}/: 144
/: 60
/cards/{name}/: 12 (9 all in the same minute from a bot not respecting our Crawl-Delay)
/seasons/all/archetypes/: 71
/rotation/: 19 (but not live a lot of the time!)
/seasons/all/archetypes/{id}/: 20
/league/current/: 4
/seasons/{id}/league/: 5
/seasons/all/cards/: 70
/seasons/{id}/competitions/: 16
/api/gitpull/: 2
/api/cards/: 2
/competitions/: 14
/retire/: 2
/seasons/{id}/rotation/changes/: 4 (all id=1?)
/competitions/{id}/: 2
/cards/{name}/: 2 (Swamp, Negate)
/seasons/all/cards/{name}/: 9 (Plains, Evolving Wilds, Hermit Druid, ...)
/seasons/8/competitions/: 1
/rotation/: 4
/rotation/changes/: 8
/rotation/speculation/: 1
/archetypes/: 9
/admin/prizes/: 3
/decks/{id}/: 13
/seasons/all/people: 3
add_report: 5
signup: 5
do_claim: 2
person_status api: 5
post_archetypes: 1
/deckcheck/: 1
about: 2
process_github_webhook: 3
/people/: 3

= Queries

Cards (this season) on /: 89
Card legality on /seasons/1/rotation/changes/: 24 (these all being season 1 is interesting!)
Main query on /seasons/all/cards/: 16
Main query for cards_api: 17
load_decks (unheavy) on /cards/{id}/: 2
SELECT * FROM _cache_card AS c WHERE ... on /seasons/1/rotation/changes/: 3
Archetypes on  /decks/{id}/: 31
News query on /: 1
on /cards/{name}/: 2
main query for /cards/: 2
w/d/l for decks on /seasons/{id}/: 2
main query on /archetypes/: 6
main query on /seasons/{id}/archetypes/: 6
api person status: 6
_cache_card on rotation speculation: 2
_cache_card on rotation changes: 5
_cache_card on /seasons/all/{name}/: 2
_cache_card on /cards/{name}/: 1
load_competitive_stats in /admin/prizes/: 4
base_query: 18+
main query on /seasons/all/people: 3
insert into card_legality: 2
deck query on /: 2
decks for /seasons/competitions: 3
decks on /seasons/{id}/cards/{name}/: 1

Closing for now but perf as a whole is still a known issue.


Issue with arrows on healthy thinking main page

@sdmcraft

The arrows switched sides here:

This is on the homepage.


Editor lag when cursor hovering over Sprite or while moving a Sprite in 2D

Godot version:
5dc2b12efa161ca48d893fc930ff5501ba51e809
OS/device including version:
Windows 10 x64
GPU: Nvidia gtx 1080
DRIVER: GeForce 398.11

Issue description:
Editor lags (freezes for half of a second) when the mouse cursor is hovering over Sprite that is displaying a large texture (for example, mine was 750x733), or even a small part of large texture file. This is mostly noticeable when i pan the scene around with middle mouse button while the cursor is above the sprite, or if i move the sprite itself with left mouse button.
This does not happen if mouse cursor is not positioned over the sprite.
This does not happen in official GODOT v3.0.6 release.
This does not happen with small textures (for example, 40x40 pixels).

Steps to reproduce:
-Create a new scene
-Add Node2D as its root
-Add a Sprite as a child of root node
-Attach a large texture (mine was 750x733) to the sprite
-Drag the sprite around or pan the scene, both so that the mouse cursor is positioned over the sprite
Minimal reproduction project:

Sprite_hover_lag_Example_project.zip

https://github.com/godotengine/godot/issues/21059

Thanks for the report! Closing as duplicate of #21059.


Formatting messes up code when not using self-closing tags (HTML5) for  or

When I format HTML5 type markup, the formatter messes up my code. Because it is not able to handle non closed tags like
,  or <meta>
For instance this simple page:
<!DOCTYPE html>

    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>Document</title>

Turns into this abomination, after formatting:
<!DOCTYPE html>

        <meta charset="UTF-8">
            <meta content="width=device-width, initial-scale=1.0" name="viewport">
                <meta content="ie=edge" http-equiv="X-UA-Compatible">
                    <title>Document</title>

Downgrading to 0.3.1 version works for me

@ignism I'll get into contact with the developer behind Pretty Diff about this issue. Thanks 👍

Ok, I have pushed an update where the formatter will interpret the code as HTML instead of Twig and it should fix this closed tag issue. Previously setting the language as TWIG, it thought the code was XML which is very strict about having closed tags but HTML is laxer 😄


Use spanmetrics connector to generate RED metrics

Changes
Use spanmetrics connector to generate RED metrics.
The span2metrics in combination with the prometheusremotewrite exporter will be producing:

target_info series
traces_spanmetrics_calls_total series
traces_spanmetrics_duration_seconds_{count/sum/bucket} series. If we want to temporarily produce what Tempo metrics generator is producing we need to add metricstransofrm processor to rename traces.spanmetrics.duration to  traces.spanmetrics.latency and disable --feature-gates=pkg.translator.prometheus.NormalizeName flag to get rid of the unit prefix, then we will end up with traces_spanmetrics_latency_{count/sum/bucket}

Follow up:

Once servicegraph is released as connector, update the otel config to use it as connector.
Make OTel prometheus exporter (the one with the text exposition format) work with spanmetrics connector. Currently, it all the resource attributes are copied to series attributes.

Can we do the Tempo metrics already in this PR? Or is it planned immediately after this?
We are building towards the Tempo metrics for July, and I am not super confident if we're updating the App O11Y app to the connector metrics and not the Tempo metrics.

I meant doing this in this PR as well, or in a very quick subsequent PR:

If we want to temporarily produce what Tempo metrics generator is producing we need to add metricstransofrm processor to rename traces.spanmetrics.duration to traces.spanmetrics.latency and disable --feature-gates=pkg.translator.prometheus.NormalizeName flag to get rid of the unit prefix, then we will end up with traces_spanmetrics_latency_{count/sum/bucket}

I want to make sure we don't use the metric names: traces_spanmetrics_duration_seconds_{count/sum/bucket} in the App O11Y plugin.


results.php page: athlete data is not loaded after selection

groups, athletes, forms, forms data etc. can be chosen:

but there is no athlete data displayed or loaded.

this issue is related to the Firefox-browser
(as far as I can see, chrome works fine)


Create CODE_OF_CONDUCT.md

Add a link to Microsoft's Code of Conduct

Coverage increased (+36.2%) to 58.0% when pulling b3277bf38f3ff87df516f7f1109b72c3f4c8f34a on add-code-of-conduct-1 into b476903ac66593d0c852dd1e3466b034051b3a47 on master.


Vitest: doesn't resolve typescript aliases

Describe the bug
I've added nxext/vitest to my existing project and switched one of the libs from jest to vitest. When I run the tests using vitest it doesn't take into account
To Reproduce

Create a library
Create a library that depends on that library by importing using an alias.
Run tests using vitest

Expected behavior
I'd expect the build to succeed and the files to be taken according to typescript aliases in the tsconfig.base.json

The Vitest package won't get many updates in the future, cause the ongoing official plugin will replace it

Found it: https://nx.dev/packages/vite
Thanks a lot!


error in the code

[Epoch #1] loss: 4.703 = (CE: 4.703) + (Ent: 0.0 * 2953.708) + (Rec: 0.0 * 0.000): 100% 244/244 [1:48:44<00:00, 25.80s/it]
train loss: 5.829274394473091 (CE 5.829274394473091 + E 2903.751967133069 + REC 0.0)
Traceback (most recent call last):
File "train.py", line 165, in
main()
File "train.py", line 142, in main
val_scores, _, _ = score(model, val_iter)
File "/content/drive/My Drive/RecNet/utils.py", line 174, in score
scores = calc_scores(refs, hypos)
File "/content/drive/My Drive/RecNet/utils.py", line 192, in calc_scores
score, scores = scorer.compute_score(ref, hypo)
File "/content/drive/My Drive/RecNet/pycocoevalcap/bleu/bleu.py", line 26, in compute_score
bleu_scorer += (hypo[0], ref)
File "/content/drive/My Drive/RecNet/pycocoevalcap/bleu/bleu_scorer.py", line 166, in iadd
self.cook_append(other[0], other[1])
File "/content/drive/My Drive/RecNet/pycocoevalcap/bleu/bleu_scorer.py", line 115, in cook_append
cooked_test = cook_test(test, self.crefs[-1])
TypeError: cook_test() missing 1 required positional argument: 'refmaxcounts'
I have run this code in google colab in python3 1 epoch has done
after that i am getting this error
how to solve it
i need the model ckpt file
how to save it
pls help
thanks in advance

Hi,
You should use python 2.7, not 3. The evaluation code which I got from here requires us to use python 2.7.


Accommodate change in cell error codes

Attempts to access deleted cells have previously thrown 500 errors. Going forwards, they should instead use the 404 status.

NOTE: This is expected to fail CI until the back end change is deployed.

Minor nit only.
My understanding is that the tests for this should pass once we deploy this Saturday.
Let's wait to make sure that's the case and then merge.


Mounting a sub-app onto a router doesn't emmit the 'mount' event.

How to reproduce:
var express = require('express');
var subapp = express();
var app = express();

subapp.on('mount', () => {
    console.log('mounted');
})

app.use('/subapp', subapp);

app.listen(8080);

=> mounted

but
var express = require('express');
var subapp = express();
var app = express();

subapp.on('mount', () => {
    console.log('mounted');
})

var router = express.Router();

router.use('/subapp', subapp);
app.use(router);

app.listen(8080);

no log :P

Yes, this is working as intended. An app is only "mounted" on another app. Adding an app to a router does not run through the same semantics, namely how it links together the settings, locals, and more. This is as designed.
I hope this helps!


Bad Pool Caller - BSOD

Whenever I do a disk intensive operation like installing some packages or use git to clone a repository, this error comes up. The BSOD shows up and the machine reboots.
This happens in both the WSL with bash on windows and archlinux subsystem for windows.

Windows build number - Version 1703 (OS Build 15063.14)

Any memory intensive operation like git cloning a dotfiles repository or downloading packages throws this error.

Anyway to handle this ?

I tried installing vim-plugins with vim-plug, the crash appeared when cloning multiple git repositories.
Any clue how to debug this ?

BSOD's can be security issues, so, as this repo's README says, please don't report them here.  Instead, please find the minidump associated with the BSOD in C:\Windows\minidump and e-mail it to<EMAIL_ADDRESS>attn: @benhillis , or anyone else on the WSL team.
If you do want to debug further yourself, the minidump would be a good place to start.  There are lots of tools online for working with minidumps.  I once had a repeatable BSOD (but not specific to WSL; just specific to high disk activity); the minidump fingered the driver for my disk subsystem, and upgrading to the latest driver direct from the manufacturer (the Windows Update version was out-of-date) fixed the issue.  Of course, it's only that simple if the bug is in a driver and has been fixed :-)

@SageEx - Please send any memory dumps if you have them.

Hi @benhillis, I'm currently away from my laptop for 2 weeks. I'll cause the BSOD and get you the dump in 2 weeks.
I'll be closing this issue for now. I'll open it again once I get the dump.

Hello,
I have a similar issue with Debian Buster in WSL. I can provide minidump if needed.
Could you reopen this issue or should I create a new one.
Note, that I also run a Debian stretch within Legacy WSL on the same host without any problems.

@kittel please send the dump to<EMAIL_ADDRESS>and reference this issue.


USD export PreviewSurface Prim missing class identifier

Exporting an instanced prefab with materials into USD and then viewing it with usdview causes it to emit these error messages - and display the model with no material:
(USDtools) D:\python\usdmorph\HumanUsd\h64>usdview Human-0064-0.usda
Coding Error (secondary thread): in GetBehavior at line 540 of D:\transfer\USD\pxr\usd\usdShade\connectableAPIBehavior.cpp -- Could not find prim type '' for prim prim </Human_0064/Materials/Man001_color_28332/PreviewSurface> on stage with rootLayer @Human-0064-0.usda@, sessionLayer @anon:00000000295339F0@
... (4 more of the same)
Coding Error (secondary thread): in GetBehavior at line 540 of D:\transfer\USD\pxr\usd\usdShade\connectableAPIBehavior.cpp -- Could not find prim type '' for prim prim </Human_0064/Materials/Man001_color_28332/PreviewSurface> on stage with rootLayer @Human-0064-0.usda@, sessionLayer @anon:00000000295339F0@
ERROR: Usdview encountered an error while rendering.
        Error in 'pxrInternal_v0_21__pxrReserved__::`anonymous-namespace'::_BehaviorRegistry::GetBehavior' at line 540 in file D:\transfer\USD\pxr\usd\usdShade\connectableAPIBehavior.cpp : 'Could not find prim type '' for prim prim </Human_0064/Materials/Man001_color_28332/PreviewSurface> on stage with rootLayer @Human-0064-0.usda@, sessionLayer @anon:00000000295339F0@'
... (6 more of the same)
        Error in 'pxrInternal_v0_21__pxrReserved__::`anonymous-namespace'::_BehaviorRegistry::GetBehavior' at line 540 in file D:\transfer\USD\pxr\usd\usdShade\connectableAPIBehavior.cpp : 'Could not find prim type '' for prim prim </Human_0064/Materials/Man001_color_28332/PreviewSurface> on stage with rootLayer @Human-0064-0.usda@, sessionLayer @anon:00000000295339F0@'

The relevent USD lines are as follows:
   def Scope "Materials"
    {
        def Material "Man001_color_28332"
        {
            token outputs:displacement
            token outputs:surface.connect = </Human_0064/Materials/Man001_color_28332/PreviewSurface.outputs:surface>
            token[] requiredKeywords

            def "PreviewSurface"
            {
                token info:id = "UsdPreviewSurface"
                float inputs:clearcoat = 0
                float inputs:clearcoatRoughness = 0.01
                float3 inputs:diffuseColor = (0.18, 0.18, 0.18)

The errors go away if I add a Shader class to the "PreviewSurface" line like so:
            def Shader"PreviewSurface"
            {

Notes:

Using Unity 2020.3.20f1
Using USD Package 3..0.0-exp.2
A repo with Python code that does a minimal parsing of a USDA file and repairs the issues 278, 282, 283, 284, 285 can be found at https://github.com/MikeWise2718/usdmorph - hopefully it won't be needed long before these are all repaired in a new version.

Also seeing this, can confirm.

I believe this is fixed by https://github.com/Unity-Technologies/usd-unity-sdk/pull/348- if you try it out on dev please let us know if you have any issues :)


Clarify that the resulting crypto_box public key is deterministic

This wouldn't really be useful if it was non-deterministic – so perhaps this clarification isn't overly necessary. Still, language may as well convey what happens 😉

👍 Thanks!


Migrations.sol  Missing  “;”

Migrations.sol:7:3: ParserError: Expected token Semicolon
got 'RBrace'
}
^

➤ Nikhil Kumar Mishra commented:
replace code in migrations.sol
contract Migrations {
address public owner;
uint public last_completed_migration;
modifier restricted() {
if (msg.sender == owner) _;
}
function Migrations() {
owner = msg.sender;
}
function setCompleted(uint completed) restricted {
last_completed_migration = completed;
}
function upgrade(address new_address) restricted {
Migrations upgraded = Migrations(new_address);
upgraded.setCompleted(last_completed_migration);
}
}


Configuration commands table converted to list view.

Coverage increased (+0.005%) to 56.339% when pulling 98afa2fa99ec0a987ae9e136b7278c1d7b28be3f on Spacewalker2:master into cf4591d3e018105275ca7a74e2b1a18af40a401e on newsboat:master.

(Linking this to issue #441).

Also, don't throw out the scripts you used to prepare this, because #936 already adds a new setting, and I'm not sure how many more we'll add before this PR is merged. Though perhaps a couple settings can be added by hand as well.

The script is very simple and uses the dsv file too so I think it could be integrated in the build process in some way. But before that it needs one or two minor modifications.


Remove unnecessary keys from the FormResponse

What
We're submitting a few fields in FormResponse records that shouldn't exist there. These keys, such as _csrf_token are being sent through to the data team.
The changes here are to sanitise the session data and remove unnecessary keys when persisting the form response to the DB.
How to review
After completing the questions check that the response data in the DB does not contain any of
check_answers_seen
_csrf_token
current_path
previous_path
session_id

Links
https://trello.com/c/SsnvWiaA/463-remove-unnecessary-fields-from-formresponse

Thanks for your work here!
Sorry to be super pedantic but can we have some of the PR description (the what and the why) in the commit message please? As it's a single commit this should be fairly straight forward. You've linked to the Trello card, which is great, but Trello boards aren't necessarily long-lived and future us (or whoever comes in next) might need to go back to the individual commit for context.

@steveholmes We need to coordingate this release with https://github.com/alphagov/covid-engineering/pull/285
I also think the reporting team is relying on session_id

Now confirmed that session_id is not in fact used, so will remove session_id

@steveholmes we're ready for these fields to disappear now! 🎉


#237 aggregate_spatial needs to translate incoming geometries to same CRS as the data

If the incoming geometries have a different crs, we now "translate" this to the same CRS as the data (since the xvec function assumes same crs without checking it).
I have added the line that i think should fix this. Please check that its correct and does not have any side-effects that I was unaware of.

A simple test before the geometry_url test (https://github.com/Open-EO/openeo-processes-dask/blob/main/tests/test_aggregate.py#L150) could look like this:
    gdf = gpd.GeoDataFrame.from_features(polygon_geometry_small, crs="EPSG:4326")
    gdf_equi7 = gdf.to_crs(
        "+proj=aeqd +lat_0=53 +lon_0=24 +x_0=5837287.81977 +y_0=2121415.69617 +datum=WGS84 +units=m +no_defs"
    )
    output_cube_transform = aggregate_spatial(
        data=reduced_cube, geometries=gdf_equi7, reducer=reducer
    )
    assert len(output_cube_transform.dims) == len(output_cube.dims)
    assert output_cube_transform.shape == output_cube.shape

I opened a PR on your fork to merge the latest updates of openeo-processes-dask into your branch.

@ValentinaHutter trying to create an example using aggregate_spatial I also faced a related bug.
pydantic checks the CRS here: https://github.com/Open-EO/openeo-pg-parser-networkx/blob/50e71097929086beca7377ac6d909831a2ecb87c/openeo_pg_parser_networkx/pg_schema.py#L112
which is not compatible of what we get with a geoJSON string, which is a dictionary.
Here is a code to reproduce the issue:
import json
import geopandas as gpd
from openeo.local import LocalConnection
local_conn = LocalConnection("./")

url = "https://earth-search.aws.element84.com/v1/collections/sentinel-2-l2a"
spatial_extent =  {"east": 11.40, "north": 46.52, "south": 46.46, "west": 11.25}
temporal_extent = ["2022-06-01", "2022-06-30"]
bands = ["red", "nir"]
properties = {"eo:cloud_cover": dict(lt=80)}
s2_datacube = local_conn.load_stac(
    url=url,
    spatial_extent=spatial_extent,
    temporal_extent=temporal_extent,
    bands=bands,
    properties=properties,
)

b04 = s2_datacube.band("red")
b08 = s2_datacube.band("nir")
ndvi = (b08 - b04) / (b08 + b04)

sample_geojson_string = """
{"type":"FeatureCollection","features":[{"type":"Feature","properties":{},"geometry":{"coordinates":[[[11.348766682377743,46.48077235403869],[11.348766682377743,46.47721029746353],[11.35563673107842,46.47721029746353],[11.35563673107842,46.48077235403869],[11.348766682377743,46.48077235403869]]],"type":"Polygon"}},{"type":"Feature","properties":{},"geometry":{"coordinates":[[[11.365497271567875,46.48683844486996],[11.362870488240105,46.48441765486314],[11.365658919772045,46.48208023815508],[11.3688514718161,46.48305417398808],[11.367477462075641,46.485725451348884],[11.365497271567875,46.48683844486996]]],"type":"Polygon"}},{"type":"Feature","properties":{},"geometry":{"coordinates":[[[11.372809654880939,46.486050715872665],[11.371383328810936,46.484121615720795],[11.375203845069393,46.482332752634534],[11.37754709654618,46.48349025889712],[11.3788206018977,46.48548953006227],[11.375407607374086,46.486226085126646],[11.372809654880939,46.486050715872665]]],"type":"Polygon"}},{"type":"Feature","properties":{},"geometry":{"coordinates":[[[11.358546395621374,46.47956165241811],[11.358240754320718,46.478158509926004],[11.363283835883294,46.47563276206486],[11.365219564109765,46.47864961374469],[11.362723493271574,46.481245375637826],[11.358546395621374,46.47956165241811]]],"type":"Polygon"}},{"type":"Feature","properties":{},"geometry":{"coordinates":[[[11.35324861290701,46.48243798140945],[11.359004857403477,46.48170137505551],[11.360278362822669,46.483244729307046],[11.359157678053293,46.48527908392737],[11.355082460711827,46.48510371152537],[11.35324861290701,46.48243798140945]]],"type":"Polygon"}}]}
"""

sample_geojson = json.loads(sample_geojson_string)
#The data is in EPSG:32632, we need to convert the geoJSON in EPSG:4326 to that
geoms = gpd.GeoDataFrame.from_features(sample_geojson).set_crs("EPSG:4326").to_crs("EPSG:32632")

# Doesn't work due to Pydantic (AttributeError: 'dict' object has no attribute 'strip')
geojson_32632_dict = json.loads(geoms.to_json())
ndvi_stats = ndvi.aggregate_spatial(geometries = geojson_32632_dict, reducer = "median").execute()

# Doesn't work due to openeo-processes-dask, which expects a dict
geojson_32632_dict["crs"] = 32632
ndvi_stats = ndvi.aggregate_spatial(geometries = geojson_32632_dict, reducer = "median").execute()

Hmm, sadly i discovered this : "The support for specifying Coordinate Reference Systems (CRS) other than WGS 84 was removed from the GeoJSON specification in its 2016 version, RFC 7946, which mandates that all coordinates are assumed to be in the WGS 84 system. For applications needing a different CRS, transformations must occur outside the GeoJSON format, as it exclusively assumes WGS 84 coordinates."
As i understand it, this meanst that we cannot specify (other) CRS:s for polygons, only for the bounding box ("west", ....). However, since the rastercube  still may be a of different CRS, i guess we still need to convert the polygon to the CRS of the rastercube (which should be possible once in geopandas).

Hmm, sadly i discovered this : "The support for specifying Coordinate Reference Systems (CRS) other than WGS 84 was removed from the GeoJSON specification in its 2016 version, RFC 7946, which mandates that all coordinates are assumed to be in the WGS 84 system. For applications needing a different CRS, transformations must occur outside the GeoJSON format, as it exclusively assumes WGS 84 coordinates."
As i understand it, this meanst that we cannot specify (other) CRS:s for polygons, only for the bounding box ("west", ....). However, since the rastercube still may be a of different CRS, i guess we still need to convert the polygon to the CRS of the rastercube (which should be possible once in geopandas).

Exactly. geoJSON doesn't support other CRSs than EPSG:4326. The action points here are:

Convert the CRS to the native of the datacube, like we did in the filter_spatial implementation here: https://github.com/Open-EO/openeo-processes-dask/blob/main/openeo_processes_dask/process_implementations/cubes/_filter.py#L122-L128
Implement a process to load vector cubes from other files (like GeoParquet as mention by @soxofaan)

but it is in filter_bbox the "magic" happens right? There you transform the geometries to the same crs as the rastercube
(removed error handling for clarity)
    input_crs = str(data.rio.crs)
    if not pyproj.crs.CRS(extent.crs).equals(input_crs):
        reprojected_extent = _reproject_bbox(extent, input_crs)

Implement a process to load vector cubes from other files (like GeoParquet as mention by @soxofaan)

FYI: the current approach we use is load_url with a geoparquet file (which supports non-EPSG4326 CRSes).
Drawback of that approach is that it requires you to host your geometry on a publicly available URL, which is more cumbersome than just having inline GeoJSON.
As a workaround I propose in https://github.com/Open-EO/openeo-processes/issues/498  to also support data URLs in load_url, allowing to embed binary data directly in process graphs, based on a well-established standard. Feel free to weigh in on the discussion there.


clipboard curl fix for Windows

A quick fix to make copied curl command to work for Windows. Since this commit the copied curl command has stopped working for Windows, since strings have to be enquoted with double quotes.

Yeah setting sounds good 👍

Looks great, thank you! 🎉


Implementing an actual ls?

Hi, thanks for making this! Do you have any plans to implement an actual ls and mkdir function as opposed to defaulting to a hardcoded response? I want to put personal files on my website and having those would be great. For example, https://github.com/Jaredk3nt/HomeTerm

Thanks for the suggestion - I am currently preoccupied with other projects but I do have plans to eventually implement functional mkdir for LiveTerm. If you'd like, feel free to make a pull request that attempts this!


Fix for faulty getWorldResource issue

A fix for the getWorldResource() bug.

fixed RoverService.java in rover.service due to an issue with the init of world resources


database

provide json database

There is no JSON database
This project is just scraping data from the site

There is no JSON database This project is just scraping data from the site

I understand your point, and I appreciate your input. I have some data available that could be useful. If you could assist in making it global, it would be really helpful as sadqah e jaria
github.com/haseebllc/api-oneislam

Your project is so great
I think I can't help you with it
But what do you mean by making it global? I see you already deployed it to versel


resizing incremental index

It seems that when creating an index we need to specify the number of elements it holds. I have a few questions related to this.

If we add entries to more than the number of elements specified, what would happen?
Is it possible to auto expand the allocated index size when it reaches a threshold eg: 75% of max

Hi @lzuwei ,

It would now throw an exception.
It is not implemented at the moment. Manual expansion will be added soon (hopefully next weekend) via saving/loading of the index (this would allow avoiding doubling the memory consumption during the expansion moment). Pool requests for the auto expansion are welcome.

@lzuwei Yes, it will be exposed.

@lzuwei I've added support for index resizing via saving/loading. Please see the updated example https://github.com/nmslib/hnsw/blob/master/examples/example.py

Thank you! I will take a look at it!


SAML Applications will not work as the middle-tier API in an OBO flow

One limitation in the OBO flow is that the middle-tier API must not be a SAML Application (setup to handle SAML SSO, containing a SAML signing certificate). Doing so results in an AADSTS50013 error. I can't find anywhere in our public documentation that describes this behavior.
I have had multiple customers who have struggled with this problem and did not have any documentation to look at to help them.
I think this page is a great place to describe this limitation since it directly affects the OBO flow.
Please let me know if I can elaborate or more thoroughly explain the issue.

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

ID: 1d91ee0b-7926-c0ad-aca2-48958c81acf3
Version Independent ID: 9fa490aa-49e4-8034-83c2-d6c8517834da
Content: Microsoft identity platform and OAuth2.0 On-Behalf-Of flow - Microsoft identity platform
Content Source: articles/active-directory/develop/v2-oauth2-on-behalf-of-flow.md
Service: active-directory
Sub-service: develop
GitHub Login: @hpsin
Microsoft Alias: hirsin

@mbukovich
Thanks for your feedback! I've assigned this issue to the author who will investigate and update as appropriate.

Thanks! I look forward to it

Has there been any progress on this issue?

Hi @JamesTran-MSFT and @hpsin,
I'm just following up to see if any one has been able to review this issue.

As an update we're reviewing this internally and believe there's a bug here related to custom signing keys and JWT creation.

Ah, not a bug but undocumented limitation for security purposes.  Because the admin of the service principal owns the custom signing key, but not the application registration, we cannot allow them to mint tokens that can be used for the OBO flow, which crosses tenants.  Allowing this would permit a cross-tenant elevation of privilege attack.

hspin updated me through email that this is not a bug and is designed behavior because of security implications and that this is not just a matter of SAML SSO enabled apps, but apps containing custom signing certificates.
@nickludwig will documentation be updated to alert customers not to use apps with custom signing certificates as mid-tier APIs in the OBO flow?

@mbukovich yup! Took over docs ownership from Hirsch 2 weeks ago, so still doing some onboarding here. My goal is to submit a PR updating the doc next week, and I'll tag you when I do so you can take a look.

@nickludwig
Awesome, thanks!

Created PR with changes required to close this issue

PR has been merged

#please-close


GET Trainee in HESA Format

Context
The GET /trainees endpoint currently supports returning data in the standard Register format.
We need to map from our internal Register data format to HESA data formats to be returned from the API.
This is related to the ticket to set up mapping for the POST requests, i.e. mapping from HESA data to Register data.
Changes proposed in this pull request
This just involved updating the trainee serializer used in the controller. In some case, we needed to reverse the mapping between what we store in the database, and what HESA send us in POST requests.
Guidance to review
I think the reverse mappings that I've done are correct, but please do double check them.
Important business

[ ] Does this PR introduce any PII fields that need to be overwritten or deleted in db/scripts/sanitise.sql?
[ ] Does this PR change the database schema? If so, have you updated the config/analytics.yml file and considered whether you need to send 'import_entity' events?
[ ] Do we need to send any updates to DQT as part of the work in this PR?
[ ] Does this PR need an ADR?

NB: Please notify the #twd_data_insights team and ask for a review if new fields are being added to analytics.yml

I think there are a few attributes that we are returning the HESA label for, rather than the HESA code which is what I think we want. E.g. sex: "female" vs "10"

What makes you say that @tomtrentham? With sex for example, we're getting the key from this hash, based on the sex of the trainee.
MAPPING = {
        "10" => ::Trainee.sexes[:female],
        "11" => ::Trainee.sexes[:male],
        "12" => ::Trainee.sexes[:other],
        "96" => ::Trainee.sexes[:prefer_not_to_say],
        "99" => ::Trainee.sexes[:sex_not_provided],
      }.freeze

I think there are a few attributes that we are returning the HESA label for, rather than the HESA code which is what I think we want. E.g. sex: "female" vs "10"

What makes you say that @tomtrentham? With sex for example, we're getting the key from this hash, based on the sex of the trainee.
MAPPING = {
        "10" => ::Trainee.sexes[:female],
        "11" => ::Trainee.sexes[:male],
        "12" => ::Trainee.sexes[:other],
        "96" => ::Trainee.sexes[:prefer_not_to_say],
        "99" => ::Trainee.sexes[:sex_not_provided],
      }.freeze

Yeah, so what I'm seeing in the API response is "sex": "female" so I think something is off somewhere. Is the method for this being merged in to the hash?


Make it possible to be enable all mdast-util-toc options on TypeScript

Fix: #32

Codecov Report

Merging #33 (a2f833f) into main (de29ba0) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main       #33   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            1         1
  Lines            8         8
=========================================
  Hits             8         8

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 de29ba0...a2f833f. Read the comment docs.

Thanks @babie, released!


local_socket_stream test fails when running cargo test two times

Describe the bug
When I run the tests they succeeds at first, but running them again a second time right after the first and the local_socket_stream test  fails for me.
To Reproduce
Run tests
Run tests again
test local_socket_stream fails.
left: [],
right: [66, 121, 116, 101, 115, 32, 102, 114, 111, 109, 32, 115, 101, 114, 118, 101, 114, 33, 0]'
Expected behavior
Tests should pass every time I run them.
Additional context
Running on Windows 10

Fixed by a78c360. Will close upon release of 2.0.0.

2.0.0 has been released and the fix is now available on Crates.io.


[Bug]Class not registered error on boot up

Hey Chris @ChrisAnd1998 - hope all ok at your end.
please see below screenshot for the issue I am facing
https://imgur.com/a/P5GLVQI
This is happening quite often now while I start my machine in the morning.
On clicking OK, I get the default windows taskbar.
The only way to get TaskbarX back is then to open it via Windows start.

@onlytanmoy Hi, everything is ok :)
This mostly happens when people try to uninstall TaskbarX without removing the taskschedule. I assume you still want to use TaskbarX so what you can try to do is open the configurator and go to the Taskschedule tab. In that tab you will see a delay option. Try to increase that value with a couple seconds and see if that fixes it.

@ChrisAnd1998 yes Chris, I most certainly want to continue using TaskbarX (one of my favourites), so I increased the value from 3 to 7 in the Taskschedule tab, hopefully this will take care of the issue.
Can I have this ticket remain open for couple of days and then I close down?

@onlytanmoy Yes of course... Hope that fixes the issue.

@ChrisAnd1998 I got that pop-up again today at start up :( increased the time out to 10 now.
Do you recommend uninstalling TaskbarX and then install back again?

Seems to be working fine now :) Will close this ticket now. Thanks mate.


fix concat, update mypy, pyright

[x] Closes #888

Updated mypy, pyright versions as well.

@twoertwein I figured out a way that we can make things work by adding additional overloads that don't include None at the top, and leaving in the Never so we get the best of both worlds.

Thank you @Dr-Irv ! It's great that you found a way to get it to work (even if it creates a few near-duplicate overloads).


Batched agent scheduling

This PR implements agent batching, where we run the agents in one big mutation to decrease the number of functions run per second.
This works pretty well for four agents, but I'm finding it hard to get this to scale to eight. The main problem is that batching everything into one big transaction makes it (1) slow and (2) have a large read set. This makes the agent transaction race with the engine and persistently fail with OCC retries.
I haven't seen it fully exhaust OCC retries yet, but there's long scheduling delay between the mutation getting scheduled and it completing, which makes the agents unresponsive.
Some options I'm going to explore:

Try to make the "one mutation loop per agent" approach work better by decreasing the number of functions run per second. Currently, I believe this approach is overwhelming our UDF layer, causing it to go into LIFO.
Continue to batch the agents into one big mutation but try to simulate snapshot isolation by doing all data fetching in a query. I have this working, but it's annoying to handle transient failures for the scheduled action.
Move the agent behavior into the game engine. This makes the agent less modular but will likely solve all our problems since it's now "on the main thread" and not reading from data the game engine's writing.

Am I understanding the comment correctly that this is a draft for now? I'll review, but let you merge it

Closing since this runs into too many OCC errors having all the agents in a single big mutation.


nvm use (with no arguments) as alias for nvm?

In switching over from (non-fish) nvm, I was tripped up by the "use the .nvmrc-specified version" command being nvm rather than nvm use. Would you be open to supporting argument-less nvm use to not diverge from nvm? What about having argument-less nvm output usage notes, like in nvm?

No, I prefer the way it works now, but thanks for the suggestion.


Change "perf" to "performance"

The choice of using "perf" instead of "performance" seems a bit out of place, when "perf" is used nowhere else as an abbreviation for "performance".

We shouldn't use abbreviations unless well defined in language else it will break localization.


[Performance] Typing performance

[ ] Measure the performance of typing comparing this to other apps in the market
[ ] Analyze any code bottlenecks that is bringing the typing speed down.
[ ] Fix the identified issues.

Method used perform the testing.
We used iPhone 5S to capture the slo-mo video. Once captured, we then loaded the videos into Premier-Pro and started calculating the time difference between when the key got pressed and the character appeared in the premier editor.
Parameters to consider for testing this.

Test this with small, medium large projects
Run it with code hints enabled and disabled.
Test by typing in one char vs many chars (continous chars like qwerty should give an accurate results compared to any standard words.)
Use flash update on MAC from quartz debug to figure out the paint areas

After following the steps mentioned above, the following are the readings for single character press. They could be off by 30-60 ms as the nos were got by measuring frames in the slo-mo video, captured using iPhone 5S. Premier Pro was used to determine the no of frames that elapse from the moment key is pressed to the moment the character appears on the screen.
WINDOWS
Configuration
Processor: i7 3.45 GHz,
RAM: 16GB,
OS: Windows 7 64-bit.
With code hints enabled
| Small Project | Medium Project | Large Project
------------ | ------------- | --------------- | -------------
Brackets 1.3 | 133ms | 333ms | 300ms
Sublime Text 2 | 133ms | 133ms | 133ms
Atom | 233ms | 200ms | 200ms
Visual Studio Code | 333ms | 233ms | 166ms
With code hints disabled
| Small Project |	Medium Project | Large Project
------------ | ------------- | --------------- | -------------
Brackets 1.3 | 166ms | 166ms | 400ms
Sublime Text 2 | 100ms | 100ms | 167ms
Atom | 100ms | 166ms | 266ms
Visual Studio Code | 166ms | 277ms | 277ms

Any idea why the code hints being disabled make typing slower? Am I reading the chart right?

@ryanstewart Even I don't see a pattern here with code hints. I doubled checked the videos in Premier Pro and every time I got the same results. I then recaptured all of the videos using iPhone 6 Plus. But I am yet to do the analysis. So let me repeat the same exercise with the new set of videos and then do a cross reference to see if there any pattern with code hints at all.

@nethip, it would help to see what the stddev looks like for these measurement, over how many runs etc. if you still have the raw data at hand, that is.

@busykai you mean the project size right ? I will update it with the project size. is that what you meant by stddev?

@nethip, sorry. i was just thinking outloud.  stddev = standard deviation, an estimation of measurement accuracy. the point being 133ms +/- 80ms is more or less the same as 166ms +/- 100s. as opposed to 133ms +/- 4ms is very different from 166ms +/- 5ms.
30ms difference in median value could (or could not) result from any other activity on the system (e.g. a player in the background or a anti-virus being active or lots of hw interrupts, e.g. if you move mouse a lot). so I was thinking the first step is to see if how accurate the value is, the second question is whether the median is derived from a single run or multiple runs at random times (to mitigate error due to other processes occupying resources).
it's clear, through, that the project size impacts and a lot.

@busykai Thanks for clarifying stddev part :smile: Sure! I will try to add standard deviation as well.

Closing this card temporarily.

How are you defining small, medium, and large projects?

@mylocameron We have taken small to be 500~1000 files, medium to be more ~4000 files and large to be anything more than 15,000 files. This is strictly for measuring purposes and not based on any real user data. Kind of a hunch.


[Doc]Add roadmap page into site

Roadmap should expose to users on arctic site.
Reference resources:

https://iceberg.apache.org/roadmap/
https://hudi.apache.org/roadmap/

This is a breif of roadmap for arctic in 2022:
Certain ones:

Using arctic table as a dimention table on flink
Supporting insert part of columns of arctic table  on flink in streaming mode(streaming inline upsert)
Supporting manage already existing iceberg table
Supporting delete/update/merge into for hive table
AMS terminal on kyuubi
unify Changestore and Logstore for flink source
expose benchmark code and docker enviroment

Under Discussions

Supporting sort key and z-order
Supporting aggregate key
Supporting manage hudi table

Any suggesion and question are welcomed!

@zhoujinsong, IMO, support Flink 1.15, 1.16 version should be needed.

can support Spark 3.3 be considered?

@zhoujinsong, IMO, supporting Flink 1.15, 1.16 version and materialized view could be taken into consideration.

Thanks for your very useful suggestion, I would take it.

@zhoujinsong, IMO, supporting Flink 1.15, 1.16 version and materialized view could be taken into consideration.

Thanks for your very useful suggestion, I would take it.

Thanks for your very useful suggestion, I would take it.

Thanks for your very useful suggestion, I would take it.


Hamming distance calculator

Would like to add Hamming distance calculator.
Thanks!

Go ahead
Deadline 10 May,2021


Drum-kit Project

Drum Kit Project
The live project is not working.
The keypress event is not working for this project
Describe alternatives you've considered
I want to contribute to this project. I have done the same project, so if you suggest I want to add my Drum-Kit project here.
Additional context
This is the Project

This project already exists.

This issue is a duplicate of #322
It is recommended to check for similar issues, before opening a new one.


What should streams return?

I proposed that streams return "events" along with an "event type" - e.g., for Account, the "event type" would be something like BALANCE_UPDATED or NONCE_UPDATED.
@avive proposed that the stream just stream updated Account objects.
In the former case, you can figure out what happened just by looking at the stream, i.e., statelessly. In the latter case you'd need to compare to previous state.
I'm not sure if this matters.
See https://github.com/spacemeshos/api/pull/2#discussion_r417531729.

It does matter. I think we should not return events at all - just data objects that includes the current state from the mesh perspective on a node - see my comments in the PR review.

So, in this design pattern, when data changes which would have triggered an event stream call - that data object is just sent as-is on its standard stream instead of raising the event so the client gets it from that data object. e.g. a transaction status field. We have to deal with the same objects changing states anyhow as layers, blocks, transactions are all not really immutable and can change state in several cases. e.g. tortoise overrides hare results, self healing, state transition function output etc... if we just stick with objects then we have a forward-compatible design with reorgs which is super important for this project...

Discussed with Aviv, we're both comfortable with his proposal that the API just stream data elements as they change, not events. Per @avive:

I think it is good we keep the node data api as low-level and stateless as possible with just emitting data as it is created or updated and let modules up in the flow deal with what state they are interested at and track this

We're not concerned about consuming more bandwidth for small changes in state since these nodes will probably be running local to the consumer anyway. Basically we'll just "keep the streams dumb."

Cf. Aviv's helpful comments here: https://github.com/spacemeshos/api/pull/2#discussion_r417802062


DNN-30782: merge changes from https://github.com/apache/logging-log4net/tree/release/2.1.0.

Fix #2893

It looks fine for my untrained eye, but my only question is regarding the deprecation notices, the version was removed and the whole deprecation attribute commented, what is the rationale here?

It looks fine for my untrained eye, but my only question is regarding the deprecation notices, the version was removed and the whole deprecation attribute commented, what is the rationale here?

Thanks @valadas , that just the log4net repo made the same changes, the made some properties to be un-deprecated, thx

Thanks @zyhfish I saw that, looks strange


Backport the statistics command to swift.

This has been implemented upstream, but can be useful for swift as well.
swift-4.2-release branch edition.

@swift-ci test and merge

@swift-ci test and merge

@swift-ci test and merge