get_coord_seq without extra clone

From the docstring of get_coord_seq:

Note: this clones the underlying CoordSeq to avoid double free (because CoordSeq handles the object ptr and the CoordSeq is still owned by the geos geometry) if this method’s performance becomes a bottleneck, feel free to open an issue, we could skip this clone with cleaner code.

My use case is to bind GEOS algorithms to the GeoArrow memory layout (an efficient geometry layout for arrays of geometries, see geoarrow.org and my WIP rust implementation at https://github.com/geoarrow/geoarrow-rs). My current plan is to always store geometries before and after each operation in GeoArrow memory, and therefore GEOS objects are totally ephemeral during an operation. So the process goes like

Take an array of e.g. polygons
Iterate over the array, converting each into GEOS objects
Apply a GEOS operation, say, buffering
Construct a new GeoArrow array from the polygon outputs

Therefore the IO to and from GEOS objects is really important to me, because it's overhead for every operation on the array.
One option is to improve this get_coord_seq, removing a clone. The other possibility for me is to have something like into_coord_seq or into_inner. Given that I want to consume the GEOS geometry anyways, and only access its coords, this might be easier to implement?
I'd be willing to attempt a PR!

Both approaches sound good to me but if the into_coord_seq approach is simpler, please go ahead with this one.
Might still be worth to improve get_coord_seq in the future though.

Actually thinking about this a little more.. might one way to solve this be to implement a ConstCoordSeq struct just like there's a ConstGeometry?

That could work too.


[Question] How do you generate from a model after 'chained' LoRa trainning?

I have qLora finetuned a mistral model via:
python lora/convert.py --hf-path mistralai/Mistral-7B-Instruct-v0.1 -q --mlx-path /path/to/raw_model/mlx
python lora.py --model /path/to/raw_model/mlx --train --data /path/to/data \
                          --adapter-file /path/to/adapter_file1.npz
python lora.py --model /path/to/raw_model/mlx --train --data /path/to/data \
                         --resume-adapter-file /path/to/adapter_file1.npz \
                        --adapter-file /path/to/adapter_file2.npz

I.e., the LoRa weights from the first training were stored in /path/to/adapter_file1.npz and the weights from the second training (which resumed from the state of this first set of weights) were stored in /path/to/adapter_file2.npz
Will that second adapter file (adapter_file2.npz) be the cumulative adjustment for both training such that the first one can be deleted? if so, is all I need to generate from the state of this cumulative training the following?:
python lora.py --prompt "Some prompt" --model /path/to/raw_model/mlx  --adapter-file /path/to/adapter_file2.npz
Or will I somehow need to specify both?

if so, is all I need to generate from the state of this cumulative training the following?:

Yes that's correct! You only need to specify the second adapter file, not both. Specifying both would be wrong actually. When you load from the first and resuming training the adapters are updated from where you left off and then resaved.


Suggestion: Listen on localhost by default

As I'm sure you're aware, the majority of memcached installations do not need to be exposed to the internet. And yet, there are tens of thousands of instances publicly accessible right now.
I would hazard a guess that a terrifyingly large percentage of those instances are also missing security patches.
Changing the default configuration to listen on localhost/<IP_ADDRESS>/::1 rather than INADDR_ANY will not magically make all these vulnerable servers go away, but I think it will significantly reduce the number of exposed instances in the future.
As a "case study", the Ubuntu Server repos already package memcached so that it listens on <IP_ADDRESS> by default. The Ubuntu builds also return e.g. STAT version 1.4.25 Ubuntu, so we can trivially scan the internet for these instances. According to my shodan search results, not even a single Ubuntu system is exposing memcached to the internet - ostensibly due to the safe(r) default configuration.
If there's a worry about people's installations breaking on upgrade, this seems like a good candidate for the -o modern option.
I'd be happy to make a relevant PR if this change would be welcome.

I'd probably have to give the project up to someone else to accomplish that. It'll cause years of breakage since people upgrade so slowly, and I don't have the time or the funding to cope with this. :(
Earlier this year I worked with vendors and just about everyone changed their default configurations; which was great since that only affects new installations or folks not customizing setups. If you change the default upstream it'll be rolling out behind the vendor changes anyway. So any extra benefit should be minimal.
However, you may have missed that we were able to disable UDP by default: https://github.com/memcached/memcached/commit/dbb7a8af90054bf4ef51f5814ef7ceb17d83d974 - since usage is so low, and that was the primary concern this year. I may also be able to lock the administrative commands to localhost by default without breaking much.
Thanks for your concern. Wish it weren't such a big deal, but we've done some seemingly minor changes to the defaults in the past and pretty much drove a huge section of the userbase away.

It'll cause years of breakage since people upgrade so slowly

That may be true, but I'm hoping that the benefits outweigh the downsides here. Obviously I'm biased because I don't have to maintain/support anything, but this is my reasoning:
For simplicity, let's say there are 3 categories of memcached users:

Users who obtain their memcached builds/updates from a vendor, which defaults to listening on localhost (Great - they receive timely security updates, and they wouldn't be remotely exploitable by default anyway)

Users who obtain their memcached builds/updates from a vendor, which defaults to listening on INADDR_ANY. (OK - Will be vulnerable to RCE exploits if/when they appear, but will receive timely updates)

Users who downloaded a memcached binary/package from a random blog post etc., because their OS does not have a more "official" distribution channel. They do not receive security updates, and will inevitably sit waiting for someone to pwn them.

I'm assuming/hoping that category 1 is the large majority of memcached users, followed by 2 then 3. Category 1 will not be affected by my proposed changes, because it will already be their default configuration.
Category 2 will be affected - their vendors will have to adjust their packaged config, or users will have to adjust their local config, (but only if they really did depend on the default behaviour of listening on INADDR_ANY)
Although category 3 accounts for the smallest proportion of memcached users (hopefully), I believe it accounts for the majority of vulnerable instances on the public internet, right now.
In summary, I believe my proposed changes will have a negligible impact on the overall memcached userbase, but a very large positive impact on the security of "category 3" users, moving forwards.
RE: The UDP changes, I did see the commit, and that was why I was hoping these changes would be considered too. I'm not that concerned with the UDP reflection vulnerabilities anyway - my primary concern right now is that there are thousands of instances still vulnerable to older RCE exploits. My proposed changes won't fix this right away, but I hope it can reduce the next wave of mass exploitation in say, 10 years time.

It's a perfectly reasonable thing to do, that alienates users and causes a support nightmare. It doesn't actually solve the problem entirely either, as it's a network daemon and plenty of people will enable the networking and never secure it (how many mysql instances are open on the internet?). I have no idea how many of those people exist vs localhost installations.
While you're targeting (3), a small portion of users, every "real" user with networked pools of memcached's on secured networks will likely have to make an adjustment. If they get their updates solely through distro upgrades (as many do) that will be a surprise for them.
Nobody else works on this thing and I've no funding. If you (or anyone) were showing up as a dedicated volunteer to work on the project for a year that'd make it more likely to consider, but that's a pipe dream :)

what I really want to do is introduce even basic auth tokens to the client standard and eventually flip that as a default. This is one of the many nice things I'll likely never have.


WindowsStartScriptGenerator uses the wrong classpath

Sorry for deleting the issue template, but this is not so much a bug report as a code issue I noticed when trying to use a custom Windows start script template. WindowsStartScriptGenerator accesses a resource using UnixStartScriptGenerator.class instead of WindowsStartScriptGenerator.class here:
https://github.com/gradle/gradle/blob/e975872ae2cf1d521b73f1107cae772ca09c63cd/subprojects/plugins/src/main/java/org/gradle/api/internal/plugins/WindowsStartScriptGenerator.java#L26
If the Gradle team agrees this is an issue, I'd be happy to PR the fix.

The class is used for loading locating the text file. It's strange to use the UnixStartScriptGenerator but doesn't have any effect.


[SPARK-26851][SQL] Fix double-checked locking in CachedRDDBuilder

What changes were proposed in this pull request?
According to Brian Goetz et al in Java Concurrency in Practice, the double checked locking pattern has worked since Java 5, but only if the resource is declared volatile:

Subsequent changes in the JMM (Java 5.0 and later) have enabled DCL to work if resource is made volatile, and the performance impact of this is small since volatile reads are usually only slightly more expensive than nonvolatile reads.

CachedRDDBuilder. cachedColumnBuffers and CachedRDDBuilder.clearCache both use DCL to manage the resource _cachedColumnBuffers. The missing ingredient is that _cachedColumnBuffers is not volatile.
Therefore, this PR makes _cachedColumnBuffers volatile.
How was this patch tested?

Existing SQL unit tests
Existing pyspark-sql tests

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Test build #102261 has started for PR 23768 at commit 9e7974f.

Test build #102261 has finished for PR 23768 at commit 9e7974f.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/102261/
Test PASSed.

Ah, good catch! The reference for that is http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html, too.
LGTM
cc: @cloud-fan @srowen

LGTM! merging to master!


stevenblack-blocklist: 3.14.96 -> 3.14.100

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for stevenblack-blocklist is: Unified hosts file with base extensions
meta.homepage for stevenblack-blocklist is: https://github.com/StevenBlack/hosts
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.14.99 in filename of file in /nix/store/iq6mb0npxrldprd05s78mhdnslzpssrb-stevenblack-blocklist-3.14.99

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

stevenblack-blocklist

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/iq6mb0npxrldprd05s78mhdnslzpssrb-stevenblack-blocklist-3.14.99 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A stevenblack-blocklist https://github.com/r-ryantm/nixpkgs/archive/d6e4ebad8c1ccac7164da2ae1e0da9824cc0d375.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/d6e4ebad8c1ccac7164da2ae1e0da9824cc0d375#stevenblack-blocklist

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/iq6mb0npxrldprd05s78mhdnslzpssrb-stevenblack-blocklist-3.14.99
ls -la /nix/store/iq6mb0npxrldprd05s78mhdnslzpssrb-stevenblack-blocklist-3.14.99/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

6 packages built:

stevenblack-blocklist
stevenblack-blocklist.ads
stevenblack-blocklist.fakenews
stevenblack-blocklist.gambling
stevenblack-blocklist.porn
stevenblack-blocklist.social

Maintainer pings
cc @moni-dz @Guanran928 @Frontear for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for stevenblack-blocklist is: Unified hosts file with base extensions
meta.homepage for stevenblack-blocklist is: https://github.com/StevenBlack/hosts
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.14.100 in filename of file in /nix/store/zgl8prwc3gcc908wjhv6s3kx5l3bfrcx-stevenblack-blocklist-3.14.100

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

stevenblack-blocklist

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/zgl8prwc3gcc908wjhv6s3kx5l3bfrcx-stevenblack-blocklist-3.14.100 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A stevenblack-blocklist https://github.com/r-ryantm/nixpkgs/archive/3e674f42647ca8f7b62b9891aaa884ac89a9ff89.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/3e674f42647ca8f7b62b9891aaa884ac89a9ff89#stevenblack-blocklist

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/zgl8prwc3gcc908wjhv6s3kx5l3bfrcx-stevenblack-blocklist-3.14.100
ls -la /nix/store/zgl8prwc3gcc908wjhv6s3kx5l3bfrcx-stevenblack-blocklist-3.14.100/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

6 packages built:

stevenblack-blocklist
stevenblack-blocklist.ads
stevenblack-blocklist.fakenews
stevenblack-blocklist.gambling
stevenblack-blocklist.porn
stevenblack-blocklist.social

Maintainer pings
cc @moni-dz @Guanran928 @Frontear for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

@NixOS/nixpkgs-merge-bot merge


GEODE-9489: Assert exception type, not message

PROBLEM
GeodeRedisServerStartupDUnitTest.startupFailsGivenPortAlreadyInUse()
asserted that the root cause message of the expected exception was
exactly "Address already in use". The JDK makes no guarantee about the
exception message of a BindException, so this assertion is overly
strict.
SOLUTION
Change the test to assert that the thrown exception is a
BindException.

The stress test failures are due to another test method in this class. That test method is being addressed in a separate PR: https://github.com/apache/geode/pull/6748

The distributed test failure is from a test known to fail intermittently: https://issues.apache.org/jira/browse/GEODE-7183

Closing as duplicate of: https://github.com/apache/geode/pull/6744


why the background is so black?

I do see this happening on my device as well! I suspect it may be something with the compositing settings? I'm looking into this now, thanks for bringing it up!


Conflicting docker configurations resulted in a container in excess

I started a composer suite while a second one with the same configuration was still running. This resulted not only in an error message about an allocated DB port, as expected, but in a container in excess.
The container in excess was bafba6dc12f4_elmarhinz_mysql_1.
It showed up by calling: docker-compose ps.
I solved this by removing that container: docker rm  bafba6dc12f4_elmarhinz_mysql_1.

Seems to be a migration from an older docker-compose version. I'm not sure if we can do anything here.

Just wanted to file the event. I think there is nothing to do, but in case that's how to handle it.


Set authorizer lambda runtime to node18.x

Fixes: https://github.com/aws-controllers-k8s/community/issues/1825
Set authorizer lambda runtime to node18.x
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Fixes https://github.com/aws-controllers-k8s/community/issues/1825

/lgtm


MAUI password field is not available

Different input types for MAUI dialog is in backlog:
https://github.com/dotnet/maui/issues/9913
If this is not implemented soon we can provide this via a dialog service for each platform.

moved to: https://github.com/mku11/Salmon-Vault/issues/3


Simple db tests

Branched off https://github.com/rusoto/rusoto/pull/977 . Starting point for https://github.com/rusoto/rusoto/issues/978 . 😄
Designed so someone can pick up this work if I don't get around to wrapping it up. If you'd like it, write a comment saying you'll do it. 👍

Since we need to implement AWS v2 signing for SDB to work, there is more to this than just adding tests. A good course of action is to merge this as is, so the integration tests are ready for when SDB is implemented and we don't lose them by having a branch drift out of date.
Any thoughts?


Service test changes

r? @canndrew
(maidsafe_highfive has picked a reviewer for you, use r? to override)

We really shouldn't need an entire second per message on that test. Or even an entire 100ms for that matter.


bad user input at global offers

while I visit non-logged, got error from graphql endpoint
https://beta.kodadot.xyz/snek/offers/
"message": "Variable \"$id\" of required type \"String!\" was not provided.",
            "extensions": {
                "code": "BAD_USER_INPUT",
                "exception": {
                    "stacktrace": [
                        "GraphQLError: Variable \"$id\" of required type \"String!\" was not provided.",
                        "    at _loop (/squid/node_modules/graphql/execution/values.js:94:17)",
                        "    at coerceVariableValues (/squid/node_modules/graphql/execution/values.js:121:16)",
                        "    at getVariableValues (/squid/node_modules/graphql/execution/values.js:50:19)",
                        "    at buildExecutionContext (/squid/node_modules/graphql/execution/execute.js:203:61)",
                        "    at executeImpl (/squid/node_modules/graphql/execution/execute.js:101:20)",
                        "    at execute (/squid/node_modules/graphql/execution/execute.js:60:35)",
                        "    at execute (/squid/node_modules/apollo-server-core/dist/requestPipeline.js:205:48)",
                        "    at processGraphQLRequest (/squid/node_modules/apollo-server-core/dist/requestPipeline.js:148:34)",
                        "    at runMicrotasks (<anonymous>)",
                        "    at processTicksAndRejections (node:internal/process/task_queues:96:5)"
                    ]
                }
            }

👋


Input & Validation Events Race Condition

Describe the bug
My team is currently working on creating a form with a number of different fields and validation types. We want all fields who fail our validation (and requirement standards) to perform logic that disables the 'purchase' button as well as other visual notifiers that the data is incorrect.
We are currently working in a React Application, so the encouraged way to get both the input and isValid data is via events; in this case the input event and the auroInput-validated event. These two events fire simultaneously when input is added to the auro-input component.
Our issue is that given the way these events were given to us, they currently encourage the development of a race condition that is pretty difficult to resolve.
We store our fields in a single object with two attributes (example below);
// example object
const fieldData = {
  value: 'test',
  isValid: true
}

When the input event listener is triggered, it updates the value property of that object.
When the auroInput-validated event listener is triggered, it updates the isValid property of that object.
Because both events fire simultaneously, they overwrite each other, leaving one of the two values missing (whichever event fired second). In general, there really isn't a way for us to get around this without storing data in two separate locations, however that's really bad practice as those two attributes should be connected because they are functionally connected.
We've been able to get around this for now because the input field just returns the entire Input Event that is triggered from this event. This Input Event contains the element itself that was being triggered, meaning we're able to actually grab the isValid property that is currently set on that element.
// added event listener for auro-input 'input' event

// example of how we get around it (event => `Input Event` object received from 'input' event)
const fieldData = {
  value: event.target.data,
  isValid: event.target.isValid
}

All in all, I'd suggest that the "auroInput-Validated" event is removed and combined with the "input" event as to avoid the race condition. That way we can keep with best data storage practices and avoid two events triggering at the same time.
To Reproduce
Steps to reproduce the behavior:

Add 'auro-input' component to your project.
Add 'input' event listener to that component, and console.log result.
Add 'auroInput-validated' event listener to that component, and console.log result.
Run project.
Enter Input into rendered field.
See two events fire at the same time; notice how storing both data points (input string, and isValid boolean) would be difficult to store in the same location.

Expected behavior
In general, I expect auro-input to be able to provide me with an easy way to grab the newly input data into the field as well as alerting me to whether or not it passes or fails my validity check; essentially returning two data points (value, isValid) on input trigger.
While technically I'm able to do this today, the documentation suggests that I should be doing this with two different events that fire simultaneously.
I'd appreciate either:

Auro's event docs to say say you can get both the input & isValid data points from one event
Combining both "input" and "auroInput-validated" into one function and explaining you can get both there

Either way, the way the api docs are now almost encourages a race condition.
Screenshots
Result from "input" event:

Find important data at:

value: event.target.value
isValid: event.target.isValid

Note: The 'Type Returned' portion of this event's API doc is wrong. The docs don't outline what is returned but it is an entire Input Event object. I'm attempting to update that object in the API docs currently.

Result from "auroInput-validated" event:

Find important data at:

isValid: event.details.isValid

Note: The 'Type Returned' portion of this event's API doc is wrong. It is not CustomEvent<{isValid: boolean>, it is an entire Custom Event object. I'm attempting to update that object in the API docs currently.

Desktop (please complete the following information):

OS: MacOS Monterey 12.3 (21E230)
Browser: Chrome
Version: Version 101.0.4951.64 (Official Build) (arm64)

Additional context
I'm currently in the process of updating the documentation to reflect what is currently live.
Also note, because we're able to get around the bug by utilizing the input event's response we will have to update our application should changes be made to that event's response.
We realize our solution felt a little "tech debt-y" and only felt comfortable releasing to prod if we actually created an issue for the debt we were seeing. This is why we made the Github issue even if we've gotten around the problem.

Created the PR above to address the API doc inconsistencies with what's currently deployed. This pull request DOES NOT address the issue brought up in this issue.

The API document you updated is not a static document. With each build this is auto-generated from the code. For example, please see https://github.com/AlaskaAirlines/auro-input/blob/main/src/base-input.js#L465-L472 as the lines that generate the update you edited for auroInput-validated.
Please see this README for how to use JSDoc with web components.

The API document you updated is not a static document. With each build this is auto-generated from the code. For example, please see https://github.com/AlaskaAirlines/auro-input/blob/main/src/base-input.js#L465-L472 as the lines that generate the update you edited for auroInput-validated.
Please see this README for how to use JSDoc with web components.

I might need some assistance figuring out how to update the docs then. If its programmatically created, I don't know how to get what makes sense in there. The way the docs show Event Type make me thing calling "auroInput-validated" would get response like this Custom Event { isValid: true }, but that's not what we see. How can I make a more detailed response to illustrate you get a full element with the isValid attribute in the event.details section?
The same goes for the input event. How do I outline that a full Input Event is added, as well as the updated description?
Apologies in advance, this is my first auro-input PR.

If updating this doc requires making implementation changes to the codebase, I'm inclined to delete the PR because I'm not familiar enough with its internal mechanics to enable it to generate the documentation that would be easier for users to understand.
Would love your advice on next steps, @blackfalcon. Thanks!

We're using <auro-input> in production with React currently, and we are able to capture changes to both event.target.value and event.target.isValid properties in a single event, passed via a function we set on the onInput, onBlur, and onFocus event attributes. You shouldn't need an additional event listener for auroInput-validated.
Here is an example on CodeSandbox: https://codesandbox.io/s/auro-input-in-react-example-2trqfu
I think this is how you already handled it in your "workaround" example, and I think this is the intended way to capture both properties. auroInput-validated should only be used if you are solely concerned with isValid.

Sorry, I just noticed you are using event.target.data instead of event.target.value; that could also be causing an issue here?

@MattSidor In regards to your latest comment, I think that was just a mistype on my end.
But the previous comment makes sense! Is there a way to update the docs to where that is called out? I keep running into this issue where I look to the docs for ways to get the data I need and am a tad dumbfounded when reading; when I finally get something to work it feels 'hacky' because I'm usually not using the event (or other feature) the way the documentation alongside that event says it should be used.
Is there a way to better update that documentation so that others don't have to go through everything I went through to get that isValid data point? I'm at a loss for how to do that considering the api readme is auto-generated.
I'm really just trying to prevent others from going through everything we went through when trying to add validation. It took us nearly a day and a half to figure out we could get that isValid data from the "input" event because we were trying to use the docs "validated" event and having an issue updating that single object.

Awesome thank you so much for your response.
I'd love to see a short code snippit demo this functionality just so that getting the isValid field is shown. I'm familiar with events on getting event.target.value, I just didn't expect the isValid attribute to be accessible there since I didn't see that it should be (or could be) accessible there via the docs. I'll make that update in my PR and hopefully make the docs more clear.
Thanks for your offer to connect with me also! I'll definitely be taking you up on that next time we come into an issue. If there's anything I can do to better communicate the issues we're experiencing, please don't hesitate to give me feedback! I'm trying to be as researched and communicative as possible when making Github issues, so if I'm forgetting to do something (or you have a new pattern you want me to follow) please let me know.
Thanks again! Be on the lookout for an updated PR.

I was wondering though, @blackfalcon, why is there an "auroInput-validate" event if the "input" event gives both string and "isValid"?

I was wondering though, @blackfalcon, why is there an "auroInput-validate" event if the "input" event gives both string and "isValid"?

auroInput-validate is used for cross component communication of error states in more complex multi-tiered Auro components such as auro-combobox where the validation state needed to be kept in sync between the various peer dependencies (e.g. dropdown and input). In this specific case, it was better to rely directly on a validation state change event than to watch for an input value change and look for the resulting validating check that came with it.

@jason-capsule42 That makes a lot of sense, thank you for responding! I might add something like that to the event description, just to make it more clear in my PR. Really appreciate the camaraderie while we're trying to figure this out. Cheers!


Unable to use DNS and resolver_name in DogStatsdSink

If you are reporting any crash or any potential security issue, do not
open an issue in this repo. Please report the issue via emailing
<EMAIL_ADDRESS>where the issue will be triaged appropriately.
Title: Unable to set DNS address while configuring DogStatsdSink
Description:
I am trying to configure a DogStatsdSink as metrics sink to send metrics to Telegraf which is running in the same namespace as envoy.
As per the docs, the address has to be an IP address. If it has to be a DNS, then a resolver must be set. I am not able to understand what to set here. The documentation is unclear and could not find an example anywhere.
Envoy errors with DNS address without setting the resolver name.
│ 2024-12-05T13:49:43.374404Z    critical    envoy main external/envoy/source/server/server.cc:133    error initializing config '  etc/istio/proxy/envoy-rev.json': malformed IP address: telegraf-service.services-gateway-apigw-usw2-prf-jain.svc.cluster.local.    thread=28

Envoy Config
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: stats-filter
spec:
  workloadSelector:
    labels:
      app: istio-gateway
  configPatches:
    - applyTo: BOOTSTRAP
      match:
        context: GATEWAY
      patch:
        operation: MERGE
        value:
          stats_flush_interval: 30s
          stats_sinks:
          - name: envoy.stat_sinks.dog_statsd
            typed_config:
              "@type": type.googleapis.com/envoy.config.metrics.v3.DogStatsdSink
              address:
                socket_address:
                  protocol: UDP
                  address: telegraf-service.default.svc.cluster.local
                  port_value: 6999
                  resolver_name: ???

Telegraf Config
[agent]
  debug = true
  quiet = false
[[outputs.file]]
  files = ["stdout"]
  data_format = "json"
[[inputs.statsd]]
  protocol = "udp"
  service_address = ":8125"
  datadog_extensions = true
  datadog_distributions = true
  datadog_keep_container_tag = true

[optional Relevant Links:]
https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/metrics/v3/stats.proto#extension-envoy-stat-sinks-dog-statsd
https://github.com/influxdata/telegraf/blob/master/plugins/inputs/statsd/README.md

cc @taiki45 @jmarantz

Thank you for bringing this up. I’ll try to provide some clarification, though my response may not fully reflect the latest updates in the project.
The statsd_sink and dog_statsd_sink extensions do not support DNS resolution over UDP. For UDP-based configurations, the address field must specify a logical or physical IP address. More details can be found in here: https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/core/v3/address.proto#config-core-v3-address
If DNS resolution is required, you can use statsd_sink with the tcp_cluster_name field, which allows for DNS-based resolution for TCP connections. Unfortunately, dog_statsd_sink does not support tcp_cluster_name, so enabling DNS resolution for dog_statsd_sink would require additional implementation.
For context, the current implementation assumes a common use case where metrics are sent to a local statsd daemon. In such scenarios, specifying a physical IP address for UDP communication is sufficient and aligns with the intended design. If this approach fits your architecture, it might be a simpler alternative to consider.

The problem with stasd sink is, it does not support tags and Telegraf errors when parsing Istio metrics from statsd sink because of additional colons in the source_principal and destination_principal. Also, stats config does not work with statsd so I cannot even drop this tags to solve this.
telegraf-576cc6bddb-wnfnj telegraf 2024-12-09T15:47:55Z E! [inputs.statsd] Splitting '|', unable to parse metric

Dogstatsd sink works perfectly with Telegraf but it does not support TCP or DNS.

When configuring DogStatsdSink, Envoy requires that UDP addresses be specified either as numeric IPs or accompanied by a DNS resolver configuration. By default, Envoy will not do DNS resolution for UDP endpoints just by providing a DNS name. If you specify a DNS hostname, you must also define and reference a DNS resolver extension in the bootstrap configuration, then reference it by resolver_name in the socket address.
Why Is This Necessary?
The resolver_name field in Envoy’s address configuration points to a named DNS resolver extension. Without a configured resolver, Envoy treats UDP addresses as literal IPs. If you provide a DNS name without a resolver, Envoy can’t resolve it and will produce an error like malformed IP address: .
What resolver_name Should Contain
resolver_name must match the name of a DNS resolver extension that you have configured in the Envoy bootstrap. Envoy comes with built-in DNS resolvers such as envoy.network.dns_resolver.cares or envoy.network.dns_resolver.apple (on macOS). You must explicitly configure one of these in your bootstrap (not via an EnvoyFilter) so that Envoy knows how to resolve the provided hostname.
Example Bootstrap Configuration
Suppose you want to use the c-ares DNS resolver. In your Envoy bootstrap configuration (the main config file loaded on startup), you might specify something like:
Partial example of bootstrap config
static_resources:
Your existing clusters, listeners, etc.
Configure the DNS resolver extension.
typed_dns_resolver_config:
name: envoy.network.dns_resolver.cares
typed_config:
"@type": type.googleapis.com/envoy.extensions.network.dns_resolver.cares.v3.CaresDnsResolverConfig
resolvers:
# Typically the cluster DNS IP (e.g., from within K8s this might be the cluster DNS IP)
- <IP_ADDRESS>
# Optional: other c-ares configurations
This configuration tells Envoy to use the c-ares DNS resolver with the given resolvers. The name field here matches what you’ll use in the resolver_name in your EnvoyFilter.
Using the Resolver in the EnvoyFilter
Once the bootstrap has the DNS resolver defined, you can reference it in your EnvoyFilter:
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: stats-filter
spec:
workloadSelector:
labels:
app: istio-gateway
configPatches:
- applyTo: BOOTSTRAP
match:
context: GATEWAY
patch:
operation: MERGE
value:
stats_flush_interval: 30s
stats_sinks:
- name: envoy.stat_sinks.dog_statsd
typed_config:
"@type": type.googleapis.com/envoy.config.metrics.v3.DogStatsdSink
address:
socket_address:
protocol: UDP
address: telegraf-service.default.svc.cluster.local
port_value: 6999
resolver_name: envoy.network.dns_resolver.cares
Important Notes:
1.	Bootstrap Is Required:
You cannot add DNS resolver configurations solely via EnvoyFilter. DNS resolvers must be set in the main Envoy bootstrap configuration which Istio’s sidecar is using. Adjusting that may require a custom sidecar proxy configuration or a custom bootstrap template.
2.	Cannot Use Clusters for DogStatsdSink:
The DogStatsdSink does not support referencing a cluster name like some other sinks do. If it did, you could rely on Envoy’s cluster-level DNS resolution. Since it doesn’t, you must define a resolver as shown.
3.	No TCP or Cluster Option for DogStatsd:
DogStatsd is inherently UDP-based. If you require DNS or dynamic resolution, the resolver approach is the only way. Using a static IP address is simpler if you can ensure a stable IP for your Telegraf instance.


Feature shibv421

Upgrade to v4.2.1
Resolves #53

Now resolves #58

Some minor changes to align config with what is provided in Shibboleth v4.2.1. The inclusion of the SCHAC schema into attribute is the most significant change.

Awesome work @trsau! I'll make changes accordingly in rapid-idp-ansible and also rapid-idp-manager.


Completion script initialisation problems

Using sdkman SDKMAN 5.11.2+698 on Ubuntu Linux 20.04 and bash 5.0.17(1) with the necessary code in .bashrc to put it in the path.
When I start a new terminal, i.e. invoke a new bash, output like the following sometimes appears on the console:
ommand not found
36m====: command not found

Command '0music' not found, did you mean:

  command 'music' from deb music-bin (1.1.16-1.1build2)

Try: sudo apt install <deb name>

Command '0music' not found, did you mean:

  command 'music' from deb music-bin (1.1.16-1.1build2)

Try: sudo apt install <deb name>

Command '0music' not found, did you mean:

  command 'music' from deb music-bin (1.1.16-1.1build2)

Try: sudo apt install <deb name>

================================================================================: command not found

I did not manage to find out why/when this happens, it appears to be almost random, though it usually happens when opening the first terminal after a restart or after a longer time.
I have observed this behaviour for several weeks now and I am certain this only happens when the SDKMAN-related code is active in .bashrc, never happens when I comment that out.
The "command not found"  complaints I get appear to come from strings inside the bash prompt definition and from the names of random directories in my home directory. I have no idea at all what could be going on here, but it became so annoying that I usually deactivate sdkman completely.
So sadly, I cannot provide steps to reproduce because this problem occurs seemingly randomly (but often enough to be very annoying).

Hi @johann-petrak,
Looking at this, I think you have something else going on with your system. We don't have any references to 0music in our code, nor do we access anything in your home folder outside of .sdkman. My guess would be that something else is up here.
If the problem persists, please feel free to chat with us on the SDKMAN slack as described in the contributor guidelines.

As I said, it provably only ever happens whe sdkman is in the .bashrc - i deliberately observed both settings for several weeks.

After chatting on Slack, we discovered an interaction with the update command and the bash completion script. Opening this issue for further investigation.

As it turns out, this probably comes from the second line of code that gets included in the .bashrc by the sdkman installation:
source <(sdk completion bash)

This command is supposed to emit bash code that gets sourced on stdout but sometimes, the command sdk completion bash appears to emit other things on stdout.
When enabling debug mode in .sdkman/etc/config the following message is emitted before the actual bash code:
No update at this time. Using existing cache: ant,asciidoctorj,ballerina,bpipe,btrace,ceylon,concurnas,cuba,cxf,doctoolchain,flink,gaiden,gradle,gradleprofiler,grails,groovy,groovyserv,http4k,infrastructor,java,jbake,jbang,jmc,jreleaser,karaf,kotlin,kscript,layrry,leiningen,maven,micronaut,mulefd,mvnd,pomchecker,sbt,scala,spark,springboot,sshoogr,test,tomcat,vertx,visualvm,webtau
Not refreshing version cache now...

This is probably NOT what was causing the original intermittent problem (as the symptoms are different) but it is very likely that the sdk function may occasionally also emit other messages or output other than just the bash code when running sdk completion bash.
For me, as a workaround to test, I have changed the lines in .bashrc to:
[[ -s "/home/johann/.sdkman/bin/sdkman-init.sh" ]] && source "/home/johann/.sdkman/bin/sdkman-init.sh"
source /home/johann/.sdkman/contrib/completion/bash/sdk

I do not understand why the installation procedure does not do it like this in the first place, I do not think there
should ever be the need to execute anything but the code in the completion script to make this work.
So if one could just directly source the completion file, the danger of the sdk completion xxx command emitting something in addition to the code to stdout somewhere immediately would be removed.

I have the same problem. Sometimes when I open up the shell, I see "/proc/self/fd/22:1: bad pattern: ^[[1". Since I'm using zsh, the output looks a bit different, but I think the problem is the same.
Here is what i found out:
When opening the shell, zsh does the usual source <(sdk completion zsh).
Normally, the completion snippets will be generated and inserted here. However sometimes sdkman finds updates and prepends a broadcast message to the output. So the output of sdk completion zsh sometimes is:
==== BROADCAST =================================================================
* 2021-05-15: jbake 2.6.7 available on SDKMAN!
* 2021-05-15: webtau 1.41 available on SDKMAN!
* 2021-05-12: micronaut 2.5.3 available on SDKMAN!
================================================================================
#!/usr/bin/zsh

_sdk() {
	case "${CURRENT}" in
	2)
…

This output is then sourced by the shell. While zsh just complains about a "bad pattern", bash replaces the * with the content of your current directory (this is why you see "music" in the error message).
A propper fix would be to disable broadcast messages in the completion subcommand.
Hope I could help :)

I have  the same  problem with CentOS 6.x

We will be releasing a fix for this as soon as possible. In the meanwhile, please reference the file directly from your bash/ZSH profile like @johann-petrak suggested.

FWIW I'm also affected by this, and the workaround suggested by @johann-petrak appears to be working fine.
One slight tweak that might make it more generally reusable is to leverage the SDKMAN_DIR environment variable which should've been set at that stage, i.e.:
source "$SDKMAN_DIR/contrib/completion/bash/sdk"

Also, in terms of general recommendation for setting up completion, I wonder isn't it more efficient to simply source the completion file directly rather than invoking a command that'll echo the completion?

Thanks for the fix!
Still curious though: why does the skd installation procedure not just put the code for sourcing the appropriate completion file directly, why does this need to go through the sdk function?

Agreed, it would be a better option. We could even source it from within the sdkman-init.sh, with the type of completion based on if it's bash/ZSH. We could also add a feature toggle to switch it on/off.

I think we have a tactical fix for now, but I'm going to keep this open so we can do this properly.

Okay, changes have been made and are on master (and available to try in the beta channel).
All that is required now is to add the sdkman_auto_complete=true to the .sdkman/etc/config.
It will automatically sense your shell and source the appropriate completion script.
Please give it a go and let me know if that works.

Great!
So if I understand correctly this means that by default the only line placed in .bashrc will be the line sourcing sdkman-init.sh because the shell will be auto-detected for completion support?
Will the sdk command "completion"  then still be supported/needed and what will it do?

I can confirm that the current beta version does not produce any warnings when I fire up my shell. Completion works as expected in zsh.
Thank you very much.

@johann-petrak yes exactly, but I've done it in such a way that having that snippet in there (for people that have already added it) won't break anything. I've also removed completion as a command in the help output, so it is purely there for compatibility's sake and does nothing.
@jochenwierum excellent stuff, glad to hear that it's working :+1:

After pulling in from the beta channel, all good on my end as well. :+1:
BTW @marc0der, now that the completion command is obsoleted, do you think it makes sense to also remove it from the completion file itself? I see it's still present in there, so thing are a bit inconsistent with what sdk help offers.

Ah, I thought I'd removed it. Yes indeed. I'm also going to remove the sdkman-completion.sh all together.

Hey, I just tried to type sdk completion bash in my terminal right now and, beyond the completion script, sdkman also printed the warning about a new version of sdkman:
ATTENTION: A new version of SDKMAN is available...

The current version is 5.11.4+709, but you have 5.11.0+644.

Would you like to upgrade now? (Y/n):

I'm not sure if this is related to the current bug but, if that update notice gets sourced, then it would cause a bug resembling to this one.

@christophehenry are you seeing this on the beta channel? This is where we've fixed it.

I've done some final cleanup on this feature and addressed the completion tweaks as suggested by @vpavic. Please give it a final test before I release this version into the wild.

I've just pulled the latest from the beta channel (i.e. master+712) and everything looks good to me.
On top of verifying that the completion is set up properly without having anything completion specific in my .bashrc, these are the other things that I've tried:

completion doesn't offer completion command:

$ sdk
broadcast   current     env         help        install     offline     uninstall   upgrade     version
config      default     flush       home        list        selfupdate  update      use

help command doesn't list completion command:

$ sdk help

Usage: sdk <command> [candidate] [version]
       sdk offline <enable|disable>

   commands:
       install   or i    <candidate> [version] [local-path]
       uninstall or rm   <candidate> <version>
       list      or ls   [candidate]
       use       or u    <candidate> <version>
       config
       default   or d    <candidate> [version]
       home      or h    <candidate> <version>
       env       or e    [init|install|clear]
       current   or c    [candidate]
       upgrade   or ug   [candidate]
       version   or v
       broadcast or b
       help
       offline           [enable|disable]
       selfupdate        [force]
       update
       flush             [archives|tmp|broadcast|version]

   candidate  :  the SDK to install: groovy, scala, grails, gradle, kotlin, etc.
                 use list command for comprehensive list of candidates
                 eg: $ sdk list
   version    :  where optional, defaults to latest stable if not provided
                 eg: $ sdk install groovy
   local-path :  optional path to an existing local installation
                 eg: $ sdk install groovy 2.4.13-local /opt/groovy-2.4.13

executing completion command doesn't return error i.e. everything's backwards compatible:

$ sdk completion bash && echo $?
0

Great to hear. Also, there will be no unexpected broadcasts or update messages. I'll release it shortly.

@marc0der

are you seeing this on the beta channel?

Well, you also removed the completion command on beta channel so I can't tell but the sdkman_auto_complete option works nicely. Be careful to correctly advertise this when releasing though because this is a breaking change.
Anyway, thank you for your work here. Really helpful! :+1:

The completion command is still there for backward compatibility but is now simply noop with 0 return code. This guarantees backward compatibility.
I've simply removed all references to it so it is no longer advertised.

This has now been resolved and was released in 5.11.5.

@christophehenry The completion command is still there but is now simply noop with 0 return code. This guarantees backward compatibility.
I've simply removed all references to it so it's no longer advertised.

But please advertise that we need to manually modify .sdkman/etc/config . I reinstalled my system and spend entire afternoon trying to figure out why my old workaround sdk completion bash >> sdkman_bash_completion was returning an empty file. I haven't been keeping track of sdkman issue-tracker since my issue #466 was resolved and you were aware of broadcast message issue and working on it.
Maybe in Installation guide,  add a section that explains how we can enable completions, or maybe in future release, you can set sdkman_auto_complete=true as default config, so users can get completion out of box.


CI

Hello. Thanks for taking the time to write this and make it public. I came in via #42 but can see you use a unit testing framework.
I've been trying to generate coverage, both by forking your repo and running your travis.yml there are errors. I wasn't sure if you knew about them, including but not limited to commands for executable files that are not installed, passing a token that can just be set via travis settings.
I'm currently trying to fix these problems, but it seems C++ coverage is harder to generate than the same in Java, C# or scripting language.

https://github.com/CODESIGN2/silicon/tree/coverage-works/ has the dockerfile build tests that generate coverage using lcov. There still seems to be some problem (it's reporting 0.0%) but it does so based upon the silicon source tree so as soon as I've worked out what has gone wrong there I have the coveralls system receiving that data.

Just for info I did some work some time ago to make the travis.yml work again: https://travis-ci.org/matt-42/silicon
I had to disable all compilers but clang-5.0 and also the optional test.

That is the vein of work I've picked up. Thanks for that. So-far the largest problem seems to be differing CLI API's between versions of needed software. I think once it's built successfully matrix, tests only built for clang builds and sending coverage, then the rest should be easy to turn back on.


Makes README gender neutral with removal of 'he' and 'his'

Current README implies male users with use of 'he' and 'his' which is completely unnecessary.
Simple change of wording to make it gender neutral.

What a great change. Thanks for this.

Decided to check the rest of the repository and found a few more references which I have fixed in the commit I just pushed.


Canonical 22.04 support ?

Is Canonical 22.04 supported ?
For instance  Irun Canonical 0001-com-ubuntu-minimal-jammy minimal-22_04-lts

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

ID: 61687573-f03b-85dc-54cf-e95d95efb235
Version Independent ID: 7bfd1c0f-0ecd-44da-9724-6118b950f4ff
Content: Automatic VM Guest Patching for Azure VMs - Azure Virtual Machines
Content Source: articles/virtual-machines/automatic-vm-guest-patching.md
Service: virtual-machines
Sub-service: maintenance
GitHub Login: @maulikshah23
Microsoft Alias: maulikshah

@ezYakaEagle442, the Canonical 0001-com-ubuntu-minimal-jammy minimal-22_04-lts is not supported today for Auto VM Guest Patching.

@ezYakaEagle442
Thanks for your feedback! We will investigate and update as appropriate.

@ezYakaEagle442
if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.
@maulikshah23
Thanks for you quick response.

@ezYakaEagle442
We are going to close this thread as resolved but if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.


[ProductCatalogService] Add product catalog service problem patterns

Changes
Refactored the featre flag querying in ProductCatalogService to be reusable
Added Problems to ListProducts and GetProduct endpoints in the product catalog service:

ItemListInternal - will fail ListProducts with Internal error code
ItemNotFound - will fail GetProduct with NotFound error code

Merge Requirements
For new features contributions please make sure you have completed the following
essential items:

[x] CHANGELOG.md updated to document new feature additions
[ ] Appropriate documentation updates in the docs
* [ ] Appropriate Helm chart updates in the [helm-charts][]

Hey @klucsik, nice to see you here!
Before we check your PR, could you sign the EasyCLA?

Hey @klucsik, nice to see you here! Before we check your PR, could you sign the EasyCLA?

Yes yes, we are on it, just having some learning path with commit signing :D

Hey @klucsik, nice to see you here! Before we check your PR, could you sign the EasyCLA?

Nice to work with you again :) EasyCLA is green

