Make it permanent for real this time

Electric Boogaloo

i just don't see why it's a launch option, more benefit to just always apply

I'm pretty sure that's an option and not default because some games do things before it closes, terminating the process won't let it do that

Don't know what you mean by "that part"
I've seen the idea of implementing it permanently floating around and i didn't see any objections from devs when the subject was brought up

Whats the problem with how it is rn tho? It's just a single config you can toggle, it doesn't take allot of effort.

Quitfix can cause some issues: The user not being properly disconnected, the game not being saved, ...

Just close this request

By "that part" I meant you're just removing a boolean check instead of removing the entire implementation like the config setting, the launch option on the bootstrap dll, references about it on README.md, idk what else but it doesn't really matter anyway

Yeah just close this request and lock it


MediaNotification.Provider.handleCustomAction never get called

Hi media team 👋
I'm integrating the new MediaNotification.Provider abstraction, but I realized the handleCustomAction() is never called because of the implementation in MediaSessionService.onStartCommand.
https://github.com/androidx/media/blob/850bd69dddca45915199f221d48573fca3fc790b/libraries/session/src/main/java/androidx/media3/session/MediaSessionService.java#L346
The session field is required here, but since the DefaultActionFactory.createCustomAction() doesn't provide any uri to the intent, the session field will always be null for custom actions, and there's no way to provide a customize action factory.
media3 Version: 1.0.0-alpha03

Thanks for reporting!
This is fixed to some extend in the main branch, but you are right that the URI needs to be added to the Intent also. We will provide a fix for that to include the URI properly.

@marcbaechinger  Thanks for replying! Looking forward to the new releases 🙌

I'm closing for now as this is fixed in the upcoming release.


Update index.js

Added OutputKeyPrefix parameter to params array for elasticTranscoder.createJob in order to store transcoded files in a folder to align the code with the code provided as Listing 3.1 in the book.

closing as just realized this is covered by https://github.com/sbarski/serverless-architectures-aws/pull/17


chore: bdd-gh-1582224229 to 0.0.1

chore: Promote bdd-gh-1582224229 to version 0.0.1

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

Needs approval from an approver in each of these files:

OWNERS

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


feat: add basic runtime api skeleton

What this PR does: add basic runtime API skeleton
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

Pls translate your Chinese comment into English

Pls translate your Chinese comment into English

Done


update cross-spawn dep

https://github.com/greenkeeperio/greenkeeper is invaluable

Coverage remained the same at 95.413% when pulling 9041911cfd5e5cbd8c42505531d07b774d8bc699 on caseyWebb:update-deps into fec48cb4e642dfcd62bbdae144f2496a4e43fd0f on observing:master.

+1

Landed in master.


Don't crash when modifying a global observed variable

The terrible hack in SILGen here is to not visit opaque accessors of global variables if they were added to the decls list by the parser.  That needs to include the setter for an observed global variable, which we apparently did not have tests of.
rdar://46472759

@swift-ci Please smoke test.


running slow!

any idea why it runs quite slow and how to solve it??

Please refer to #6. Let me know if you still have problems.

can i ask u is it one of the reason is that running corenlp in this way requires Internet connection? and i am now using nltk to load stanford models first, then process corenlp functions, it runs much more faster (some of the functions just cost within 1s)!

No, it does not require internet connection. It does cost time to start the Java server. When it is done, it processes faster. Please take a look at the example code in #6.

@yzho0907 Could you add references to how you're using NLTK to load Stanford models first, then process CoreNLP functions to runs much faster? Also, could you provide codes?

@The-Gupta here just an example:
import os
from nltk.parse import stanford
os.environ['STANFORD_PARSER'] = 'yourpath/Downloads/stanford-parser-full-2018-02-27/stanford-parser.jar'
os.environ['STANFORD_MODELS'] = 'yourpath/stanford-parser-full-2018-02-27/stanford-parser-3.9.1-models.jar'
cn_parser = stanford.StanfordParser(model_path="yourpath/chinesePCFG.ser.gz")


CLN: Rework bazel build setup

Rework build setup so that addons is linked to the TF CXX11 ABI by default. If for some reason you don't want it to match you can edit the .bazelrc file after running .configure.sh
Also matched the shared library parsing that was added to custom-op so that we only call tf.sysconfig.get_link_flags once.
cc @kyleabeauchamp this look okay to you?

Code changes seem reasonable (modulo my limited bazel knowledge).  I can check that it runs this evening.

I can confirm that the build works for me.  I'd have one more pair of eyes for the review as I'm fairly new to bazel.

Would love to get a review / merge on this one, as I think it will finally make building on my system possible without source code changes.


Minor Lua Patch

this says id idk what to put here uhhhhh
fixes getGlobalFromScript
fixes panic unprotected error on pcall
bring backs libs that are safe

oh yeah forgot to say, tested and the crash handler for luas now works, very cool

Panic issues were fixed at 0.6.1 sooo


Istioctl says fromNamespaces in CUSTOM AuthZ policy is not valid, but it appears to be

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] This is not a question about how to use Istio

