fix: Athena read_sql_query cache errors for qmark style parametrized queries

Feature or Bugfix

Bugfix

Detail

fix: Athena read_sql_query cache errors for qmark style parametrized queries

Relates

Closes #2956

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

AWS CodeBuild CI Report

CodeBuild project: GitHubCodeBuild8756EF16-4rfo0GHQ0u9a
Commit ID: a554c47947d19d9edf26280852ccedc4c4efc86b
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubDistributedCodeBuild6-jWcl5DLmvupS
Commit ID: a554c47947d19d9edf26280852ccedc4c4efc86b
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubCodeBuild8756EF16-4rfo0GHQ0u9a
Commit ID: aebfddfffe8b6237758c7b5babf99274c6ce279d
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubCodeBuild8756EF16-4rfo0GHQ0u9a
Commit ID: 202abb2fe3a28ae8fed326ec08c31a5b4e66f53b
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubDistributedCodeBuild6-jWcl5DLmvupS
Commit ID: aebfddfffe8b6237758c7b5babf99274c6ce279d
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubDistributedCodeBuild6-jWcl5DLmvupS
Commit ID: 202abb2fe3a28ae8fed326ec08c31a5b4e66f53b
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubCodeBuild8756EF16-4rfo0GHQ0u9a
Commit ID: 64c4e13b76f86e5561264490ecf92e5b7b0d0145
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubDistributedCodeBuild6-jWcl5DLmvupS
Commit ID: 64c4e13b76f86e5561264490ecf92e5b7b0d0145
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubCodeBuild8756EF16-4rfo0GHQ0u9a
Commit ID: 7d8101393121ded1039c2b0719b990912cc7cede
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubDistributedCodeBuild6-jWcl5DLmvupS
Commit ID: 85e7a4875b2eb8bde57b08e0584eb989a01d8955
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubDistributedCodeBuild6-jWcl5DLmvupS
Commit ID: 7d8101393121ded1039c2b0719b990912cc7cede
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


Re-using content with images on multiple renders

Put a test here to demonstrate the problem, but I'm not sure where to add a 'fix'.
General issue is that re-using a context object with images fails on subsequent renders (images come up blank) because the IO objects need to be 'rewound' before they can be used a second time.
https://github.com/senny/sablon/pull/182

I'm not sure this is an issue that Sablon necessarily needs to be concerned with. The gem renders the IO that you give it, if the given IO is already read, there's nothing more for Sablon to read. I feel this is more of a caller problem.
I can acknowledge that it is something that might trip people up but at the same time, I don't think that Sablon should rewind any IO's or similar. If it's easy to detect that the IO is already exhausted, we could print a warning.

Since we're sending in the content as what seems like a static JSON object, the caller's instinct is that it should just work 🤷
I just figured it may be easy to add a lightweight call somewhere that rewinds all stream/io objects that doesn't feel terrifically invasive to sablon. If that's harder than I think it is, than that's fine. There are certainly workarounds and maybe we can just add a little info on the documentation for this quirk.

The conceptional issue I see with calling rewind on the passed context is that this imposes side-effects onto objects given to Sablon. This is not expected and could cause issues with IO objects that might behave differently than a regular File or StringIO buffer.
I think it's preferred that the caller produces a new IO to give to sablon on each request. Could be implemented with a proc or a context object where the method does not memoize the IO.

OK, I think you make a fair point that the IO being rewound is a side effect the caller may not expect.
I think the biggest surprise/gotcha with this is that the images just vanish (i.e. fail to render anything) on subsequent renders with no errors or warnings. Perhaps it would be better for Sablon to throw an error/warning when a Content object's attempt at read/render results in zero bytes. It took me awhile to understand what was going on.

Perhaps it would be better for Sablon to throw an error/warning when a Content object's attempt at read/render results in zero bytes. It took me awhile to understand what was going on.

I think this is a fair point and would be welcome as an addition. Printing a warning and indicating how to resolve it should be sufficient to make the user aware of this concern. We might also want to add some documentation about it.


Add Capacitor 6 support

Please, add support for Capacitor 6
Thanks !

Capacitor provides a migration script npx @capacitor/plugin-migration-v5-to-v6@latest updating the files automatically.
https://capacitorjs.com/docs/updating/plugins/6-0#using-capacitorplugin-migration-v5-to-v6

No worries. Thanks for the plugin anyways.

Hi @jepiqueau, please before upgrading to version 6, could you please review the pull request I made to add DRM support to the native players. I also tried to contact you, because I need to develop a number of features over the video player and I want to check with you how we can collaborate.
I already sent you and email explaning the situation.
Thanks you very much for your time and for this awesome plugin.

This fork exists, can't say if it works or not tho
https://github.com/Jiwoks/capacitor-video-player

Hello, all,
I have been granted new maintainer of this project.
As an update, Capacitor 6 support will be my main priority, second of course to looking at outstanding PR's. (@ivancduran)
Please, bear with me as I get my legs for this project.

@harmonwood I created a PR for the update to Capacitor v6 (https://github.com/harmonwood/capacitor-video-player/pull/164)
I also have two other PRs for fixes that I found while using this plugin with a client project.

https://github.com/harmonwood/capacitor-video-player/pull/162
https://github.com/harmonwood/capacitor-video-player/pull/163

@harmonwood , let me know if you need something else in the PRs, so I can work on that and we could merge them to master
Thank you! 😄

version 6.0.0 has been published to npm


Crashes on ConversionException in query

Heya!
Was just playing around and input a query I knew to be bad, and managed to crash harlequin:
select 0::struct(id int)

This was in version 0.0.8

Thanks for the report

@Mause this is patched in v0.0.9


scanner: Add a NestedProvenanceResolver

The ProvenanceTreeResolver is used to resolve nested repositories in a
RepositoryProvenance. It will be used by a new experimental scanner
implementation in a later commit, therefore it is also located in the
"experimental" package for now.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@34b27d8). Click here to learn what that means.
The diff coverage is 35.61%.

:exclamation: Current head a754d7b differs from pull request most recent head a0c4a71. Consider uploading reports for the commit a0c4a71 to get more accurate results

@@            Coverage Diff            @@
##             master    #4257   +/-   ##
=========================================
  Coverage          ?   64.92%
  Complexity        ?      477
=========================================
  Files             ?      165
  Lines             ?     6541
  Branches          ?      853
=========================================
  Hits              ?     4247
  Misses            ?     1902
  Partials          ?      392

Impacted Files
Coverage Δ

advisor/src/main/kotlin/advisors/NexusIq.kt
0.00% <0.00%> (ø)

advisor/src/main/kotlin/advisors/VulnerableCode.kt
92.85% <92.85%> (ø)

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 34b27d8...a0c4a71. Read the comment docs.


Bump clang format version in CI to v18

This patch bumps the clang format version in CI to v18 as v18 is the latest LLVM release (currently) and includes quite a few patches for clang-format.