I agree with @austinlparker's comment about introducing another feature flag for a simple blunt failure scenario. We already have several similar feature flags across different aspects of the demo. What observability demo and/or use cases are we trying to solve with this feature flag?

@austinlparker @julianocosta89 @puckpuck Thank you for reading through my PR, and the comments.
What do you mean of triggering 100% failure scenarios? As I understand, and experienced, the problem scenarios can be triggered partially if we set the feature flag in the feature flag service like 0.3 (which gets triggered every 30% of the calls).
My goal is basically to introduce 404 and 500 errors in a Go service, so we can demonstrate what can one see with open telemetry data, and with more instrumentation. Initally these meant to be in the SearchProducts, but turned out, nothing calls the SearchProducts endpoint (and the loadgenerator doesnt seem to handle gRPC requests) so I moved them where it made most sense to me.
I could trigger the 404 from the loadgenerator side, but 500 should be in the ProductCatalogService.
I could imagine the ListProduct would be able to error out if it gets a malformed data json, or if we would use some DB to store the products and that would have an outage or similar problem.
I'm very much open for your suggestions, my goal would be to introduce these errortypes in a meaningfull form, triggerable from the featureflag service.

@klucsik we already have a feature flag in the Product Catalog service that will return a 500 for a specific product ID when the flag is enabled. Would the productCatalogFailure feature flag support your need to see a Go service return a 500 under some conditions? https://github.com/open-telemetry/opentelemetry-demo/blob/main/src/productcatalogservice/main.go#L279-L303
I want to leverage feature flags to showcase potential failures, but I would like the failures to be more than just blunt failures on a feature flag being positive. It would help that the failure was due to a specific scenario, such as a product ID or multiple specific products being purchased, etc.

