onedrive deletion on BYOD

hey I'm trying to fully understand what happens when user accout  is deleted on M365 I got this article:
and part that makes me wonder is:
Important! If the deleted user used a personal computer to download files from SharePoint and OneDrive, there's no way for you to wipe those files they stored on their computer. They will continue to have access to any files that were synced from OneDrive.
does that mean Intune can't delete this data? I thought that's one of main selling points of BYOD with intune??

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

ID: f6245943-00b8-c47b-f739-731531d5d357
Version Independent ID: a9ec7066-ed8c-7b77-1d87-8c50bf74ec6c
Content: Delete a user from your organization - Microsoft 365 admin
Content Source: microsoft-365/admin/add-users/delete-a-user.md
Service: microsoft-365-business
GitHub Login: @kwekuako
Microsoft Alias: kwekua

@peterwww Thank you for your feedback. In case the user downloads it on a personal and not the one that is configured via Intune (BYOD).
Hope this helps!
Thanks
Sri

ok so as long as this personal BYOD is enrolled into Intune, work profile data can still be deleted? Is this correct?
Kind regards,
Peter Wiktorowski
Customer Success Manager | Modern Workplace
@.***
+44 (20) 76608537
@.***?anonymous&ep=signature>
Book time to meet with @.***?anonymous&ep=plink>
[cid:5500883d-f44b-4397-873f-451a8e66cd57]