This will be clang-format clean when #126 lands.


Update README.md

Prototype DDos Script!
If there are bugs please report them!

Kok error merah

Prototipe kak yg V2 masih kerja
Pada Sel, 11 Jun 2024 22.21, Quastars @.***> menulis:

Kok error merah
—
Reply to this email directly, view it on GitHub
https://github.com/indoTeambully73/IndoDdos-Prototype/pull/1#issuecomment-2160893907,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BGHG7M2HS37XH37NNSSTPVDZG4BVXAVCNFSM6AAAAABI7WBNFOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRQHA4TGOJQG4
.
You are receiving this because you authored the thread.Message ID:
@.***>


Fix for compiler defines

Some of optimized code branches were disabled by #if defined(__AVX512F__) && defined(DAAL_INTEL_CPP_COMPILER) check for icc compiler.
This PR removes check for __AVX512F__ define and changes check from DAAL_INTEL_CPP_COMPILER to __INTEL_COMPILER.

/intelci: run

/intelci: run

@maria-Petrova  - i think this is worth noting this within icx migration effort - currrently ICX can't handle all code properly. So we roll back to just icc compiler here and there are other places with AVX512 define that should be checked.
The difference between algorithms and data management as @Alexsandruss pointed out - algorithms get build for particular arch, while datamanagement have single instance that works for multiple arches.


Add Vega-Lite Auto Examples

Updated auto-examples to generate notebooks from the JSON examples.
For the time being, I did not commit executed versions because the visualizations don't show up until you run them in a browser anyway.
(Though I did auto-execute all of them to confirm that the Python runs correctly)

For reference, here's a link to the auto-generated example index: https://github.com/jakevdp/altair/blob/122a7ad2d6f2977a53b9696a7dc053ef6af55771/notebooks/auto_examples/Index.ipynb

Oops – realized I wasn't actually running all of them. I found and fixed a small bug with datetime serialization, confirmed that all examples run, and added a link to them in the index.

Great, should I merge?

I think it's good to go


CSS Modules example