@klucsik we have just merged a PR that removed the current FeatureFlagService in favor of OpenFeature and FlagD.
Unfortunately your PR needs to be revisited.
Would you be able to update it?

Hey @julianocosta89. Sorry for going radiosilent about this. We discussed it a lot internally.
I'll definetly rework this, as we need these problem patterns present, but maybe we shouldn't merge it to upstream as you guys pointed out that from pure otel perspective these arent providing much value.

@klucsik got it.
Should we close this PR then?


[lightdash-gcp] dbt version incompatibility

Summary

Lightdash connects to dbt projects and provides CLI commands to generate lightdash-ready model YAMLs, namely
lightdash generate , lightdash deploy , lightdash dbt run.
Currently all of these commands fail on plural deployment of lightdash.
I verified the issue to be a version incompatibility between lightdash and dbt, it's related to

https://github.com/lightdash/lightdash/issues/4290
and by extension the true underlying issue https://docs.getdbt.com/guides/migration/versions/upgrading-to-v1.4
Basically plural's lightdash version 0.3... expects a root_path var in each node in the dbt-generated manifest.json, but dbt >1.4 removed that.

Fix
Bumping the version of the lightdash image to 0.525.0 fixed that.
You would need to bump that version everywhere in the plural app, image, tags, ....
Reproduction