Bug Description
When using a filter of namespace in a CUSTOM authz policy, eg:
spec:
  action: CUSTOM
  provider:
    name: some-external
  rules:
  - from:
    - source:
        namespaces:
        - whatever

Validate throws up:
AuthorizationPolicy//pip: invalid policy pip.platform-testing: From.Namespaces is currently not supported with CUSTOM action

But it works (i've tested it on the cluster).  So feels like this is validation for an old condition which is no longer the case?
Older issue, same subject: https://github.com/istio/istio/issues/47157
Version
1.22

Additional Information
No response

How do you make it pass the src namespace to external authz server?

Actually, in this custom authz case, all the decision is made by the server, the From.SourceNamespace does not apply to external authz server. You can configure whatevere policies on the authz server in another way

@hzxuzhonghu i don't think i understand you?
I'm saying:
spec:
  action: CUSTOM
  provider:
    name: some-external
  rules:
  - from:
    - source:
        namespaces:
        - whatever

Is valid config, is accepted by the API server, and it works as expected (only applies to requests from the whatever namespace).
However istioctl validate rejects it.

Do you not run a validation webhook?
$  cat <<EOF | kubectl apply -f -
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: httpbin
spec:
  action: CUSTOM
  provider:
    name: some-external
  rules:
  - from:
    - source:
        namespaces:
        - whatever
EOF
Error from server: error when creating "STDIN": admission webhook "validation.istio.io" denied the request: configuration is invalid: invalid policy httpbin.default: From.Namespaces is currently not supported with CUSTOM action

yup 🤔
❯ cat <<EOF | kubectl apply -f -
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: httpbin
spec:
  action: CUSTOM
  provider:
    name: some-external
  rules:
  - from:
    - source:
        namespaces:
        - whatever
EOF
authorizationpolicy.security.istio.io/httpbin created

lol

I think you don't have defaultRevision set so it ends up not creating one that applies to objects without istio.io/rev.
$ ik manifest generate | kubectl grep Val*/ -s
ValidatingWebhookConfiguration/istio-validator-istio-system.
$ ik manifest generate --set values.defaultRevision=default | kubectl grep Val*/ -s
ValidatingWebhookConfiguration/istio-validator-istio-system.
ValidatingWebhookConfiguration/istiod-default-validator.

Anyhow, to the original point... it looks weird. I don't see any part of it that doesn't work. The original PR explicitly adds tests for all the other From types but not namespace, but if I add namespace it appears to work. The original PR has no context on why it marked these as unsupported..


Is this model still under construction or completed?

Hi,
I am curious if this model is completed or still in process of building. I check the scripts, but it looks like missing some parts.

Have the same question

Also wondering the same question.

1


Dependency on SQLite is incompatible with AWS Amplify

Bodega has an explicit version number dependency:
.package(url: "https://github.com/stephencelis/SQLite.swift.git", exact: Version(0, 13, 3)),

and Amplify has an explicit dependency:
.package(url: "https://github.com/stephencelis/SQLite.swift.git", exact: "0.13.2"),

which makes them incompatible, and now I need to have both in my project.
Any way to change this on Bodega's side? On the side of AWS this is a known issue: https://github.com/aws-amplify/amplify-swift/issues/2592

Hey @ristkof! I spent the day thinking about this and consulting with a few other open source maintainers and came to the conclusion that I should make the change you're requesting in Bodega. I was initially hesitant to unpin the library from a specific version for likely the same reasons the Amplify maintainers pin their library to a specific version, ease of maintenance, but in the context of people using many open source libraries with differing requirements I shouldn't enforce this kind of requirement.
I'm going to work on a few Boutique and Bodega related features over the next couple of days and will make sure to include this. If you'd like to expedite it you're free to submit a pull request that bumps the version to at least 0.13.2.
That would be going into Bodega's Package.swift and replacing this line
.package(url: "https://github.com/stephencelis/SQLite.swift.git", exact: Version(0, 13, 3))
With
.package(url: "https://github.com/stephencelis/SQLite.swift.git", from: Version(0, 13, 2))
If you do this please make sure to run Bodega's tests, and to try the Boutique Demo and Performance Profiler projects to make sure they all still work fine. I do remember there were some issues with earlier versions of SQLite.swift, I wonder if that's what the Amplify maintainers ran into as well.
Thanks a lot for bringing this to my attention, and hopefully the upgrade goes smoothly.

Ive been on the Amplify discord all day trying to find a path forward on this same issue. Happy to see this has been raised here and has a solution in mind. Any idea of when this will be updated?

Hi folks, so sorry I've had a really busy last couple of months and lost track of this issue. Last night I pushed up a commit that removes exact pinning, instead starting from 0.13.2. I'll make a more formal release soon when I have some free time, but in the mean time you can point your project to Bodega's main branch in SPM to unblock you.
Thanks for being patient, and appreciate the nudge!

Hey folks, I wanted to check and see if everything worked now? If so I'll close out this issue.

It does indeed. Thank you so much, greatly appreciated!

Terrific, glad to hear that!

I apologize that this took so long to turn into a formal release but the last few months I've had some other obligations that took priority over Boutique and Bodega work.
As of version 2.1.0 Bodega officially pins SQLite.swift to any version of SQLite.swift greater than 0.13.2, so if you were pointing your dependencies to the main branch you can now point it to the 2.1.0 release.


Discard all android data

Did you discard or include any data for android in this calculation?
All this data is bogus and should be ignored.
To the best of my knowledge only iOS Safari has real data.

Yes and no!
I am familiar with the problem with caniuse's Chrome for Android data. The issue is filed here. https://github.com/Fyrd/caniuse/issues/3518
compute-keystone-release-dates.mjs completely ignores and_chr for the purposes of computing the keystone release dates. https://github.com/dfabulich/baseline-calculator/blob/main/compute-keystone-release-dates.mjs#L59 Without that line, we'd compute that all of the keystone release dates are the release date of and_chr 113 on May 2, which is obviously wrong.
But we do use and_chr data for these purposes:

When deciding whether a feature is available in all major browsers (i.e. whether the feature is "Baselineable") we do use and_chr for that. Otherwise, we would treat https://caniuse.com/input-file-multiple as Baselineable, but, in fact, it's not supported in and_chr, so we don't count it.
We also include and_chr in the market share calculations. i.e. if a feature has 80% share because it's supported in Chrome for Desktop and Android, we do count that. This will systematically overestimate the market share of features that have non-trivial share in older versions of Chrome.

For example: https://caniuse.com/dialog Caniuse says that dialog is at 94.18% share today, but that's an overestimate, because it treats all "Chrome for Android" as v113, but we know that at least 5% of the 40 points of "Chrome for Android" share is on an older version of Chrome. (We don't know how old, but we know at least not v113.) So Dialog might really be closer to 93% market share instead. In the worst case, it might be as low as 92% share.
But there is a partial mitigation in place: although the current HEAD revision does not include accurate historical data about and_chr, we're measuring historical data by checking out old revisions of data.json, and I those old revisions are accurate about the then-current version of and_chr as it was at the time. (But they were wrong even then about then-obsolete versions of Chrome.)
With this mitigation in place, I think the data is "good enough" for our purposes. This calculation is meant to be an approximation in any case, and I don't think those subtle differences will fundamentally alter the question I'm asking, which is: how long do we have to wait for 80% of features to reach 95% market share?
I argue that it's four years, and maybe we should really wait 4.5 years, if only we had access to real data for and_chr, but for some features you'd really have to wait seven or eight years, and for some features just two years is enough.
The alternative would be to entirely exclude and_chr from market share calculations. To do that, I'd have to disregard the top-line usage_perc_y number for each feature, and calculate it by hand based on all of the other browsers. But this would wildly exaggerate the relative market share of "weird" old browsers like IE, Opera Mini, and UC Browser. Fully excluding Chrome for Android would imply that Opera Mini is, itself, more than 1% of market share, which it isn't, and shouldn't be.

But there is a partial mitigation in place: although the current HEAD revision does not include accurate historical data about and_chr, we're measuring historical data by checking out old revisions of data.json, and I those old revisions are accurate about the then-current version of and_chr as it was at the time. (But they were wrong even then about then-obsolete versions of Chrome.)

Cool!

I argue that it's four years, and maybe we should really wait 4.5 years,

This matches my data, so that seems correct.

Good to close 🙇


Version check for polyfills

Sometimes we need to implement polyfills for older Node.js versions and for this we have to check version manually like:
const vArr = process.versions.node.split('.').map(num => parseInt(num));
if (vArr[0] > 8 || (vArr[0] === 8 && vArr[1] >= 2)) {
  ...
}

I propose to implement function that will check if process' version is older than required.
if (common.nodeVersionCompatible('8.2')) {
  ...
}

or
if (common.v8VersionCompatible('8.2')) {
  ...
}

WDYT?
/cc @lundibundi @nechaido @belochub @tshemsedinov

AFAIK we need to check that the current version is equal or higher than the specified version, not compatible.
Example: we only use mkdip polyfill for <10.12.0.

Version
Polyfill
v10.12.0 compatible

8.0.0
:heavy_check_mark:
:negative_squared_cross_mark:

10.0.0
:heavy_check_mark:
:negative_squared_cross_mark:

10.12.0
:negative_squared_cross_mark:
:heavy_check_mark:

11.0.0
:negative_squared_cross_mark:
:negative_squared_cross_mark:

@nechaido Agree, function name should be changed. What about verifyVersion or checkVersion? Can as well make compareVersions.


remove js sort on string versions

Purpose

remove js sort on string versions to prevent the incorrect ordering of the product version dropdown

The suggested change is not applicable to Choreo docs as we don't have versions. Therefore, closing this.

@Nashaath if this is the case then the code should be removed. This bug has been propagated to all docs being copied. so it is important to remove it everywhere to ensure it doesn't get copied again.


Qubo poly solver

Add possibility to solve the hydraulics equation using a full qubo approach. This approach bypass the newton raphson entirely. Instead we recast the hydraulics equation as a set of polynomial equation that we directly solve using a QUBO approach.
This only works for chesy-manning or darcy-weinsbach headloss for which  the exponent of the flow is an integer. For DW the code assumes that we are in a full turbulent regime.

superseeded by #28


SSDMobileNetV3 no output at all

This is my model structure

It works on tflite official app tho. So the problem should be related to this library

Hi @sooxt98 ,
Did you manage to make SSDMobileNetV3 work within Flutter?
Just wanted to confirm.
Thanks!

@ourii  yes after tons of research and trying, I found out that the inference_type must use FLOAT in order to make it work

Good to know @sooxt98 ! And how do you actually change the weights from int to float? I guess the model needs to be trained from the beginning with float weights instead of int weights, right?
But I don't see any parameter for changing this in the .config file... where do you have to specify it?

mabye  img preprocessing  have divce  255?

But did you change any configuration when training the model, or after training the model?
I am using RGB images, with values from 0 to 255...

Hello,
I finally managed to make it work.
For the record, I used the following:

Trained ssd_mobilenet_v3_small_coco from the Tensorflow Detection Model Zoo
Exported checkpoint to tflite frozen graph (.pb) with the following link
Convert .pb to .tflite with the following command:

tflite_convert
--graph_def_file=built_graph/ssd_mobilenet_v3.pb
--output_file=built_graph/ssd_mobilenet_v3.tflite
--input_format=TENSORFLOW_GRAPHDEF
--output_format=TFLITE
--input_shape=1,300,300,3
--input_arrays='normalized_input_image_tensor'
--output_arrays='TFLite_Detection_PostProcess','TFLite_Detection_PostProcess:1','TFLite_Detection_PostProcess:2','TFLite_Detection_PostProcess:3'
--mean_values=0
--std_dev_values=255
--inference_type=FLOAT
--input_data_type=FLOAT
--allow_custom_ops
--add_postprocessing_op=True


SyntaxError: Cannot use import statement outside a module

I'm trying to run the simple example:
import { request } from 'graphql-request'
const query = {   Movie(title: "Inception") {     releaseDate     actors {       name     }   } }
request('https://api.graph.cool/simple/v1/movies', query).then(data => console.log(data))
But that's what I get when running: node file.js
SyntaxError: Cannot use import statement outside a module

I second this, getting the same error, did you figure it out?

nope :(

You can simply use:
const {request, GraphQLClient} = require('graphql-request');
instead of using "import", should be all good then.

For some reason now, i'm having issues with "fetch" as not defined, for some reason.

To be honest.
To everyone using this package in Node.js, i recomend just using fetch instead, like so:
const fetch = require("node-fetch");
const query = `
  query {
    Lift(id: "panorama") {
      name
      status
    }
  }
`;
const url = "https://snowtooth.moonhighway.com/";
const opts = {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ query })
};
fetch(url, opts)
  .then(res => res.json())
  .then(console.log)
  .catch(console.error);
});