Hello everyone!
This is the first iteration on the CSS Modules example.
I implemented the Tweet Card from mobile.twitter.com, using the following tweet (as agreed in #3):
https://mobile.twitter.com/mxstbr/status/755481795206971392
Notes:

I installed the css-loader from GitHub because of webpack/css-loader/pull/307
there's a small animation on the "favorite" button
components could be split into smaller ones but I wanted a feedback first
I used postcss-modules-values but if you think it's out of the scope we can easily remove it

I hope you like it and I'm looking forward to receiving some feedback.
359px

360px

600px

On the road right now, I love that you included listing. How strict is it? We need to be as strict as humanly possible.

Maybe we should go with vanilla airbnb? That'd make it easy for most people.

Finally getting around to checking this out now, sorry for the wait! Let's kick this mofo off!

Let's not render into document.body, let's choose a root node. (something unique like #example-root) This will make creating the site with the different approaches a lot easier when we get around to that.

I still want to use vanilla airbnb. It's not about the whole semicolons-or-not thing, I think that it will make people more comfortable with the style if we use the vanilla one.

 Maybe the transformation utils and the data should be in a shared, top-level folder so all the examples can use the same functions and data without copy and pasting?

Same goes for the eslint config, that should be shared example-wide?

What about the assets? Shouldn't they also be shared?

Use http://mxstbr.com/headshot.jpeg for the tweet avatar – I changed my avatar and now the display is broken, which shouldn't happen. mxstbr.com/headshot.jpeg will always exist 👍

Other than that, the component structure and all that looks good to me!

hey @mxstbr, thanks for reviewing my PR.
I'll push a new commit with the changes.
I've got just one question:

I still want to use vanilla airbnb. It's not about the whole semicolons-or-not thing, I think that it will make people more comfortable with the style if we use the vanilla one.

do you want me to remove only the "rules" or do you think it's better removing the "import/resolver" setting too?
sharing data, config and assets sounds great.
I think we should merge this one first and then we can create a shared folder in a different PR, if it makes sense for you.

I think we should merge this one first and then we can create a shared folder in a different PR, if it makes sense for you.

Sure thing, sounds good to me – let's get this done!

do you want me to remove only the "rules" or do you think it's better removing the "import/resolver" setting too?

Just the rules should be fine, I think. 😊

It should be ok now @mxstbr.
Please let me know if there's something else I can do to improve it.

I like it. I say we merge it, factor out the common stuff and get onto the next one! 👍
What do you think @geelen @JedWatson?

Just realised we're including a .ejs template without any ejs specific stuff. Let's rename it to index.html, throw it in the root of the example and point HTMLWebpackPlugin at that?
Seems more obvious for beginners.

I also don't think we need to differentiate between containers and components – really, they're all components. Let's put them in the same folder in an effort to put the focus on the method of styling used!

Along the same vein, what do you think about getting rid of the resolve.root setting? I feel like this'll only serve confuse newcomers not used to webpack, I'd much rather avoid that and have the focus be on the styling method used.

We should also add a README to all methods of styling used and explain where to find the docs and what some of the specialities and ideas are – I can do that.


fix: Make signature of LazyTextFile constructor adhere to its parent class

Please check if the PR fulfills these requirements

[x] The commit message describes your change
[ ] Tests for the changes have been added if possible (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Fix the constructor signature of the LazyTextFile class which should accept a parameter of type Project but was set to take a Construct instead

What is the current behavior? (You can also link to an open issue here)

Wrong type signature on LazyTextFile class.

What is the new behavior (if this is a feature change)?

This change should introduce no change to runtime behavior due to type erasure during compilation

Does this PR introduce a breaking change? (What changes might users need to make in their setup due to this PR?)

Nope

Other information:

Small oversight when accepting the previous PR

After the switch to the constructs lib, projen components should also use the construct tree and not all take the project. See https://github.com/projen/projen/blob/main/src/textfile.ts#L30
Or am I misinterpreting this?

Nope, my bad. Seems Webstorm had an old dependency cached. One rm -rf node_modules && yarn install later it showed up correctly.


Enhancement Request - Increase div.clusters height in Vue left nav bar (explorer cluster section)

v2.6.0 and v2.6.1-rc2
It would be nice if we could use some more vertical real estate on the left nav pane for div.clusters - only four clusters get listed even on a huge 4k monitor or when otheriwse having tons of vertical real-estate.
Pictured:
4 of my 5 clusters are listed. Due to the overflow a scrollbar is shown - this wasn't very visually noticable to me so I thought there was a bug and my 5th cluster wasn't shown. It turns out that the vertical height is just rather small for div.clusters for some reason.

@davidnuzik The number of clusters shown is configurable via the User Avatar Menu --> Preferences --> Formatting section

Oh, wow! My apologies for not being aware of this. Thank you! :)
Closing.


In upload example of Croppie, if we upload image of higher size(e.g., 5mb) and if we uploading image of lower size(e.g. 300kb), is there any way through which the size of cropped image is being controlled?

Expected Behavior
Actual Behavior
Steps to Reproduce the Problem

Example Link
Please recreate your issue using JSbin, JSFiddle, or Codepen.

Link:

Specifications

Browser:
Version:

This is controlled when you set the viewport option. See the section on the main site


Add titles to docs

I now have 4 different bootstrap docs pages open while upgrading, and each of them says "Bootstrap, from Twitter". It'd be nice if they had titles like "Bootstrap: Components", "Bootstrap: Upgrade guide", etc.

@fat, can we make this part of the Mustache templates?

yup - totes


MAP for IPHONE

How do I get the Map to work on an Iphone? I just have the desktop map for my Macbook.

@movak93 check #652 . Thanks.

@23ten  Thanks a ton!

Sure thing :)


Cannot boot Windows 7 x86 guest due to instruction emulation error

when i tried boot windows 7 x32 sp1 , i got thus message.

i view the source code and debug it , i found it's  vcpu_simple_decode produce it when handle ept violation。it looks like some opcode doesn't support。

Let's close this one and use #12 to track the instruction emulator bug.

thanks。


feat: Added notebook for CoT and ReACT

Description
This notebook demonstrates advanced prompting techniques such as chain of thought reasoning, and building ReAct agents using LangChain, Vertex AI and Gemini.

[x] Follow the CONTRIBUTING Guide.
[x] You are listed as the author in your notebook or README file.

[x] Your account is listed in CODEOWNERS for the file(s).

[x] Make your Pull Request title in the https://www.conventionalcommits.org/ specification.
[x] Ensure the tests and linter pass (Run nox -s format from the repository root to format).
[x] Appropriate docs were updated (if necessary)

@lazyprgmr I am going to merge as-is to keep things moving, but an additional PR for the non-LangChain implementation would be fantastic. Thank you!

@lazyprgmr I am going to merge as-is to keep things moving, but an additional PR for the non-LangChain implementation would be fantastic. Thank you!

Thanks @kweinmeister, we'll work on it!


changed structure of Input to fix style issue when a label is present…

… with a prefix/suffix

 (0) Fix  prefix/suffix with label


perf(diff/controller): add leader election for diff cache writer

Resolves #80

Codecov Report
Patch coverage has no change and project coverage change: -0.17 :warning:

Comparison is base (7cb5e98) 36.08% compared to head (98b5859) 35.91%.

:exclamation: Current head 98b5859 differs from pull request most recent head 73d7873. Consider uploading reports for the commit 73d7873 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #87      +/-   ##
==========================================
- Coverage   36.08%   35.91%   -0.17%
==========================================
  Files          32       32
  Lines        2325     2336      +11
==========================================
  Hits          839      839
- Misses       1424     1435      +11
  Partials       62       62

Impacted Files
Coverage Δ

pkg/util/channel/channel.go
61.49% <0.00%> (-4.51%)
:arrow_down:

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Host a live demo

Hosting a live demo of the trace extension using a Theia-based IDE completely removes the setup time so it greatly encourages people to try out the tool.

Removing the setup makes collecting feedback from busy analysis experts much more realistic
Example: Grafana live demo

Prerequisite: Allow connecting to a remote trace server (by specifying the URL #79)

A related issue that may give a nice first live demo on gitpod: https://github.com/theia-ide/theia-trace-extension/issues/79

An additional way of providing a demo would be to create a minimal single-purpose Theia application only for trace viewing:

Issue #84: Add minimal trace-viewer example app

The README will soon explain how to run a demo via Gitpod so this issue can be "put to sleep" for the next couple months. Having a Gitpod live demo meets the project's current needs since people who are trying the tool at this stage are potentially also interested in seeing the source code.
Further in the future, when people trying out the tool are less involved in development, it could become valuable to provide a live demo that goes straight to the tool similar to Grafana.

Right now there's a live demo via Gitpod and if we want something directed more towards users than devs we can create a separate issue for that.


Add ability to send separated stream frames

Q
A

Bugfix?
❌

Breaks BC?
❌

New feature?
✔

Issues
https://github.com/roadrunner-php/issues/issues/15

[x] Waiting for https://github.com/roadrunner-php/worker/pull/30

Codecov Report
Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (30d89df) 14.63% compared to head (0e7c7c9) 15.97%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff              @@
##                3.x      #18      +/-   ##
============================================
+ Coverage     14.63%   15.97%   +1.34%
- Complexity       53       56       +3
============================================
  Files             4        4
  Lines           164      169       +5
============================================
+ Hits             24       27       +3
- Misses          140      142       +2

Files
Coverage Δ

src/HttpWorker.php
40.98% <75.00%> (+1.69%)
:arrow_up:

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


css file not changing

We have written the needed data into your clipboard because it was too large to send. Please paste.

Can you give us the information what is happening here? Right now, we can't help you.

My guess is that the  in the HTML document doesn't point to the styling.css file. Can you check the network tool to see if the CSS is not loaded? If you filter by styles it should show up as read.
https://learn.microsoft.com/en-us/microsoft-edge/devtools-guide-chromium/network/
In my case here, the layout.css has a "x/" in front of it which means it can't be found, so the network tool shows it as red and the fix is to remove the x/

Even better would be to show us your code.


Giganode node doesn't exist anymore

Models/Config/TezosNodeClientConfig defaultMainnetURLs.primaryNodeURL is no longer in service as of October 1, 2021.   This should migrate to another node, ex: https://mainnet.smartpy.io
https://twitter.com/GigaNode/status/1435265400699342854?s=20

That may be the goal but in practice, the node is down.  I guess it doesn't matter that much if you have a fallback URL.  I've only used this SDK for 2 minutes (literally), so I haven't gotten that far into understanding it.

@aklowther ping might be disabled on the server, or it could have been down briefly due to an issue.
I was working on the develop branch of this yesterday. I tested mainnet balance requests and it was fine against giganode. I'll keep an eye on it and change the default if it does go down. But it's not necessary right now to change it.
If it does go down, the config object allows you to pass in your own urls. That convenience init is just to help people new to tezos or new to the swift library to get up and running to conduct tests. Most apps end up deploying their own nodes and will point to their own anyway
Also if you do end up using this library for your own app, let us know. It's mainly for our own use cases, but it can help us secure funding if we can show others are relying on it


[Bug]: [ARM][SDK] armRenameListByOperation decorator prevent client.tsp re-arrange the operation groups

Describe the bug
SDK emitter (and TCGC) takes interface (interface with @client/@operationGroup in client.tsp takes precedence) to group the client and operation groups.
@armRenameListByOperation decorator on ArmResourceListByParent operation template would rename the operation to pattern listBy<parent-resource-name>. This present SDK putting 2 or more ArmResourceListByParent operation (different resource, but same parent resource) to a single operation groups.
See https://gist.github.com/weidongxu-microsoft/fa420c35cf0611a62a8d155771dd3425#known-approach-to-group-operations
For brownfield service, SDK would need to keep the operation group structure, to avoid breaking changes.
One solution would be to remove the @armRenameListByOperation decorator from ArmResourceListByParent operation template.
But this leaves one question: what can we do to guide (particularly greenfield) service dev on operation name. E.g. it would be welcome that the operation name being consistent for new services, e.g. listByResourceGroup or listByTenant.
If we remove the decorator, breakdown could be

rename all existing operation to the expected name of @armRenameListByOperation (so that operation name would be same, regardless of the existence of @armRenameListByOperation)
remove @armRenameListByOperation from ArmResourceListByParent operation template
[optional] find another way to guide service on the List operation name

Reproduction
playground
Checklist

[X] Follow our Code of Conduct
[X] Check that this issue is about the Azure libraries for typespec. For bug in the typespec language or core libraries file it in the TypeSpec repo
[X] Check that there isn't already an issue that request the same bug to avoid creating a duplicate.
[X] The provided reproduction is a minimal reproducible example of the bug.

@allenjzhang
Let me know if we follow this breakdown. And if I can help you to do #1 on the renames on existing operation.

This should be fixed in the July release


Strange delay on SSH connection caused by seemingly innocuous change

Bug description
For context, we have a Pod like this:
    ports:
    - containerPort: 9080
      name: http-web-admin
      protocol: TCP
    - containerPort: 8317
      name: http-web
      protocol: TCP
    - containerPort: 8318
      name: tcp-sftp
      protocol: TCP

And a Sidecar like this (note, only referencing the http ports):
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: vds-acceptor
  namespace: vds-acceptor
spec:
  ingress:
  - defaultEndpoint: <IP_ADDRESS>:8317
    port:
      name: http-app
      number: 8317
      protocol: HTTP
  - defaultEndpoint: <IP_ADDRESS>:9080
    port:
      name: http-admin
      number: 9080
      protocol: HTTP

And the following annotation on the PodSpec:
annotations:
  traffic.sidecar.istio.io/includeInboundPorts: 8317,9080

And everything is fine.
However, we thought that the annotation traffic.sidecar.istio.io/includeInboundPorts: 8317,9080 is redundant due to the more recently added Sidecar ingress config shown above.
When we remove the annotation the service still works, but we start getting a delay (feels like around 500ms but does have some variance):
❯ telnet
telnet> o
(to) <IP_ADDRESS> 22
Trying <IP_ADDRESS>...
Connected to <IP_ADDRESS>.
Escape character is '^]'.

<-- delay here

SSH-2.0-SSHD-CORE-1.4.0

This causes us issues as we have services expecting to see SSH-2.0-SSHD-CORE-1.4.0 without such a delay.  It feels like protocol sniffing, but we have enableProtocolSniffingForInbound and enableProtocolSniffingForOutbound set to false and also just for the sake of sanity we tried setting protocolDetectionTimeout: 1ms.
I'm also slightly confused, why with or without the annotation we get a listener?
❯ istioctl proxy-config listeners vds-acceptor-79878c5667-qw7sh.vds-acceptor
ADDRESS           PORT      TYPE
<IP_ADDRESS>     8317      HTTP
<IP_ADDRESS>     9080      HTTP
<IP_ADDRESS>     22        TCP

We cannot see any differences in the proxy-config listeners|clusters between a deployment with or without this annotation, so we're stumped.  Adding the annotation back removes the delay.
[ ] Docs
[ ] Installation
[x] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[x] User Experience
[ ] Developer Infrastructure
Expected behavior
Removing the annotation to not to introduce an arbitrary tcp delay.
Steps to reproduce the bug
As above
Version (include the output of istioctl version --remote and kubectl version --short and helm version if you used Helm)
1.5.10
How was Istio installed?
Helm
Environment where bug was observed (cloud vendor, OS, etc)
GKE

traffic.sidecar.istio.io/includeInboundPorts only impacts the iptables so it would make sense it doesn't impact the XDS config

@howardjohn we're unable to reproduce this on 1.6.
The issue was actually raised against a 1.5 control plane.  On 1.5 we've worked around it with the includeInboundPorts annotation, and obviously don't expect you to be releasing a fix for 1.5 so will close it off.


Simple signing scheme: now only support GPGKeys key type.

Following the simple signing golang repo: https://github.com/containers/image

@jialez0 can you close this issue?


False positives with v1.10.1?

Since few hours we observe errors with Run JustinBeckwith/linkinator-action@v1. Maybe that come from the new v1.10.1 release.
Nothing changed on our side, the error began to appear after having rebased some of our PRs.
Example of errors in https://github.com/twbs/bootstrap/runs/7268820877?check_suite_focus=true.
In order to have more details, I have enabled verbosity: debug in my fork and created a fake PR. The result with more details can be found in https://github.com/julien-deramond/bootstrap/runs/7269113811?check_suite_focus=true.
If we consider those two errors:
Error: [404] _site/docs/5.2/assets/img/bootstrap-icons.png,
Error: [404] _site/docs/5.2/assets/img/bootstrap-themes.png,

When launching the corresponding website locally, all the images in error exist at those URLs.
When deployed by Netlify (using this _site directory) they also exists:

https://twbs-bootstrap.netlify.app/docs/5.2/assets/img/bootstrap-icons.png
https://twbs-bootstrap.netlify.app/docs/5.2/assets/img/bootstrap-themes.png

Other images in this same img directory (not at the same level) are not detected as 404 errors:
[200] _site/docs/5.2/assets/img/favicons/apple-touch-icon.png
[200] _site/docs/5.2/assets/img/favicons/favicon-32x32.png

Something seems weird in this extract; the tested URL contains a comma at the end.
[
  {
    "config": {
      "method": "GET",
      "url": "http://localhost:33887/docs/5.2/assets/img/bootstrap-icons.png,",
      "headers": {
        "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36"
      },
      "responseType": "stream",
      "timeout": 0
    },
    // ...
  }
]

Our GitHub workflow: https://github.com/twbs/bootstrap/blob/main/.github/workflows/docs.yml
Seems to be reproductible as well by doing the following:
git clone git@github.com:twbs/bootstrap.git
cd bootstrap
npm i
npm run start

## In an other terminal
npx linkinator http://localhost:9001 --verbosity debug

There are not much modifications in your repo since the last version except in src/action.js. Maybe it comes from some bumped dependencies.
I'm still trying to go further in my analysis.
Edit: By running npm<EMAIL_ADDRESS>http://localhost:9001 --verbosity debug I don't see any errors.
So this regression seems to be observed in the new 4.0.1 version (I can move this issue in the linkinator repo if needed :) ).
Just saying that by reading the code so it is just a hunch, but in https://github.com/JustinBeckwith/linkinator/commit/9a8a83c35182b3cd4daee62a00f156767fe5c6a7 in src/links.ts there was a         .split(',') that doesn't seem to be there anymore and could maybe explain the presence of comma in some of the 404 URLs :shrug:

Ooof - thank you for doing some of the early analysis here!  I am going to go ahead and move this to the linkinator repository since you've narrowed it down to that last PR :) That code was really only running in the case of a srcset element, and in that case I was super parsing those properties wrong 😆  Curiosity - have you identified the specific place in your source code where these links are present?  Is there a chance those commas actually exist inside of a srcset attribute, and have the comma?  It's entirely possible this is a bug in the library I picked up to do the parsing 🤦


[bug] Can't remove mainnet from supported chains when configured via configureChains

Is there an existing issue for this?

[X] I have searched the existing issues

RainbowKit Version
0.4.5
wagmi Version
0.6.0
Current Behavior
Situation: We do not support mainnet in our dApp, but we need to include an RPC-provider in configureChains to have ens-name & avatar lookups working properly. So we do something like this:
export const supportedChains: Chain[] = allChains.filter((chain) =>
  env.supportedChains.includes(chain.id)
)
export const { chains, provider } = configureChains(
  Array.from(new Set([chain.mainnet, ...supportedChains])),
  // ...

Now we don't want rainbowkit to offer the mainnet-option in its chain-switcher menu (which it would obviously do if we just use the exported chains object). This is why we do filter the chains object (again) after running through configureChains via:
export const supportedWagmiChains: Chain[] = chains.filter((chain) => {
  return env.supportedChains.includes(chain.id)
})

And using it like:
<RainbowKitProvider chains={supportedWagmiChains}>…</RainbowKitProvider>

But that doesn't solve the problem. "Ethereum" is still shown as an option in the chain-switch menu (without icon though):

Expected Behavior

If a chain is not passed to RainbowKitProvider, fully ignore it.
But more importantly, offer an easy way to provide a mainnet RPC for ens-lookup without requiring mainnet to be supported.

Steps To Reproduce
No response
Link to Minimal Reproducible Example (CodeSandbox, StackBlitz, etc.)
No response
Anything else?
Thanks in advance as always ❤

Any ideas @markdalgleish @jxom @nicoglennon? Or can I provide any more information?

@wottpal Just opened a PR to support this!

Awesome, thanks!
The useMainnet function looks good to me, but of course, you should wait for more sophisticated reviewers 🤓

You can now filter chains before passing them to RainbowKit in v0.4.8.


error migrating from 0.6.13 -> 0.7.0

Running pypgstac migrate --debug from a ghcr.io/stac-utils/pgstac:v0.7.0 container gives:
DEBUG:pypgstac.db:PG VERSION: 13.8.
INFO:pypgstac.migrate:Migrating PGStac on PostgreSQL Version 13.8
DEBUG:pypgstac.db:VERSION: 0.6.13
INFO:pypgstac.migrate:Migrating from 0.6.13 to 0.7.0.
DEBUG:pypgstac.migrate:Running migration file pgstac.0.6.13-0.7.0.sql.
DEBUG:smart_open.smart_open_lib:{'uri': '/opt/src/pypgstac/pypgstac/migrations/pgstac.0.6.13-0.7.0.sql', 'mode': 'r', 'buffering': -1, 'encoding': None, 'errors': None, 'newline': None, 'closefd': True, 'opener': None, 'compression': 'infer_from_extension', 'transport_params': None}
INFO:pypgstac.db:NOTICE - role "pgstac_admin" already exists, skipping
INFO:pypgstac.db:NOTICE - role "pgstac_read" already exists, skipping
INFO:pypgstac.db:NOTICE - role "pgstac_ingest" already exists, skipping
INFO:pypgstac.db:NOTICE - role "user_postgres_admin" is already a member of role "pgstac_admin"
INFO:pypgstac.db:NOTICE - must be owner of table _items_15, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_18, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_6, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_3, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_13, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_14, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_26, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_25, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_27, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_30, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_5, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_7, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_8, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_12, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_22, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_19, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_21, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_24, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_28, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_29, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_17, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_10, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_32, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_23, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_20, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_33, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_34, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_9, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_4, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_31, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_11, skipping
INFO:pypgstac.db:NOTICE - must be owner of table _items_2, skipping
INFO:pypgstac.db:NOTICE - schema "pgstac" already exists, skipping
Traceback (most recent call last):
  File "/usr/local/bin/pypgstac", line 8, in <module>
    sys.exit(cli())
  File "/opt/src/pypgstac/pypgstac/pypgstac.py", line 118, in cli
    fire.Fire(PgstacCLI)
  File "/usr/local/lib/python3.9/dist-packages/fire/core.py", line 141, in Fire
    component_trace = _Fire(component, args, parsed_flag_args, context, name)
  File "/usr/local/lib/python3.9/dist-packages/fire/core.py", line 466, in _Fire
    component, remaining_args = _CallAndUpdateTrace(
  File "/usr/local/lib/python3.9/dist-packages/fire/core.py", line 681, in _CallAndUpdateTrace
    component = fn(*varargs, **kwargs)
  File "/opt/src/pypgstac/pypgstac/pypgstac.py", line 57, in migrate
    return migrator.run_migration(toversion=toversion)
  File "/opt/src/pypgstac/pypgstac/migrate.py", line 143, in run_migration
    cur.execute(migration_sql)
  File "/usr/local/lib/python3.9/dist-packages/psycopg/cursor.py", line 723, in execute
    raise ex.with_traceback(None)
psycopg.errors.InsufficientPrivilege: permission denied for table _items_15

The migration to 0.6.13 was run on 2023-02-21T17:56:48.969Z
Do you have any thoughts on what the issue may be?

Ah, these tables are created by partitions_trigger_func, which doesn't exist any more. It looks like they were created with a different owner, presumably because that was the user which created the partitions.
Is there any danger in deleting or switching the owner of these tables?

updated the owner to pgstac_admin manually and the migration passed


FAST: fix data-platform-dev folder in stage 03-data-platform

I did run all Fabric Fast steps and noticed an issue when applying the 03-data-platform stage. It references to a non-existing folder. The 01-resman stage creates specific data-platform-dev and data-platform-prod folders and writes them to the resulting tfvars file. As this file is used as input to stage 03-data-platform, the specific data-platform-dev folder must be referenced, but actually only a generic data-platform folder, which does not exist, was referenced.
With this PR i fixed it to use the existing data-platform-dev folder.

Hey Stefan, thanks for this! Could you merge master in, or give us permissions to do so? Linting and tests also need attention, you can check our contributing guide, or we can do it once we can push to your fork.

Hi Ludovico, thanks for the quick review! I think i fixed the linting and the tests. I also rebased to master. Just wasn't able to execute pytest locally due to some errors.
You also have access to our repo now and could also apply changes if needed.

Thanks Stefan, all good! I think you can mark forks as accessible from the forked repo admins when you create the fork, no need to share individually next time. :)


ARROW-3087: [C++] Implement Compare filter kernel

This is the first step in supporting basic expressions of the form column_x > k.

How do you feel about renaming the files from comparator to compare? That seems more in line with the rest of the kernel file naming :)

@pcmoritz will do.

Error is
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
terminate called after throwing an instance of 'std::system_error'
  what():  Not enough space
98% tests passed, 1 tests failed out of 58

@pitrou could you do a review pass?

@fsaintjacques Can you rebase? Building fails here.


feat(@angular-devkit/schematics-cli): add support for camelCase arguments

At the moment, only kebab case args works, and this might be misleading if you come from the Angular CLI. As for instance --dryRun will have no effect.
Fixes #12599

@clydin can you take a look please?


Url encode body breaks on Android Gmail

Hi,
Thanks for creating this lib :-)
Your recent change in https://github.com/tschoffelen/react-native-email-link/pull/71 breaks the email body on Android for me. Gmail now renders the email encoded e.g. Hi%20there%20 etc.
Reverting the 'fix' in said PR resolves the issue for me.
This happens with Gmail 2020.06.14 (=latest version) on Android 9. I haven't tried other clients.
Perhaps openComposer needs an option encodeBody that controls this behaviour?