Install any lightdash bundle on a plural cluster and use it with a dbt project using dbt >= 1.4.
The issue is the version incompatibility.
UI/UX Issue Screenshots

For lightdash generate:
(I didn't get a chance to save all errors, because I already fixed it locally by bumping the version in the lightdash image tag)
  ❯ lightdash generate
(node:63648) NOTE: We are formalizing our plans to enter AWS SDK for JavaScript (v2) into maintenance mode in 2023.Please migrate your code to use AWS SDK for JavaScript (v3).For more information, check the migration guide at https://a.co/7PzMCcy
        (Use `node --trace-warnings ...` to show where the warning was created)
        ? Are you sure you want to generate .yml for all models in project? Yes
        Generated .yml files:
        ✖   Failed to generate stg_yfinance__equities_1d.yml
        The "path" argument must be of type string. Received undefined
        TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received undefined
            at new NodeError (node:internal/errors:387:5)
            at validateString (node:internal/validators:162:11)
            at Object.join (node:path:1172:7)
            at /usr/local/lib/node_modules/@lightdash/cli/dist/dbt/models.js:212:49
            at step (/usr/local/lib/node_modules/@lightdash/cli/dist/dbt/models.js:67:23)
            at Object.next (/usr/local/lib/node_modules/@lightdash/cli/dist/dbt/models.js:48:53)
            at /usr/local/lib/node_modules/@lightdash/cli/dist/dbt/models.js:42:71
            at new Promise (<anonymous>)
            at __awaiter (/usr/local/lib/node_modules/@lightdash/cli/dist/dbt/models.js:38:12)
            at findAndUpdateModelYaml (/usr/local/lib/node_modules/@lightdash/cli/dist/dbt/models.js:198:12) {
          code: 'ERR_INVALID_ARG_TYPE'
        }
        TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received undefined
            at new NodeError (node:internal/errors:387:5)
            at validateString (node:internal/validators:162:11)
            at Object.join (node:path:1172:7)
            at /usr/local/lib/node_modules/@lightdash/cli/dist/dbt/models.js:212:49
            at step (/usr/local/lib/node_modules/@lightdash/cli/dist/dbt/models.js:67:23)
            at Object.next (/usr/local/lib/node_modules/@lightdash/cli/dist/dbt/models.js:48:53)
            at /usr/local/lib/node_modules/@lightdash/cli/dist/dbt/models.js:42:71
            at new Promise (<anonymous>)
            at __awaiter (/usr/local/lib/node_modules/@lightdash/cli/dist/dbt/models.js:38:12)
            at findAndUpdateModelYaml (/usr/local/lib/node_modules/@lightdash/cli/dist/dbt/models.js:198:12)

        Report this issue with 1-click:

          🐛 https://github.com/lightdash/lightdash/issues/new\?assignees\=\&labels\=🐛+bug\&template\=bug_report.md\&title\=The%20%22path%22%20argument%20must%20be%20of%20type%20string.%20Received%20undefined

The error on lightdash dbt run and lightdash deploy was clearer about the root_path, but I don't have that error message anymore.
Additional Info about Your Environment

Tested on google cloud, but should be the same on all clouds.

Pretty sure this has been fixed already.


Update README.md

Link to my github account

Hi @bhavanshu-1112 , thanks for the pull request. Any reason why you closed it?

Hi, actually I had not closed it intentionally.
As I am new in pulling requests on GitHub so by mistake it got closed.
Will you please guide me how to contribute to the open source community and
doing pull requests.
Thanks 😊😊
On Sun, Sep 22, 2019, 00:32 Eddie Jaoude<EMAIL_ADDRESS>wrote:

Hi @bhavanshu-1112 https://github.com/bhavanshu-1112 , thanks for the
pull request. Any reason why you closed it?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/eddiejaoude/hacktoberfest-practice/pull/42?email_source=notifications&email_token=AK7THFQVMIVMVN4KVWMHYWLQKZVU5A5CNFSM4IY6GQ52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7IXYWY#issuecomment-533822555,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AK7THFQV46QMMFRYD34VVLTQKZVU5ANCNFSM4IY6GQ5Q
.

You created/raised the PR correctly, but you pressed closed. You can click reopen.
So it seems like you are doing well 🤓 . If you have any questions let me know.


Add endpoint for getting results of the quizzes authored by a teacher

Describe the aim of this enhancement
When the API is used with kweeznuts, it can be observed that the frontend makes multiple GET requests in order to render the Reports page of the logged in teacher. This enhancement will allow the client to instead make a single request and hopefully lighten the load especially on a PostgreSQL server.

backend server

client (both the My Quizzes and Reports pages display a list of the quizzes authored by the logged in teacher, yet the latter still makes multiple requests, as seen in the backend logs above)

Describe the solution you'd like
Similar to the GET /quizzes/ endpoint, write a path operation for accessing the results of the quizzes authored by a teacher

G lang ako
Pero atm, I dont think priority natin ang performance ng web app since hohost lang naman natin for a limited amount of time? Kaya for me, ok lang kahit di efficient algos.
What do you think?

agree
pero since naadd ko na yung code merge ko na rin xDD
update ko yung ibang items mamaya, basta concern ko lang yung maging smooth ang transactions ng user with d app


BlSvgPath ignores viewbox

BlSvgPath class has a viewbox instance variable which is written but not used.
I suppose the intention is the one described here: https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/viewBox

Moved from: https://github.com/pharo-graphics/Bloc/issues/136#issue-854787928

Should be fixed by 0142f8225c8113d58f7ba2b59d1e1c86cd30a032


Noble uses EFI (extensible firmware interface) not MBR (Master Boot Record)

Requires a "boot" partition, "/boot/efi:
must be partition type fat32, formatted as vfat, needs at least 6MB, 30MB should be enough
typically /dev/sda1; root partition migrates to /dev/sda2.
Enables certain features, such as accessing GPUs w/ > 16 GiB RAM

added efi support for aws,gcp,vsphere with the following commits

e8d1cce201064731d34c514fb038b0df246dfde4
696e13392fc8f6fe0fe525745e6fa9a6cbd5763c
a7adae7bb41eb60c50b2b9f22f31fddf7a4f947a


What are templates and what is content?

General Support Request
When reviewing the generated docs it is hard to know what are template files and what are content files.

[ ] The template for apiExmaples comes from '../docs/partials/apiExamples.md'
[ ] The README comes from '../docTemplates/README.md'
[ ] The demo.md comes from '../docs/partials/demo.md'

Support request
I'd suggest that we move all the templates to a single location to make this easy to maintain. Right now we have to read the generateDocs.js file to find out what is what.

Docs are organized in an intentional way. The ./docs and ./apiExamples contains the only files that should be managed/edited by the component creator/editor.
Sounds like this is something we should be putting somewhere in the readme to help the engineers.

Moving this ticket to WC-Generator as I think the right approach here is to document this in the template so it gets pulled into the future docs for all components.


[1.23] [ambient] EndpointSlices without a TargetRef may result in workload fetch errors

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
In namespaces with

Headless services
EndpointSlices with no TargetRef

Istio versions <= 1.23 may fail to proxy traffic with the following ztunnel error:
2024-10-24T15:01:17.472017Z	error	state:proxy{wl=aiem-workload/engine-a08bd334-3540-40ca-a9e2-cd8fbf443b10-0}	workload does not match proxy workload uid. this is probably a bug. please report an issue
2024-10-24T15:01:17.472036Z	error	access	connection complete	src.addr=<IP_ADDRESS>:45700 src.workload="aiem-operator-59657b57bf-bfhr2" src.namespace="aiem-system" dst.addr=<IP_ADDRESS>:54321 dst.service="engine-a08bd334-3540-40ca-a9e2-cd8fbf443b10-hl.aiem-workload.svc.cluster.local" dst.workload="engine-a08bd334-3540-40ca-a9e2-cd8fbf443b10-hl-5769b" dst.namespace="aiem-workload" direction="inbound" bytes_sent=0 bytes_recv=0 duration="0ms" error="connection closed due to policy rejection"

This is because the workload info obtained from WDS by IP lookup does not match the local proxied workload info exactly.
As per @howardjohn this is caused by EndpointSlices not having a TargetRef, which breaks the logic designed to "collapse" ES down to a real workload.
It has been reported that this is resolved in 1.24+, as in 1.24 we no longer do WDS lookups by IP in ztunnel. Might need to cover this scenario with some tests tho and there still could be corner cases here to solve for.
xref: https://istio.slack.com/archives/C041EQL1XMY/p1729793894262819
Version
NA

Additional Information
No response

From some testing on 1.24 I think this works as expected (not on 1.23 though, that is just broken). The user will not get HBONE when calling the service, but that is basically expected -- they explicitly configured an opaque endpoint not linked to a pod


Redundant, unclear, and missing cases in the definition of function termination

Section 16.14 Function Invocation (3rd edition) defines function termination:

Execution of f terminates when the first of the following occurs:
• An exception is thrown and not caught within the current function activation.
• A return statement (17.12) immediately nested in the body of f is executed and not intercepted in a finally (17.11) clause.
• The last statement of the body completes execution.

The last statement of the body is always a return statement because one is implicitly appended to the body to make this true.
It seems like the third case of the definition implies the second one, and thus the third case is redundant.

I'm not going to file yet another issue but the first clause above is not completely clear, either.
By the obvious reading, if f calls g and g calls h and h throws an exception that is caught by g, then f terminates because the first of those things that happened was that an exception was thrown and not caught within the current function activation.
We want to make it not caught within the activation of f.  We're really defining termination of an activation, not a function.

The list is missing two cases of function termination.  From the spec for yield*:

If the enclosing function m is marked async* and the stream u associated with m has been canceled, then let c be the finally clause (17.11) of the innermost enclosing try-finally statement, if any. If c is defined, let h be the handler induced by c. If h is defined, control is transferred to h. If h is undefined, the immediately enclosing function terminates.

And from the specification for yield*:

If the stream u associated with m has been canceled, then let c be the finally clause (17.11) of the innermost enclosing try-finally statement, if any. If c is defined, let h be the handler induced by c. If h is defined, control is transferred to h. If h is undefined, the immediately enclosing function terminates.

Both of these constructs can terminate the immediately enclosing function.

An option is to just say that a yield after subscription cancellation will act equivalently to return;, which it does, instead of specifying the same behavior again.

@lrhn That is definitely better.  It nicely avoids the bug #25921 where the problem is that yield and yield* execute a return without setting the current return value.


Topology.from_openmm raises informative error if origin PDB lacks CONECT

[x] Fixes #356
[x] Adds test to ensure informative error is thrown

Codecov Report

Merging #357 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #357      +/-   ##
==========================================
+ Coverage   75.95%   75.97%   +0.01%
==========================================
  Files          17       17
  Lines        5431     5435       +4
==========================================
+ Hits         4125     4129       +4
  Misses       1306     1306

Impacted Files
Coverage Δ

openforcefield/topology/topology.py
73.45% <100%> (+0.14%)
: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 cc1d5eb...817e37f. Read the comment docs.


Webhook URL is not valid anymore

Slack has changed incoming webhooks URL's, therefore, I would replace:
url = 'https://' + options.domain + '.slack.com/services/hooks/incoming-webhook?token=' + options.token,

by
url = options.endpoint ? options.endpoint : 'https://' + options.domain + '.slack.com/services/hooks/incoming-webhook?token=' + options.token,

To allow flexibility between every kind of endpoints ;)