No errors, just works.

Fetch isn't natively supported in server-side node js. You have to use node-fetch or some other package

A repro repo would help here.

Is this issue still open?


[cloud_firestore] Allow iOS and macOS to be imported as a module

Description
Define the module by setting DEFINES_MODULE in the podspec.

If enabled, the product will be treated as defining its own module. This enables automatic production of LLVM module map files when appropriate, and allows the product to be imported as a module.

See also CocoaPod modular headers docs.
Related Issues
https://github.com/FirebaseExtended/flutterfire/issues/1258
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
[x] If the pull request affects only one plugin, the PR title starts with the name of the plugin in brackets (e.g. [cloud_firestore])
[x] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See [Contributor Guide]).
[x] All existing and new tests are passing.
[x] I updated/added relevant documentation (doc comments with ///).
[ ] The analyzer (flutter analyze) does not report any problems on my PR.
[x] I read and followed the [Flutter Style Guide].
[ ] I updated pubspec.yaml with an appropriate new version according to the [pub versioning philosophy].
[x] I updated CHANGELOG.md to add a description of the change.
[x] I signed the [CLA].
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
[x] No, this is not a breaking change.

Awesome! Thank you so much for sending over this PR 🎉

CI failure is unrelated to this change - known issue of Firestore e2e tests failing when multiple CI runs are running in parallel as they're conflicting on a live Firebase project - we're internally working on moving tests to use the Firestore emulator.
As both the build stages passed and the apps have ran successfully on CI I'm happy to merge this.

As both the build stages passed and the apps have ran successfully on CI I'm happy to merge this, unless you have any objections?

Works for me, thanks!


SCB-634 - Fix minor locale bugs

Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Make sure there is a JIRA issue filed for the change (usually before you start working on it).  Trivial changes like typos do not require a JIRA issue.  Your pull request should address just this issue, without pulling in other changes.
[ ] Each commit in the pull request should have a meaningful subject line and body.
[ ] Format the pull request title like [SCB-XXX] Fixes bug in ApproximateQuantiles, where you replace SCB-XXX with the appropriate JIRA issue.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Run go build go test go fmt go vet to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Codecov Report

Merging #369 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #369   +/-   ##
=======================================
  Coverage   71.46%   71.46%
=======================================
  Files          25       25
  Lines        3690     3690
=======================================
  Hits         2637     2637
  Misses        884      884
  Partials      169      169

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 f25fa18...b096b4b. Read the comment docs.

Coverage increased (+0.01%) to 74.642% when pulling b096b4b7a5fdc4c3d0e90af7d39b03978d03f3e5 on asifdxtreme:master into f25fa18ba053e239dc842baafe39cbf8e8217a8a on apache:master.


DIff Only

Build.Reason:Manual by Michael Jin
Build.Url:https://apidrop.visualstudio.com/Content CI/_build/results?buildId=325794&view=results

Learn Build status updates of commit 89107b8:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error: CannotMergeCommit] Cannot merge commit 89107b832719416f0ff0b3e9419163d3dc0fa424 in branch michael/pr-10-17 of repository https://github.com/MicrosoftDocs/azure-docs-sdk-python into branch michael/pr-10-17-base (commit 02bf6164481cc0d4ca9fc39224dfc177c5affad1). Please follow this documentation: https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/ to use git.exe to resolve you content conflicts locally and then push to remote.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Learn Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel


Update circe-core, circe-generic, circe-jawn... to 0.10.1

Updates

io.circe:circe-core
io.circe:circe-generic
io.circe:circe-jawn
io.circe:circe-parser
io.circe:circe-testing

from 0.10.0 to 0.10.1.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention @scala-steward in the comments below.
Have a nice day!

Codecov Report

Merging #39 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #39   +/-   ##
=======================================
  Coverage   86.71%   86.71%
=======================================
  Files          11       11
  Lines         128      128
  Branches       12       12
=======================================
  Hits          111      111
  Misses         17       17

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 a272637...ec927d1. Read the comment docs.


Anerdw: Watch maltabulletin.mt

Anerdw requests the watch of the watch_keyword maltabulletin\.mt. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

maltabulletin\.mt has been seen in 2 true positives, 0 false positives, and 0 NAAs.

Approved by Cow in Charcoal HQ


option 2 no answer

because when I choose option 2 the bot stays stuck and does not show any error

synchronize your system time

thanks


pick pick #41676 #41740 #41857

Proposed changes
pick #41676 #41740 #41857

run buildall

run buildall


Have PendRename ensure a path exists prior to calling the TFS API

Reviewed with @spraints while on IRC.

This should hopefully fix #133


Not Readable for one long line.

So would you mind to wrap one line to multiple line for better reading? PR welcome?