It also breaks some other emails on iOS. I think everyone has to do it by himself.

Hey @radko93 @emielvanliere,
I also had this issue so I added the encodeBody body flag you requested.
Cheers!


Press Key keyword no longer works with strings

Following example results in error (actual variable names replaced):
Press Key    ${EnterSomething}    test-something
This will error with message: ValueError: Unknown key named 'test-something'

@deaglejv, the update we made to the Press Key keyword in 1.7.3 had some unintended consequences. For now, I recommend rolling back to 1.7.2 if it's time critical, but we're definitely working hard to get a patched release out.
The issue isn't that the - doesn't work, but rather that Press Key no longer accepts a string of characters to be pressed. This is mostly my fault for missing that detail in the code review.
As I said, we'll have a patch out ASAP. Sorry for any inconvenience.

There's a few solutions that I can think of off the top of my head.

Check to see if a string with length > 1 matches a special key. If so, use the special key. Otherwise just send the string.

Press Key   text_field    q          # The letter 'q'
Press Key   nav_console   ARROW_UP   # Named ARROW_UP key
Press Key   login_button  \\\\13     # ASCII code for Enter key
Press Key   custom_input   mystring  # String to be entered

Make the special keys all some sort of variable that's built into the global context.

Press Key   nav_console   ${SELENIUM_KEYS.ARROW_UP}   #Arrow up key