Some changes has been done on my fork, I republished the plugin as grunt-slack-hook-task to npm, if you get back and include the changes I can remove it. I let you the credits in the package.json file...
See ya !

@YouriT Thank you very much for publishing your fork officially. Funny Timing, was just starting to work on patching this up myself

My pleasure @EdHurtig :)

See #6 for a proper PR.


[Feature]: App name visible on all app detail pages

Is there an existing issue for this?

[X] I have searched the existing issues

Summary
Add the app name to UI (to header or menu or page content) so the name is visible while the user is browsing through app details settings (e.g. Configuration, Secrets, etc.).
Also the name of services could be emphasised as well in a similar fashion.
Why should this be worked on?
When I'm, for instance, updating secrets for multiple apps at once (in multiple opened browser tabs) then I'm afraid I'll accidentally edit the wrong instance and brake the production app. The same apply when I return to work and I'm not sure what app I was configurating.

I'm closing this issue, because tracking features will be moved to GitHub discussions. Github issues will be only for bugs.
Version 4 is in full focus. v3 related issues will be closed, if it is not a critical bug.
Thanks for your understanding.


import tensorflow failed, "ImportError: DLL load failed". Even after install visual studio 2015, Microsoft Visual C++ 2015 Redistributable Update 3.

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): no
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): win10 x64
TensorFlow installed from (source or binary):  pip install --upgrade tensorflow
TensorFlow version (use command below): 1.6.0
Python version: 3.6.4
Bazel version (if compiling from source):
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version:
GPU model and memory:
Exact command to reproduce:

Describe the problem
I was trying to install tensorflow cpu version on windows10, but always got error when import tensorflow.
I read the common_installation_problems , tried many solution I found on github, stackoverflow, etc. I install visual studio 2015, visual studio 2017, Microsoft Visual C++ 2015 Redistributable Update 3(both 32 and 64),  msvcp140.dll can find in both System32 and SysWow64 folder. But still can't import tensorflow.
Is there something I missed out?
Source code / logs

import tensorflow error info:

Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import tensorflow as tf
Traceback (most recent call last):
  File "C:\Users\sss\AppData\Local\Programs\Python\Python36\lib\site-packages\tensorflow\python\pywrap_tensorflow_internal.py", line 18, in swig_import_helper
    return importlib.import_module(mname)
  File "C:\Users\sss\AppData\Local\Programs\Python\Python36\lib\importlib\__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 994, in _gcd_import
  File "<frozen importlib._bootstrap>", line 971, in _find_and_load
  File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 658, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 571, in module_from_spec
  File "<frozen importlib._bootstrap_external>", line 922, in create_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
ImportError: DLL load failed: 动态链接库(DLL)初始化例程失败。

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\sss\AppData\Local\Programs\Python\Python36\lib\site-packages\tensorflow\python\pywrap_tensorflow.py", line 58, in <module>
    from tensorflow.python.pywrap_tensorflow_internal import *
  File "C:\Users\sss\AppData\Local\Programs\Python\Python36\lib\site-packages\tensorflow\python\pywrap_tensorflow_internal.py", line 21, in <module>
    _pywrap_tensorflow_internal = swig_import_helper()
  File "C:\Users\sss\AppData\Local\Programs\Python\Python36\lib\site-packages\tensorflow\python\pywrap_tensorflow_internal.py", line 20, in swig_import_helper
    return importlib.import_module('_pywrap_tensorflow_internal')
  File "C:\Users\sss\AppData\Local\Programs\Python\Python36\lib\importlib\__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
ModuleNotFoundError: No module named '_pywrap_tensorflow_internal'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\sss\AppData\Local\Programs\Python\Python36\lib\site-packages\tensorflow\__init__.py", line 24, in <module>
    from tensorflow.python import *
  File "C:\Users\sss\AppData\Local\Programs\Python\Python36\lib\site-packages\tensorflow\python\__init__.py", line 49, in <module>
    from tensorflow.python import pywrap_tensorflow
  File "C:\Users\sss\AppData\Local\Programs\Python\Python36\lib\site-packages\tensorflow\python\pywrap_tensorflow.py", line 74, in <module>
    raise ImportError(msg)
ImportError: Traceback (most recent call last):
  File "C:\Users\sss\AppData\Local\Programs\Python\Python36\lib\site-packages\tensorflow\python\pywrap_tensorflow_internal.py", line 18, in swig_import_helper
    return importlib.import_module(mname)
  File "C:\Users\sss\AppData\Local\Programs\Python\Python36\lib\importlib\__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 994, in _gcd_import
  File "<frozen importlib._bootstrap>", line 971, in _find_and_load
  File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 658, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 571, in module_from_spec
  File "<frozen importlib._bootstrap_external>", line 922, in create_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