From: Sriraman M S @.>
Sent: 15 September 2023 14:19
To: MicrosoftDocs/microsoft-365-docs @.>
Cc: Peter Wiktorowski (MICROSOFT CORPORATION) @.>; Mention @.>
Subject: Re: [MicrosoftDocs/microsoft-365-docs] onedrive deletion on BYOD (Issue #12795)
@peterwwwhttps://github.com/peterwww Thank you for your feedback. In case the user downloads it on a personal and not the one that is configured via Intune (BYOD).
Hope this helps!
Thanks
Sri
—
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/microsoft-365-docs/issues/12795#issuecomment-1721272026, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA7FIQD7QIYR272N2662S3TX2RIXTANCNFSM6AAAAAA4X2NWC4.
You are receiving this because you were mentioned.

@peterwww  That is correct.
Thanks
Sri

@msbemba Thank you very much for the contribution and sharing this explanation. @peterwww Hope this comment is helpful for you. If you see a documentation update is required, please feel free to open an issue for the same. We proceed here to close it. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


Butterknife keeps binding cache after change view from java to kotlin

Hey friends, I have an issue which looks like this:
We had a fragment in Java binding the views from xml using butterknife, then, we decided to migrate this fragment from java to kotlin using synthetic to bind the views, thus, we no longer use butterknife in this fragment class.
What happen is, this application is on play store and currently being used for several users. When we published the new version of the app, somehow, butterknife kept the binding cache of that old Java fragment and it's views components, even though, that old Java view doesn't exist anymore because we have made it in kotlin now and using synthetic.
While developing, we noticed that we could solve this problem by cleaning android studio project cache. But, when we launched the app the problem persist in some users.
How could we force butterknife to clear its view cache when upgrading app version? Is there a flag we could use in gradle or somewhere else? Any help is appreciated

Currently, we solved this issue by adding a try catch statement when using Butterknife.bind(), but, we belived is not the nicest solution.

There is no cache across versions or even app launches. What you are experiencing is something else, but there isn't enough information to begin to diagnose the problem. For starters, what is the exception?

Did you remove Butterknife.bind() in the fragment kotlin? @limallucas96


Add Spanner Client API

This PR implements the Client API, which is what users will use to connect to Cloud Spanner in their applications. A client is created from the main Spanner object:
require "google/cloud/spanner"

spanner = Google::Cloud::Spanner.new
db = spanner.client "my-instance", "my-database"

The Client object offers the same functionality as Session, but also allows the creation of a Read/Write transaction:
require "google/cloud/spanner"

spanner = Google::Cloud::Spanner.new
db = spanner.client "my-instance", "my-database"

db.transaction do |tx|
  results = tx.execute "SELECT * FROM users"

  results.rows.each do |row|
    puts "User #{row[:id]} is #{row[:name]}""
  end
end

As well as a Read/Only snapshot:
require "google/cloud/spanner"

spanner = Google::Cloud::Spanner.new
db = spanner.client "my-instance", "my-database"

db.snapshot do |snp|
  results = snp.execute "SELECT * FROM users"

  results.rows.each do |row|
    puts "User #{row[:id]} is #{row[:name]}""
  end
end

This PR completes the major pieces of the API that users will use, but does not complete the Spanner implementation. There are still several missing features, such as the session pool, retrying aborted transactions, and resuming broken streams. But those features will not see much change to the public API as defined in this PR.

The Client object offers the same functionality as Session, but

Is Session now gone for good?

Yes, Session is no longer part of the public API, but it will remain in the international API and will see additional features when session pooling is added.

Gonna merge now so we can open the follow-up PRs.


not working!!! just can find out where is the face in debug

Yes exactly. However his app seems working. Do you found any solution?

It was not working because our image size is less that minFaceSize = 20. You need to change the minFaceSize to get it worked. I did
mFaceCropper.setFaceMinSize(20);
and it worked.

thanks your help
------------------ 原始邮件 ------------------
发件人: "Sangam Kumar<EMAIL_ADDRESS>发送时间: 2019年11月26日(星期二) 上午10:14
收件人<EMAIL_ADDRESS>抄送: "John<EMAIL_ADDRESS><EMAIL_ADDRESS>主题: Re: [lafosca/AndroidFaceCropper] not working!!! just can find out where is the face in debug (#9)
It was not working because our image size is less that minFaceSize = 20. You need to change the minFaceSize to get it worked. I did
mFaceCropper.setFaceMinSize(20);
and it worked.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

I try,but fail.Finally I abandon the cut function and just keep the function which can find out the face. My english is not good LOL
------------------ 原始邮件 ------------------
发件人: "Sangam Kumar<EMAIL_ADDRESS>发送时间: 2019年11月26日(星期二) 上午10:14
收件人<EMAIL_ADDRESS>抄送: "John Cheung"<875677993<EMAIL_ADDRESS>主题: Re: [lafosca/AndroidFaceCropper] not working!!! just can find out where is the face in debug (#9)
It was not working because our image size is less that minFaceSize = 20. You need to change the minFaceSize to get it worked. I did
mFaceCropper.setFaceMinSize(20);
and it worked.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


Support GET for HealthCheckHandler

Can we add support for GET requests in HealthCheckHandler? Kubernetes only supports GET and not HEAD requests for its built-in startupProbe and livenessProbe checks, so this would make k8s deployment easier.

solved in https://github.com/unioslo/tsd-file-api/pull/205


Develop

Codecov Report
Patch coverage: 30.63% and project coverage change: +0.18% :tada:

Comparison is base (034f7cd) 24.53% compared to head (958d902) 24.72%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff             @@
##             main      #15      +/-   ##
==========================================
+ Coverage   24.53%   24.72%   +0.18%
==========================================
  Files          48       48
  Lines        2168     2148      -20
  Branches      354      357       +3
==========================================
- Hits          532      531       -1
+ Misses       1617     1599      -18
+ Partials       19       18       -1

Files Changed
Coverage Δ

...pp/discord-bot/services/message/message.service.ts
6.73% <6.38%> (+0.46%)
:arrow_up:

...chatgpt/service/yt-chat-gpt/yt-chat-gpt.service.ts
27.94% <14.28%> (+1.85%)
:arrow_up:

...t/service/image-chat-gpt/image-chat-gpt.service.ts
38.09% <16.66%> (+2.38%)
:arrow_up:

...atgpt/service/pdf-chat-gpt/pdf-chat-gpt.service.ts
40.00% <23.07%> (+2.50%)
:arrow_up:

...atgpt/service/txt-chat-gpt/txt-chat-gpt.service.ts
40.00% <23.07%> (+2.50%)
:arrow_up:

...atgpt/service/url-chat-gpt/url-chat-gpt.service.ts
38.46% <23.07%> (+2.56%)
:arrow_up:

...t/service/audio-chat-gpt/audio-chat-gpt.service.ts
38.88% <25.00%> (+2.52%)
:arrow_up:

...ervices/chatgpt-gateway-service/chatgpt.service.ts
32.89% <38.88%> (+1.31%)
:arrow_up:

...ot/services/setup-keyword/setup-keyword.service.ts
7.40% <40.00%> (+0.49%)
:arrow_up:

...s/yggdrasil-core-engine/src/app/auth/auth.guard.ts
57.14% <66.66%> (+0.89%)
:arrow_up:

... and 3 more

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Update Go Toolset image

The one we used seems to be blacklisted in some way, also switch to the UBI based image so we can get it from the free registry.

Merging to enable builds to pass


Add MiqExpression#to_arel

This allows for simplifying the composition of SQL fragments (as with
AND, OR, etc.) since we no longer need to wrap the result of recursion
in SqlLiteral nodes.
It also allows MiqExpression#to_sql to delegate to this method and
call #to_sql on the result, removing some duplication.
@miq-bot add-label core, refactoring

👍 Looks good!


Fix "Notebook loading error" on colab

There was a missing comma after the array element on line 46, so I added it. From what I can tell, this was causing the colab to be unable to load.

Resolves #79. @wwboyer You also have to remove the comma on line 48, I think. I tried loading your version in colab and it failed: JSON.parse: unexpected character at line 48 column 7 of the JSON data.
Try it here: https://colab.research.google.com/github/wwboyer/AIDungeon/blob/patch-1/AIDungeon_2.ipynb

You're absolutely right. Fix one typo and forget about another. Now it should be good, at least as far as I can tell.

Sorry guys!

No biggie, if I had a nickle for everytime I missed a comma, I'd be a rich man.


ARROW-6074: [FlightRPC][Java] Middleware

(This is on top of #5013 since they would conflict otherwise.)
This is a draft implementation of middleware for Flight in Java, both client-side and server-side, to accompany the corresponding mailing list discussion.
In the integration tests, there's an example of a simplified OpenTracing-like integration. This also sends various uncaught exceptions in the Flight implementation to the middleware for handling.
Some unresolved details:

This allows for both binary and text headers, but this is a bit of a gRPC detail. We may instead to just present one or the other (and fold them into each other, e.g. binary headers get presented as base64-encoded headers).
At this point, we may want to just expose headers to the RPC method bodies as well (through CallContext).
This does its best to expose an HTTP/1-like request flow where headers always precede bodies, and there is always only one set of headers, even though this is not true of gRPC. (gRPC may skip initial headers if the response is an error, and always sends a set of trailers.)
The final (or followup PR) should add a complete OpenTracing example somewhere (e.g. in a contrib/ directory) to ensure that integrating with such APIs works well.

Codecov Report

Merging #5068 into master will increase coverage by 2.08%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #5068      +/-   ##
==========================================
+ Coverage   87.63%   89.72%   +2.08%
==========================================
  Files        1014      674     -340
  Lines      145922   101357   -44565
  Branches     1437        0    -1437
==========================================
- Hits       127886    90946   -36940
+ Misses      17674    10411    -7263
+ Partials      362        0     -362

Impacted Files
Coverage Δ

r/src/recordbatch.cpp

r/R/Table.R

js/src/util/fn.ts

go/arrow/array/bufferbuilder.go

r/src/symbols.cpp

rust/datafusion/src/execution/projection.rs

rust/datafusion/src/execution/filter.rs

rust/arrow/src/csv/writer.rs

rust/datafusion/src/bin/main.rs

go/arrow/ipc/file_reader.go

... and 330 more

Continue to review full report at Codecov.

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

I took a quick look through this, and it seems reasonable, need to do another closer look for details. Two questions:

is there a reason that you accept multiple middleware implementations/factories?  it seems like it might make some of the core code simpler if you only accepted one and provide an implementation as of a composite middleware object.
It would be good to clarify expected thread-safety guarantees for the middleware (sorry if I missed them).

Also note, it looks like a rebase is required.

Thanks @emkornfield for taking a look, I've rebased. I added some more comments about thread-safety of server middleware (FlightServerMiddleware.java) and documented the use of MetadataAdapter.
I chose to allow the user to give a list of middleware in order to have a convenient way to access middleware state from within a RPC method implementation. (I chose this approach as I didn't want to tie us to gRPC's context mechanism.) It could be done with a composite middleware object as you suggest, but that would be another interface on top.

I chose to allow the user to give a list of middleware in order to have a convenient way to access middleware state from within a RPC method implementation.

What are the use cases you had in mind for this?

I chose to allow the user to give a list of middleware in order to have a convenient way to access middleware state from within a RPC method implementation.

What are the use cases you had in mind for this?

In this case, passing an OpenTracing span (or other unique request identifier) from the server middleware to client middleware. Another use case might be implementing an auth mechanism without using Flight's mechanism, and passing the identity of the peer to the method body. (Flight doesn't allow, for instance, making auth optional on certain methods.) I'm not attached to this design, though, so long as there's some way to do it. An alternative might be to let middleware update a Map stored in the CallContext (perhaps using the typed key pattern for better type safety), so that we're not tied directly to the middleware instances.
gRPC uses a context object, which has to be manually passed around throughout the request (this is mostly invisible to you unless you are a middleware author or you spawn threads inside your RPC method implementation). Data gets passed around by means of static final key objects which get/set a corresponding object inside the context. I don't want to expose this in Flight and don't like the odd global-looking state (i.e. I'd rather make Flight put this in CallContext somehow).

Rebased, Travis build: https://travis-ci.com/lihalite/arrow/builds/125596743
I would consider this ready to review, with how to expose headers as a question that could be resolved. If adding a contrib/ directory makes sense, I can add an OpenTracing/OpenTelemetry example as well.

@emkornfield i am not too familiar with this part of arrow (also we are not yet integrated with flight)
will take a stab at reviewing this though..

Thanks @rymurr! Yes, Python/C++ client/servers do not support middleware yet. If a Java middleware adds headers, Python/C++ will ignore them.

Just following up here. I've rebased/updated the branch, are there any further comments on this implementation?

@lihalite I should have some time later in the week to do another review if you think it is warranted.

@emkornfield the code is the same as when you looked, did I address your questions above sufficiently?

What is the status of this PR? It seems like we would want to merge this, review and merge the C++/Python PR, then work on reconciling the details and adding integration tests

I believe it's ready for review, and so is the C++/Python one. I can look at integration at parallel, I think I commented on JIRA asking whether it would be worth refactoring the current script before we add on a lot of new things to it.

I'll take one more pass through this today.

Thanks @emkornfield for the thorough review. I'll address feedback and follow up.

Hopefully I've addressed feedback. I've also brought this up to par with C++/Python (only exposing text headers, using an enum to identify the RPC method being intercepted).
I will report back with benchmarks. As with C++, I don't expect much of a difference with middleware, but 1) the benchmark is broken and 2) the benchmarks we have measure the wrong thing (I would expect it to affect calls/s more than MB/s).
Is there a path to getting Flight benchmarks into Archery, if they're just self-contained localhost ones?

Baseline on master (+patch to fix benchmarks):
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 722.680948 MiB/s. 23680809.290938 record/s. 5783.327245 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 957.121162 MiB/s. 31362946.231556 record/s. 7659.458729 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 1052.723115 MiB/s. 34495631.022257 record/s. 8424.523008 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 622.971845 MiB/s. 20413541.408594 record/s. 4985.395083 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 1095.041172 MiB/s. 35882309.111991 record/s. 8763.177531 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 998.438105 MiB/s. 32716819.837771 record/s. 7990.101741 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 1030.980368 MiB/s. 33783164.684464 record/s. 8250.524479 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 994.156941 MiB/s. 32576534.631242 record/s. 7955.841288 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 1014.400947 MiB/s. 33239890.240287 record/s. 8117.845994 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 1005.636702 MiB/s. 32952703.465825 record/s. 8047.709240 batch/s.

Baseline on this branch:
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 585.023693 MiB/s. 19170056.375622 record/s. 4681.711168 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 1000.070838 MiB/s. 32770321.223802 record/s. 8003.167849 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 973.966051 MiB/s. 31914919.552986 record/s. 7794.261653 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 1001.385129 MiB/s. 32813387.920023 record/s. 8013.685598 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 1026.597626 MiB/s. 33639551.004005 record/s. 8215.451146 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 1015.019718 MiB/s. 33260166.123188 record/s. 8122.797771 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 634.883764 MiB/s. 20803871.185682 record/s. 5080.721421 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 1020.964235 MiB/s. 33454956.060482 record/s. 8170.369369 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 624.611664 MiB/s. 20467275.011115 record/s. 4998.517903 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 614.653123 MiB/s. 20140953.546989 record/s. 4918.823675 batch/s.

If we just always enable interceptors:
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 585.145531 MiB/s. 19174048.762522 record/s. 4682.686189 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 615.882281 MiB/s. 20181230.578687 record/s. 4928.660132 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 1066.380142 MiB/s. 34943144.490068 record/s. 8533.814747 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 1095.946366 MiB/s. 35911970.517956 record/s. 8770.421440 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 640.732409 MiB/s. 20995519.571030 record/s. 5127.525790 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 1039.859213 MiB/s. 34074106.707477 record/s. 8321.578340 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 1085.222835 MiB/s. 35560581.843079 record/s. 8684.605298 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 1081.660765 MiB/s. 35443859.949202 record/s. 8656.099477 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 1060.792128 MiB/s. 34760036.434775 record/s. 8489.096098 batch/s.
Transferred 100000000 records totaling<PHONE_NUMBER> bytes at 1048.367279 MiB/s. 34352899.000164 record/s. 8389.664994 batch/s.

It seems max perf is about the same, but much less consistent. I'll remove the checks and always add the (dummy) interceptor.

+1, thanks for th addressing the comments.  I reset the failing CI build, feel free to merge when everything is green.

Thanks @emkornfield!


Regular Expressions - Match Anything

I wanna a regular expression which match anything like numbers, Spanish words, format numbers e.g: ¡Hola! Mi nombre es Julian y tengo 22 años mi identificación es 1.22-46646
I have tried: .* but it does not work

for me it works: lark.Lark('start: /.+/').parse('ąðć')
\.*\ is apparently not permitted for earley parser because it matches zero-length string.
Also you probably need to exclude terminating character from the matched string, to make it possible to terminate. For example if you want to use space you'll write start: /[^ ]+/.

this didn't work for me. Error:
from lark import Lark
parser: Lark = Lark(r"""
    rterm: "(___hole 0" anything  ")" | ESCAPED_STRING

    anything: /.+/

    %import common.ESCAPED_STRING
    %import common.SIGNED_NUMBER
    %import common.WS
    %ignore WS
    """, start='rterm')
test_strings: list[str] = ["(___hole 0 (fun n : nat => ___hole 1 (___hole 2 eq_refl : 0 + n = n)))"]
for test in test_strings:
    print(test)
    print(parser.parse(test).pretty())
(___hole 0 (fun n : nat => ___hole 1 (___hole 2 eq_refl : 0 + n = n)))
Traceback (most recent call last):
  File "/Users/brandomiranda/miniconda/envs/iit_term_synthesis/lib/python3.9/site-packages/IPython/core/interactiveshell.py", line 3398, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-5-5499195ecb8d>", line 18, in <cell line: 16>
    print(parser.parse(test).pretty())
  File "/Users/brandomiranda/miniconda/envs/iit_term_synthesis/lib/python3.9/site-packages/lark/lark.py", line 581, in parse
    return self.parser.parse(text, start=start, on_error=on_error)
  File "/Users/brandomiranda/miniconda/envs/iit_term_synthesis/lib/python3.9/site-packages/lark/parser_frontends.py", line 106, in parse
    return self.parser.parse(stream, chosen_start, **kw)
  File "/Users/brandomiranda/miniconda/envs/iit_term_synthesis/lib/python3.9/site-packages/lark/parsers/earley.py", line 305, in parse
    raise UnexpectedEOF(expected_terminals, state=frozenset(i.s for i in to_scan))
lark.exceptions.UnexpectedEOF: Unexpected end-of-input. Expected one of:
	* RPAR

@SupraSummus what is the meaning of the forward slashes in /.*/?

@brando90 It is the syntax for regex, see https://lark-parser.readthedocs.io/en/latest/grammar.html#terminals.


Broken styling on numbered list

Visible on pages like https://docs.konghq.com/0.14.x/getting-started/enabling-plugins/ and https://docs.konghq.com/0.14.x/getting-started/adding-consumers/

"Fixed" this by correctly putting the numbers after the heading indicator (###) - this correction took place in at least a couple different PRs.


kfctl updates for v0.7 - GCP docs only

This PR updates the docs in the GCP section to use the new kfctl semantics in v0.7.
The PR addresses some of the updates for https://github.com/kubeflow/website/issues/1226. Further PRs will update non-GCP docs.

This change is

Preview:

https://deploy-preview-1234--competent-brattain-de2d6d.netlify.com/docs/gke/deploy/deploy-cli/
https://deploy-preview-1234--competent-brattain-de2d6d.netlify.com/docs/gke/customizing-gke/
https://deploy-preview-1234--competent-brattain-de2d6d.netlify.com/docs/gke/deploy/monitor-iap-setup/
https://deploy-preview-1234--competent-brattain-de2d6d.netlify.com/docs/gke/deploy/delete-cli/

Note: I've set the config URLs to interim paths in /kubeflow/manifests/master/. (Example.) When we know the path for the v0.7 RC1 release, we must update these paths.

This PR is now ready for review. I'm applying a hold to allow for multiple reviewers.
/hold

/assign @jlewi
/assign @swiftdiaries

/assign @thedriftofwords

Thank you so much @sarahmaddox

Thanks @jlewi PTAL
I'll work on getting the other kfctl PRs to the same point as this one, and then discuss with the community whether we're ready to brand the website as v0.7. I think we should be good to do that, once all the deployment guides are correct for the latest v0.7 RC.
If agreed, then I'll merge all the deployment guides and rebrand the site at the same time.

Status: I'm busy updating the files for the coming change in name of config file and in 'kfctl delete'. Stay tuned. Thanks @jlewi for the info!

@jlewi I've applied all your feedback. PTAL.

Thanks @jlewi! The commenting format on this PR has turned weird, so I've copied your comments and replied in line:

Users currently have to do one of the following

Pick a zone with K80s
or
Disable node-autoprovisioning or change node-autoprovisioning config.

To see which accelerators are in which zones they can run
 gcloud compute accelerator-types list

To disable node-autoprovisioning they would run
kfctl build -f ...
Then edit gcp_config/cluster-kubeflow.yaml and set enabled to false
https://github.com/kubeflow/manifests/blob/4d2939d6c1a5fd862610382fde130cad33bfef75/gcp/deployment_manager_configs/cluster-kubeflow.yaml#L73

Good info. I've added the info to the customization guide, and added a link from the deployment guide instead of complicating the deployment guide.

nit: "This also becomes" -> "This will also be" or "This will be used as the"
Users create ${KF_DIR} below "becomes" implies to me that some other process is creating the directory

Good point. Updated.

I think the final names will be
https://raw.githubusercontent.com/kubeflow/manifests/v0.7-branch/kfdef/kfctl_gcp_iap.0.7.0.yaml
Those files don't exist yet but I think you could update the docs to use that pattern so the docs don't need to be updated again once we create those files.

I think I'll keep going with the RC URLs, for two reasons. First, we may decide to publish the docs when we have a good RC. And second, reviewers in the other CLs are sure to point out the broken link. :)

@sarahmaddox apologies for the delay
/lgtm
/approve
The 0.7.0.yaml files now exist for the GCP configs
https://github.com/kubeflow/manifests/tree/v0.7-branch/kfdef
Did you want to update the links in this PR or get it merged and then we'd fix in a follow on PR.
/hold

The 0.7.0.yaml files now exist for the GCP configs
https://github.com/kubeflow/manifests/tree/v0.7-branch/kfdef
Did you want to update the links in this PR or get it merged and then we'd fix in a follow on PR.

Thanks @jlewi! I'll update the version number and YAML URLs in this PR and all related PRs, so that we can submit them at approx the same time. I'll do that tomorrow morning PT.
I'll also put together a PR to brand the website as v0.7.
Are you happy enough with RC5 for us to follow the above steps? (I think publishing the docs and rebranding the website is kind of a statement that we have a good RC.)

@sarahmaddox a couple clarifications

I think only the GCP configs have 0.7.0 suffixes right now;

For AWS and existing (and GCP) we should match what is current in https://github.com/kubeflow/manifests/tree/v0.7-branch/kfdef and if it changes we will update the docs.

When we are happy with the RC we will remove the RC label from it an publish it just as 0.7.0

I think it makes sense to publish the docs with reference to an RC release (whichever is the latest) so that we can more people to try things out.
Lets keep the default docs as 0.6 until we final the release (i.e. remove the RC tag)
The current RC is looking pretty good but there are still a couple known issues.

Thanks @jlewi This PR now reflects the latest RC and config URLs. If you're happy to LGTM, we can merge the PR.
/hold cancel

/lgtm
/approve


Fix Rollup + sourceMapContents: Mismatched sourcesContent

This fixes #678.
In compilers/esm.js L121, a workaround had been introduced for Babel not respecting the sourceFileName option:
    // for some reason Babel isn't respecting sourceFileName...
    if (output.map && !load.metadata.sourceMap)
      output.map.sources[0] = load.path;

However, I believe that this option is not meant to be used along with inputSourceMap, as in the later case the original source file names are already embedded in the provided sourcemap, whereas sourceFileName is designed to provide the original file name when Babel is the entry point of the build pipeline (and the code is provided as a string and not a path).
The corresponding sourceMapContent test seems broken at the moment, hence no tests in the PR :(

I ran into a similar problem, but didn't have time to investigate. This does solve the problem - at least it no longer throws an exception - so it's good.

Ok great, thanks for the PR!

@guybedford Has this PR, made it's way into JSPM 17?

@alexisvincent yes in 0.17.0-beta.32.

Weird, I'm still getting the error. Happens when I set sourceMap: 'inline'

@guybedford Can we please revert this PR. It breaks other things as described in #743


Adding support for MerlinEM Medipix3 detector

We're planning on starting to utilize Instamatic for automating parts of our TEM workflows, which includes MerlinEM detectors. So at some point in the future (not sure exactly when) we'll have a pull request which includes remote control of the Quantum Detector MerlinEM detectors via the TCP/IP API.
This will most likely be via incorporating the code from my old library Merlin Interface, which I can relicense to work with Instamatic's license.
At first this will most likely be just the control part, without getting data.

Hi @magnunor great to hear you are interested in contributing some code to instamatic! Merlin support is definitely something that would be great to have. I have been in contact with Quantum Detectors over the last couple of weeks to support the Merlin detector for the data collection part. So I think our efforts will be quite complementary :-)

Hi @stefsmeets, I noticed another branch for the Merlin. We will be getting a Merlin soon, and we would certainly like to test Instamatic on our system. Have you tested the new software with a Merlin detector?

Thanks for the update! We'll be getting a Merlin with from QD in a few weeks, so I will test it then! I had a chance to set up Instamatic on our microscope using a simulated camera this week. I have some issues that I will raise in another post, but very excited to get it working with the Merlin.

@stefsmeets, I noticed the merlin branch. Could you make a pull request with this branch? To make it easier to collaborate on the changes. I think I could include some of the code from https://gitlab.com/fast_pixelated_detectors/merlin_interface directly, after relicensing it to BSD.

Yeah, I can do that later this week. I may also merge to main directly to have a baseline to work from.

I just merged preliminary support for the merlin detector in #65
It's still early stages (see limitations in the PR 😅), but the interface at least works well.

Nice! I'll try to have a look at this sometime in June, but not 100% sure. In any case, I'll have some students working on this from the autumn.

The merlin interface is working and seems to be quite stable. So I think this issue can be closed. Feel free to re-open or make a new issue if you run into any issues with testing.


Declaration of "bindables" should be sorted

Using the grid.js wrapper as example. it is easy to see that the current "random" ordering of declarations makes it easier to to miss declaring an attribute as bindable - as it was with height attribute in grid.js wrapper

Fixed grid.js - https://github.com/aurelia-ui-toolkits/aurelia-kendoui-plugin/commit/6392bfef1f43932414cb6eb39a65a713c3c6a338

as this is now in our componente checklist, can this be closed? before we release a wrapper we'll sort the bindables

Yes, of course


Census JSON schema

Following on from #4, @callummole to provide a description of the Census data that conforms to the to-be-determined JSON schema.

We now have an example here


OCM-785 | docs: Add instructions to get rosa binary from latest

Existing rosa-aws-cli:latest image in registry.ci could be leveraged to test the binary
locally without the need to build from source code. Added instructions to get the rosa
cli binary from the container.

/lgtm
/approve

@enriquebelarte can you post a link to the pipeline where the image is pushed to the registry?

@enriquebelarte can you post a link to the pipeline where the image is pushed to the registry?

https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/branch-ci-openshift-rosa-master-images-images/1658867238247075840

/lgtm


Upgrade to lens breaks ability to connect to eks clusters: E0112

Describe the bug
When upgrading to latest lens (required upgrade now) the connection to clusters no longer works at all.  There is now a E0112 error.
E0112 16:41:52.132276 16677 proxy_server.go:147] Error while proxying request: getting credentials: exec: executable aws not found

It looks like you are trying to use a client-go credential plugin that is not installed.

To learn more about this feature, consult the documentation available at:
https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins

getting credentials: exec: executable aws not found

It looks like you are trying to use a client-go credential plugin that is not installed.

To Reproduce
Steps to reproduce the behavior:

install old lens and connect to an eks cluster
upgrade lens and reconnect to cluster....
get error

Expected behavior
no error
Screenshots

Environment (please complete the following information):

Lens Version:

OS: OSX

Installation method (e.g. snap or AppImage in Linux): dmg

Logs:
When you run the application executable from command line you will see some logging output. Please paste them here:
Your logs go here...

Kubeconfig:
Quite often the problems are caused by malformed kubeconfig which the application tries to load. Please share your kubeconfig, remember to remove any secret and sensitive information.
there was no change in the kubeconfig.

Additional context
This only happens with lens.  Terminal and kubectl work fine.  Lens is completely broken here.

What shell are you using? Is it configured as your default shell?

I am also getting this error

@jaydeland Can you answer the questions above for yourself?

I am using zsh - kubectl commands work as expected, as does the VS Code Kubernetes Plugin

Do you see that notification?

I don't see that noticiation. The lens log has this:
error: [CLUSTER]: Failed to connect to "arn:aws:eks:us-east-1:711984989527:cluster/internal-test": StatusCodeError: 500 - "getting credentials: exec: executable aws not found\n"
debug: getting credentials: exec: executable aws not found
 {"isError":true,"meta":{"accessible":false,"disconnected":false,"id":"ca04dcb6180b9dcdbf1a8b4c89ef4fb6","name":"arn:aws:eks:us-east-1:711984989527:cluster/internal-test","online":false,"ready":false}}
info: [CLUSTER]: activate {"accessible":false,"disconnected":false,"id":"ca04dcb6180b9dcdbf1a8b4c89ef4fb6","name":"arn:aws:eks:us-east-1:711984989527:cluster/internal-test","online":false,"ready":false}
info: [CLUSTER]: bind events {"accessible":false,"disconnected":false,"id":"ca04dcb6180b9dcdbf1a8b4c89ef4fb6","name":"arn:aws:eks:us-east-1:711984989527:cluster/internal-test","online":false,"ready":false}
debug: Starting connection ... {"isError":false,"meta":{"accessible":false,"disconnected":false,"id":"ca04dcb6180b9dcdbf1a8b4c89ef4fb6","name":"arn:aws:eks:us-east-1:711984989527:cluster/internal-test","online":false,"ready":false}}
info: [CLUSTER]: reconnect {"accessible":false,"disconnected":false,"id":"ca04dcb6180b9dcdbf1a8b4c89ef4fb6","name":"arn:aws:eks:us-east-1:711984989527:cluster/internal-test","online":false,"ready":false}
debug: [KUBE-AUTH]: stopping local proxy {"accessible":false,"disconnected":false,"id":"ca04dcb6180b9dcdbf1a8b4c89ef4fb6","name":"arn:aws:eks:us-east-1:711984989527:cluster/internal-test","online":false,"ready":false}
debug: Authentication proxy started {"isError":false,"meta":{"accessible":false,"disconnected":false,"id":"ca04dcb6180b9dcdbf1a8b4c89ef4fb6","name":"arn:aws:eks:us-east-1:711984989527:cluster/internal-test","online":false,"ready":false}}
info: [KUBE-AUTH-PROXY]: found port=62072
debug: Refreshing connection status ... {"isError":false,"meta":{"accessible":false,"disconnected":false,"id":"ca04dcb6180b9dcdbf1a8b4c89ef4fb6","name":"arn:aws:eks:us-east-1:711984989527:cluster/internal-test","online":false,"ready":false}}

Do you see anything about shell env or shell sync failing?

Nope - anywhere else I should look?

SHELL-SYNC is the prefix, you should see [SHELL-SYNC]: Synced shell env if it worked.

@barkerja what OS are you running lens on? What version of lens are you using and if you look at the logs do you see something about SHELL-SYNC

@barkerja No I mean the main ones. You can get them by do Help > Export Support Logs

Do you see any notification about failing to sync env vars?

Have you used chsh to switch to fish or set your "Default Shell" setting to fish?

If you do the following:
$ node
> os.userInfo().shell

Is the output /bin/fish? If so, can you please check your settings within Lens to make sure that it wasn't previously set to zsh

The only thing that I can think of is that somewhere along the line that setting got set which causes this issue.
I know that you have been responding more than OP. But I am going to close this as fixed.

using MacOS, had very long uptime, restarting system worked the trick for me ✅

I'm having this issue with the latest version of lens 2023.11.81519-latest
Was not an issue in the previous version


Add PositionName

Add PositionName as ValueObject

Coverage remained the same at 100.0% when pulling cb936506b64a6b6dedcc7463829a7f7f845a22b4 on add-position-name into e8c56597f5fd5d62a9c910a573fe5aa3dc3d7c3e on develop.

Coverage remained the same at 100.0% when pulling cb936506b64a6b6dedcc7463829a7f7f845a22b4 on add-position-name into e8c56597f5fd5d62a9c910a573fe5aa3dc3d7c3e on develop.

@MasayukiFukada LGTM


[LIBCLOUD-1017] Improvements to Azure ARM compute driver

[LIBCLOUD-1017] Improvements to Azure ARM compute driver
Description
The following are the proposed changes in brief:

Add ability to set API version to be used
Add functionality to resize a volume in Azure
Add functionality to update the network profile of a node
Add functionality to update a network interface's properties
Add functionality to check IP address availability
Create and Update some fixtures
Some minor fixes to docstrings

Status

done, ready for review

Checklist (tick everything that applies)

[x] Code linting (required, can be done after the PR checks)
[x] Documentation
[x] Tests
[ ] ICLA (required for bigger changes)

Notes to reviewers

I am still in doubt about the fixtures I generated

I don't know if setting your own API version is actually a good idea?  The idea is that the driver code is written against a known API version.  If you tell Azure to use a different API version, the driver code may be out of sync if the Azure API has a different expectation or response than what the driver code was written for.  What's your use case?

@tetron My main concern was using a single API version for all the calls. But, I also found that I was not able to tag a network interface in the 'West US 2' region with the older version.
Here's part of my stacktrace that was the reason behind me letting users specify the version:
  File "/Users/palash.gandhi/git/libcloud/libcloud/compute/drivers/azure_arm.py", line 1959, in ex_create_tags     else:   File "/Users/palash.gandhi/git/libcloud/libcloud/common/azure_arm.py", line 228, in request     method=method, raw=raw)   File "/Users/palash.gandhi/git/libcloud/libcloud/common/base.py", line 637, in request     response = responseCls(**kwargs)   File "/Users/palash.gandhi/git/libcloud/libcloud/common/base.py", line 153, in __init__     headers=self.headers) BaseHTTPError: [NoRegisteredProviderFound] No registered resource provider found for location 'westus2' and API version '2016-04-30-preview' for type 'networkInterfaces'. The supported api-versions are '2014-12-01-preview, 2015-05-01-preview, 2015-06-15, 2016-03-30, 2016-06-01, 2016-07-01, 2016-08-01, 2016-09-01, 2016-10-01, 2016-11-01, 2016-12-01, 2017-03-01, 2017-04-01, 2017-06-01, 2017-08-01, 2017-09-01, 2017-10-01, 2017-11-01, 2018-01-01, 2018-02-01, 2018-03-01, 2018-04-01, 2018-05-01, 2018-06-01, 2018-07-01, 2018-08-01'. The supported locations are 'westus, eastus, northeurope, westeurope, eastasia, southeastasia, northcentralus, southcentralus, centralus, eastus2, japaneast, japanwest, brazilsouth, australiaeast, australiasoutheast, centralindia, southindia, westindia, canadacentral, canadaeast, westcentralus, westus2, ukwest, uksouth, koreacentral, koreasouth, francecentral'
That said, I agree that the driver wouldn't expect a different response, but shouldn't the driver at least use the same API version instead of using different versions for multiple calls?
And if not, I am open to suggestions to get around this without letting users specify the version.

I am not sure why the travis-ci build hasn't been updated even after the build has passed. I am also considering not adding functionality to let users specify the API version to be used and keeping that in mind I will close this PR and reopen a new one with the hope that the checks results are updated here.


DeliveryMap-Cannot read property 'length' of null

Apparently, there is a little bug in DeliveryMap.js when markers is null at lines 21 and 40. It is not checking for null.
line 21: if (map.addedMarkers.length !== markers.length){
line 40: markers.forEach((marker, index) => {
So, I changed line 21 to:
if ((map.addedMarkers && markers) && (map.addedMarkers.length !== markers.length)) {
and added a condition for the else at line 39:
else if (markers) {
It works perfect now.

@RahimPasha  you should create Pull Request of the fix. Somebody from the team will review and take it forward.


Update README.md

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

/retest

/retest

/retest

/retest

retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest


Remove Streamlit Core support for Python 3.7

📚 Context
Streamlit no longer supports Python 3.7 as of Streamlit version 1.24.0
🌐 References
Notion: Doc Request: Update Python versions for Cloud
Contribution License Agreement
By submitting this pull request you agree that all contributions to this project are made under the Apache 2.0 license.

This PR includes the commits from PR#716. If the Cloud update is published ahead of 1.24.0, then PR#716 can merge first. If the update ends up concurrent with 1.24.0, then this PR alone will suffice to reduce commit clutter.


Notes: Init notes interface

Establish an Interface for Client Notes and Country Notes to serve as an easy interface for others to use.

ignore this issue creation


feat: mnemonic validation on wallet creation

:tada: This PR is included in version 1.0.0-dev.5 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


XmlnsDefinitionAttribute does work with XamlCompilationOptions.Compile nor Intellisense

Please mention that this XmlnsDefinitionAttribute doesn´t work work XamlC i.e.
[assembly: XamlCompilation(XamlCompilationOptions.Compile)]

nor does it enable intellisense

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

ID: 3a849344-bfe7-89eb-3949-10591484a2cf
Version Independent ID: 8be4b6ea-3cd8-8d74-58db-b07dcdf78ab6
Content: XAML Custom Namespace Schemas in Xamarin.Forms - Xamarin
Content Source: docs/xamarin-forms/xaml/custom-namespace-schemas.md
Product: xamarin
Technology: xamarin-forms
GitHub Login: @davidbritch
Microsoft Alias: dabritch

Hi @ahmedalejo
I just tried the sample and enabled XAMLC in the MyControls library project. It compiled/ran just fine.
I'll close the issue here as you've also logged it at https://github.com/xamarin/Xamarin.Forms/issues/11721

Thanks for the feedback @davidbritch could point to the sample project you tested it on?
I´ll follow up on xamarin/Xamarin.Forms#11721

@ahmedalejo
https://github.com/xamarin/xamarin-forms-samples/tree/master/XAML/CustomNamespaceSchemas

@davidbritch sorry for the delay. I had solved the issue with a workaround and moved forward.
The following seems to work
//in: MyCompany.Controls.csproj
[assembly: XamlCompilation(XamlCompilationOptions.Compile)]
[assembly: XmlnsDefinition("http://mycompany.com/schemas/controls", "MyCompany.Controls")]

but not the following
//in: CustomNamespaceSchemaDemo.csproj
[assembly: XamlCompilation(XamlCompilationOptions.Compile)]
[assembly: XmlnsDefinition(
    "http://mycompany.com/schemas/controls",
    Na"MyCompany.Controls",
    AssemblyName: "MyCompany.Controls")]


Simplify sampled curves

When the animation is hand made, many of the curves are very smooth. Therefore, it should be possible to reduce the number of keyframes.
The exporter should fit a cubic spline to the curves, maybe using the keyframes from the artists as knob hint positions.
Maybe Maya's built-in key reducers could be used for this? See MEL's simplify command
The idea is as follows:

The fitting should start at the root node.

The small error introduced by the fitted curve should be corrected by modifying the child node local transforms in such a way that they are identical to their original world transforms.

Ideally the error is measured by applying skinning and computing the error at the vertices. However, since the same rig can be used for multiple characters, this is not a perfect approach, so it might be better to just check the errors on the world transforms (origin point and origin + length*direction point)

An extension could be provided that stores the differences between the original samples and fitted curve, using very few bits. This would also work for mocap

An extension could store the logarithm of the quaternion curves (as quaternions should be linearly blended in their log space, GTLF incorrectly blend quaternions linearly). See also this code

For other approaches, see also ACL, gltfPack
I wasn't able to find a viewer for the animation curves, so add one too.

I was able to reuse this mit licensed code.
https://github.com/robertjoosten/maya-keyframe-reduction
It works very well.

There's also state of the art research here:
C2 Continuity!!!
http://www.cemyuksel.com/research/interpolating_splines/

Thanks! The problem is that glTF uses simple y=at³ + bt² + ct +d piecewise cubic polynomials.
Maya's curves and the one in the papers are real 2D curves, e.g. both X and Y are function of the curve parameter t... This allows the user to have a lot of freedom creating animation curves, but it is very expensive to interpolate, e.g. to find Y for a give time X value, you first need to find the curve parameter from that X, and that is slow. Too slow for games. Actually the glTF spec explicitly mentioned this.
Nevertheless the papers and code you provided look very very interesting, and I will certainly look into these.

@ziriax As far as I'm aware currently frames are always stored for every frame - even when e.g. a part of the animation is static for a few frames. If I were to implement logic to filter out those keys that are redundant (e.g. previous + next frame are not different than current frame) where should that logic roughly be implemented?

I think NodeAnimation.cpp, finish method. It already has a TODO for this


Run CI w/o conda env file

Wondering if we should run the CI tests from an environment installed from the pyproject.toml file. This would help prevent issues like: https://github.com/TomNicholas/VirtualiZarr/issues/88 in the future.

Companion PR: https://github.com/TomNicholas/VirtualiZarr/pull/90

This was closed by #90 right?


WIP - refactor rendering for higher image quality

Addressing  #104, #105 and faster supersampling rendering.

Merging this admittedly huge PR as 1.0.0 release candidate.


Documentation has many inaccuracies, leads to much confusion

When reading the documentation, it is confusing to see remnants left behind from its Guild Mesh sources.
For example, compare the following:

https://developer.adobe.com/graphql-mesh-gateway/reference/extending-unified-schema/#programmatic-additionalresolvers
https://the-guild.dev/graphql/mesh/docs/guides/extending-unified-schema#programmatic-additionalresolvers

The Guild version references meshrc.yaml, and proceeds to show an example in YAML format. The Adobe version also references meshrc.yaml, but shows an example in JSON format. A reader with no knowledge of the underpinnings of Adobe API Mesh might think they completely missed an earlier guide.
Moreover, the sample projects used to guide the reader, such as multiple-sources-prog-resolvers, are never really explained in the Adobe documentation.
There are many examples of these inconsistencies throughout other areas of documentation. Whenever I read the Adobe docs, I must also have the corresponding version from The Guild open in another tab to compare for truth.
This ends up feeling very sloppy. I also question the integrity of the approach to documentation. To copy sources from another location and replace their examples to match some of the subtle differences in the Adobe implementation seems careless or disingenuous. I think it would be more valuable to re-write documentation almost from scratch, with actual use cases that would be common to the platform and its ecosystem (ex: e-commerce).
My intent here is to be constructive. I love the capabilities that this service can deliver on AEP for its customers. My ask is that you reconsider how you're documenting its features and get more precise in the guidance your giving.

Thanks for the feedback @vbuck. We've addressed some of the issues with the /reference/ section in https://github.com/AdobeDocs/graphql-mesh-gateway/pull/75. Take a look and let me know if you have any feedback.
We are uniquely challenged in that the API Mesh uses a specific version of The Guild's GraphQL Mesh and their documentation is not versioned. Each time the GraphQL Mesh packages are updated a large PR like the one linked above is required to accommodate the changes. As we develop a more consistent relationship between the GraphQL Mesh packages and the API Mesh, we will likely rewrite or remove the /reference/ section entirely and link to the Guild's documentation.

Thanks, @jhadobe. It looks like you've made many updates since I last checked that PR. Also, I understand what you mean about maintaining unversioned docs for versioned packages. I think that further supports the idea of writing your own documentation to reflect your implementation/flavor of The Guild's offering (if not linking directly to it for further reading). Maybe this should be moved to a roadmap item as the undertaking would be quite large. We can collaborate from there.
Citing the specific example in my issue, I see where you've updated the meshrc references; however, it looks like maybe it was a find & replace exercise and not one of comprehension of the change. What I mean is, Adobe docs give the example of using AIO CLI to create a mesh.json file (here). But in 27f8b90b you mention .meshrc.json. This is a minor detail, but to my original point is likely to confuse the reader; ie: "What is a dot-meshrc file?"

Thanks for your response @vbuck. I have clarified the unsupported transforms in PR #75. Please let me know if you have any more suggestions. I would be happy to collaborate with you further.
The .meshrc file is an example file that The Guild's documentation refers to.  "meshrc" is just the name of the file. The Guild provides a link to the file here: https://github.com/charlypoly/graphql-mesh-docs-first-gateway/blob/master/packages/multiple-sources/.meshrc.yaml

I believe this is closed by PR #75


Release 23.1

January 2024 release
Milestone: January'24
Version: 23.1
Features

#1969
#1462
#1974
#1953
#1944
#1972
#1769
#1826

January 2024 (version 23.1.0-beta0001) aka Hornussen release

Codenamed as Hornussen Sport
Read the Docs: Ocelot 23.1

Focus On

Multiplexing middleware aka Request Aggregation feature

Significant refactoring and design review of the Multiplexer
Optimizing multiplexer performance: HttpContext is not copied when there is only one downstream route, and etc.
Fixed the bug in the multiplexer: HttpContext.User information was not copied if there was more than one downstream request.

System routing. Content streaming when Transfer-Encoding: 'chunked'

Correction of the bug when creating requests: The header Transfer-Encoding: chunked was present even when there was no content or the request body size was 0. These cases are now addressed.

Updates of the features: QoS, Load Balancer and Error Status Codes

Quality of Service: Possibility of implementation of custom Polly v8.2 providers. New AddPolly extension methods.
Load Balancer: Extension of the route key format, ensuring that the key remains unique for cases of UpstreamHost route property and ServiceName vs ServiceNamespace properties in Consul setup.
Error Status Codes: When 413 Content Too Large, Ocelot now returns a 413 PayloadTooLargeError (Ocelot error code 41).

Documentation for Request Aggregation

Request Aggregation

Stabilization aka bug fixing

See all bugs of the January'24 milestone

Honoring :medal_sports: aka Top Contributors :clap:
1st :1st_place_medal: goes to Guillaume Gnaegi for delivering 2 features
2nd :2nd_place_medal: goes to Alexander Reinert for delivering 1 feature in 8 files changed
3rd :3rd_place_medal: goes to Steven for delivering 1 feature in 5 files changed with 353 insertions
Starring :star: aka Release Influencers :bowtie:
:star::star:  Guillaume Gnaegi
:star:  Alexander Reinert
:star:  Chris Williams
:star:  Masoud Bahrami
:star:  Raynald Messi├й
:star:  Steven
:star:  Ugway77
Features in Release 23.1.0-beta0001
36986d6e by Guillaume Gnaegi on Friday, March 01 at 18:33 →
#1825 #1330 #1287 #1069 Improvements of the multiplexing middleware (#1826)
42ac3ca5 by Guillaume Gnaegi on Friday, March 01 at 12:00 →
#749 Bad error handling for IOException while reading incoming request body (#1769)
319e397d by Alexander Reinert on Thursday, February 29 at 22:16 →
#1971 #928 Avoid content if original request has no content and avoid Transfer-Encoding: chunked if Content-Length is known (#1972)
8845d1b9 by Steven on Thursday, February 29 at 09:44 →
#849 #1496 Extend the route key format used for load balancing making it unique (#1944)
171e3a7b by Masoud Bahrami on Tuesday, February 27 at 19:05 →
Logging bug in HttpRequesterMiddleware (#1953)
0404c247 by Raynald Messi├й on Monday, February 26 at 09:24 →
#1844 More open customization of Polly use (#1974)
108bedef by Ugway77 on Thursday, February 22 at 23:38 →
#1396 Lost context User in MultiplexingMiddleware (#1462)
a9dff7c1 by Chris Williams on Thursday, February 22 at 04:25 →
Fix typo in the name of the DistributedCacheRateLimitCounterHandler class (#1969) by @williamscs


Cannot set default in subclass with subscripted generic hint (eg: Union)

Checks

[x] I added a descriptive title to this issue
[x] I have searched (google, github) for similar issues and couldn't find anything
[x] I have read and followed the docs and still think this is a bug

Bug
Output of python -c "import pydantic.utils; print(pydantic.utils.version_info())":
             pydantic version: 1.9.0
            pydantic compiled: True
                 install path: <some venv>
               python version: 3.9.7 (default, Nov 15 2021, 13:16:09)  [Clang 13.0.0 (clang-13<IP_ADDRESS>)]
                     platform: macOS-12.0.1-arm64-arm-64bit
     optional deps. installed: ['typing-extensions']

When checking the default field value on a subclass, we call lenient_issubclass (and thus issubclass) with the original type hint - which errors if that is a subscripted generic such as Union[int, str]:
from typing import Union

from pydantic import BaseModel

class A(BaseModel):
    x: Union[int, str]

class B(A):
    x = "hi"  # 1.9.0 - TypeError: Subscripted generics cannot be used with class and instance checks

This wasn't supported before https://github.com/samuelcolvin/pydantic/pull/3018 / 1.9.0 anyway (one would have had to explicitly set the type hint in the subclass - which still works, so no regression), but I missed that lenient_issubclass doesn't handle Union/generics. Apologies for not getting around to testing this out before 1.9.0. :/
--
I'm happy to take a crack at fixing, but what is the best approach? At the simplest, should lenient_issubclass be made smarter to (at least) support Unions?
cc @PrettyWood as reviewer on https://github.com/samuelcolvin/pydantic/pull/3018

Your example works on V1.10.X, so it seems like it got fixed at some point.
For Pydantic V2 though we require explicit type hints on all fields, including overrrides, so you'll have to do:
from typing import Union

from pydantic import BaseModel

class A(BaseModel):
    x: Union[int, str]

class B(A):
    x: Union[int, str] = "hi"

For Pydantic V2 though we require explicit type hints on all fields

Is there a way I can request (or help implement) this not be required on subclasses for fields already defined (or maybe an explanation of the motivation I missed)? 😅 I'm working on a library that expects users to subclass some base classes defined in the library and requiring it would add a lot of stutter to the end users' code.

@samuelcolvin do you remember why we went back to the old behavior?


Adding example to test Gauge for leaks.

This test will iterate through five Gauge instances with random radius and thickness parameters.
It checks for the fill color escaping from inside the gauge.
It is coded for the FunHouse but can be easily adapted for other devices,
just update the display and top_group variables.

Thank you!


Swift: Add flag for optional enums

Added swift option optionalEnums
Use case:
When an API where Enums are used and might be expanded later versions. Decoding would fail in those cases, with this option it's now decoded as nil.

⭐ ⭐ ⭐
Very useful, been thinking about this addition!

@afajl thank you! Sorry for delay. We've just updated our CI to work again.
Can you add a test for this option? Add it to quickTestRendererOptions in languages.ts under the Swift definition.


UIActivityViewController, SMS modal, cancel button not visible

let  activityViewController : UIActivityViewController = UIActivityViewController(
            activityItems: [viewImage], applicationActivities: nil)
        // Anything you want to exclude
        activityViewController.excludedActivityTypes = [
            UIActivityTypePostToWeibo,
            UIActivityTypePrint,
            UIActivityTypeAssignToContact,
            UIActivityTypeSaveToCameraRoll,
            UIActivityTypeAddToReadingList,
            UIActivityTypePostToFlickr,
            UIActivityTypePostToVimeo,
            UIActivityTypeAssignToContact,
            UIActivityTypePostToTencentWeibo,
            UIActivityTypeAirDrop
        ]

        self.presentViewController(activityViewController, animated: true, completion: nil)

When showing the action sheet to share a content, then selecting SMS share, the modal that appears lake its "title" and its cancel button. this is due to the replacement of the original viewWillAppear: methode.

Hello did you find the correct answer?

already fixed. Thx.


Delete removed elements from the clone while running GC

What type of PR is this?

Uncomment only one  /kind <> line, hit enter to put that in a new line, and remove leading whitespace from that line:
/kind api-change

/kind bug

/kind cleanup
/kind deprecation
/kind design
/kind documentation
/kind failing-test
/kind feature

What this PR does / why we need it:
Delete removed elements from the clone while running GC
When initially designing the GC, it was implemented so that only removed
elements from the original were deleted. However, to solve the problem
of accumulating removed elements in the clone, they are also deleted.
Which issue(s) this PR fixes:

Fixes #100 and Related to https://github.com/yorkie-team/yorkie-js-sdk/pull/101
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

Additional documentation:

As a result of testing, I confirmed that it works normally. 👍


polymer-project.org Element catalog - downloading individual elements error

After selecting the  "elements folder" method and then clicking download, I get this error message -

I'm on the latest Chrome OS dev channel.

This issue was moved to Polymer/polymer-element-catalog#168


uv_getrusage return wrong ru_maxrss for android

Version:  v1.45.0
Platform:  android arm64 samsung

ru_maxrss for android return KB,  not Byte.  not match the document

In the ios this value show result in BYTE,  in android it shoud in KB.

In android, the memory show in KB, I get result from libuv says app use 34M memory,  but use top -p from adb shell, show the same pid just use 8.2M RES.
I guess the RES and ru_maxrss is same for apples os, not same for linux ?

ru_maxrss is in kilobytes, also on android (unless google really hacked up their kernel fork recently.)
My hunch is top reads from /proc/<pid>/stat and doesn't use getrusage(). The RSS field from that file (23rd when counting from zero) is computed somewhat differently than ru_maxrss.
I wouldn't call it a bug, more a platform quirk.

ru_maxrss is in kilobytes for android and linux, but bytes for apple ios.  test confirmed.
libuv should return them in same unit.

Apple's own documentation claims otherwise:

ru_maxrss    the maximum resident set size utilized (in kilobytes).

That said, the xnu source code suggests it's indeed in bytes, not kilobytes. I'll open a pull request.


clean up

removed dead import, unused code, added dead_code flag
wrapped test function in test module, splitting imports for mod test from others.3.

nothing broken

LGTM!


cmd/go/internal/modcmd: download with -json flag doesn't print JSON objects to stdout for some module download errors

Go version
go version go1.23.1 darwin/arm64
Output of go env -changed in your module/workspace

GOPROXY='http://<IP_ADDRESS>'

What did you do?
https://pkg.go.dev/cmd/go#hdr-Download_modules_to_local_cache says:

The -json flag causes download to print a sequence of JSON objects to standard output, describing each downloaded module (or failure), corresponding to this Go struct: type Module struct { ... }

It seems that doesn't always happen for some networking errors observed in the Go build system (build<PHONE_NUMBER>916323825 being one example). Consider a minimal set of step which seems to reproduce the problem:
$ export GOPROXY=http://<IP_ADDRESS>  # simulate an error downloading modules
$ cd $(mktemp -d)
$ printf 'module test\nrequire example.com v0.0.0\n' > go.mod
$ go mod download -json

What did you see happen?
No JSON is printed to stdout:
$ go mod download -json 2>/dev/null
$

What did you expect to see?
JSON is printed to stdout, describing the error:
$ go mod download -json 2>/dev/null
{
	"Path": "example.com",
	"Version": "v0.0.0",
	"Error": "Get<EMAIL_ADDRESS>dial tcp <IP_ADDRESS>:80: connect: connection refused"
}
$

CC @matloob, @samthanawalla.

Related Issues and Documentation

cmd/go: document that go mod download -json uses exit code 1 when at least one JSON entry contains non-zero Error #35380
Proposal: cmd/go: return parseable errors for mod download #30725 (closed)
cmd/go: go module fetching gives unexpected stderr output #36297 (closed)
cmd/go: make go mod download -json return the exit status 0 in case of errors #36833 (closed)
go mod download does not fallback to http if https is not available #36394 (closed)
cmd/go: go mod download -json does not output json when sumdb fails #34485 (closed)
cmd/go: go test -json has non-JSON printed to stdout when build fails #35169 (closed)
cmd/go: treat most errors as fatal when resolving a package with a proxy #31730

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)


remove tldraw computer

we shipped

There should be a celebration section for products that actually shipped!

Hi @steveruizok,
Thanks for the suggestion! 🎉 A celebration section for shipped products sounds like a great idea. I’ll look into adding it to the repo.
Appreciate your input!


Bring security validation back

We can't use the special test auth on cluster any longer but have to work w/ HTTP basic auth (and remember that we need the full qual. URL for any DB). When that is there, we can bring back that test also. Maybe rebase after #400

merged!

@sebastianrothbucher can you close this PR?


Upgraded to t-digest 3.3.

Signed-off-by: dblock<EMAIL_ADDRESS>Description
The upgrade to t-digest 3.3 fixes a number of bugs in calculating percentiles.
Looking at sample output, the old version 3.2 was interpolating data (see https://github.com/opensearch-project/OpenSearch/pull/3634#issuecomment-1162666812 for an explanation) and producing different (wrong) results, especially in the small sample size. For example, given input of [1, 51, 101, 151] the 25th, 50th and 75th percentiles changed from [26,76,126] to [51,101,151] with this upgrade.
The tests in this PR have been adjusted to reflect the new expected percentiles, and I added both a 2.x mixed cluster test, and made all the other tests select a 3.x node to preserve a trail of this change. I also corrected the assumption that the number of centroids is <= that the number of data points, not =.
Because results change significantly I think this is a 3.x change and should not be back-ported, but open to other considerations.
There are many changes between t-digest 3.2 and 3.3, see https://github.com/tdunning/t-digest/pull/194.
Issues Resolved
Closes https://github.com/opensearch-project/OpenSearch/issues/1756.
Check List

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Ok, doesn't look so simple...
org.opensearch.search.aggregations.metrics.InternalTDigestPercentilesRanksTests > testEqualsAndHashcode FAILED
    java.lang.AssertionError: expected:<64> but was:<81>
        at __randomizedtesting.SeedInfo.seed([DF508FEF9F0E8839:AE5FF72250E9C116]:0)
        at org.junit.Assert.fail(Assert.java:89)
        at org.junit.Assert.failNotEquals(Assert.java:835)
        at org.junit.Assert.assertEquals(Assert.java:647)
        at org.junit.Assert.assertEquals(Assert.java:633)
        at org.opensearch.search.aggregations.metrics.InternalTDigestPercentilesRanksTests.createTestInstance(InternalTDigestPercentilesRanksTests.java:56)
        at org.opensearch.search.aggregations.metrics.InternalTDigestPercentilesRanksTests.createTestInstance(InternalTDigestPercentilesRanksTests.java:42)

java.lang.AssertionError: aggregations.percentiles_int.values.25\.0 didn't match expected value:
        aggregations.percentiles_int.values.25\.0: expected Double [26.0] but was Double [51.0]
            at org.opensearch.test.rest.yaml.section.MatchAssertion.doAssert(MatchAssertion.java:115)
            at org.opensearch.test.rest.yaml.section.Assertion.execute(Assertion.java:89)
            at org.opensearch.test.rest.yaml.OpenSearchClientYamlSuiteTestCase.executeSection(OpenSearchClientYamlSuiteTestCase.java:447)

@tdunning Would you mind assisting here a bit please?
The upgrade from 3.2 to 3.3 produces different percentiles in some scenarios given very simple data. You can see raw data in https://github.com/opensearch-project/OpenSearch/blob/37651e9b5fe914a99f0abe0a36e10bd46d958691/rest-api-spec/src/main/resources/rest-api-spec/test/search.aggregation/180_percentiles_tdigest_metric.yml and the diff in this PR for how those changed. The data is just 4 values: 1, 51, 101 and 151.
I didn't expect such a big difference in a dot release. At the very least I'd like to understand whether this is expected, and whether this is going to have to be released as a major breaking change for OpenSearch users.

I am not entirely clear about how to read the difference here.
I think that what you are saying is that given samples [1, 51, 101, 151]
the 25th, 50th and 75th percentiles changed from [26,76,126] to
[51,101,151].
Is that correct?
If so, this was a bug fix involved in cleaning up the behavior of the
system in small count cases. The problem is that with just four data
points, we don't need to summarize the data at all. As such, any quantiles
that involve interpolation between observed values are simply wrong.
On Tue, Jun 21, 2022 at 10:55 AM Daniel (dB.) Doubrovkine <
@.***> wrote:

@tdunning https://github.com/tdunning Would you mind assisting here a
bit please?
The upgrade from 3.2 to 3.3 produces different percentiles in some
scenarios given very simple data. You can see raw data in
https://github.com/opensearch-project/OpenSearch/blob/37651e9b5fe914a99f0abe0a36e10bd46d958691/rest-api-spec/src/main/resources/rest-api-spec/test/search.aggregation/180_percentiles_tdigest_metric.yml
and the diff in this PR for how those changed. The data is just 4 values:
1, 51, 101 and 151.
I didn't expect such a big difference in a dot release. At the very least
I'd like to understand whether this is expected, and whether this is going
to have to be released as a major breaking change for OpenSearch users.
—
Reply to this email directly, view it on GitHub
https://github.com/opensearch-project/OpenSearch/pull/3634#issuecomment-1162105083,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAB5E6XFO6CHQPJNE2LVYX3VQH62BANCNFSM5ZJKGMWQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

Sorry... I missed your very fine explanation.
I understand now that you were doing a regression test against previous behavior and were surprised at a change in this behavior.
The fact is, however, this old behavior was a bug. That bug was fixed.
If we look at the quantile curve for your data, we see this:

The circles indicate an open boundary and the filled dots indicate a closed one. Because we retain all of the data, we can't in good faith interpolate. The only question is whether the quantile at exactly 0.25 should be 1 or 51. In t-digest, I settled on the lower value. The old code was interpolating and was just wrong.

The upgrade from 3.2 to 3.3 produces different percentiles in some scenarios given very simple data. Neither the old data nor the new data is "correct", but that is expected I imagine given that we use t-digest. You can see raw data in https://github.com/opensearch-project/OpenSearch/blob/37651e9b5fe914a99f0abe0a36e10bd46d958691/rest-api-spec/src/main/resources/rest-api-spec/test/search.aggregation/180_percentiles_tdigest_metric.yml and the diff in this PR for how those changed. The data is just 4 values: 1, 51, 101 and 151.
Data	Percentile	Result
1	1	2.5
51	5	8.5
101	25	38.5
151	50	76
75	113.5
95	143.5
99	149.5
100	151
I didn't expect such a big difference in a dot release. At the very least I'd like to understand whether this is expected, and whether this is going to have to be released as a major breaking change for OpenSearch users.

In case you are curious, a similar issue arises with the cdf function. There, the graph for you data looks like this:

Here, what I have chosen is to use the mid point when you ask for the CDF at exactly a sample point. This gets a bit fancier when there are multiple samples at just the same point. In general, I take the CDF to be the

This is an expected change if the number of data points is a significant
fraction of the compression factor. Exactly when equality fails depends on
the minor version, the scale function and a tiny bit on the data itself.
If you don't compress the digest before examining it, more samples will be
retained than the so-called public compression, but less than or equal to
the private compression. The guarantee is that when you serialize the
digest, it will respect the compression factor you set, but until then
there can be more data in memory than allowed by the factor you set.
On Thu, Jun 23, 2022 at 1:49 PM Kartik Ganesh @.***>
wrote:

@.**** approved this pull request.
Just one question for my understanding:
I also corrected the assumption that the number of centroids is <= that
the number of data points, not =.
@dblock https://github.com/dblock is this an expected change with the
minor version bump? Or has the old assertion been passing serendipitously?
—
Reply to this email directly, view it on GitHub
https://github.com/opensearch-project/OpenSearch/pull/3634#pullrequestreview-1017632480,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAB5E6WKDKSG7XWOCOMPMSTVQTEWZANCNFSM5ZJKGMWQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

Just one question for my understanding:

I also corrected the assumption that the number of centroids is <= that the number of data points, not =.

@dblock is this an expected change with the minor version bump? Or has the old assertion been passing serendipitously?

Thanks @tdunning for your thorough explanation, I've learned a bunch! Either way the assertion was testing an internal assumption to t-digest.

Does anyone think we should consider this a bug fix and backport it to 2.x (queries will start returning different, more correct results)? @kartg @kotwanikunal ?

I'm inclined towards backporting since any future 2.x backports that modify these files would result in conflicts (see https://github.com/opensearch-project/OpenSearch/pull/3248#issuecomment-1122871590 for another such instance)

@kartg I do care about users more than merge conflicts, but I hear you. Any feelings about user impact?

One of the functional tests from OpenSearch Dashboards displayed the incorrect value [link it issue]. We will update the value on main but keep the 2.x branches untouched.

I settled on the lower value.

Then shouldn't the result be [1, 51, 101]?
[1, 51, 101] is the result I get from Mathematica as well:
vec = {1, 51, 101, 151};
Quantile[vec, #] & /@ {1/4, 1/2, 3/4}

{1, 51, 101}

@tdunning ^

So when updated the values for this test it seemed to get inconsistent values for the 50th, 75th, and 95th percentile for example: https://github.com/opensearch-project/OpenSearch-Dashboards/runs/7120932868?check_suite_focus=true
and
https://github.com/opensearch-project/OpenSearch-Dashboards/pull/1822#issuecomment-1170573139

@kavilla Are you sure? I felt like I was getting something similar, but turned out the tests were seeded with some random value.
In any case if you are sure, open a new issue?

I am happy to comment on the t-digest side of things if somebody can say what the test is actually doing.

I settled on the lower value.

Then shouldn't the result be [1, 51, 101]?
[1, 51, 101] is the result I get from Mathematica as well:
vec = {1, 51, 101, 151};
Quantile[vec, #] & /@ {1/4, 1/2, 3/4}

{1, 51, 101}

@tdunning Could you check out the above, please?

@kavilla Want to open an issue in t-digest re: ^ ?

The problem here is that the inverse CDF (aka quantile) is not a function.
For the example you give with observations at [1, 51, 101, 151], the CDF is
well behaved and looks like this:
[image: image.png]
This does have discontinuities at each observed value, of course, and we
could adopt a variety of conventions to define the value of the CDF exactly
at each sampled value. One convention defines the CDF as segments that are
open on the left, but closed on the right. This would make the value of
CDF(1) be 0. The opposite convention has all segments closed on the left
and open on the right so CDF(1) would be 0.25. These conventions are
asymmetric, however, which can lead to surprising results if, for instance,
you negate all sampled values. I would prefer that CDF(samples, x) ==
CDF(-samples, -x) so t-digest uses the convention that the CDF is midway
between these alternative conventions so that CDF(1) = 0.125 instead of
either 0 or 0.25.
Resolving the value at these discontinuities does not solve the problem you
are talking about. As you can see, the value of the CDF is constant for all
values in the open interval (51, 101). This means that there is no unique
value for the inverse CDF at 0.5. Any value in (51, 101) could be used.
Mathematic uses 51. Julia and R use 76. T-digest uses 101.
On Wed, Jul 6, 2022 at 11:04 AM Daniel (dB.) Doubrovkine <
@.***> wrote:

I settled on the lower value.
Then shouldn't the result be [1, 51, 101]?
[1, 51, 101] is the result I get from Mathematica as well:
vec = {1, 51, 101, 151};
Quantile[vec, #] & /@ {1/4, 1/2, 3/4}
{1, 51, 101}
@tdunning https://github.com/tdunning Could you check out the above,
please?
—
Reply to this email directly, view it on GitHub
https://github.com/opensearch-project/OpenSearch/pull/3634#issuecomment-1176522178,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAB5E6XAUISG2R7HV62BBRDVSXDC7ANCNFSM5ZJKGMWQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

@tdunning The images didn't make it to GitHub, if you care to edit, but thanks for your explanation!

From https://www.rdocumentation.org/packages/stats/versions/3.6.2/topics/quantile and https://mathworld.wolfram.com/Quantile.html, we could choose between 9 standardized definitions.
To make sure we are comparing the same things - especially in unit tests - we probably should decide on a default one, and optionally enable the choice of the others types.
Mathematica uses type 1 by default, R uses type 7 by default, but both provide the option to choose.

@tdunning The images didn't make it to GitHub, if you care to edit, but thanks for your explanation!

Sorry about that. The image is very similar to what I posted in an earlier comment. I have edited my reply but in editing the response, I had difficulty getting the image to show up.

So I have been experimenting a fair bit with the Julia implementation (easier than playing with the Java version because interactive).
I have changed the problem in question a tiny bit to make it more clear what is happening. I am using points at [1,11,15,30].
My first experiment was to verify that the cdf function performs as expected. It does. In particular, the cdf at exactly the sample points shows the desired interpolation behavior. Here is a picture produced by scanning x in small increments to get the blue line and then plotting points at exactly the sample points:

The point of real interest, however, was to determine how the quantile function behaves. The following plot shows that the quantile (wider blue line) and cdf (thin gray line) functions lay right on top of each other. Further, evaluating quantile just before and just after q=[0.25,0.5,0.75] (green and purple dots) we see the desired boundary behavior.

I would contend that it is hard to do better than this due to inevitable floating point limits.
@dblock , @kavilla , @sharp-pixel what do you think?
Also, I looked into the R and Julia implementations of the quantile function. In fact, they are trying to estimate the theoretical distribution rather than the empirical inverse cdf. This is a different problem entirely. Adding the Julia quantile to the graph shows what I mean

The result is far from the empirical inverse cdf function.

Thanks @tdunning.
It seems Julia uses type 7 (from https://docs.julialang.org/en/v1/stdlib/Statistics/), so we just need to pick one quantile function type as the default, document it, and optionally have the choice to override the type.

I opened https://github.com/opensearch-project/OpenSearch/issues/5115 to discuss the user-facing aspects of this. Because there's no one correct result at the edges, I think we could support multiple strategies to everybody's satisfaction.


Track promql query errors with logs, tracing spans and metrics

Occasionally the memory usage across thanos components spikes up a lot and we've
usually had a hard time finding the offending query that lead to it. This is to
help debug and find bad queries easily. All queries are logged with debug level,
and qry.Exec() errors with an additional error label.
A new metric thanos_query_api_failures_total keeps track of the query error
count. Along with instantQueryDuration + rangeQueryDuration this should allow
us to compute the percentage of promql queries that fail.
Example log line:
level=debug ts=2019-05-28T16:46:36.10666776Z caller=v1.go:307 query="topk(10, count by (__name__)({__name__=~\".+\"}))" error="query was canceled in expression evaluation" duration=1.400047035

How about we instead add the query as a tag to the trace span?

@brancz That's a good idea! I've updated the patch. We are not tracing thanos in our env yet, so I've not tested that part.
The logs seems to be working alright, but I'm yet to see it being useful because I'vent had a OOM kill after this deployment.

If that's the problem, then probably adding a debug log line that always logs every query before actually starting to execute it sounds like a more useful place.

@brancz Updated. All queries are logged with debug level, ones that failed are additionally logged in warning level as well.

@brancz Changed both to debug.

@bwplotka @brancz Just to make sure we are on the same page,

log every query in debug level; this will help us find bad queries before memory spikes
Ignore errorBadData; this is just bad queries which should just be ignored as this wont cause prometheus/thanos issues.
Log all qry.Exec() errors as debug with an additional error label; so this can be grepped and analysed.

Is that OK? 👍

Sample metrics:
thanos_query_api_failures_total{app="thanos-query",error="canceled",instance="thanos-query-68878f4f75-psb9t",job="monitoring/thanos-query",namespace="monitoring"}
thanos_query_api_failures_total{app="thanos-query",error="timeout",instance="thanos-query-68878f4f75-psb9t",job="monitoring/thanos-query",namespace="monitoring"}

We were hoping that extensively logging queries will help us find the ones that lead to memory spikes but in practice it didn't.  Closing this off.


Skip auth

mongolly appears to require auth for mongo. this makes the db auth conditional and also removes them from the validation check.

Thanks @stim371

I've released version 0.2.9 with this change.


Solution Examples will not import on Documentation Page for Outbound Messaging in CSW

The Flow examples will not import into new Dynamics. They both get the following error
The solution file is invalid. The compressed file must contain the following files at its root: solution.xml, customizations.xml, and [Content_Types].xml. Customization files exported from previous versions of Microsoft Dynamics 365 are not supported.
My Org is setup on Database version 9.2.22031.00144
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 66aa257f-c9a0-22a2-d46d-396b25545de5
Version Independent ID: 5cf27d9c-86b4-91f6-a17b-4c1f92fe2fb6
Content: Configure outbound messaging in Omnichannel for Customer Service
Content Source: ce/customer-service/outbound-messaging.md
Service: dynamics-365-customerservice
GitHub Login: @gandhamm
Microsoft Alias: mgandham

Thanks for your comment, @BillOwens. This issue has been assigned to the doc author for review.

The PM was able to follow the steps in the topic and successfully import the flow in the internal environment.

As this doesn't seem to be a documentation issue but a tech/product issue, request @BillOwens to create a support ticket.
To contact Support, consider one of the options described here:
https://docs.microsoft.com/en-us/dynamics365/get-started/support/
Closing this issue.


Not working why?

So I just tried to give me some badges around 6-7 and I did put it into the plugins folder but its not working why?

This plugin will override your badges, you can set these to any badge you want. If you want to keep your old badges you need to add their ids as well. And yes, you can have a maximum of 3 badtes at the same time.

Please show me your main.cpp line where you send the badge ids

SendCommandToServer( "clientupdate client_badges=Overwolf=0:badges=935e5a2a-954a-44ca-aa7a-55c79285b601" );
So I have to add the gamescom 2018 icon and the other icon too right?

As I said, this command will override your badges. To get the other ones you had on your screenshot too (the Gamescom 2018 and TS early adopter one), your command should look like
SendCommandToServer( "clientupdate client_badges=Overwolf=0:badges=4eef1ecf-a0ea-423d-bfd0-496543a00305,64221fd1-706c-4bb2-ba55-996c39effa79,935e5a2a-954a-44ca-aa7a-55c79285b601" );


Inference Graph YAML unformatted

Expected Behavior
When I was learning how to use InferenceGraph, I noticed that the API documentation YAML does not have proper indentation.
You can check it at https://kserve.github.io/website/0.11/reference/api/#serving.kserve.io/v1alpha1.InferenceRouter
Actual Behavior
The entire YAML file lacks any indentation, with all code being indented to the left.
Additional Info
Additional context
Add any other context about the problem here.

Very nice finding @yolk-pie-L, if you want to contribute by fixing it, feel free, it will be really appreciated :)

@yuzisun @ckadner @terrytangyuan Hey guys, I was investigating this issue and found that:
These yaml files are loaded from: https://github.com/kserve/kserve/blob/master/pkg/apis/serving/v1alpha1/inference_graph.go#L104
and this script will generate the reference api doc.
The script above uses this tool  to read all the api files and build this api.md
However, the tool that reads the comments from the go files seems to be removing all the spaces from the yaml chunks.
On the other hand, if we try to add think like tabulations, (simple pressing tab) go fmt would remove that from the comments.
With that said, the only way I found to make the indentation to work with the current approach, is a little bit hacky, but solves the issue we have by updating these contents from go comments by adding tabulation controller chaaracter.
The proposed solution looks like:
1 - add tabulation character in the go comments, like (kserve/kserve side):
// ```yaml
//
// kind: InferenceGraph
// metadata:
//
// \tname: canary-route
//
// spec:
//
// \tnodes:
//
//\t\troot:
//\t\t\trouterType: Splitter
...

2- And in the kserve/website, have a script to read these comments and apply the tabulation, e.g.:
...
        indented_line=""
        while [[ $next_line != "
" ]]; do
            # Add break lines
            indented_line+="$next_line\n"
            # Read the next line
            read -r next_line
        done
        # Print the indented YAML content by applying the tabs
        tabs 2
        echo -e $indented_line
...

3 - call this script inside the gen-api-reference-docs.sh to properly format it, it will output in the docs/reference/api.md something like this:

InferenceRouter defines the router for each InferenceGraph node with one or multiple steps

kind: InferenceGraph
metadata:
  name: canary-route
spec:
  nodes:
    root:
      routerType: Splitter
...

Please let me know what you think about it, this approach is basically done in my end, I can send the PR for a better review.

The yaml file in the inference_graph.go cannot work, I have tried it. I think it is only for demonstration, but not a real file that follows the api. So to fix the documentation, I think we need to rewrite the yaml file.
@spolti

@yolk-pie-L my guess it that it was done this way to keep easier to generate the api reference doc, this approach have this downside part. Let's wait other to see what we can do :)


Are you considering DV related investments as well?

Not an issue, but a question/suggestion:
I'm impressed with the HDR tonemap results I got so far. Now I'm wondering if you have any interest in looking at DV areas as well. What I have in mind:

Expand DV support. MPV only consumes peak metadata, but there is an opportunity to consume the dynamic metadata/DV tonemapping as well.

Even only for peak metatada, DV ignores Profile 7 data as FEL titles could bring the wrong peak data when not consuming the 2nd video stream. But it's possible to detect if a given stream is FEL or MEL and still consume the peak metadata from MEL titles. (there is an open feature request on LibPlacebo)

Cherry on top: Find a way to properly support the second video stream for FEL Profile 7 titles. That's where Coreelec has an edge today.

Thanks for the hard work!

There's nothing I can do about DV.


Fix -w

Redo the -w flag to properly handle words.
Update documentation that this affects.

xref discussion under https://github.com/petdance/ack2/issues/445 Metacharacters and Non-Word chars ; https://github.com/petdance/ack2/issues/565 Unicode (ugh but should have tests to track what DOES work or new enough perls)

This needs #1 for proper testing.

Right now this has been changed to this:
    if ( $opt->{w} ) {
        $str = "\\b(?:$str)\\b";
    }

Not sure if this is what we want to live with.

As discussed on prior thread, that handles the commonsense case (where $str is in fact a sensible literal word, or a RE that will match word-chars only) but has nasty edge/corner cases when $str may match whitespace or non-word-punc in first or last position.
root issue is that the \b zerowidth assertion treats non-word printables asymmetrically from word-printable, in that (1)there is no \b within sequente space punc space punc, and (2)the beginning and end of string are Non-word for \b purposes so \b(-foo-)\b will not match in first or last position ever.
we must either document that only the commonsense case where -w means word means word and Warn/Error if pattern $str starts or ends with non-word punc [including  metachas; if you want -w $RE you should drop the -w and say which word-effect you want]  or define exactly what -w means for $str to match a non-word word in documentation and tests and then implement it.
We discussed some ways using \k etc to make it work in edge cases but depends what we want the edges to be.

I'll be getting at those edge cases today.  That's why I didn't close this.

(?:^|\b|\s)\K(?:PATTERN)(?=\s|\b|$) is what we talked about latest.

We may also want to make an optimization such that if $pattern =~ /^\w+$/ that we use the simple \b$pattern\b.

\b{wb} would be better than \b, at least for acking natural language, but it is relatively new to Perl and the semantics are less well-known than programmers’ longstanding expectations of “word boundaries.”

When did it come around?  I'm not familiar with it.

Perl 5.22 with notable improvements in 5.24.
References:

perl5220delta: qr/\b{wb}/
perl5240delta: qr/\b{wb}/ is now tailored to Perl expectations
perlrebackslash: \b{wb}

Interesting.  Thanks for the pointers.
I would never put something in ack where the behavior changes depending on what version of Perl is running.

The regex syntax and semantics change in every Perl release, including those of \b when new Unicode “word” characters are added, and therefore those of ack change as well, but I understand your desire for a relatively stable flag.


[Feature]: Allow images from Codeberg.org

Related Problem
No response
The Elevator Pitch
Allow readme.md to reference images from Codeberg.org, specifically, https://codeberg.org/*/*/raw/*/*/**.* where * means a single directory while ** means any directory or multiple directories. For example, the link to the one of the official logos of Codeberg in the official icon repository is https://codeberg.org/Codeberg/Design/raw/branch/main/logo/icon/png/codeberg-logo_icon_blue-64x64.png.
Additional Context and Details
Codeberg.org is a FOSS-only code hosting platformed based on Forgejo, which is a soft fork of Gitea.

I think it can do this already, at least on regular repositories on Codeberg. The example URL provided above to the blue icon looks fine.


RTCP?

Hi,
I am seeing some rtcp related messages in debug , does anyone have any information regarding RTCP in sipml5 ? Is it working, broken or not really implemented?

I believe (although I am not 100 % sure) that RTCP should be processed by an RTP-engine, which is used by browser or other WebRTC-enabled client. It is not the responsibility of js-based SIP library like sipML5.