Add a new keyword that just performs send_keys

Send Keys   custom_input   mystring   # String to be entered

I'm up for hearing any other suggestions as well.
/cc @pekkaklarck, @emanlove, @HelioGuilherme66, @aaltat

I think I'd just revert the change done in earlier version. This is so severe regression that a fix is needed ASAP and I doubt we can come up with a good design that quick.

Possible new design should be backwards compatible with 1.7.1 and earlier. Bigger changes require deprecation in 1.8 first and may not be a good idea even then.

I agree with @pekkaklarck. Let's revert back the changes. It gives us time to consider what we need to do. Also I fear that jumping to new code, will lead to more problems than it will solve.
If we decide to make the changes, let's review the current test and make corrective actions to prevent this from happening.
Then deside what the keyword should do, how to change it and when to change it. Write test to cover the new functionality. Write code, refactor and polish. Send pull request, do review... Like normal iterative process. When things are do with enough thinking (slow enough), one then achieves better results with great speeds.

I'll get to work on this asap.

Agree with @pekkaklarck and @aaltat

When reading the history, it seems that we need to do something with these commits:
cdb336009852492a03a512964d54fbded2b621a8-Hélio Guilherme-Merge pull request #3 from zephraph/press_key_#275
46c052e1044f9aee72373a7561f69ca37f10c50c-zephraph-Fixes suggested by pekka
d1f592e5fcad64acccff7aa533aafd2ef3ed1b55-Helio Guilherme-Deprecates the use of backslash escaping for ASCII and NAMEioGuilherme66-Add named keys to Press Key.
Also commit:
353b2dfb3eadb2f43ae92b8a6fc9ec388dd64a49-zephraph-Fix documentation, small bugs
should be looked more closely, because it because it touches _element.py
@zephraph how it does look by your eyes?