What is this referring to?

What is this referring to?

For example, in file ViewExtension.swift those functions and comments are too long for reading, I think wrap line should be better.

Hello Yonggang,
im not sure if you are referring to the documentation comments or the actual source code or something different.
If you are referring to the documentation comments, they are not intended for being read inside the code, but for XCode to preview more details on how to use it. So it makes no difference here how long the lines are.
If you are referring to the source code, the same goes here; this is my current type of writing code and styling code. If you prefer it in a different way, you can always use my code and change it however you like and even publish it, because it is licensed under the MIT Licence. But I can work better with less lines and therefore sometimes less readable code.
Greetings,
Lucas

Hello Yonggang,
im not sure if you are referring to the documentation comments or the actual source code or something different.
If you are referring to the documentation comments, they are not intended for being read inside the code, but for XCode to preview more details on how to use it. So it makes no difference here how long the lines are.
If you are referring to the source code, the same goes here; this is my current type of writing code and styling code. If you prefer it in a different way, you can always use my code and change it however you like and even publish it, because it is licensed under the MIT Licence. But I can work better with less lines and therefore sometimes less readable code.
Greetings,
Lucas

Respect your writing style.

Just found this issue and wanted to mention that I changed my writing style in your favour. Im using SwiftLint, which enforces shorter line length.

Just found this issue and wanted to mention that I changed my writing style in your favour. Im using SwiftLint, which enforces shorter line length.

Well done~ hope you like it!


DTPP

DTPP will be open source? Or has TPP been open sourced?
Is DTPP your latest work?

Does the Scenario Tree（the output of transformer decoder) include the trajectory of the self-driving car?

Hi, @StephenGordan, thank you for your interest. Yes, DTPP will be available as open source and included in tuplan_garage. In the meantime, you can refer to the code of TPP here. The scenario tree does not include the trajectory of the SDC because its future trajectory is already generated by the ego trajectory sampler.

Thank you very much.！
DTPP is not open source yet, right? When will it be?
DTPP should be your job, why is it included in tuplan_garage?
Is the structure of DTPP likely to be the development direction of learning based palnner?

I will do my best to make it available in late February. DTPP will be included in the model zoo in tuplan_garage; however, the code will be released on my side. I believe that DTPP has the potential to be utilized in commercial vehicles, and I hope it can become a direction of learning-based planning.


fix(csharp/src/Drivers/Apache): interim fix to workaround concurrency issue

Provides an interim work-around for the concurrency issue identified in #2280.