ImportError: DLL load failed: 动态链接库(DLL)初始化例程失败。

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\sss\AppData\Local\Programs\Python\Python36\lib\site-packages\tensorflow\python\pywrap_tensorflow.py", line 58, in <module>
    from tensorflow.python.pywrap_tensorflow_internal import *
  File "C:\Users\sss\AppData\Local\Programs\Python\Python36\lib\site-packages\tensorflow\python\pywrap_tensorflow_internal.py", line 21, in <module>
    _pywrap_tensorflow_internal = swig_import_helper()
  File "C:\Users\sss\AppData\Local\Programs\Python\Python36\lib\site-packages\tensorflow\python\pywrap_tensorflow_internal.py", line 20, in swig_import_helper
    return importlib.import_module('_pywrap_tensorflow_internal')
  File "C:\Users\sss\AppData\Local\Programs\Python\Python36\lib\importlib\__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
ModuleNotFoundError: No module named '_pywrap_tensorflow_internal'

Failed to load the native TensorFlow runtime.

See https://www.tensorflow.org/install/install_sources#common_installation_problems

for some common reasons and solutions.  Include the entire stack trace
above this error message when asking for help.

run tensorflow_self_check.py result:

ERROR: Failed to import the TensorFlow module.

- Python version is 3.6.

- TensorFlow is installed at: C:\Users\sss\AppData\Local\Programs\Python\Python36\lib\site-packages\tensorflow

- Could not load 'cudart64_80.dll'. The GPU version of TensorFlow
  requires that this DLL be installed in a directory that is named in
  your %PATH% environment variable. Download and install CUDA 8.0 from
  this URL: https://developer.nvidia.com/cuda-toolkit

- Could not load 'nvcuda.dll'. The GPU version of TensorFlow requires that
  this DLL be installed in a directory that is named in your %PATH%
  environment variable. Typically it is installed in 'C:\Windows\System32'.
  If it is not present, ensure that you have a CUDA-capable GPU with the
  correct driver installed.

- Could not load 'cudnn64_5.dll'. The GPU version of TensorFlow
  requires that this DLL be installed in a directory that is named in
  your %PATH% environment variable. Note that installing cuDNN is a
  separate step from installing CUDA, and it is often found in a
  different directory from the CUDA DLLs. You may install the
  necessary DLL by downloading cuDNN 5.1 from this URL:
  https://developer.nvidia.com/cudnn

- Could not find cuDNN.

I'm also having the same issue. ANybody with a fix?

Seems tensorflow 1.6 is the issue,
I installed 1.5 and it works just fine
try
pip install tensorflow==1.5

https://github.com/tensorflow/tensorflow/issues/17386#issuecomment-370129452

Closing, duplicate of #17386

@thuojb, thanks. it fixed my problem

@thuojb thanks mate. This solution still works till this day running tensorflow 1.8. Life saver

@thuojb Thanks man, it still works.
But can you tell me how can we switch to tensorflow 1.8 without any errors while running

@thuojb It really works! Thank you~

Have in mind that downgrading to tensorflow 1.5 might not be the best solution because for instance, you won't have access to some of the new features of tensorflow like the 'eager execution' feature for example.
What i did in my case was to install tensorflow 1.8 with conda instead of pip. From my little experience with conda and pip, conda seems to perform better when it comes to placing required files in their proper location.
In summary, Instead of pip3 install --upgrade tensorflow, i used conda install tensorflow which will install the latest version properly.
In case you don't have Anaconda installed for conda commands. Download from https://www.continuum.io/downloads

@Abdulr-intija conda install tensorflow worked for me in an identical situation.  Many thanks for ending my struggle!

@thuojb,  thanks,  yes it works with version 1.5.0
@Abdulr-intija conda install tensorflow worked for me too.  able to install 1.8.0 successfully. thanks

i am getting the same issue with tensorflow 1.8.0.
can anybody help me with this issue?

Same issue here. It worked with version 1.5.
This problem could occur when the CPU lacks AVX instruction. Using a wheel built without AVX also fix problem.

thuojb, thank you so much! I am so happy I got it working.

i have same problem, when i import show error like this

ImportError                               Traceback (most recent call last)
c:\python\lib\site-packages\tensorflow\python\pywrap_tensorflow.py in
57
---> 58   from tensorflow.python.pywrap_tensorflow_internal import *
59   from tensorflow.python.pywrap_tensorflow_internal import version
c:\python\lib\site-packages\tensorflow\python\pywrap_tensorflow_internal.py in
27             return _mod
---> 28     _pywrap_tensorflow_internal = swig_import_helper()
29     del swig_import_helper
c:\python\lib\site-packages\tensorflow\python\pywrap_tensorflow_internal.py in swig_import_helper()
23             try:
---> 24                 _mod = imp.load_module('_pywrap_tensorflow_internal', fp, pathname, description)
25             finally:
c:\python\lib\imp.py in load_module(name, file, filename, details)
241         else:
--> 242             return load_dynamic(name, filename, file)
243     elif type_ == PKG_DIRECTORY:
c:\python\lib\imp.py in load_dynamic(name, path, file)
341             name=name, loader=loader, origin=path)
--> 342         return _load(spec)
343
ImportError: DLL load failed with error code -1073741795
During handling of the above exception, another exception occurred:
ImportError                               Traceback (most recent call last)
 in