You know, looking back through the documentation, this wasn't actually a documented feature.
Here's the description put in 1.7.2:

Simulates user pressing key on element identified by locator.
key is either a single character, or a numerical ASCII code of the key
lead by '\\'.

Yes, this was an undocumented feature. It was also untested which was the main reason we didn't notice it when making changes. I consider breaking the feature still a bug because the original behavior was reasonable and we cannot expect users to read docs in such detail. It would probably be a good idea to update docs and add at least one test for it.

Fixed in 1.7.4.
I'm going to work on a strategy for mitigating the risk of this happening again in the future.

Named Keys (e.g. ENTER) are not working with Press Key in recent version 1.7.4, too?

And that is correct behaviour with that release. The issue #498 contains more information about the improvements intended to support new "Press Keys" keyword.

Hope named keys will come back soon in the future. They are so much more intuitive to use and ways better to read.

what's the format when use keyword "press key" with "ctrl+t" ? I met no need locator,but locator is a mandatory parameter

what's the format when use keyword "press key" with "ctrl+t" ? I met no need locator,but locator is a mandatory parameter


validator updates original model with variable replacement

After merging master into my branch, my model comes back from validation with all of the variables in the model replaced with values from the variables file. It did not do this previously, and my belief is that it should not be updating the model that is passed from the tool. This is blocking my work on the variables injection.

discoverDomain.log


Why does test discovery search in projects that are clearly not test projects?

Description
The output window lists things like
[10/24/2018 12:43:39 AM Diagnostic] Discovering tests in C:\Users\astanton\AppData\Local\Temp\.NETFramework,Version=v4.5.2.AssemblyAttributes.cs

[10/24/2018 12:43:39 AM Diagnostic] Discovering tests in c:\tfs\Trunk\UnitTest\PrinterTests\obj\x64\Debug\TemporaryGeneratedFile_036C0B5B-1481-4323-8D20-8F5ADCB23D92.cs

[10/24/2018 12:43:39 AM Diagnostic] Discovering tests in c:\tfs\Trunk\Source\SapModuleStuff\SAPRFCTemplate.cs

The third one is a class library project, but there are web application projects, windows services, console apps, winforms, wpf, etc. It looks at all of them.
Steps to reproduce
Turn on Diagnostic level output, let test discovery run, view output window
Expected behavior
I expect it to only look in projects marked as unit test projects.
Actual behavior
It looks in every code file in every project, and then some that are totally external to the solution.
In a large solution all these extra files it looks in makes discovery take a long time and is chewing up resources that I need for other things
Environment
VS 2017 15,8 something.
Adapter is mostly the MS QualityFramework dll as MSTest2 apparently can only reliably discover all tests if we "upgrade" to package reference.