Removes the SQL DELETE statements from the SQL table scripts.
Skips the ClientTests version of CanExecuteUpdate (commented with issue link)
Fixes the missing application of HttpRequestTimeout due to an incomplete implementation of the ValidateOptions in SparkDatabricksConnection.
Improve table create table syntax to CREATE OR REPLACE TABLE to reduce probably of inconsistent state.

Note: this is not the final solution. A more robust isolation of table creation needs to done to isolate concurrency.

@CurtHagenlocher - this is quick work-around.
Would it be better to do the "full" fix rather than this work-around? As there is no CI around these tests, no one will notice this failure.


Implement GETEX command

Implement the GETEX command, which gets the current value at the specified key and then sets an expiry for the key.
Reference: https://redis.io/docs/latest/commands/getex/
Client-Server Spec:
Command File: ./internal/modules/generic/commands.go
Test File: ./internal/modules/generic/commands_test.go
Command: getex
Module: constants.GenericModule
Categories:  constants.WriteCategory, constants.FastCategory
Description: (GETEX key [EX seconds | PX milliseconds | EXAT unix-time-seconds |   PXAT unix-time-milliseconds | PERSIST]) Get the value of key and optionally set its expiration. GETEX is similar to [GET], but is a write command with additional options.
Sync: true
Embedded Spec:
Command File: ./echovault/api_generic.go
Test File: ./echovault/api_generic_test.go

@kelvinmwinuka I'll pick this one up next after my current PR gets approved and I address anything that needs fixing there.


Possible attribute for built in display being shut

It is possible to configure built in laptop displays (or possibly something to do with new foldable devices with different technical screens) to be closed but still active.  This might be something we should expose through some property.
Use case: A presenter configures their layout on one set of monitors off the stage. Closes the lid, unplugs monitors and walks onto stage. Plugs projection things in, then opens lid.
The OS could initialize the built in display with the lid closed (thinking of MacOS possibly.) Then turn it off until the lid is opened. Or depending on the user configuration, leave it on and active even if closed.
There are many open questions in what OSes expose, how they expose it, and if it could be effectively utilized within an app to help manage state.
This kind of thing should not be a blocker to the initial spec release, at least in my point of view. However, it is something to keep in mind with the complexities in this area for a later revision.

I'm adding a super basic one-line use case for this and some other new potential Display properties. I'll dig into research and expanding specific details and use cases and as this proposal evolves. Let me know if you have more input or feedback as we forge ahead, thanks!


Great mod  -Just having issues with clicking confirm on a buy or sell because it crashes after that

After I click on confirm it crashes, I can click on the sign and set it up with no problems and seems to work fine until I hit confirm. then the server crashes. with the following errors:
Gunpowder Database Thread/ERROR Error on Database Thread! Please report to the mod author if this is unexpected!
it says "Abort due to constraint violation (UNIQUE constraint failed: Balance.user)"
line 1785 is where run the file here are my logs:
https://paste.shockbyte.com/kavidenefesazazugiqa

Does this also happen on the 1.17 version?

no just the 1.16.5 version, the 1.17 works but my smp is still on 1.16

im just testing out the older versions of the signshop


Added instructions for scoop

Signed-off-by: metonymic-smokey<EMAIL_ADDRESS>Description
This PR fixes #400
Notes for Reviewers

Added instructions for installing using Scoop, based on the resources linked in the issue.
Possible changes needed in the Meshery releases page and mesheryctl links. Should I fix those as part of this PR or open a separate issue for those?

Screenshot of Changes

Signed commits

[x] Yes, I signed my commits.

@leecalcote ,
Please review this PR and let me know if there are any changes I should make.
Also, just take a look at the links in the first part of the Windows User section. Meshery releases page should be highlighted as a llnk too I think.
Thanks!

Thanks, @metonymic-smokey. Yes, please do go ahead and include other related fixes in this PR, if you would. A couple items to consider:

Let's put the Scoop instructions as the first option. Use of this package manager should be more convenient for the user.
Let's remove the hyperlink from "Meshery releases page" and move it to mesheryctl.
Let's avoid use of the phrase "for the same". It's grammatically incorrect (despite it's wildly, popular use in India).
You can use the phrases "Using Scoop" and "Using binary". Under "Using binary", put a subsequent line with "Not a Scoop user? Download the mesheryctl binary directly."
Under Kubernetes, will you update the "Using Manifests" section to include a subsequent line with "Not a Helm user? Use the Meshery manifests directly."

@leecalcote ,
Thanks for the feedback!
These are the screenshots after making the changes:
1.

Let me know if there are any changes to be made!
Thanks!

Well, that was fast. 😄
Looking over these changes, I'm left with very little room to complain. Not good. Not good at all. I need something to complain about.
Hmm. My complaint is that there is no room to complain. There. I found something. 😉
Nice work, @metonymic-smokey. 👍


Feature/font update

Rolled up the StandardizeBranch into the FontUpdate branch. Landing both with one request.
Unified all function names and enum names
Simplified the font implementation and added new fonts

Looks good


Current minimum driver version is 390, not 396

Until we cut a new release (I think this little mistake does not warrant one), we should just ignore warnings.
We actually want to keep ffnvcodec-headers pin to our current version, any other subsequent version seems to bump driver requirements >390.

Yeah, lets keep it


await ens.reverse(address).name() promise never resolves

I believe I've instantiated correctly:
import ENS from 'ethereum-ens';
import Web3 from 'web3';

const provider = new Web3.providers.HttpProvider();
const ens = new ENS(provider);

let name = await ens.reverse(address).name();
if (address !== await ens.resolver(name).addr()) {
  name = null;
}

The ens.reverse(address).name() promise never resolves and just hangs.  The method directly after doesn't run.
There is a network request being made to infura: https://ipfs.infura.io:5001/api/v0/add?pin=true,
returning hash, name, and size values - but not sure if its this method that's making that exact request
Thanks for any help

I don't mean to bad-mouth but for others running into the same situation I found the solution elsewhere using:
import { ethers } from 'ethers';
const provider = new ethers.providers.Web3Provider(web3.currentProvider);
const name = await provider.lookupAddress(address);


Incoming Webhook not working with AdaptiveCard

Steps to reproduce
Hi, not sure if this is a bug but incoming webhook is not working with adaptivecard (It works fine with MessageCard). I created an incoming webhook using the connector (I know it will be deprecated soon). Instead it is returning "AdaptiveCards.AdaptiveSerializationException: Property 'type' must be 'AdaptiveCard'" . Here is what my request looks like
    const formatted_Card_Payload = {
        type: 'message',
        attachments: [
            {
                contentType: 'application/vnd.microsoft.card.adaptive',
                contentUrl: null,
                content: {
                    $schema:
                        'http://adaptivecards.io/schemas/adaptive-card.json',
                    type: 'AdaptiveCard',
                    version: '1.6',
                    body: [
                        {
                            type: 'TextBlock',
                            text: 'Submitted response',
                        },
                    ],
                },
            },
        ],
    };

    axios
        .post(options.webhookUrl, formatted_Card_Payload, {
            headers: { 'content-type': 'application/json' },
        })
        .then(function (response) {
            console.log(response);
        })
        .catch(function (error) {
            console.log(error);
        });

Expected behavior
Should send an AdaptiveCard to channel
Actual behavior
It's not sending an AdaptiveCard and instead returning an error message.
Error details
"AdaptiveCards.AdaptiveSerializationException: Property 'type' must be 'AdaptiveCard'"

Hi @miguelc1221 - Could you please try sending the same JSON using POSTMAN or cURL and verify if that works or not? We tried sending the below JSON using POSTMAN and it worked fine.

{
       "type":"message",
       "attachments":[
          {
             "contentType":"application/vnd.microsoft.card.adaptive",
             "contentUrl":null,
             "content":{
                "$schema":"http://adaptivecards.io/schemas/adaptive-card.json",
                "type":"AdaptiveCard",
                "version":"1.2",
                "body":[
                    {
                    "type": "TextBlock",
                    "text": "Submitted response"
                    }
                ]
             }
          }
       ]
    }

@Prasad-MSFT Hey, I get the same error when using postman, only MessageCards work. I followed these docs to create a webhook https://learn.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook?tabs=newteams%2Cdotnet. Any idea if it's possible my org has any settings not allowing this? The error message doesn't make sense if that is the case.

@miguelc1221 - This is quite strange as this works perfectly fine at our end. Also, could you please let us know if this issue is specific to this particular card JSON or is it happening with any card JSON?

@Prasad-MSFT It happens with any AdaptiveCard Json, only works with MessageCards

Hi @Prasad-MSFT
I encountered the same issue here.
When using Adaptive Card json, it shows that the type must be AdaptiveCard, and I changed it from "messaage" to "AdaptiveCard", and it will pop up error like there must be Summary or Text, things like that.
I was using a python script to send this post request to my incoming webhook, and it also reproduce with the REST API tools like Postman, etc.
I have changed to MessageCards but I got this warning all the time.

Thanks!

@hachi1030-Allen , this entire feature is being removed in July-August 2024.
See: https://devblogs.microsoft.com/microsoft365dev/retirement-of-office-365-connectors-within-microsoft-teams

Hi @Prasad-MSFT , so you meant that the incoming webhook will be removed totally from Teams connector is that correct?
Thanks,
Allen

None of connector will work after 1st of October. You can still use current connectors until that date. Until 15th of August there is possibility to create new connectors.

Update:
Microsoft has extended the retirement timeline through December 2025 to provide ample time to migrate to another solution such as Power Automate, an app within Microsoft Teams, or Microsoft Graph.
https://devblogs.microsoft.com/microsoft365dev/retirement-of-office-365-connectors-within-microsoft-teams/

Hello Everyone,
I could see the differences in Adaptive Card version part:
We have tried with "version":"1.2" and you all are trying with "version":"1.6"
Please test once with 1. version.
You can also refer this sample:
https://github.com/OfficeDev/Microsoft-Teams-Samples/tree/main/samples/incoming-webhook/nodejs


Major difference between ITimer and PerfEvents?

As far as I can see，ITimer engine is able to fetch native stack and java stack without "perf_event_open" enabled.
PerfEvents engine can fetch kernel/native/java stack with "perf_event_open" enabled.
Without "perf_event_open"，PerfEvents engine can only get java stack.
The question is: I found a large portion of samples decrease of java stack when I switch from PerfEvents to ITimer. Is there something I'm missing?
tomcat stack 75.19%  (21809 samples / 29080 total) with PerfEvents engine

tomcat stack 47.43%  (14881 samples /  31375 total) with ITimer engine

ps:  qps is stable and this phenomenon has been observed on many services

Appreciate for your rapid response. I'll do the digging.

Take a look at #272 for the related discussion.
I'd only add that PerfEvents engine can collect native stack traces even when kernel stacks are unavailable. Just add --cstack fp or --cstack dwarf option.

Appreciate for your rapid response. I'll do the digging.


Propagate deleted files to the container

This PR propagates and makes sure that all files which were deleted
locally in the source code is also deleted within the container on
OpenShift.
To test:
touch foobar.txt foobar2.txt && odo push && echo "\nPUSHING WITH REMOVING FILE\n" && rm foobar.txt foobar2.txt && odo push -v 4

Closes:
https://github.com/openshift/odo/issues/1354

TODO:

[ ] Add integration test
[ ] Add unit test(s)

@cdrage Is this a WIP?

/retest

Tests have been written and are passing :+1:
Time for a review!
@kadel @girishramnani @dharmit @mik-dass @amitkrout

/approve

/retest

/rest

[odo]  ✗  Unable to connect to OpenShift cluster, is it down?

/test integration

/lgtm

/retest

/retest

Heck. /lgtm label was removed since I updated the commit message.
Need another approval @amitkrout / @mik-dass

/lgtm

/test all


add spring boot configuration properties example

Coverage remained the same at 49.738% when pulling 7e10b67c5a5aee6164c7b863e4398dfb22f72f02 on nobodyiam:spring-boot-demo into aefdea8ce95a4bb1835486be73e7705feb95b0c3 on ctripcorp:master.

Codecov Report

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

@@             Coverage Diff             @@
##             master    #570      +/-   ##
===========================================
+ Coverage     46.39%   46.4%   +0.01%
- Complexity     1364    1365       +1
===========================================
  Files           325     325
  Lines          8782    8782
  Branches        840     840
===========================================
+ Hits           4074    4075       +1
  Misses         4415    4415
+ Partials        293     292       -1

Impacted Files
Coverage Δ
Complexity Δ

.../apollo/internals/RemoteConfigLongPollService.java
80.71% <0%> (+0.71%)
24% <0%> (+1%)
:white_check_mark:

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 aefdea8...7e10b67. Read the comment docs.


fix ansible clean.yml

Coverage remained the same at 34.607% when pulling d68f026f4675379f8903827824bc70173b99cb68 on yuye/rm-fix into c5b96ed770d3428b5ee57402e0078607126956a9 on pai-1.1.y.


Uri parses "example.com" but fails to parse "example.com/foo"

The title says it all really; I am using http::Uri to parse things that look like URIs, and I was surprised to find that "example.com" parses successfully, but "example.com/foo" fails with an InvalidUri(InvalidFormat) error. "http://example.com/foo" parses successfully.
Is this deliberate (there could be a subtlety I'm missing here) or a bug?
This is using http 0.1.17.

Looking at the spec linked elsewhere, I can see why this is the case I believe.
My intention was to use this Uri object to parse things that look like valid HTTP URLs, but perhaps this is not the right crate for the job? I tried using the url crate initially, but that is far broader in scope and I was looking for something restricted to HTTP URLs.

I ended up using the url crate but adding some rules to handle the not-quite-urls I wanted to deal with. Sorry for the noise :)


Curl api for iTunes Connect app status?

New Issue Checklist

[ x ] Updated fastlane to the latest version
[ x ] I have read the Contribution Guidelines

Issue Description
Does spaceship provide any curl API for iTunes Connect app status? with/without authentication?

Sorry I'm not sure I understand what you mean. What do you want to do?

these days, we use cert or sigh,  both failed, the outputs indicate it's attributed to login to member center or iTunes Connect, so is spaceship now available?

I would like to have the app status in iTunes Connect (Ready for sale/Waiting for review/...) via curl, is it possible via spaceship?

@gran33 You could do that, you can easily access the login cookie from spaceship, but it requires a lot of knowledge around http requests and cookie handling 👍


PLAT-5385 : Fix bug to escape HTML code.

Build triggered. sha1 is merged.

Build started sha1 is merged.

Build finished.

Codecov Report

Merging #144 into dev will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##              dev     #144   +/-   ##
=======================================
  Coverage   88.05%   88.05%
=======================================
  Files         135      135
  Lines        2403     2403
  Branches      279      279
=======================================
  Hits         2116     2116
  Misses        176      176
  Partials      111      111

Impacted Files
Coverage Δ

...onyoss/integration/webhook/WebHookIntegration.java
86.74% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Upgrade to tokio 1.0

This also removes the need for native TLS library.

Ping @fbriden

/ping @fbriden again
If you have a minute... :pray:

Bump, could this be updated and merged?