----> 1 import tensorflow as tf
c:\python\lib\site-packages\tensorflow_init_.py in
20
21 # pylint: disable=g-bad-import-order
---> 22 from tensorflow.python import pywrap_tensorflow  # pylint: disable=unused-import
23
24 try:
c:\python\lib\site-packages\tensorflow\python_init_.py in
47 import numpy as np
48
---> 49 from tensorflow.python import pywrap_tensorflow
50
51 # Protocol buffers
c:\python\lib\site-packages\tensorflow\python\pywrap_tensorflow.py in
72 for some common reasons and solutions.  Include the entire stack trace
73 above this error message when asking for help.""" % traceback.format_exc()
---> 74   raise ImportError(msg)
75
76 # pylint: enable=wildcard-import,g-import-not-at-top,unused-import,line-too-long
ImportError: Traceback (most recent call last):
File "c:\python\lib\site-packages\tensorflow\python\pywrap_tensorflow.py", line 58, in
from tensorflow.python.pywrap_tensorflow_internal import *
File "c:\python\lib\site-packages\tensorflow\python\pywrap_tensorflow_internal.py", line 28, in
_pywrap_tensorflow_internal = swig_import_helper()
File "c:\python\lib\site-packages\tensorflow\python\pywrap_tensorflow_internal.py", line 24, in swig_import_helper
_mod = imp.load_module('_pywrap_tensorflow_internal', fp, pathname, description)
File "c:\python\lib\imp.py", line 242, in load_module
return load_dynamic(name, filename, file)
File "c:\python\lib\imp.py", line 342, in load_dynamic
return _load(spec)
ImportError: DLL load failed with error code -1073741795
my sistem are:

windows 7 64 bit
python 3.5.2rc1
intel core 2 due e8400

i got this message with tenserflow 1.10.0,
solution ?

@Abdulr-intija   thank you,i finaly resolve it .thank you

For reference, using ProcessMonitor is a good way to determine which DLL can't be loaded by tensorflow. Documented here: http://shitalshah.com/p/debugging-tensorflow-dll-importerror/

Win 10 64bit. python 3.5.2, CUDA 8.0, cuDNN v5.1 still having DLL load failed on both tensorflow-gpu 1.10 and 1.12. Other setups tested including python 3.6.7, CUDA 9.0/10.0, cuDNN 7.4.1 for 10.0, 7.4.1/7.3.1 for 9.0.  Confirmed msvcp140.dll, added cuda/bin, include, lib paths, made a copy for both cudnn64_5.dll and  cudnn64_6.dll, reinstalled python with Tcl/Tk, etc. Nothing worked so far.
I even tried ProcessMonitor @testlump posted above, and last two dlls were "C:\Windows\System32\nvcuda.dll" and "C:\Windows\System32\setupapi.dll" However, it didn't fail. Does anyone have a clue?

You might find it's best to recompile from source. This resolved the issue for me (see below for more information).
Here are some things I found compiling on Windows 10 with GPU support:

Check your CPU instruction set supports AVX with CPU-Z or an equivalent tool. If this isn't present (E.g. you're running an older CPU), you'll likely need to recompile tensorflow from source if you want it to work (this will likely apply irrespective of the OS).

Check you've got the correct CUDA libraries installed. The release Python package version of tensorflow (1.12) is built against CUDA 9.0 (I used package: cuda_9.0.176_win10.exe) and CuDNN 7.0 (I used package: cudnn-9.0-windows10-x64-v<IP_ADDRESS>.zip). If you have multiple CUDA versions installed side-by-side (v7.0, v9.0, v10.0) etc which you are not using, uninstall them.

Make sure your CUDA System environment variables are configured (E.g. for v9.0):
- Variable: CUDA_PATH Value: C:\Program Files\NVIDIA CPU Computing Toolkit\CUDA\v9.0
- Variable: CUDA_PATH_V9_0 Value: C:\Program Files\NVIDIA CPU Computing Toolkit\CUDA\v9.0

The CuDNN libraries should be unzipped to the CUDA install path, on Windows by default this is C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0 for version 9.0

Building from source

Install BAZEL and MSYS2 to their default locations (recommended). E.g. C:\MSYS2\ and C:\Bazel\

If you want to build the Python package from source follow these instructions: https://www.tensorflow.org/install/source_windows. Ensure you configure your BAZEL and MSYS2 installations according to their respective web-pages (linked from tensorflow), pay particular attention to environment variables. If you've installed CUDA, CuDNN you can skip the section Install GPU support (optional)

Clone or download the source as per the instructions and expand (E.g. C:\temp\tensorflow-master\)

Edit the source file {sourcegit for tensorflow path}\third_party\gpus\cuda_configure.bzl and change the line ["grep", "--color=never", "-A1", "-E", define, to: ["C:/msys64/usr/bin/grep", "--color=never", "-A1", "-E", define,  (RESPECT THE INDENTATION!)

If you have a username with a space in it - for example Peter Blakey so you users folder is C:\users\Peter Blakey\, create a symlink from 'Peter' in C:\Users\ - E.g. C:\users\Peter -> C:\users\Peter Blakey\ - The white-space causes path resolution problems during the build. E.g. from a command prompt in C:\users\ type mklink /d Peter "C:\Users\Peter Blakey" - you should now be able to cd in c:\users\Peter\ and see the contents of c:\users\Peter Blakey

If you have a username with a space in it, edit your User environment variables to path to Python.exe at the symlinked directory. E.g. Edit c:\users\Peter Blakey\AppData\Local\Programs\Python\Python36\ to C:\users\Peter\AppData\Local\Programs\Python\Python36\ and  c:\users\Peter Blakey\AppData\Local\Programs\Python\Python36\Scripts\ to c:\users\Peter Blakey\AppData\Local\Programs\Python\Python36\Scripts\

Create a empty folder for the build - E.g. C:\temp\buildcache - make sure you have at least 20GB free.

When you execute the prebuild step python configure.py from the location of the source you cloned from github:
- Check the python path or override No whitespace should be in the pathname.
- Check the python packages path or override No whitespace should be in the pathname.
- Choose N for XLA JIT support
- Choose N for ROCm support
- Choose Y for CUDA support
- Enter the version of CUDA you want to use or accept the default (9.0)
- Check the CUDA library path exists or if installed to another location, override.
- Enter the version of cuDNN you want to use or accept the default (7)
- Check the cuDNN path exists or if installed to another location, override
- When prompted for the compute capability you want to enable for your GPU, visit https://developer.nvidia.com/cuda-gpus and enter the correct value. E.g. for a Geforce GTX 970 it was 5.2
- Hit enter to accept the default optimization flags
- Choose Yes when asked to override eigen strong inline (Speeds up compilation time).

Build Step

Your compilation command should be something like this: bazel --output_user_root=C:/temp/buildcache build --config=opt --config=cuda --define=no_tensorflow_py_deps=true //tensorflow/tools/pip_package:build_pip_package

** or **

If your CPU does not support AVX instruction set, when you build tensorflow omit the --config=opt  flag so you build with bazel --output_user_root=C:/temp/buildcache build --config=cuda --define=no_tensorflow_py_deps=true //tensorflow/tools/pip_package:build_pip_package

Once it's built (takes several hours), follow the instructions to build the pip package (E.g. execute bazel-bin\tensorflow\tools\pip_package\build_pip_package C:/tmp/tensorflow_pkg and then install the resulting Python wheel package to your environment).
Finally, test the installed tensorflow with:
python -c "import tensorflow as tf; tf.enable_eager_execution(); print(tf.reduce_sum(tf.random_normal([1000, 1000])))"
Other notes

If the build fails, make sure you run bazel clean and delete the contents of the buildcache folder (E.g. c:\temp\buildcache) before commencing a new build

You can build against the latest version of CUDA (v10.0) and cuDNN (v7) if you want. You may wish to try building against the supported version first, once you've verified that you can uninstall CUDA / CuDNN, install the latest versions and rebuild tensorflow.

@testlump I appreciate the detailed help. I actually attempted to compile from source first because the original pip install didn't work. Then, I soon realized fixing pip install could be easier than setting up the environment to build from source. Now it's circling back to source compiling again... I didn't want to run this on Ubuntu because the package dependency is pretty messed up there already and it keeps crashing, but perhaps I should try on Ubuntu. I will try source compiling as the last resort if that doesn't work either. Thanks for the help anyways...

ImportError                               Traceback (most recent call last)
~\Anaconda3\lib\site-packages\tensorflow\python\pywrap_tensorflow.py in
57
---> 58   from tensorflow.python.pywrap_tensorflow_internal import *
59   from tensorflow.python.pywrap_tensorflow_internal import version
~\Anaconda3\lib\site-packages\tensorflow\python\pywrap_tensorflow_internal.py in
27             return _mod
---> 28     _pywrap_tensorflow_internal = swig_import_helper()
29     del swig_import_helper
~\Anaconda3\lib\site-packages\tensorflow\python\pywrap_tensorflow_internal.py in swig_import_helper()
23             try:
---> 24                 _mod = imp.load_module('_pywrap_tensorflow_internal', fp, pathname, description)
25             finally:
~\Anaconda3\lib\imp.py in load_module(name, file, filename, details)
241         else:
--> 242             return load_dynamic(name, filename, file)
243     elif type_ == PKG_DIRECTORY:
~\Anaconda3\lib\imp.py in load_dynamic(name, path, file)
341             name=name, loader=loader, origin=path)
--> 342         return _load(spec)
343
ImportError: DLL load failed with error code -1073741795
During handling of the above exception, another exception occurred:
ImportError                               Traceback (most recent call last)
 in
1 import pandas as pd
----> 2 from keras.models import Sequential
3 from keras.layers import Dense
4 import numpy as np
5 from sklearn.model_selection import train_test_split
~\Anaconda3\lib\site-packages\keras_init_.py in
1 from future import absolute_import
2
----> 3 from . import utils
4 from . import activations
5 from . import applications
~\Anaconda3\lib\site-packages\keras\utils_init_.py in
4 from . import data_utils
5 from . import io_utils
----> 6 from . import conv_utils
7
8 # Globally-importable utils.
~\Anaconda3\lib\site-packages\keras\utils\conv_utils.py in
7 from six.moves import range
8 import numpy as np
----> 9 from .. import backend as K
10
11
~\Anaconda3\lib\site-packages\keras\backend_init_.py in
87 elif _BACKEND == 'tensorflow':
88     sys.stderr.write('Using TensorFlow backend.\n')
---> 89     from .tensorflow_backend import *
90 else:
91     # Try and load external backend.
~\Anaconda3\lib\site-packages\keras\backend\tensorflow_backend.py in
3 from future import print_function
4
----> 5 import tensorflow as tf
6 from tensorflow.python.framework import ops as tf_ops
7 from tensorflow.python.training import moving_averages
~\Anaconda3\lib\site-packages\tensorflow_init_.py in
22
23 # pylint: disable=g-bad-import-order
---> 24 from tensorflow.python import pywrap_tensorflow  # pylint: disable=unused-import
25
26 from tensorflow._api.v1 import app
~\Anaconda3\lib\site-packages\tensorflow\python_init_.py in
47 import numpy as np
48
---> 49 from tensorflow.python import pywrap_tensorflow
50
51 # Protocol buffers
~\Anaconda3\lib\site-packages\tensorflow\python\pywrap_tensorflow.py in
72 for some common reasons and solutions.  Include the entire stack trace
73 above this error message when asking for help.""" % traceback.format_exc()
---> 74   raise ImportError(msg)
75
76 # pylint: enable=wildcard-import,g-import-not-at-top,unused-import,line-too-long
ImportError: Traceback (most recent call last):
File "C:\Users\admin\Anaconda3\lib\site-packages\tensorflow\python\pywrap_tensorflow.py", line 58, in
from tensorflow.python.pywrap_tensorflow_internal import *
File "C:\Users\admin\Anaconda3\lib\site-packages\tensorflow\python\pywrap_tensorflow_internal.py", line 28, in
_pywrap_tensorflow_internal = swig_import_helper()
File "C:\Users\admin\Anaconda3\lib\site-packages\tensorflow\python\pywrap_tensorflow_internal.py", line 24, in swig_import_helper
_mod = imp.load_module('_pywrap_tensorflow_internal', fp, pathname, description)
File "C:\Users\admin\Anaconda3\lib\imp.py", line 242, in load_module
return load_dynamic(name, filename, file)
File "C:\Users\admin\Anaconda3\lib\imp.py", line 342, in load_dynamic
return _load(spec)
ImportError: DLL load failed with error code -1073741795
Failed to load the native TensorFlow runtime.
See https://www.tensorflow.org/install/errors
for some common reasons and solutions.  Include the entire stack trace
above this error message when asking for help.
dataframe = pd.read_csv("dia

Hi, I solved the problem as.
First, I created the conda environment as following:
conda create -n myenv  python=3.6
conda activate myenv
Then I installed the keras-gpu=2.2.2
conda install keras-gpu=2.2.2 #this command also installed the tensorflow

Open ...\Python37\Lib\site-packages\tensorflow\python_pywrap_tensorflow_internal.pyd use Dependency Walker, it will show you the DLL dependency tree, you will find which DLL cause the problem. TensorFlow always linked to the specific CUDA version.

I fixed it.
Spend days searching to fix them.
Installed tensorflow with pip install tensorflow-cpu
Updated visual c++ 2015-2019
issue was because i didn't had nvidia graphics so that i should install with cpu version because i am using Raedon vega 8 graphics
Hope it helps.

(base) PS C:\Users\Priyanshi> pip install tensorflow==1.5
ERROR: Could not find a version that satisfies the requirement tensorflow==1.5 (from versions: 1.13.0rc1, 1.13.0rc2, 1.13.1, 1.13.2, 1.14.0rc0, 1.14.0rc1, 1.14.0, 1.15.0rc0, 1.15.0rc1, 1.15.0rc2, 1.15.0rc3, 1.15.0, 1.15.2, 2.0.0a0, 2.0.0b0, 2.0.0b1, 2.0.0rc0, 2.0.0rc1, 2.0.0rc2, 2.0.0, 2.0.1, 2.1.0rc0, 2.1.0rc1, 2.1.0rc2, 2.1.0)
ERROR: No matching distribution found for tensorflow==1.5
i found this kind of error please anyone help me?

Simply downgrade your TF version!
pip uninstall tensorflow
pip install tensorflow==2.0.0
(for me happened when I upgraded to 2.1.0 and I had problem with any pip version)

If it works on 2.0.0 but not on 2.1.0 then you need to install the 2019 MSVC redistributable as the requirements state
If it doesn't work on 2.0.0 either, then check if your Python interpreter is on 64 bits (it has to be) and if your CPU supports AVX (it has to). If Python interpreter is not right, please install the right one. If CPU does not support AVX, then you can compile from source.
Since this is the solution, locking conversation to prevent bad advice and "it works for me" messages


Why not treat as object when mixing key types?

And then allow numbers for keys too, is there a technical reason why it shouldn't be done?

Can you provide any examples of where this behaviour would be useful?
The library encodes the input value you provide as JSON — if it converted numbers to strings the JSON would no longer represents the data you provided. If you decoded it it wouldn't be the same data that you started with. I can't think of a scenario where this kind of automatic conversion would be beneficial.

Yeah, you're right.
In my use case, I'm using this to convert tables into strings which can then be obfuscated back and forth and then converted back to tables from strings. I'll probably make a modified version which can allow the mixed keys and just assume that strings from the JSON which are numbers are to be numbers as keys in the tables.

If you're only using the serialised data with your own program and don't need a standard format you might be better served using something like serpent. This would allow you to serialise data that wouldn't be directly mappable to JSON, such as tables with non-string key types.