@StingyJack , AFAIK the discovery only happens for the source(test dlls) that user provides as input to vstest.console. This most likely could be VS IDE issue, can you please share a small repro project for us to investigate.
Also can you please share details about what kind of tests are not being discovered by mstestv2 for you? It would be helpful if you can share a small project for that as well.

@mayankbansal018 - #241 has several repros of the skipping of tests. The solution there wont be feasible until package ref reaches feature parity
I'm not sure if it matters whether or not its an IDE (VS 15.8.7 Enterprise) issue, its something in Test that is reporting these diagnostic messages to the output window. Live Unit Testing is turned off as well as I can turn it off (a simple on/off switch for that would have been nice instead of making us figure out how to use the current settings). I do have R# but I've always turned off the Unit Test and a few other features I dont really care for. We dont use any of the other testing frameworks.
Can you look up the message "Discovering tests in" to see where its coming from?  I cited 3 lines of examples but there are at least a few hundred of them for a solution with 150 projects.

Also this is only a question if you read the title and not the rest. Kindly remove the question tag.

@StingyJack these are logs from the VS IDE, as @mayankbansal018 said, the discovery only happens for the source (test dlls). Log this issue at https://developercommunity.visualstudio.com/ and an appropriate team will get back to you.

@karanjitsingh - This is the issue page for mstest related issues, and the issue is mstest related and issues I've logged on dev comm will sometimes end up getting transferred here.
I would say that if you think its served by a different team there (which I don't believe is true, considering the same folks tend to work tickets in both places), then you can move it there and see that it gets handled appropriately. I'm not really into doing your bureaucratic work for you. I dont appreciate the push off either.
Actually, I dont see how you even have the permission to close this as you are not listed as a member or even a contributor.
If you find this response offensive, then I have properly echoed the sentiment and message you have given to me.

@StingyJack , we will keep the issue open, however the IDE side issues are handled by different team from Redmond. We will investigate this confirm that it's not a fault from mstest adapter side, & will only close it if it's not.
@karanjitsingh , can you please see if you can create a repro for this, take help from comment to see if you can create one.

@mayankbansal018 @StingyJack, these logs do not relate to MSTestAdapter. As you mentioned logs only appear in diagnostics mode in the IDE scenario, file a bug at developer community and the folks from IDE team should pick it up.

@karanjitsingh  - Please do not try to make me a victim of what seems to be an imagined bureaucracy. Members in this very repository open test related issues with Visual Studio, with screenshots of visual studio, etc. I've opened intellitest issues in devcomm and had them worked by members and contributors (which you were not until a day or two ago) of this repository.
What is someone in a general VS IDE team going to do with MStest diagnostics that I have previously enabled at the direction of a member of this repository? I can tell you because I have significant experience in this area - they will do nothing. The issue will sit in triage forever like so many I've logged or be closed inappropriately.
I dont use any other testing frameworks or adapters, I cant even use MSTest2 yet. R# unit test support has always been disabled. I even try disabling LUT as much as is possible. What else in Visual Studio is going to report Discovering tests in... in the "Tests" output window if its not an mstest related component? Thats part of what I'm asking, because whatever that module is doing, it ain't right. But instead of even trying to answer the question, you would rather tell a lifelong customer to effectively "sod off" (not the term a New Jerseyan would actually use). And serve as an example to a coworker on how to do it.

@StingyJack I'm not sure what to reply here, as Karan has clearly mentioned, & validated that the issue is entirely at VS IDE side.
Folks do open issues of all kind, but we do not take them until they are caused in some way by mstest adapter.
As per this issue, the mstest adapter is not even remotely in picture, & neither is the vstest platform. If the whole purpose of keeping this issue opened here is so that VS IDE folks will take a look it, or we will constantly nudge them to fix this, is a wrong expectation.
The bugs filed in developer community are actively looked on, & we ourselves have fixed, & closed plenty of them based on their severity. I agree that not all bugs are fixed, some get closed because of lack of diagnostic data , others get closed if there is a feasible workaround available, & the scenario doesn't have much merit to it.
Specifically for this issue, it is related to additional diagnostics logs, which I agree on the face of it look wrong, but IDE team can take a better look, & let us know why is it coming so.
I urge you to please file a bug there, & raise the issue if they close it w/o proper explanation.

@mayankbansal018  - is a log file with the name like the one below really not in your area of responsibility?
vstest.console.1456.TpTrace.host.18-11-14_22-07-33_03798_22.log

I'm tired of filing bugs in devcomm, it has been literally unable to count or show me all of them sometime after logging the 200th one (Its > 400 now). I dont want the wrong team to look at this and this is the one and only MSFT test repository. There are other VS-centric issues with testing logged here by members of this repo, and that is evidence counter to Karan's statement. Karan was not even listed a contributor until a few days ago, but needs to understand that responses and posturing like that is always going to result in a negative experience for everyone involved. Take this feedback as evidence of that.

& the scenario doesn't have much merit to it.
Always be very careful with that judgement, MSFT does not assess impact to users correctly to begin with, and there are many people who simply have a hard time explaining or communicating in general (especially in the programming field). Neither of those change the fact that someone is blocked and needs help.

@StingyJack the log file is definitely our responsibility, but there is no mention of

vstest.console.1456.TpTrace.host.18-11-14_22-07-33_03798_22.log

in the beginning of this issue, & I'm not sure how does this just now came into picture in your last comment.
Your initial comment only talks about Test Window logs from VS IDE

[10/24/2018 12:43:39 AM Diagnostic] Discovering tests in C:\Users\astanton\AppData\Local\Temp.NETFramework,Version=v4.5.2.AssemblyAttributes.cs

[10/24/2018 12:43:39 AM Diagnostic] Discovering tests in c:\tfs\Trunk\UnitTest\PrinterTests\obj\x64\Debug\TemporaryGeneratedFile_036C0B5B-1481-4323-8D20-8F5ADCB23D92.cs

[10/24/2018 12:43:39 AM Diagnostic] Discovering tests in c:\tfs\Trunk\Source\SapModuleStuff\SAPRFCTemplate.cs

Again if your bugs at devcomm are closed w/o proper resolution or response, then it is unfortunate, but I cannot comment on that for other teams. I've no control on how they close their bugs, but we try to diagnose the issue as best as possible, & reach the best possible solution.
Karan is relatively new to our team, & it's possible that the contributors page might not have reflected him, since he might not have pushed anything yet to testfx repo, but the folks do get permissions to take action for repo as needed, be it regarding closing an issue, or any other thing.

There are other VS-centric issues with testing logged here by members of this repo, and that is evidence counter to Karan's statement

I'm acknowledging that fact, but that doesn't mean we want to keep those issues open, which we have analyzed, & found clearly that they are not related to this repo, the current issue being a clear example.

& the scenario doesn't have much merit to it.

Please do not half quote me, what I said was "others get closed if there is a feasible workaround available, & the scenario doesn't have much merit to it.". These things can happen, if we have a scenario which is outdated, or a better solution is available for them, but We will always provide a clear workaround, or alternative & support till the features/products life-cycle We do not yank out the support willy-nilly, without properly updating our customers.

but needs to understand that responses and posturing like that is always going to result in a negative experience for everyone involved. Take this feedback as evidence of that.

We do this feedback, & will keep this in mind, we could have been more elaborate while closing this issue, & give more details on why we are doing so.
Please I do not wish to engage in further discussion regarding this.
Coming back to original issue here, can you tell me if you have any concerns with logs in "vstest.console.1456.TpTrace.host.18-11-14_22-07-33_03798_22.log", & these are what we do control,
if yes, do file a fresh bug either here, or in vstest repo, but please do not ask my team to fix IDE diagnostics logs.

Your initial comment only talks about Test Window logs from VS IDE

My initial comment is about what the messages in the output window for Tests are reporting. See below for a customer information sanitized version of the depicted window.

can you tell me if you have any concerns with logs .... please do not ask my team to fix IDE diagnostics logs.

I dont have concerns with the logs, and I didnt ask anyone to fix logs. Please do not fixate on the logs being the core of the issue. I had a question about whatever the testing framework is doing that its reporting in the logs.
Here is an excerpt from a few minutes ago for a small solution. Note the discovery happening in the \Source and \Tools folders where there are no unit test projects.
[11/16/2018 12:13:04 AM Informational] Logging TestHost Diagnostics in file: C:\Users\astanton\AppData\Local\Temp\vstest.console.28896.TpTrace.host.18-11-16_00-13-03_38201_7.log
[11/16/2018 12:13:04 AM Diagnostic] Discovering tests in c:\projectdev\Customer1\TrunkShared\Tools\TestHarness\Program.cs
[11/16/2018 12:13:06 AM Diagnostic] Discovering tests in c:\projectdev\Customer1\TrunkShared\UnitTest\DecoderTests\DecoderTests.cs
[11/16/2018 12:13:06 AM Diagnostic] Discovering tests in c:\projectdev\Customer1\TrunkShared\Source\CustomDecoder\Decoder.cs
[11/16/2018 12:13:07 AM Warning] No test is available in c:\projectdev\Customer1\TrunkShared\Source\CustomDecoder\Decoder.csproj c:\projectdev\Customer1\TrunkShared\Source\SerializationProvider\SerializationProvider.csproj c:\projectdev\Customer1\TrunkShared\Tools\TestHarness\TestHarness.csproj c:\projectdev\Customer1\TrunkShared\UnitTest\DecoderTests\DecoderTests.csproj. Make sure that test discoverer & executors are registered and platform & framework version settings are appropriate and try again.
[11/16/2018 12:13:07 AM Informational] ========== Discover test finished: 0 found (0:00:04.2609949) ==========

Please do not half quote me

I dont mean to. The & in the middle of the sentence breaks the idea up when I read it.

pinging @mayankbansal018  as I forgot to do so in the above response

Tagging folks from the IDE team @ManishJayaswal @AbhitejJohn
I guess this is a known issue, is there an existing workitem to track this one?

@StingyJack : The "Discovering Tests in *.cs" entries are tied to a source based analyzer that quickly determines tests in a solution. This analyzer only analyzes tests in projects that have a known framework referenced (which today is MSTest, Xunit or Nunit). Although the logs would show up for all documents in the solution so we can troubleshoot, its optimized to only be parsing files from a project that refers a known test framework. Hopefully that explains things. Apologies the diagnostic logs caused a confusion - I'll file an internal bug to refines these.

@AbhitejJohn - Thank you. That does explain most of it. A few follow up questions if you dont mind.
Why is it looking in files that aren't part of any project? Is that just a project system quirk?
I dont have any references to X/Nunit or even MSTest2 in most projects, just the old QualityFramework dll. Why would it be scanning projects that dont have those references or that dont have a unit test project type guid?

@StingyJack : Currently we scan all .cs files in the solution and optimize further processing based on references and whether its part of a project etc. We also parse MSTest V1 tests, so yes projects that reference QualityTools should start showing tests as you type. The only reason we have these in diagnostic logs is so we could troubleshoot issues where for some reason we haven't looked at an actual test file. These should be more descriptive once we get to fix the internal bug I've mentioned earlier.

@AbhitejJohn  - Got it. Thanks for the explanation. This item may remain closed.


uglybob1

VSCode Version:
OS Version:

Steps to Reproduce:

Does this issue occur when all extensions are disabled?: Yes/No

Seems I am working on it and will get back to you on that soon tks.
On Wed, Mar 6, 2019, 7:41 PM Harry Johnson<EMAIL_ADDRESS>wrote:

VSCode Version:
OS Version:

Steps to Reproduce:

Does this issue occur when all extensions are disabled?: Yes/No
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/69923, or mute the thread
https://github.com/notifications/unsubscribe-auth/AMHOI3Ao_5KqmCnEBMuQ1AMEwddLDRGoks5vUG5kgaJpZM4biLQi
.


Clarify effects of little-endian versus big-endian configuration

The effects of choosing little-endian versus big-endian in register fctrl need some clarification.
When an IOMMU is configured for big-endian memory accesses, what are the sizes for which bytes are reversed in memory in each instance?  For MSI PTEs, it is explicitly stated that each doubleword is reversed, but for other data structures nothing is specified.  For example, given that an extended-format device context is shown as a single entity of 512 bits, should we assume that changing the endianness mode reverses all 64 bytes in memory, as though the structure were one 512-bit integer?  When configured for little-endian, I presume the tc doubleword of this structure is meant as the first 8 bytes, but when configured for big-endian, should we assume the first 8 bytes (at the lowest addresses) are the reserved bytes, and tc is the last 8 bytes (at the highest addresses)?
I recommend instead, for non-array data structures larger than 8 bytes, that the configured endianness determines the byte order within each 64-bit doubleword in memory but that the order of doublewords within each structure is invariant of endianness.  (Except that MRIF doublewords are always little-endian, as the document already says.)  This would be most consistent with what the proposed Advanced Interrupt Architecture both requires and recommends (some of each).
Furthermore, it appears that an IOMMU's endianness configuration is intended to have no effect on accesses to the memory-mapped registers.  In fact, the byte order for these registers is never stated, although we can guess they're "normally" supposed to be little-endian.  Is it correct that an IOMMU's memory-mapped registers are always little-endian---even in the case that an IOMMU's endianness configuration is big-endian-only (field capabilities.END = 0 and fctrl.END = 1, meaning big-endian)?

Agree that the configured endianness should determine byte order within each 64-bit doubleword in memory and the order of doublewords in each structure is invariant of endianness. Yes, its correct that IOMMUs memory-mapped registers are always little-endian - even with the IOMMUs configuration is big-endian. As noted END bit description clarifies it applies to memory resident data structures but is silent on the memory-mapped registers.
Both items needs an update to clarify.

Addressed by PR#12 - https://github.com/riscv-non-isa/riscv-iommu/pull/12