Changes to avoid IndexOutOfBoundsException when only one embedded Credential is present in the url.

Issue #970
Also, handled all the edge conditions and made the code more bullet-proof.

@indraneelb1903 Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@indraneelb1903 Thank you for signing the Contributor License Agreement!

Codecov Report

Merging #980 into master will decrease coverage by 0.13%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master     #980      +/-   ##
============================================
- Coverage     75.88%   75.75%   -0.14%
+ Complexity      816      805      -11
============================================
  Files           100       99       -1
  Lines          3119     3094      -25
  Branches        419      418       -1
============================================
- Hits           2367     2344      -23
  Misses          584      584
+ Partials        168      166       -2

Impacted Files
Coverage Δ
Complexity Δ

...rk/cloud/config/client/ConfigClientProperties.java
89.38% <100%> (+2.71%)
39 <0> (+4)
:arrow_up:

.../server/environment/JGitEnvironmentProperties.java
77.77% <0%> (-4.05%)
7% <0%> (-2%)

...environment/MultipleJGitEnvironmentRepository.java
76.12% <0%> (-2.86%)
31% <0%> (-2%)

...server/environment/VaultEnvironmentRepository.java
51.08% <0%> (-1.55%)
10% <0%> (-1%)

...erver/environment/NativeEnvironmentRepository.java
84.78% <0%> (-1.45%)
43% <0%> (-1%)

.../server/environment/JGitEnvironmentRepository.java
80.98% <0%> (-0.47%)
82% <0%> (-6%)

...ver/config/EnvironmentRepositoryConfiguration.java
78.78% <0%> (ø)
2% <0%> (ø)
:arrow_down:

...ig/server/config/ConfigServerMvcConfiguration.java
100% <0%> (ø)
5% <0%> (ø)
:arrow_down:

...environment/MultipleJGitEnvironmentProperties.java
84.61% <0%> (ø)
3% <0%> (ø)
:arrow_down:

.../server/support/AbstractScmAccessorProperties.java
81.25% <0%> (ø)
17% <0%> (ø)
:arrow_down:

... and 8 more

Continue to review full report at Codecov.

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

See our contributing guidelines which has links to eclipse formatters you can use to format the code correctly https://github.com/spring-cloud/spring-cloud-config/blob/master/.github/CONTRIBUTING.md

Is formatting still off after the changes?

Yup take a look at the diff

Diff looks good. My apologies. My first Github Pull Request!


Bad Classification Results on the Generated Embedding

Hi, thank you for this repo and open-sourcing it. I have generated embedding of approximately 7k perfectly-matched-to-face images (such as the following) and then tried  to classify them using SVM (sklearn --> linear and RBF kernels) but I have got around 85% accuracy on the task. On the other hand when I used FACENET-generated embedding on the exact same SVM I got around 94%. Please tell me if I am doing sth wrong because the results are not at all SOTA.

Again, please re-align your images before using the pre-trained model or re-train a MagFace model based on your aligned inputs.


Bug: styled.input`` filters enterKeyHint prop

Environment
## System:
 - OS: macOS 11.1
 - CPU: (4) x64 Intel(R) Core(TM) i5-4308U CPU @ 2.80GHz
 - Memory: 596.96 MB / 16.00 GB
 - Shell: 5.8 - /bin/zsh
## Binaries:
 - Node: 14.15.4 - ~/.nvm/versions/node/v14.15.4/bin/node
 - Yarn: 1.22.10 - ~/.nvm/versions/node/v14.15.4/bin/yarn
 - npm: 6.14.10 - ~/.nvm/versions/node/v14.15.4/bin/npm
## npmPackages:
 - babel-plugin-styled-components: ^1.12.0 => 1.12.0
 - styled-components: ^5.2.0 => 5.2.1

Reproduction
https://codesandbox.io/s/styled-components-base-forked-9i8t6?file=/index.js
Steps to reproduce
const Input = styled.input``

const App = () => (
    <Input enterKeyHint="next" />
)

Expected Behavior
The input in the dom should have an enterkeyhint attribute:
<input enterkeyhint="next" class="asdf">

Actual Behavior
The input in the dom does not have an enterkeyhint attribute:
<input class="asdf">

Workaround:
const InputElement = styled.input.withConfig({ shouldForwardProp: prop => true })``

I think this should be reported to: https://github.com/emotion-js/emotion/blob/main/packages/is-prop-valid
It's basically the downstream library that we've switched to for prop-names. I can confirm though that their metadata props file doesn't list it.
I'll close this, since it's downstream and we can't really resolve it here.


Update multistage-build.md

Proposed changes

Unreleased project version (optional)

Related issues (optional)

Deploy preview for modest-edison-79d82e ready!
Built with commit 7b975d00d072c0a95b0f54140b5817f79fad1dd1
https://deploy-preview-7149--modest-edison-79d82e.netlify.com


Fix IntrospectionQuery when use non-GET methods

Hello,
I have try to use elm-graphql with Apollo Server that require to use only POST method and I found some problems and try to fix as below.

options.method and options.schema is not pass to the config object.

add them to elmPackageJson.graphql instead elmPackageJson because the config object wull read from elmPackageJson.graphql.
2) encode body with JSON.stringify is not work
use the json: true option and set body object to body property directly.
3) In my app there are some custon scalar types such as Date that will make unexpected type error
log the error instead throw an error then a user will can fix elm code manually.

Thank you for your work.

@jahewson Is this project dead, or is it safe to use?

@anagrius, it's safe to use - sorry I've been crazy busy but I will be merging PRs and fixing bugs soon.

Really looking forward to using this with POST-only server + Elm 0.18

@jahewson this would be very helpful with Abinsthe (Elixir's GraphQL library). Could you merge please?

Any news on this?


Rename app to something other than "LBRY Browser"

Just "LBRY" is preferable to this, if nothing else.

Done. https://github.com/lbryio/lbry-android/commit/654d50cd1b986b1d63bf241571d377a634764d31


Write samples out as UTF-8

/ cc @tenderlove

So it looks like there are some CI failures where we're checking for specific encoding behaviour.
@tenderlove - do you think https://github.com/github/linguist/pull/3046/files#diff-27dd121418d642475a079f07fb7c9f4eR24 on its own should fix your needle here?

do you think https://github.com/github/linguist/pull/3046/files#diff-27dd121418d642475a079f07fb7c9f4eR24 on its own should fix your needle here?

Yes, I think so


Sensu does not handle RMQ connection issues effectivly

Setup:
Block access to/from a test rabbitMQ machine using IPTables to allow sensu to have already made a connection to the transport.
iptables -A OUTPUT -p tcp --destination ix-rmq01.priv.example.com -j REJECT
iptables -A INPUT -p tcp --source ix-rmq01.priv.example.com -j REJECT

Test:
Web request to API endpoint:
curl http://localhost:4566/info
Expected:
An API response indicating that the transport was down or otherwise timed out
{
 "sensu": { "version":"0.18.1" },
 "transport":{... "connected":false, "error": "Timeout (10s) whilst connecting to my.rmq.server:5672"},
 "redis":{"connected":true}
}

Actual:
Curl (eventually) gives up with curl: (52) Empty reply from server and nothing in logs indicate any failure whatsoever.
After considerable time, or if services are restarted AMQ TCP connection failures are logged.

The API only checks if the transport is connected before querying for stats https://github.com/sensu/sensu/blob/9a783db96ed350d35eb521875e467be01fc0d084/lib/sensu/api/process.rb#L224 Due to the async behaviour of the Sensu transports and their reconnect logic (queued callbacks), it's difficult to achieve more than a blanket timeout/halt.

The RabbitMQ queue info call may be queued for on_open(), does the API successfully return if you remove the IPTables barrier before curl gets an empty reply?

If i block, run curl, unblock and wait a few seconds the API returns successfully.
In the test below, the curl was run after IPTables started blocking ports, and i unblocked between 09:48:47 and 09:48:48
curl http://localhost:4566/info --verbose --trace-time
09:48:43.296700 * About to connect() to localhost port 4566 (#0)
09:48:43.298694 *   Trying ::1...
09:48:43.301295 * Connection refused
09:48:43.304499 *   Trying <IP_ADDRESS>...
09:48:43.306092 * connected
09:48:43.307023 * Connected to localhost (<IP_ADDRESS>) port 4566 (#0)
09:48:43.312471 > GET /info HTTP/1.1
09:48:43.312471 > User-Agent: curl/7.26.0
09:48:43.312471 > Host: localhost:4566
09:48:43.312471 > Accept: */*
09:48:43.312471 >
09:48:43.315875 * additional stuff not fine transfer.c:1037: 0 0
09:48:44.317762 * additional stuff not fine transfer.c:1037: 0 0
09:48:45.319014 * additional stuff not fine transfer.c:1037: 0 0
09:48:46.320313 * additional stuff not fine transfer.c:1037: 0 0
09:48:47.321575 * additional stuff not fine transfer.c:1037: 0 0
09:48:48.322898 * additional stuff not fine transfer.c:1037: 0 0
09:48:49.324131 * additional stuff not fine transfer.c:1037: 0 0
09:48:49.652607 * HTTP 1.1 or later with persistent connection, pipelining supported
09:48:49.652737 < HTTP/1.1 200 OK
09:48:49.652818 < Content-Type: application/json
09:48:49.652893 < Access-Control-Allow-Origin: *
09:48:49.652968 < Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
09:48:49.653042 < Access-Control-Allow-Credentials: true
09:48:49.653142 < Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
09:48:49.653231 < Content-Length: 169
09:48:49.653309 < Connection: keep-alive
09:48:49.653383 < Server: thin 1.5.0 codename Knife
09:48:49.653470 <
09:48:49.653610 * Connection #0 to host localhost left intact
{"sensu":{"version":"0.18.1"},"transport":{"keepalives":{"messages":0,"consumers":2},"results":{"messages":0,"consumers":2},"connected":true},"redis":{"connected":true}}09:48:49.653715 * Closing connection #0

@warmfusion hi there! Sorry for the radio silence on this. Several Sensu Transport enhancements have been made since your last update here, and Sensu 0.23 introduces further enhancements RE: deferrable transport connections. Is this still an issue for you or can we close it?

@warmfusion not sure if you saw my previous comment. Is this still an issue for you? If not I'd love to close this. :)

Closing due to inactivity and wrong repo. Please reopen against sensu-transport if you are still seeing this behavior under the latest release of Sensu.

Thanks folks. Once we've updated to latest I'll try and give it a retest. 👍


Avoid memory leak from cloned materials

Only the Additive and Lobby examples are changed for their SyncVar's - no testing with uMMORPG needed.

:tada: This PR is included in version 3.7.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


OV2640 probe failed with error

E (273) camera_demo: Camera probe failed with error 0x20003

0x20003 is Camera not supported.
Two causes can lead to this error:
1.) Camera-Model not activated in config.
2.) Not the correct answer over SCCB from the camera.
I guess number 1. ;)

Might be related to https://github.com/igrr/esp32-cam-demo/issues/37. See if toggling power to the camera helps.

When I recompile upload, the error was upgraded. My XCLK pin is 21. I do not understand why something goes wrong. I just started getting in touch with ESP32 last month, but I want to figure it out. This looks cool. thank you all.

@Oitzu hi,Oitzu.Camera model is not activated in configuration. Where to modify the configuration. Is it here, my module is ov2640

Given the log posted in https://github.com/igrr/esp32-cam-demo/issues/61, i think this issue is solved.

Yes, thank you for your help.Adherence is victory.

It looks like this issue is closed but doesnt seem to work for me. I get the following output:

Pin configuration is as follows:

To flash the firmware, I connected GPIO0  to GND.

Unrelated to this problem.
Maybe follow #106.


🐛  This declaration is opt-in and its usage should be marked with

What were you trying to do?
Building the app for Android with ./gradlew build command
Environment data:
 "react": "17.0.2",
 "react-native": "0.68.2",

 # build.gradle
 buildscript {
    ext {
        buildToolsVersion = "33.0.0"
        minSdkVersion = 21
        compileSdkVersion = 31
        targetSdkVersion = 31

        if (System.properties['os.arch'] == "aarch64") {
            // For M1 Users we need to use the NDK 24 which added support for aarch64
            ndkVersion = "24.0.8215888"
        } else {
            // Otherwise we default to the side-by-side NDK version from AGP.
            ndkVersion = "21.4.7075529"
        }
    }
  }

  distributionUrl=https\://services.gradle.org/distributions/gradle-7.4.2-all.zip

#  app/build.gradle
 android{
    defaultConfig {
          multiDexEnabled true

# machine
MacbookPro , Apple M1 Pro
macOS Monterey 12.4

Reproduceable Code
No response
What happened instead?

Task :react-native-vision-camera:lintDebug FAILED

Relevant log output
> Task :react-native-vision-camera:lintDebug FAILED
Lint found 3 errors, 0 warnings. First failure:

/<project-path>/node_modules/react-native-vision-camera/android/src/main/java/com/mrousavy/camera/CameraView.kt:431: Error: This declaration is opt-in and its usage should be marked with

The full lint text report is located at:
  /<project-path>/node_modules/react-native-vision-camera/android/build/intermediates/lint_intermediate_text_report/debug/lint-results-debug.txt
w: Detected multiple Kotlin daemon sessions at build/kotlin/sessions

the lint-result.debug.txt content

/<project-path>/node_modules/react-native-vision-camera/android/src/main/java/com/mrousavy/camera/CameraView.kt:431: Error: This declaration is opt-in and its usage should be marked with
<EMAIL_ADDRESS>or '@OptIn(markerClass = androidx.camera.camera2.interop.ExperimentalCamera2Interop.class)' [UnsafeOptInUsageError from jetified-annotation-experimental-1.1.0]
            Camera2Interop.Extender(previewBuilder)
                           ~~~~~~~~
/<project-path>/node_modules/react-native-vision-camera/android/src/main/java/com/mrousavy/camera/CameraView.kt:432: Error: This declaration is opt-in and its usage should be marked with
<EMAIL_ADDRESS>or '@OptIn(markerClass = androidx.camera.camera2.interop.ExperimentalCamera2Interop.class)' [UnsafeOptInUsageError from jetified-annotation-experimental-1.1.0]
              .setCaptureRequestOption(CaptureRequest.CONTROL_AE_TARGET_FPS_RANGE, Range(fps, fps))
               ~~~~~~~~~~~~~~~~~~~~~~~
/<project-path>/node_modules/react-native-vision-camera/android/src/main/java/com/mrousavy/camera/CameraView.kt:433: Error: This declaration is opt-in and its usage should be marked with
<EMAIL_ADDRESS>or '@OptIn(markerClass = androidx.camera.camera2.interop.ExperimentalCamera2Interop.class)' [UnsafeOptInUsageError from jetified-annotation-experimental-1.1.0]
              .setCaptureRequestOption(CaptureRequest.SENSOR_FRAME_DURATION, frameDuration)
               ~~~~~~~~~~~~~~~~~~~~~~~

   Explanation for issues of type "UnsafeOptInUsageError":
   This API has been flagged as opt-in with error-level severity.

   Any declaration annotated with this marker is considered part of an
   unstable or
   otherwise non-standard API surface and its call sites should accept the
   opt-in
   aspect of it either by using @OptIn or by being annotated with that marker
   themselves, effectively causing further propagation of the opt-in aspect.

   Vendor: Android Open Source Project (jetified-annotation-experimental-1.1.0)
   Identifier: jetified-annotation-experimental-1.1.0
   Feedback: https://issuetracker.google.com/issues/new?component=192731

3 errors, 0 warnings

Device
Android
VisionCamera Version
2.13.5
Additional information

[ ] I am using Expo
[X] I have read the Troubleshooting Guide
[X] I agree to follow this project's Code of Conduct
[X] I searched for similar issues in this repository and found none.

i have same

are you solved this ?

no updates on this one ?

modify android/build.gradle file
allprojects {     // append here     afterEvaluate {         if (getPlugins().hasPlugin('android') ||             getPlugins().hasPlugin('android-library')) {             configure(android.lintOptions) {                 abortOnError false                 checkReleaseBuilds false             }         }     } }
and run './gradlew clean'

modify android/build.gradle file
allprojects {
    // append here
    afterEvaluate {
        if (getPlugins().hasPlugin('android') ||
            getPlugins().hasPlugin('android-library')) {
            configure(android.lintOptions) {
                abortOnError false
                checkReleaseBuilds false
            }
        }
    }
}

and run './gradlew clean'

Thank you @flybluewolf . Your solution worked. Here's my package.json:
{   "dependencies": {     "@react-native-masked-view/masked-view": "^0.2.8",     "@react-navigation/native": "^6.1.4",     "@react-navigation/stack": "^6.3.14",     "react": "18.2.0",     "react-native": "0.71.3",     "react-native-gesture-handler": "^2.9.0",     "react-native-safe-area-context": "^4.5.0",     "react-native-screens": "^3.20.0",     "react-native-view-shot": "^3.5.0",     "react-native-vision-camera": "^2.15.4",     "react-native-zephyr": "^1.1.0"   },   "devDependencies": {     "@babel/core": "^7.20.0",     "@babel/preset-env": "^7.20.0",     "@babel/runtime": "^7.20.0",     "@react-native-community/eslint-config": "^3.2.0",     "@tsconfig/react-native": "^2.0.2",     "@types/jest": "^29.2.1",     "@types/react": "^18.0.24",     "@types/react-test-renderer": "^18.0.0",     "babel-jest": "^29.2.1",     "eslint": "^8.19.0",     "jest": "^29.2.1",     "metro-react-native-babel-preset": "0.73.7",     "prettier": "^2.4.1",     "react-test-renderer": "18.2.0",     "typescript": "4.8.4"   },   "jest": {     "preset": "react-native"   } }
Update AndroidManifest.xml:
<uses-permission android:name="android.permission.CAMERA" />
Finally, my build.gradle file (directory: android/build.gradle):
` buildscript {
ext {
buildToolsVersion = "33.0.0"
kotlinVersion = "1.7.0"
minSdkVersion = 21
compileSdkVersion = 33
targetSdkVersion = 33
    // We use NDK 23 which has both M1 support and is the side-by-side NDK version from AGP.
    ndkVersion = "23.1.7779620"
}
repositories {
    google()
    mavenCentral()
}
dependencies {
    classpath("com.android.tools.build:gradle:7.3.1")
    classpath("com.facebook.react:react-native-gradle-plugin")
}
allprojects {
// append here
afterEvaluate {
    if (getPlugins().hasPlugin('android') ||
        getPlugins().hasPlugin('android-library')) {
        configure(android.lintOptions) {
            abortOnError false
            checkReleaseBuilds false
        }
    }
}

}
}`
Note: I have added kotlinVersion = "1.7.0" and
allprojects {     // append here     afterEvaluate {         if (getPlugins().hasPlugin('android') ||             getPlugins().hasPlugin('android-library')) {             configure(android.lintOptions) {                 abortOnError false                 checkReleaseBuilds false             }         }     } }
In the gradle.build file, nothing else.

Closing as this is a stale issue - this might have been fixed with the full rewrite in VisionCamera V3 (🥳) - if not, please create a new issue.


Failing local execution of Pinot.

The local startup of Pinot(built from the master branch) using the command ./bin/pinot-admin.sh QuickStart -type batch is failing with the following exception.
TargetExternalViewCalcWorker thread interrupted
java.lang.InterruptedException: null
	at java.lang.Object.wait0(Native Method) ~[?:?]
	at java.lang.Object.wait(Object.java:366) ~[?:?]
	at java.lang.Object.wait(Object.java:339) ~[?:?]
	at org.apache.helix.common.DedupEventBlockingQueue.take(DedupEventBlockingQueue.java:102) ~[pinot-all-0.13.0-SNAPSHOT-jar-with-dependencies.jar:0.13.0-SNAPSHOT-a2086072545fc67a35f5d6756c3b9efc97d15641]
	at org.apache.helix.common.DedupEventProcessor.run(DedupEventProcessor.java:60) [pinot-all-0.13.0-SNAPSHOT-jar-with-dependencies.jar:0.13.0-SNAPSHOT-a2086072545fc67a35f5d6756c3b9efc97d15641]
END TargetExternalViewCalcWorker thread for cluster QuickStartCluster
Closing zkclient uid:7, zk:State:CONNECTED Timeout:30000 sessionid:0x100182998ad0006 local:/[0:0:0:0:0:0:0:1]:64643 remoteserver:localhost/[0:0:0:0:0:0:0:1]:2123 lastZxid:48 xid:4 sent:6 recv:6 queuedpkts:0 pendingresp:0 queuedevents:0
Session: 0x100182998ad0006 closed
Closed zkclient with uid:7
EventThread shut down for session: 0x100182998ad0006

cc: @Jackie-Jiang

This doesn't seem to be the root cause of the failure. All these classes are Helix classes, not Pinot classes. Can you check if there are other error logs before this, or if there are existing instances already running (e.g. ZK)

Got it working after some cleanup. Thanks for the help.

@abhioncbr I am facing the same issue. Can you please explain in detail what cleanup process you did & how?


[SLR86] Adding bibliography item for the Yoruba corpus.

Re-opening this PR against the current development repo.

thanks, merging


Will updating to react router v3 break anything?

I would prefer to make a switch to react router 4


Fixed linkedin link for an author in Semantic blog

Signed-off-by: Fanit Kolchina<EMAIL_ADDRESS>Description
This PR fixes the linkedin link for Milind
Check List

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

By submitting this pull request, I confirm that my contribution is made under the terms of the BSD-3-Clause License.

@krisfreedain Could you please review this PR when you get a chance? Thanks!


Do we need methods __hash__() and __eq__() for Tensorli ?

https://github.com/joennlae/tensorli/blob/7d4cf821116a45032b4a9e518427a70ab1c4ad10/tensorli/tensorli.py#L135C28-L135C28
In build_topo(), we would ask if t exists in set visited, but how we determine whether two Tensorli objects are equal ?
so do we need methods __hash__() and __eq__() for Tensorli ?

Hei :-)
Thank you for the questions. I assume you are asking this to ensure we do not add a node (i.e. Tensorli) twice.
topo: list["Tensorli"] = []
visited = set()

# build topological order such that we calculate and pass the gradients
# back in the correct order
def build_topo(t):
    if t not in visited:
        visited.add(t)
        for child in t._prev:
            build_topo(child)
        topo.append(t)

I assume you looked into the Python documentation and saw that (https://docs.python.org/3/library/stdtypes.html#set):
The elements of a set must be hashable.
In the documentation for hashable (https://docs.python.org/3/glossary.html#term-hashable):
Most of Python’s immutable built-in objects are hashable; mutable containers (such as lists or dictionaries) are not; immutable containers (such as tuples and frozensets) are only hashable if their elements are hashable. Objects which are instances of user-defined classes are hashable by default. They all compare unequal (except with themselves), and their hash value is derived from their id().
So Tensorli objects are all unequal except with themselves --> exactly the behaviour we want for the set.
Does that answer your question :-)?

Hei :-)
Thank you for the questions. I assume you are asking this to ensure we do not add a node (i.e. Tensorli) twice.
topo: list["Tensorli"] = []
visited = set()

# build topological order such that we calculate and pass the gradients
# back in the correct order
def build_topo(t):
    if t not in visited:
        visited.add(t)
        for child in t._prev:
            build_topo(child)
        topo.append(t)

I assume you looked into the Python documentation and saw that (https://docs.python.org/3/library/stdtypes.html#set): The elements of a set must be hashable.
In the documentation for hashable (https://docs.python.org/3/glossary.html#term-hashable):
Most of Python’s immutable built-in objects are hashable; mutable containers (such as lists or dictionaries) are not; immutable containers (such as tuples and frozensets) are only hashable if their elements are hashable. Objects which are instances of user-defined classes are hashable by default. They all compare unequal (except with themselves), and their hash value is derived from their id().
So Tensorli objects are all unequal except with themselves --> exactly the behaviour we want for the set.
Does that answer your question :-)?

Oh, you re right, we just wanna avoid same node, rather than same node.data
Thank you and sorry for this dumb question 😄


Issue with the view from Telegram

when I call up the lms url from telegram, the lower toolbars are not displayed or are overlaid. This has only been the case since 5.1.1, at least I think so.
This is not the case in Safari.
it's a great plugin

What? Why would you be opening this from Telegram (a messenger app)????

yes i know, it's not easy to understand, many things are possible with lms.
i can switch on my esp32 with telegram, and control it with a link to lms with material skin

Sorry, but this is a Telegram issue - its drawing its controls over the web viewport.

I have read that a padding can be transferred in 5.2, which should perhaps solve the problem.
http://server:9000/material/?topPad=32&botPad=12


Explain input/output concept

What is the issue?
Many users have difficulties to understand input and output concept and that lead them to issues they do not really understand.
We should write a page in core concept category to explain how you can link action together through input and output.
We should also explain when use docker.#Build and when not.
And also explain how create dependency between actions that not necessary has input field : link docker.#Push and docker.#Pull for instance.

Many users have difficulties to understand input and output concept and that lead them to issues they do not really understand.

Do you have a link to a thread in discord or an example about use-cases users were trying to achieve and they were finding confusing? That could help to put a guide relatively easy

Sure : https://discord.com/channels/707636530424053791/966990447065071648 is a good example

Closing this issue to consolidate since #2162 is similar.


Clarify what choice of license means (and remove Apache?)

The 3 licenses to choose from (MIT/GPL/Apache) are mostly incompatible. And will it be GPL v2 or v3?
Most users won't understand the importance of the choice, so explaining in one sentence per license what the consequence is would be very helpful. Something like:
MIT: code be used in projects using BSD, GPL or Apache
GPL: code cannot be used in projects using BSD, MIT or Apache
Apache: code cannot be used in projects using BSD, MIT or GPL

And Apache is a very much undesired license. Given that pretty much the whole system is MIT/BSD/GPL, including it in this menu of choices is unfortunate. Please consider removing it.

IIRC Thomas used these 3 ones as they where the 3 mainly used license on github:
https://github.com/blog/1964-license-usage-on-github-com

Yep, see http://choosealicense.com/ , a site that Github created.
Apache v2.0 is GPL compatible, and I don't know of any reason why it can't be used from BSD/MIT licensed code.
The template it uses if you select GPL is v3.
I really don't want to get into specifying what can and can't be done with each license, because very quickly you have to get specific about exactly what it means. For instance, readline, which is GPL licensed, is used by the Python shell, which is PSF (like BSD) licensed, and frankly I'm not really sure myself why that's OK. And then you get into the debate about how the GPL interacts with static and dynamic linking, and it's not even clear how those terms from C-like languages apply to Python code, and... bah, I'm bored :wink: .
People who have already thought about open source licensing probably have a good idea of what license they want to use. For people who haven't, I think it's more useful to try to summarise the spirit of the license than the terms, because there's no good way to do the latter briefly (except perhaps for MIT).

what about say "If you don't know go to  http://choosealicense.com/"

Apache v2.0 is GPL compatible

It's not GPL v2 compatible, see https://gnu.org/licenses/license-list.html#apache2. And here are examples of people needing to hunt down contributors to Python packages to relicense:
https://github.com/pyca/cryptography/issues/1209
https://github.com/pypa/packaging/issues/42

For people who haven't, I think it's more useful to try to summarise the spirit of the license than the terms

I don't want to start a long discussion, but the above examples clearly show that Apache is a very poor choice for Python packages. So please don't recommend it on equal footing with MIT/GPL without any context.

because there's no good way to do the latter briefly

So add a few links to good overviews?

I have added a link to http://choosealicense.com for people who want more information.
You can make arguments for and against every license. I've certainly seen projects relicensed from GPL, and I've no doubt projects have been relicensed away from MIT (especially since that's easier). I would rather people didn't create new GPL code, but many people like the GPL, and not without good reasons.
I'm sticking to the shortlist that Github has chosen (MIT, Apache, GPL) for now.

thanks for adding the link


[Bug]: Adding span html element causes the text widget to break into multiple lines

Is there an existing issue for this?

[X] I have searched the existing issues

Description
When i add
this is a  span  thing
into text widget, it breaks line. Span class should never break line.
Steps To Reproduce

Add a new text widget
Add the text as this is a  span  thing
Observe that the text splits into multiple lines

Public Sample App
No response
Issue video log
No response
Version
Cloud

Here's where the issue is originating from. Git Blame tells me it was added in #18341. Any idea @riodeuno


The # in ext-es5 breaks in Vite

According to this comment, that has been resolved in the ext package, but I am using a library that relies on d which in turn relies on the legacy package.
Yes, this is a bug in Vite and they are on it (https://github.com/vitejs/vite/pull/2432), but for now I am blocked by this. Could you update the dependency?

@kristiandupont great thanks for openning that.
This library will definitely be updated to rely on ext. Still due to other priorities  unfortunately I cannot provide any ETA.


Add support for IRC invite

The IRC channel I want to mirror with slack is invite-only. This change makes slack-irc respond to invite commands, automatically joining any channel it is invited to.

Good idea! Maybe it should check that the channel exists in the channel mapping, available at this.channelMapping, before joining? Kind of bad if you can make the bot join an arbitrary amount of channels by just inviting it.
This test needs to be updated too.

That's probably a good idea. And forgot about the tests, my bad.
I'm currently adding features that allow me to change usermodes and log in on some various IRC networks - I think the best way to go about it is to add another field to the server settings where you can specify IRC commands that are set on connect.

Yep, that could work. I thought about adding SASL support, but thought it might just be overkill as not all networks support it anyway.

I fixed the test and added the check you suggested.
I also added support for automatically sending commands on connecting, they are added to the server config like this:
"autosendcmd": [
    ["MODE", "slack", "+x"],
    ["AUTH", "slack", "password"]
]

It uses the send command in node-irc, so you can do pretty much everything with it.
Sample configs are not updated. I'm not even sure you like my implementation of the feature, and I should have left it out of this pull request, but I didn't think that far ahead before making the changes :)

I like it, added some feedback :)

Did improvements based on your latest feedback. Thanks for pointing some things out, never really had to do anything this complicated (if you can call it that) in JS.

Thanks! I'll update the readme and release a new version.

https://github.com/ekmartin/slack-irc/commit/260a5d56a844e735132ba05839060c97d3eac42d


A weird bug about ArrowVectorField

Description of bug / unexpected behavior

Expected behavior

This is a bug.
How to reproduce the issue

class BasicVectorFieldUsage(Scene):     def construct(self):         av = ArrowVectorField(lambda pos: pos)         self.add(av)
this code don't work
change "lambda pos: pos" to "lambda pos: pos*1", then it works.
I can't find the reason.
Code for reproducing the problem
Paste your code here.

Additional media files

Images/GIFs

Logs
Terminal output

PASTE HERE OR PROVIDE LINK TO https://pastebin.com/ OR SIMILAR

System specifications
System Details

OS (with version, e.g., Windows 10 v2004 or macOS 10.15 (Catalina)):
RAM:
Python version (python/py/python3 --version):
Installed modules (provide output from pip list):

PASTE HERE

LaTeX details

LaTeX distribution (e.g. TeX Live 2020):
Installed LaTeX packages:

FFMPEG
Output of ffmpeg -version:
PASTE HERE

Additional comments

I would not necessarily call it a bug, since it seems to be outside of Manim's influence and controlled by the behavior of python when it comes to lambda functions....

I would not necessarily call it a bug, since it seems to be outside of Manim's influence and controlled by the behavior of python when it comes to lambda functions....

I've zero experience with Manim (just started looking at it today), but what your comment suggests is that Python Lambda functions are buggy (really..😒)
@argb, could you please provide a minimal reproducible example

OK, I had a look into the source code and I found the cause for the observed behavior:
        output = np.asarray(self.func(point))
        norm = np.linalg.norm(output)
        if norm != 0:
            output *= self.length_func(norm) / norm
        vect = Vector(output, **self.vector_config)
        vect.shift(point)

obviously it is the vect.shift(point) operation which fails, since all vectors are still located close to the origin in the case of ArrowVectorField(lambda pos : pos):

Why is this the case?
The argument of the function evaluated in the ArrowVectorField is a numpy ndarray with all points. The function is supposed to calculate a direction of the vector field at all these points. However, the function lambda pos: pos returns not a new, calculated value for each element in the list, it just returns the list/ndarray object itself.
So from that stage on output and point link to the same object in memory, the original list of all coordinate points.
In the next step the lengths of all vectors is supposed to be normalized, so that everything fits nicely onto the screen. However, since output and point refer to the very same list, now also the point coordinates themselves are normalized and all vectors end up in a circle with radius 1 around the origin.
So, yes, the cause of the problem is the behavior of the python lambda function, returning the same object if asked for it pos=pos rather than creating a new list of new values.
It would be quite easy to circumvent this behavior with a minor change in the source code, by just adding the multiplication by 1 fix into the source code:
        output = 1 * np.asarray(self.func(point))
        norm = np.linalg.norm(output)

Fixed via #3282


The password is incorrect while unzip the ziped file

The password is incorrect while unzip the ziped file

same issue😓.

Yes


utillinux: fix "fstrim --all"

Motivation for this change
Apply patch from upstream that for NixOS fixes fstrim -a and fstrim service. See patch description for details https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/patch/?id=155d48f590a50bb5dc265162ff2f9a971daed543
Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Can you also send this patch to http://vger.kernel.org/vger-lists.html#util-linux

@Mic92 Done, thanks! Upstream accepted it.

@vcunat should util-linux go to staging first?

@Mic92 Suppose yes. My previous PR touching utillinux gone through staging https://github.com/NixOS/nixpkgs/pull/26205#issuecomment-306261617

Seems OK  It is a relatively large rebuild (>5k just on x86_64-linux), so I staged it.

@vcunat Thank you!


Ambient: individual pods can enroll using label istio.io/dataplane-mode=ambient

Please provide a description of this PR:
/closes #50355
This change enables individual pods to enroll in ambient when labelled istio.io/dataplane-mode=ambient.

Hi @eoinfennessy. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@bleggett, I'm not sure whether PodRedirectionEnabled should return true or false when a pod has both the istio.io/dataplane-mode=ambient label and the annotation ambient.istio.io/redirection: disabled. (It currently returns false)

Is this required ? I know we do it for Istio v1, but I'm not sure it's a good idea to add this extra complexity.
I would rather add a 'global enable' option - if it is possible at this point, since the end goal is to have ambient act as a cluster-wide CNI ( which doesn't have even namespace opt in or pod opt out ).
Complexity has a high cost, and such annotation is really an API that we'll need to support for ages.

There is case some pod/service unser a namespace need to be excluded, even a specific port.  +1 for a real API instead of using label in the long run

@bleggett, I'm not sure whether PodRedirectionEnabled should return true or false when a pod has both the istio.io/dataplane-mode=ambient label and the annotation ambient.istio.io/redirection: disabled. (It currently returns false)

false would be equivalent to current behavior, so that's fine to keep for now.
Ultimately people shouldn't be using the status annotation to signal disable intent tho.

Is this required ? I know we do it for Istio v1, but I'm not sure it's a good idea to add this extra complexity.
I would rather add a 'global enable' option - if it is possible at this point, since the end goal is to have ambient act as a cluster-wide CNI ( which doesn't have even namespace opt in or pod opt out ).
Complexity has a high cost, and such annotation is really an API that we'll need to support for ages.

CNI is always per-pod, any API that operates at a higher level is just a roll-up.
It's not logically or behaviorally any different to label the pod versus the namespace to the CNI.
The internal API for "is ACTUALLY" enabled is the ambient.istio.io annotation.
The label is just user intent for the CNI.

There is case some pod/service unser a namespace need to be excluded, even a specific port.  +1 for a real API instead of using label in the long run

Some of those probably would require multiple labels.
But at least I don't want the internal CNI status annotation to be used as an explicit exclusion mechanism by users, a better exclusion intent would be good.

Excluding ports - or excluding pods - is fine. We already have the
exclusion for pods with an Istio sidecar.
We probably need to adjust that a bit - I think it's reasonable to disable
mTLS in the sidecar and rely on
ztunnel ( sandwiched sidecars ) - but that can be done via injection by not
adding the label that CNI uses to opt out of ambient.
My concern was with an API to opt-in pods in a namespace or cluster where
ambient is not enabled. We have a tendency to
add tons of options just because we can - without a very clear use case or
evidence it is needed. Usually it's for some
migration - which made sense for Istio v1 since it broke K8S behaviors and
we didn't have automtls, but Ambient doesn't
have this problem and this release doesn't target any migration.
For the port exclusion - it would be ideal to use the API we already have
(the annotations) at least as a starting point.
On Thu, Apr 25, 2024 at 9:25 PM Ben Leggett @.***>
wrote:

There is case some pod/service unser a namespace need to be excluded, even
a specific port. +1 for a real API instead of using label in the long run
Some of those probably would require multiple labels.
But at least I don't want the internal CNI status annotation to be used as
an explicit exclusion mechanism by users, a better exclusion intent would
be good.
—
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/50683#issuecomment-2078605814, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAUR2QD6M5YFWMZWNVFJ5DY7HJK3AVCNFSM6AAAAABGZJAKN2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZYGYYDKOBRGQ
.
You are receiving this because your review was requested.Message ID:
@.***>

My concern was with an API to opt-in pods in a namespace or cluster where ambient is not enabled. We have a tendency to add tons of options just because we can - without a very clear use case or evidence it is needed. Usually it's for some migration - which made sense for Istio v1 since it broke K8S behaviors and we didn't have automtls, but Ambient doesn't have this problem and this release doesn't target any migration.

We only enable ambient for pods, since it is CNI - the rest is UX convenience. We already watch all namespaces and all pod events.

If the namespace is labeled with istio.io/dataplane-mode=ambient, we iterate thru every pod in that namespace, skip the ones that have sidecars/sidecar inject labels, and skip the ones that have the separate annotation ambient.istio.io/redirection: disabled.

Or, if a new pod spawns in that namespace, we do the same.

For the rest, we then physically add them to the mesh (perform traffic capture), and on success, the CNI applies the annotation ambient.istio.io/redirection: enabled (note, this is the same annotation that we currently tell users to apply as intent, if they want to disable capture, which is confusing and nonintuitive.

Until (3), the pod has user intent in the form of a label, but is not actually part of the mesh. The CNI adding the annotation ambient.istio.io/redirection: enabled is the authoritative signal.
Since the label is intent, we are already looking at every pod. It doesn't change the internal API or implementation to use the label for pods as well as namespaces, it is simply a UX convenience. It is logical and intuitive that you can express intent with a label for a pod or namespace, and it doesn't change what Istio or the CNI actually does in any meaningful way.
The user should never apply ambient.istio.io/redirection: enabled  to a pod. Yet, they try, because it is intuitive to them that they should be able to do this operation. Thus, this PR, to allow them to express that intent with the label.
Ultimately, no one but istio should ever apply ambient.istio.io/redirection to anything, and the fact that people try, and that we tell them to use one label to include and another annotation to exclude (but not to include!) is just needlessly baroque.

For the port exclusion - it would be ideal to use the API we already have (the annotations) at least as a starting point.

If we want this we do need an API, but none of the existing annotations can be safely overloaded to support this. If we wanted to add an API for this, I would prefer to follow label is intent, annotation is status guide and make port exclusions a user-applied label.

/ok-to-test

On Fri, Apr 26, 2024 at 9:04 AM Ben Leggett @.***>
wrote:

My concern was with an API to opt-in pods in a namespace or cluster where
ambient is not enabled. We have a tendency to add tons of options just
because we can - without a very clear use case or evidence it is needed.
Usually it's for some migration - which made sense for Istio v1 since it
broke K8S behaviors and we didn't have automtls, but Ambient doesn't have
this problem and this release doesn't target any migration.
We only enable ambient for pods, since it is CNI - the rest is UX
convenience. We already watch all namespaces and all pod events.

I know how it works internally. The question is what do want the UX to be
for the user, and how to keep it simple and supportable long term.
As a user, I should be able to:

enable ambient in the entire cluster - that's the ideal and simplest
case for  fresh clusters.
enable ambient in a namespace - with ability to opt out specific pods.
For clusters with existing workloads, moving towards (1)

How we deal with Istio sidecars is internal details and should not leak
into 'API'.
IMO it would be great if the pod used a "istio.io/dataplane-mode=none"
instead of the annotation ( or other data plane modes besides "ambient" ),
for consistency.
Implementation-wise it is easy to do a lot of things and have randomly
named annotations and labels :-)
The question of 'safe migration' from istio or non-istio to ambient is
tricky - my understanding is that since the namespace label will move all
workloads to ambient automatically we have
confidence that Ambient can be safely adopted without traffic loss or pod
restarts - so we shouldn't need a mode where user labels individual pods
for ambient, then namespaces, then cluster.
Less options we document - easier to support them long term and keep things
simple for user.
If we find that iterating thru namespace and enabling ambient has problems

we can revisit.

If the namespace is labeled with istio.io/dataplane-mode=ambient, we
iterate thru every pod in that namespace, skip the ones that have
sidecars/sidecar inject labels, and skip the ones that have the separate
annotation ambient.istio.io/redirection: disabled.
2.
Or, if a new pod spawns in that namespace, we do the same.
3.
For the rest, we then physically add them to the mesh (perform traffic
capture), and on success, the CNI applies the annotation
ambient.istio.io/redirection: enabled (note, this is the same
annotation that we currently tell users to apply as intent, if they
want to disable capture, which is confusing and nonintuitive.
Until (3), the pod has user intent in the form of a label, but is not
actually part of the mesh. The CNI adding the annotation
ambient.istio.io/redirection: enabled is the authoritative signal.
Since the label is intent, we are already looking at every pod. It doesn't
change the internal API or implementation to use the label for pods as well
as namespaces, it is simply a UX convenience. It is logical and intuitive
that you can express intent with a label for a pod or namespace, and it
doesn't change what Istio or the CNI actually does in any meaningful way.
The user should never apply ambient.istio.io/redirection: enabled to a
pod. Yet, they try, because it is intuitive to them that they should be
able to do this operation. Thus, this PR, to allow them to express that
intent with the label.
Ultimately, no one but istio should ever apply
ambient.istio.io/redirection to anything, and the fact that people try,
and that we tell them to use one label to include and another annotation to
exclude (but not to include!) is just needlessly baroque.
For the port exclusion - it would be ideal to use the API we already have
(the annotations) at least as a starting point.
If we want this we do need an API, but none of the existing annotations
can be safely overloaded to support this. If we wanted to add an API for
this, I would prefer to follow label is intent, annotation is status
guide and make port exclusions a user-applied label.

Labels are an API. Annotations are an API too.  And what we document to the
user is the de-facto API - we need to treat it as such, with the
understanding that any change will be very painful for users.
Message ID: @.***>

I know how it works internally. The question is what do want the UX to be for the user, and how to keep it simple and supportable long term. As a user, I should be able to: 1. enable ambient in the entire cluster - that's the ideal and simplest case for fresh clusters. 2. enable ambient in a namespace - with ability to opt out specific pods.

If it's "blanket opt-in, selective opt-out" versus "blanket opt-out, selective opt-in", I don't see a reason to not support both, since it's trival to support both, it follows k8s semantics, and it feels more natural to people who might want to dip their toes in and not change the defaults for an entire namespace.
I agree we want simple and supportable UX long term, believe me, but this is no more complex or unsupportable than the namespace label in practice. It's a very cheap bit of logical consistency, in this case (as you can see from the impl + tests).

For clusters with existing workloads, moving towards (1) How we deal with Istio sidecars is internal details and should not leak into 'API'.

Agree, and this PR is orthogonal to that.

IMO it would be great if the pod used a "istio.io/dataplane-mode=none" instead of the annotation ( or other data plane modes besides "ambient" ), for consistency. Implementation-wise it is easy to do a lot of things and have randomly named annotations and labels :-)

I may just create an issue for this, as the opt-out mechanism. I agree it seems nice and obvious to do this.

The question of 'safe migration' from istio or non-istio to ambient is tricky - my understanding is that since the namespace label will move all workloads to ambient automatically we have confidence that Ambient can be safely adopted without traffic loss or pod restarts - so we shouldn't need a mode where user labels individual pods for ambient, then namespaces, then cluster.

I agree that should be the default suggestion, for sure. But again, it's logical to say "I want to test one pod by labeling, oh that works, I have a better feeling about this, let me label the namespace" -> that should compose just as well, and we have no reason to stop someone from doing that. And they might reasonably assume they should be able to do that.

Less options we document - easier to support them long term and keep things simple for user. If we find that iterating thru namespace and enabling ambient has problems - we can revisit.

It's just as simple for us to support the same annotation on the pod as on the namespace (which the PR shows), and it directs people away from trying to use an annotation that won't work, when they dig for a way to do this (at least some of them already have).

Labels are an API. Annotations are an API too. And what we document to the user is the de-facto API - we need to treat it as such, with the understanding that any change will be very painful for users.

Agree, but there is no real cost to supporting the label in both spots. It doesn't create any gotchas for us (in fact, it makes things like istio.io/dataplane-mode=none easier and more frictionless to do in the future)

That being said, if you do object to this PR, I'll put it on the agenda for Wed to discuss.

I can live with that - in the big scheme of things and with all the
inconsistencies we have it's not so different.
Having a single label - dataplane-mode: MODE - with ambient, none, other
values (like sidecar, etc) would achieve the same result
but in a more elegant/clean way.
On Fri, Apr 26, 2024 at 3:23 PM Ben Leggett @.***>
wrote:

That being said, if you do object to this PR, I'll put it on the agenda
for Wed to discuss.
—
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/50683#issuecomment-2080189089, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAUR2SWAIZBUEFSXARUO5TY7LHUTAVCNFSM6AAAAABGZJAKN2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBQGE4DSMBYHE
.
You are receiving this because your review was requested.Message ID:
@.***>

Adding to Wed's agenda is good. This may be something to add if a lot of users asking for it. If ambient works well transparently for users, probably no need to enroll it per pod basis like sidecar has been.

Adding to Wed's agenda is good. This may be something to add if a lot of users asking for it. If ambient works well transparently for users, probably no need to enroll it per pod basis like sidecar has been.

Even if we do not enable per-pod, we still need disable per-pod and should not continue to use the annotation for that purpose, and will end up using this label for disable, but not enable - which feels weird.

Threw up https://github.com/istio/istio/issues/50736 to track the "we should not use the status annotation as a pod-level opt-out" thing that's been kicked around in this issue a bit.

Also a tiny detail - disable is needed, but also disabling disable.
One of the features of ambient is that it can't be easily bypassed ( like
sidecars ).
I am ok with per pod opt in if it's consistent with opt-out ( i.e. a single
label without the annotation).
On Mon, Apr 29, 2024, 10:25 Lin Sun @.***> wrote:

Adding to Wed's agenda is good. This may be something to add if a lot of
users asking for it. If ambient works well transparently for users,
probably no need to enroll it per pod basis like sidecar has been.
Even if we do not enable per-pod, we still need disable per-pod and should
not continue to use the annotation for that purpose, and will end up using
this label for disable, but not enable - which feels weird.
I'll add to the agenda
Agreed, disable is definitely needed and consistency would be good. Thank
you!!
—
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/50683#issuecomment-2083266902, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAUR2TNZQBDLRC367VVGSLY7Z7AHAVCNFSM6AAAAABGZJAKN2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBTGI3DMOJQGI
.
You are receiving this because your review was requested.Message ID:
@.***>

I could be wrong but this was not my re-collection of today's ambient meeting.
Please don't cherry pick this in 1.22 till I confirm with a few others in the meeting.

Thinking it over, seems no additional work to support this for waypoints, so I'm good for supporting this as a not common path.

/cherry-pick 1.22
This is needed for https://github.com/istio/istio/pull/50804, which is also getting CP'd

@bleggett: cannot checkout 1.22: error checking out "1.22": exit status 1 error: pathspec '1.22' did not match any file(s) known to git

In response to this:

/cherry-pick 1.22
This is needed for https://github.com/istio/istio/pull/50804, which is also getting CP'd

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/cherry-pick release-1.22

cc @linsun :point_up: (think we are good here but LMK if not)

Yep!! thanks for double checking!


Auto Changes (New Drivebase paths)

Are there any changes that weren't made in #66?

Are there any changes that weren't made in #66?

I think just rename auto paths to reflect file names, although the PR is so old we might be better off closing this one and doing that elsewhere.

Yeah, also rename auto paths to reflect file paths (6a56dd3) seems to have been included in fullAuto anyways.

All changes seem to have been included in the fullAuto PR


Create Mantella-Blog

Create Mantella-Blog to publish new features or changes in Mantella library.

This is now a milestone


File explorer does not move to selected file

Issue Type: Bug
When I use shortcut CTRL + P to open file, the file explorer will not move to that file.
Previosly when the file was open the file explorer would move to the file location...
VS Code version: Code - Insiders 1.32.0-insider (709bf352b12de8284683bef94cb5984129bfc776, 2019-02-08T14:50:08.266Z)
OS version: Linux x64 4.15.0-45-generic

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz (4 x 2936)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: disabled_softwaresurface_synchronization: enabled_onvideo_decode: unavailable_offwebgl: enabledwebgl2: enabled

Load (avg)
4, 4, 4

Memory (System)
23.08GB (0.36GB free)

Process Argv
--unity-launch

Screen Reader
no

VM
0%

Extensions (16)

Extension
Author (truncated)
Version

vscode-mjml
att
1.6.0

jsrefactor
cms
2.15.1

vscode-eslint
dba
1.8.0

mjml-syntax
dig
0.0.1

gitlens
eam
9.5.0

tslint
eg2
1.0.42

flow-for-vscode
flo
1.0.1

vscode-flow-ide
gca
1.2.0

beautify
Hoo
1.4.8

graphql-for-vscode
kum
1.13.0

Kotlin
mat
1.7.0

cpptools
ms-
0.21.0

vsliveshare
ms-
0.3.1151

vscode-react-native-storybooks
Ort
2.5.1

gitconfig
sid
2.0.0

vscode-react-native
vsm
0.8.0

Hmm not sure what was wrong, I experienced described behavior for couple of days, I closed / open the editor but it did not help. Today I tried to "Refresh explorer" function in editor and it started to work again.


switched packages from sys to util to avoid deprecation message

Just a quick update to avoid the deprecation message that 'sys' is now 'util'. According to the node changelog this change was made at 0.3.0.  Everything works with this update and there is not longer that annoying message.
Would be awesome if you could push this to npm as well. Thanks!

Hey, thanks for sending this over. Today I finally moved the branch "v2" over to master. I have removed all the sys references as well.
Also, this version is in npm under 'mu2'. Make sure to double check the new API changes.


Update neo4j.template.yaml

Issue #, if available:
Description of changes:
/do-e2e-tests
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/do-e2e-tests


Use Alabaster theme for docs

@jhamrick Do you have any idea why the Travis build for a30ea21 fails, but succeeds in 4e306d5, which only removes the link checking and spell checking? That suggests that one of those plugins is causing the issue, but I don't see how that's possible given that they seem to work fine on master.


Add user-configurable paths

Have you tested this with different locations for HAWCK_SHARE, HAWCK_CFG,
etc? I'm not 100% sure but I think the C++ code has some hardcoded assumptions
that need to be modified before this can be merged. I'll have to check that
first.
I also don't see the meson.build configuration for generating the output
files. E.g:
configure_file(
  input: 'hawck-install.sh.in',
  output: 'hawck-install.sh',
  install_dir: ...,
  configuration: ...
)

Have you tested this with different locations for HAWCK_SHARE, HAWCK_CFG,
etc? I'm not 100% sure but I think the C++ code has some hardcoded assumptions
that need to be modified before this can be merged. I'll have to check that
first.
I also don't see the meson.build configuration for generating the output
files. E.g:
configure_file(
  input: 'hawck-install.sh.in',
  output: 'hawck-install.sh',
  install_dir: ...,
  configuration: ...
)

Have you tested this with different locations for HAWCK_SHARE, HAWCK_CFG,
etc? I'm not 100% sure but I think the C++ code has some hardcoded assumptions
that need to be modified before this can be merged. I'll have to check that
first.

To be honest no, I haven't checked it at all beyond it building both with hardcoded paths and openSUSE defaults.
I had assumed the code always relied on ~/.local for the actual configuration files.

I also don't see the meson.build configuration for generating the output
files.

Silly me, forgot to add those to the commit. They are there now.

Have you tested this with different locations for HAWCK_SHARE, HAWCK_CFG,
etc? I'm not 100% sure but I think the C++ code has some hardcoded assumptions
that need to be modified before this can be merged. I'll have to check that
first.

To be honest no, I haven't checked it at all beyond it building both with hardcoded paths and openSUSE defaults.
I had assumed the code always relied on ~/.local for the actual configuration files.

I also don't see the meson.build configuration for generating the output
files.

Silly me, forgot to add those to the commit. They are there now.

I'm going to try out the Arch PKGBUILD on your fork, then do some grepping for hardcoded paths in the code. After I've confirmed that the PKGBUILD works, and that there are no hardcoded paths to change then we can merge this.
If I find any hardcoded paths then they should be modified by this pull request, so I'll post them here if I find them.

I'm going to try out the Arch PKGBUILD on your fork, then do some grepping for hardcoded paths in the code. After I've confirmed that the PKGBUILD works, and that there are no hardcoded paths to change then we can merge this.
If I find any hardcoded paths then they should be modified by this pull request, so I'll post them here if I find them.

The PKGBUILD works and I'm getting the exact same output for hawck-user-setup as before, so I'm going to merge it now.
PS: You'll also need post_install from https://aur.archlinux.org/cgit/aur.git/tree/hawck-git.install?h=hawck-git when packaging, it's kept as a submodule in bin/hawck-git/ and is executed by install.sh.

The PKGBUILD works and I'm getting the exact same output for hawck-user-setup as before, so I'm going to merge it now.
PS: You'll also need post_install from https://aur.archlinux.org/cgit/aur.git/tree/hawck-git.install?h=hawck-git when packaging, it's kept as a submodule in bin/hawck-git/ and is executed by install.sh.

PS: You'll also need post_install from https://aur.archlinux.org/cgit/aur.git/tree/hawck-git.install?h=hawck-git when packaging, it's kept as a submodule in bin/hawck-git/ and is executed by install.sh

Right, forgot about that one.
But in rpm one needs to do that by hand in %pre/%post/%preun/%postun. Can I just ignore it and implement it differently?

PS: You'll also need post_install from https://aur.archlinux.org/cgit/aur.git/tree/hawck-git.install?h=hawck-git when packaging, it's kept as a submodule in bin/hawck-git/ and is executed by install.sh

Right, forgot about that one.
But in rpm one needs to do that by hand in %pre/%post/%preun/%postun. Can I just ignore it and implement it differently?

@lgbaldoni Of course, as long as you make sure everything in post_install happens somehow then it should work the same.

@lgbaldoni Of course, as long as you make sure everything in post_install happens somehow then it should work the same.


icon issues on the development endpoint

Describe the bug
@alexander0042 I thought for currently if precipIntensity is above 0.02 mm/h then it would show the icon and it wouldn't show the possible text. This is what I'm currently seeing on the dev endpoint at the moment:
"currently": {
  "time":<PHONE_NUMBER>,
  "summary": "Possible Light Sleet",
  "icon": "cloudy",
  "nearestStormDistance": 216.31,
  "nearestStormBearing": 90,
  "precipIntensity": 0.217,
  "precipProbability": 0.11,
  "precipIntensityError": 0.04,
}

Live is showing the icon/summary as sleet. I assume because the probability is only 11% it's not showing the icon and adds the possible text?
Expected behavior
The currently icon should show the precipitation icon if intensity is greater than 0.02 mm/h regardless of pop
Actual behavior
The currently icon doesn't show the precipitation icon if intensity is greater than 0.02 mm/h and pop is less than 25%
API Endpoint
Development
Location
Ottawa, Ontario
Other details
No response
Troubleshooting steps

[X] I have searched this repository and Home Assistant Repository to see if the issue has already been reported.
[X] I have read through the API documentation before opening this issue.
[X] I have not included my API key anywhere in my issue.
[X] I have written an informative title.

This isn't related to the currently section but I did notice a few other misc bugs with the icon:
When I exclude NBM on both live and dev the precipitation icon shows when precipIntensity is 0. If I exclude HRRR then it shows that GFS/GEFS is showing precipitation for that hour. Taking a look at SpotWX shows that HRRR is forecasting precipitation for that hour but PW is showing 0.

{
  "time":<PHONE_NUMBER>,
  "summary": "Light Rain",
  "icon": "rain",
  "precipIntensity": 0,
  "precipProbability": 1,
  "precipIntensityError": 1.8629,
  "precipAccumulation": 0.158,
  "precipType": "rain",
  "temperature": 0.35,
  "apparentTemperature": -4.36,
  "dewPoint": 0.35,
  "humidity": 0.94,
  "pressure": 1009.92,
  "windSpeed": 13.63,
  "windGust": 25,
  "windBearing": 87.38,
  "cloudCover": 1,
  "uvIndex": 0,
  "visibility": 1.7,
  "ozone": 335.59
},

Another thing I noticed (had to exclude NBM and HRRR for this) is that if there there is enough precipitation to show the precipitation text, is enough to show the wind icon/text and is foggy then it shows the rain + wind summary with a fog icon. Looks a bit weird is all.
"time":<PHONE_NUMBER>,
"summary": "Possible Flurries and Breezy",
"icon": "fog",
"precipIntensity": 0.4429,
"precipProbability": 0.12,
"precipIntensityError": 0.0443,
"precipAccumulation": 0.0443,
"windSpeed": 32.3,
"visibility": 0.49,

@alexander0042 Noticed another issue this morning where the summary said Drizzle but icon was partly-cloudy-night
{
  "time":<PHONE_NUMBER>,
  "summary": "Drizzle",
  "icon": "partly-cloudy-night",
  "precipIntensity": 0.0797,
  "precipProbability": 0.25,
  "precipIntensityError": 0.0055,
  "precipAccumulation": 0.008,
  "precipType": "rain",
  "temperature": 1.61,
  "apparentTemperature": -5,
  "dewPoint": -0.86,
  "humidity": 0.83,
  "pressure": 1017.25,
  "windSpeed": 23.09,
  "windGust": 38.71,
  "windBearing": 238.78,
  "cloudCover": 0.77,
  "uvIndex": 0,
  "visibility": 16.09,
  "ozone": 312.75
},

I think because pop is exactly 25% it doesn't hit the possible check or the icon check so it falls back to the None icon check to set the icon.

Sorry for the radio silence! Crazy busy week, and so 2.5.0 got pushed 😢. Thanks for keeping track of everything and highlighting the issues with it, since it really, really helps. I'm going to go through the tags this weekend and put it all in, so I'll update then!

No worries. I fixed a few of the issues in my PR (feel free to change anything) but the I realised the fix for the current icon wouldn't work as it needs to be the first if statement. Also the generic precipitation texts have disappeared. I know these shouldn't appear but its there as a fallback in case it does happen.

@alexander0042 So the plan is to fix up those few issues and port the rest of the languages over to python and push it to the translations repo? If everything goes well the launch would likely be near the end of the week?

Sorry for the repeated pings here @alexander0042 but is there any estimate on when the development endpoint will come back up? It's been giving me 502 errors since yesterday morning:
{
    "message": "An invalid response was received from the upstream server"
}

Ok, a few thoughts here:

Since text is now using rain/snow/ice accumulations to determine an icon, unknown precipitation can never occur (at least in theory), so I think leaving it out continues to make sense.
re: possible threshold, a couple things. It's currently coded as "if POP is =<25% OR between 0 and 0.4 mm/h", so that's why possible is in the text.

re: the icon, it's set so it only occurs if  "if POP is > 25% and greater than 0.02 mm/h", so that's what led to the initial issue.
However, I kind of like using POP for hourly, since I think that it's useful information. Your current solution of overriding pop is great, and the only change adding a possible threshold, since using the light rain threshold is too high. I've also adjusted the POP threshold from 25% to 20%, since I think 25% was a little high.

re: HRRR precipitation. This one is from HRRR accumulation giving different results than HRRR precipitation rate. I believe that's to be expected, but it's been so long since I've looked at the raw data, so want to double check this one.
re: fog icon, I've been mulling over the "priority" order of the icons, since it's a tricky sort of question. The text makes sense, and so it's question of "should fog outrank windy". I don't know if that is always true, but I think so in most case, so ok leaving it for now.
Great catch and fix on the "exactly" 25% issue, that seems like it was it.
See above, but it's a really good question. Maybe some sort of threshold approach would make sense, like if wind is above medium threshold use the wind icon, otherwise use the fog icon?

I'm going to quickly double check those HRRR values before release, but definitely improved a few things here!

Since text is now using rain/snow/ice accumulations to determine an icon, unknown precipitation can never occur (at least in theory), so I think leaving it out continues to make sense.

Still might be a good idea to have it anyway on the off chance that it might happen.

re: possible threshold, a couple things. It's currently coded as "if POP is =<25% OR between 0 and 0.4 mm/h", so that's why possible is in the text.

re: the icon, it's set so it only occurs if  "if POP is > 25% and greater than 0.02 mm/h", so that's what led to the initial issue.
However, I kind of like using POP for hourly, since I think that it's useful information. Your current solution of overriding pop is great, and the only change adding a possible threshold, since using the light rain threshold is too high. I've also adjusted the POP threshold from 25% to 20%, since I think 25% was a little high.

So if the precipitation is between 0-0.4 and less than 20% the possible text is shown? So if for an hour there's 1.5 mm rain forecasted and only a 20% chance then it doesn't show the possible text and uses fog/wind/cloud text/summary instead?

re: fog icon, I've been mulling over the "priority" order of the icons, since it's a tricky sort of question. The text makes sense, and so it's question of "should fog outrank windy". I don't know if that is always true, but I think so in most case, so ok leaving it for now.

See above, but it's a really good question. Maybe some sort of threshold approach would make sense, like if wind is above medium threshold use the wind icon, otherwise use the fog icon?

It might make sense for the fog icon to show if the wind threshold is below the medium wind threshold? If the visibility is low enough for fog and windy enough for the breezy text then the visibility obstruction likely isn't fog.

@alexander0042 I'm noticing on the dev endpoint that sometimes precipAccumulation has more than four decimal points on the daily block.
I don't have an example on-hand this morning but I did notice on the weekend that there were a few cases of an hour having zero precipIntensity but precipAccumulation greater than zero. In that case the text showed the possible precipitation text when I don't think it should? Probably should have the accumulation set to zero if there's no intensity?


Two word translations not working

The only two word translation currently in geeksay.js is not found: 404. This however will be translated to "! found".

[ ] Create a function to check for two word translations and give them priority over one word translations.

I am interested in this one, can I be assigned?

@nigel0511 want to work on it ?

Hey there @dk3775 , I could start working on this if it's ok with you!

Yea sure you are good to go!

This issue is solved by PR #410 from @fabio-mancin and is now closed.


ShellLauncher V2 script issue

I am attempting to use the powershell WMI bridge helpers and the provided xml script in Windows 10 b1909.
I have tried various ways of escaping the unescaping the xml.  The result is the same.
My command, run from PS in system context:
PS C:\Windows\system32> Set-ShellLauncherBridgeWMI -Filepath .\ShellLauncherSid2.xml
The bridge script throws this message:
Set-CimInstance : A general error occurred that is not covered by a more specific error code.
At C:\Windows\system32\ShellLauncherBridgeWmiHelpers.ps1:17 char:5
Set-CimInstance -CimInstance $AssignedAccessCsp

    CategoryInfo          : NotSpecified: (MDM_AssignedAcc..../Vendor/MSFT"):CimInstance) [Set-CimInstance], CimExce
   ption
    FullyQualifiedErrorId : MI RESULT 1,Microsoft.Management.Infrastructure.CimCmdlets.SetCimInstanceCommand

I also got this error on a patched Windows 10 1809 build.

Sorry, This replay almost an year late.
Main reason for the error message, is due to either syntax in xml or error in xml format itself.
Did u check the xml for any errors? any missing tags?.
Edit the xml in Visual studio and fix errors.


feat: Add CommonCallParams

Related Issue: https://github.com/Mirascope/mirascope/issues/667

@willbakst
Your suggested idea was to add a from_common method to {Provider}CallParams.
However, since {Provider}CallParams is a TypedDict, we cannot add methods to it.
Therefore, I've prepared separate functions get_{provider}_call_params_from_common instead.
The implementation uses Unpack with TypedDict to provide type-safe keyword arguments while maintaining the same convenient interface you envisioned with the original from_common approach.


[feature] Easy way to set OwnerReferences in operands

It's an extremely common practice while developing operators to leverage the k8s GC to remove resources.
Usually when a user creates a new CR the relevant operands created by the operator will be referencing it as OwnerReference, it's a best practice and widespread in operators development.
Examples:

Keycloak
Cloudflow
Strimzi

It would be nice if we provide something out-of-the-box in the SDK to encourage and ease this common practice.
Bonus: if a similar mechanism can be used to set common Labels too.

Note that owner references are automatically handled by the dependent resources support by default. You can also configure your dependent to opt-out of being owned if needed.

Currently HasMetadata.addOwnerReference to do this manually. As @metacosm mentioned Dependent Resources will support this, that is the only layer I guess we can do this under the hood.


Allow format filtering on finder publisher schemas

We are moving the rendering app of the people page from whitehall to finder-frontend. In doing so, we are writing a JSON file to represent the new finder page. In that schema, we have to describe how are we going to filter the data for the finder page.
In rummager, we need to use the format so that the finder page gets populated with people (this is because the document_type of a person is an edition and the format is person).
Here is an example query: https://www.gov.uk/api/search.json?filter_format=person
This PR make is possible to filter data by format in finders.
Trello: https://trello.com/c/reCVyzpg/259-migrate-the-people-page-to-a-finder

This PR is waiting on a PR in manuals-publisher so that the tests pass.


Fixes Prototype Pollution vulnerability in Handlebars dependency

Summary
jest-cli is affected by a vulnerability published today on NPM: https://www.npmjs.com/advisories/755

This updates the offending package istanbul-api and subsequently istanbul-reports to the version needed to no longer have the handlebars vulnerability.
Test plan
I used yarn upgrade<EMAIL_ADDRESS>in the directory jest/packages/jest-cli

Thanks @tonycassara!

Note that since the new version is in semver range, you don't need to wait for Jest to publish a new version to avoid the vulnerable dependency - just upgrade locally and make sure it's in your lockfile

Cool thanks @SimenB ! Will make those changes locally.

npm upgrade handlebars --depth Infinity or yarn upgrade handlebars should do it 🙂

That worked perfectly thank you


About us section is looking very bad

Describe the bug
It is looking like this.

which is very bad
Expected behavior
It should look like this

It's fixed by older issue.


Add confirmation window options

Hey,
First off, big shoutout to everyone involved in this project – I love it !
I'm a bit more used to [Y]es or [N]o rather than [O]k or [C]ancel tho, so I thought it would be cool to make both the labels and key mappings configurable to suit different preferences.
I dont have a lot of experience in lua so i don't know if this PR respects good practices (especially regarding the mergeTables fn).

Hi, I also wanted this feature, so I implemented it myself https://github.com/stevearc/oil.nvim/compare/master...jedrzejboczar:oil.nvim:jb/confirm-dialog-config and then I checked existing PRs just to realize that someone else has already created such a PR. So basically I am all for merging this PR :)
What's funny is that my implementation is almost identical, even the naming of config options is similar. The main difference that I would suggest is to use nowait = true for the mappings (e.g. I want to use y for "[Y]es", but it waits for yank movement). I also decided to have "special" cancel keys ({ "q", "<C-c>", "<Esc>" }) explicitly in config, but this doesn't seem too important.

I dont have a lot of experience in lua so i don't know if this PR respects good practices (especially regarding the mergeTables fn).

As these tables are Lua lists (only numeric keys starting from 1) it would be simpler to use vim.list_extend, e.g.
local cancel_keys = vim.list_extend({ "q", "<C-c>", "<Esc>" }, config.confirmation.cancel.keymaps)

Note that vim.list_extend modifies the first table in-place and then returns it.

Thanks for your help  @jedrzejboczar
i updated the pr to include nowait = true and vim.list_extend : good call!

I also decided to have "special" cancel keys ({ "q", "", "" }) explicitly in config, but this doesn't seem too important.

My original thought was that those mappings are "expected" to work to cancel an action or close a window but i think you are right on this.
The whole point of this pr is to fit every one preferences so it makes sense to make them configurable too.
Maybe they should be behind a boolean flag tho, to avoid rewriting them on each config?
Something like
  confirmation = {
    confirm = {
      text = "[O]k",
      keys = { "O", "o" },
    },
    cancel = {
      text = "[C]ancel",
      keys = { "C", "c", },
      -- use "q", "<C-c>" and"<Esc>" cancel mappings
      use_defaults = true
    },
  },

Maybe not the best naming.
Let me know your thoughts on this

I pulled this locally to poke around and here's my proposal: instead of making this configurable, what about just changing the defaults to Yes/No? I've pushed back on doing this before, but I'm willing to abandon my original reasoning and accept this as a reasonable default.
But once that is the default, is there any reason to customize it? I don't think most people would want to change it to something else. What do you think?

Thanks for taking the time to test it.
Allowing for configuration (like you did in #39beb36) is a bit better imo.
But if you don't want the config options becoming heavier it's understandable and fully transitioning to yes/no makes sense then.

@omelette-watin why do you think that allowing for configuration is better? Do you have a use case for different labels/keymaps?

@stevearc in my opinion, giving option for configuration presents the advantage to avoid similar pull requests on the future for some other use cases that some users might have
The only drawback that i see is a bit heavier config.
But, as i said i’m really happy with your full transition to yes/no, so if you just to keep it like that it’s fine by me!
Anyway, thanks for taking the time to answer this pr and for this amazing plugin !

I'd also vote for leaving configuration options, for the same reason - avoiding issues like this from users. While I don't think that it is very important to have configurable labels, I'd say it is good to have configurable keymaps. It would probably be best to have something like vim.ui.confirm in the core, similar to vim.ui.input/select to give users a standard interface for a binary decision that is selected with a single key press. There is vim.fn.confirm and if using noice.nvim it looks quite good (popup), but this still cannot be customized by the user. I would be also fine with hacking some autocmd to change the keymaps myself, but it seems not possible - the windows use ft=oil_preview and there is no confirm/cancel api to bind to.
But it's also completely fair if you just want to avoid more configuration options.

I'm already a little unhappy with the amount of configuration options that oil has, and I really want to avoid adding more where it's not necessary. I don't think anyone will want the labels to change from the new values, and the keymaps can be adjusted on the user side, as explained in this comment on an earlier issue.
https://github.com/stevearc/oil.nvim/issues/114#issuecomment-1571332722
I'll merge as-is for now. If a strong need arises in the future to add configuration options, I'll reconsider at that time.
Thanks for the PR!


gulp babel-lib can't run via syntax error

On master:
$ gulp babel-lib
[11:44:14] Using gulpfile ~/mysrc/weisjohn/mojs-player/gulpfile.js
[11:44:14] Starting 'babel-lib'...
[11:44:15] Plumber found unhandled error:
 SyntaxError in plugin 'gulp-babel'
Message:
    /Users/john/mysrc/weisjohn/mojs-player/js/mojs-player.babel.js: Unexpected token (504:20)
[11:44:15] Finished 'babel-lib' after 974 ms

I notice there's no .babelrc file in the repo, maybe that's related?

Hey @weisjohn, sorry for the inconvenience! gulp is actually redundant for this repo, so we need remove it completely.


Don't Merge! PR real time test for source branch full build

Docs Build status updates of commit 86505da:
:clock10: Full build: the average full build time is 6 min(s) 7 sec(s), this is based on the last 262 build(s) for this repository.
:warning: This is a FULL build due to a configuration change (usually in .openpublishing.publish.config.json and/or docfx.json). It is strongly suggested to merge this configuration change after the business hours, as it could impact the overall build performance of other PRs on the 'pr-basebranch' branch. For more detailed info, please click here.

Docs Build status updates of commit 86505da:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details
Dependent Files

docfx.json
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Construct static maps at runtime instead of compile time

This moves static map construction into init() as a workaround for https://github.com/golang/go/issues/33437
The first commit (ffa75edc06ba19646f2ce84db8d6c64c25264b56) updates the template and can be reviewed individually.
The next commit regenerates data with go run scripts/codegen/*.go.
Fixes https://github.com/markusmobius/go-dateparser/issues/7.

Hey, thanks! I haven't encountered this issue, but I guess it's happened because of 95121ad.
It looks good, but it would be better if all locale variables declared first. That way, we only need one single init function per file to populate those variables.


#[derive(TS)] and associated types

In the following code, #[derive(TS)] generates a T: TS bound even though T is never used, only its associated types:
trait MyTrait {
    type U: TS;
}

#[derive(TS)]
struct MyStruct<T: MyTrait> {
    u: T::U,
}

fn test() {
    struct X;

    impl MyTrait for X {
        type U = i32;
    }

    // error: the trait bound `test::X: ts_rs::TS` is not satisfied
    <MyStruct<X> as TS>::export();
}

I would expect the above example to compile because i32 implements TS.
It looks like the derive macro generates the following:
impl<T: MyTrait> ts_rs::TS for MyStruct<T>
where
    T: ts_rs::TS,
{
    ...
}

In general, instead of adding bounds for each type parameter, #[derive(TS)] could add bounds for each field:
#[derive(TS)]
struct S {
    a: A,
    b: B,
    c: C,
}

impl ts_rs::TS for S
where
    A: ts_rs::TS,
    B: ts_rs::TS,
    C: ts_rs::TS,
{
    ...
}

Alternatively, #[ts] could support a bound attribute like serde: #[ts(bound = "")]

Hey!
This is a known limitation (we should probably document that somewhere).
Besides the technical reasons we currently don't support this, it's also unclear to me what we should generate for types containing associated types of a trait.
The only thing we could do is let you export a concrete instance of MyStruct to a non-generic typescript type.
However, TS currently requires that we can just export the type without any additional information. If the type is generic, then we generate a generic TypeScript type.
In this example, it's the implementation of TS::decl() trying to generate a generic TypeScript definition that causes the compiler error you see. The function which would give you the concrete (non-generic) TypeScript definition is TS::decl_concrete(), but if the thing doesn't compile, that doesn't matter.

If, at some point, we get const-generic &'static str on stable, something like this would work:
trait MyTrait {
    type U: TS;
}

#[derive(TS)]
struct MyStruct<T: MyTrait> {
    u: T::U,
}

impl<const NAME: &'static str> MyTrait for ts_rs::Dummy<NAME> {
    type U = i32;
}

Then, MyStruct::<Anything>::decl() would always yield
type MyStruct<T> { u: number };

no matter what Anything is.

@NyxCode That makes sense, thank you! What do you think about an attribute to ignore a generic parameter?
#[derive(TS)]
struct MyStruct<#[ts(skip)] T: MyTrait> {
    #[ts(as = "i32")]
    u: T::U,
}

For context, my use case is a compiler whose data structures are generic over a Driver:
trait Driver {
    type Info;
    ...
}

struct Expression<D: Driver> {
    info: D::Info,
    kind: ExpressionKind<D>,
}

enum ExpressionKind<D: Driver> {
    String(String),
    Number(i32),
    Call(Box<Expression<D>>, Vec<Expression<D>>),
    ...
}

But my TypeScript interface to this compiler always uses the same driver, so Info is always the same type (TsInfo) when the compiler is used via TypeScript. With the design above, I could use #[ts(skip)] on Expression and #[ts(as = "TsInfo")] on info. That way, my Rust code can remain generic over the driver while my TypeScript API ignores the driver altogether.
Let me know what you think!

I played with the idea of introducing #[ts(concrete = "SomeType")].
With it, your example would look like this:
trait Driver {
    type Info: TS; // (1)
}

struct TsDriver;
impl Driver for TsDriver {
    type Info = String;
}

#[derive(TS)]
struct Expression<#[ts(concrete = "TsDriver")] D: Driver> {
    info: D::Info,
}

(1): Ideally, this trait bound wouldn't be necessary, but it currently is.
I've put together a proof-of-concept here. There are a lot of edge-cases this just glosses over, but it's a start.
Could you give that branch a go and see if that's already enough for your use-case?

@NyxCode This is pretty much what I need! The only issue is that as of this change, ts-rs generates a private struct for the type parameter that I can't implement the trait for, so I get this error:
use ts_rs::TS;

trait Driver {
    type Info;
}

#[derive(TS)]
struct TsInfo;

impl Driver for ts_rs::Dummy {
    type Info = TsInfo;
}

#[derive(TS)]
struct Expression<D: Driver> {
    #[ts(as = "TsInfo")]
    info: D::Info,
}

error[E0277]: the trait bound `<Expression<D> as ts_rs::TS>::decl::D: Driver` is not satisfied
  --> src/lib.rs:14:10
   |
14 | #[derive(TS)]
   |          ^^ the trait `Driver` is not implemented for `<Expression<D> as ts_rs::TS>::decl::D`
   |
   = help: the trait `Driver` is implemented for `ts_rs::Dummy`
note: required by a bound in `Expression`
  --> src/lib.rs:15:22
   |
15 | struct Expression<D: Driver> {
   |                      ^^^^^^ required by this bound in `Expression`
   = note: this error originates in the derive macro `TS` (in Nightly builds, run with -Z macro-backtrace for more info)

Would removing the trait bounds on that generated struct fix the issue?

@NyxCode Whoops – I forgot to add the #[ts(concrete)] attribute, haha! It works great with that!

@NyxCode The only issue I'm getting now is when I add in serde — the ts attribute isn't being removed:
use serde::{Deserialize, Serialize};
use ts_rs::TS;

trait Driver {
    type Info: TS;
}

#[derive(TS)]
struct TsInfo;

impl Driver for ts_rs::Dummy {
    type Info = TsInfo;
}

#[derive(Debug, TS, Serialize, Deserialize)]
#[ts(export)]
struct Expression<#[ts(concrete = "ts_rs::Dummy")] D: Driver> {
    info: D::Info,
}

error: cannot find attribute `ts` in this scope
  --> src/lib.rs:17:21
   |
17 | struct Expression<#[ts(concrete = "ts_rs::Dummy")] D: Driver> {
   |                     ^^

Putting TS before Serialize, Deserialize doesn't seem to fix it either.

I forgot to add the #[ts(concrete)] attribute, haha! It works great with that!

Awesome!
You could get rid of the #[ts(as = "..")] and put a trait bound on Driver::Info instead.
While in theory neither should be necessary, getting rid of that requirement would be pretty messy.
I also just pushed an other commit, and now #[ts(export)] works as expected.
While the branch definetely needs a lot of cleanup, it's nice to see that this could be a solution to this issue.

The only issue I'm getting now is when I add in serde — the ts attribute isn't being removed:

Oh, that's very interesting! No clue what's going on here, will have to look into that.

Hm. Seems like serde is copying the #[ts(concrete = "..")] attributes over into it's impl Serialize. That's not good.
Unless there's some way to prevent that, we'll have to change the syntax, maybe to
#[derive(TS)]
#[ts(concrete(B = TsDriver)]
struct Expression<A, B: Driver> { }

(serde#2710)

@NyxCode Looks like changing the attribute to be on the struct instead of the generic parameters is the way to go — see https://github.com/dtolnay/syn/issues/422.

@NyxCode I just opened https://github.com/Aleph-Alpha/ts-rs/pull/262 to make the attribute be on the type instead of the generic parameters!


net:server/2 with forall/2

When using net:server/2 with forall/2, it will cause ABORT_INVALIDARGNOTVAR error, and also with a memory error.
:- initialization(main).

main :-
        net:server(['<IP_ADDRESS>:8000'], S),
        forall(
                repeat,
                (
                        http:parse(S, _, _, Path),
                        write(S, 'HTTP/1.1 404 Not Found\r\nContent-Length: 0\r\n\r\n')
                )
        ),
        halt.

Trace output:
...
Call: ... (http:parse(0x7F085C000F90, 1.1, _3, _4),write(0x7F085C000F90, 'HTTP/1.1 404 Not Found\r\nContent-Length: 0\r\n\r\n'))
Call: ... http:parse(0x7F085C000F90, 1.1, _3, _4)
ERROR: ABORT_INVALIDARGNOTVAR
*** abort: running

Core dump backtrace:
Core was generated by `tpl --trace foo.pro'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f0863d47700 (LWP 20937))]
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007f08647813fa in __GI_abort () at abort.c:89
#2  0x00007f08647bdbd0 in __libc_message (do_abort=do_abort@entry=2,
    fmt=fmt@entry=0x7f08648b2dd0 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007f08647c3f96 in malloc_printerr (action=3, str=0x7f08648b2e98 "double free or corruption (out)",
    ptr=<optimized out>, ar_ptr=<optimized out>) at malloc.c:5049
#4  0x00007f08647c47de in _int_free (av=0x7f0864ae6b00 <main_arena>, p=0x7f085c001430, have_lock=0) at malloc.c:3905
#5  0x0000562a81294a1b in query_destroy (q=0x7f085c0008c0) at src/trealla.c:1268
#6  0x0000562a81304e47 in process_restart_handler (data=0x7f085c0008c0) at src/bifs_proc.c:59
#7  0x0000562a812ff9bf in net_callback (s=0x562a829068b0, data=0x562a82903090) at src/bifs_net.c:195
#8  0x0000562a8131228b in epoll_close (data=0x562a829068b0) at src/network.c:1664
#9  0x0000562a813143e9 in start_routine (t=0x562a829050e0) at src/thread.c:159
#10 0x00007f0864af3494 in start_thread (arg=0x7f0863d47700) at pthread_create.c:333
#11 0x00007f0864835aff in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
(gdb)

Following the call to server it is in a sub-process. When there is no data,
parse will fail causing forall to finish, which then calls halt. And I
don't think you can call halt from a sub-process. Maybe exit. Crashing is a
bit harsh though.
If you want to avoid the repeat/process/fail approach the code will need
to be different. I will look into it.
On Sun, Jul 16, 2017 at 12:22 PM, Xin Wang<EMAIL_ADDRESS>wrote:

When using net:server/2 with forall/2, it will cause
ABORT_INVALIDARGNOTVAR error, and also with a memory error.
:- initialization(main).
main :-
net:server(['<IP_ADDRESS>:8000'], S),
forall(
repeat,
(
http:parse(S, _, _, Path),
write(S, 'HTTP/1.1 404 Not Found\r\nContent-Length: 0\r\n\r\n')
)
),
halt.
Trace output:
...
Call: ... (http:parse(0x7F085C000F90, 1.1, _3, _4),write(0x7F085C000F90, 'HTTP/1.1 404 Not Found\r\nContent-Length: 0\r\n\r\n'))
Call: ... http:parse(0x7F085C000F90, 1.1, _3, _4)
ERROR: ABORT_INVALIDARGNOTVAR
*** abort: running
Core dump backtrace:
Core was generated by tpl --trace foo.pro'. Program terminated with signal SIGABRT, Aborted. #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 51      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. [Current thread is 1 (Thread 0x7f0863d47700 (LWP 20937))] (gdb) bt #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1  0x00007f08647813fa in __GI_abort () at abort.c:89 #2  0x00007f08647bdbd0 in __libc_message (do_abort=do_abort@entry=2,     fmt=fmt@entry=0x7f08648b2dd0 "*** Error in %s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007f08647c3f96 in malloc_printerr (action=3, str=0x7f08648b2e98 "double free or corruption (out)",
ptr=, ar_ptr=) at malloc.c:5049
#4  0x00007f08647c47de in _int_free (av=0x7f0864ae6b00 <main_arena>, p=0x7f085c001430, have_lock=0) at malloc.c:3905
#5  0x0000562a81294a1b in query_destroy (q=0x7f085c0008c0) at src/trealla.c:1268
#6  0x0000562a81304e47 in process_restart_handler (data=0x7f085c0008c0) at src/bifs_proc.c:59
#7  0x0000562a812ff9bf in net_callback (s=0x562a829068b0, data=0x562a82903090) at src/bifs_net.c:195
#8  0x0000562a8131228b in epoll_close (data=0x562a829068b0) at src/network.c:1664
#9  0x0000562a813143e9 in start_routine (t=0x562a829050e0) at src/thread.c:159
#10 0x00007f0864af3494 in start_thread (arg=0x7f0863d47700) at pthread_create.c:333
#11 0x00007f0864835aff in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
(gdb)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/trealla-lang/trealla/issues/222, or mute the thread
https://github.com/notifications/unsubscribe-auth/AVqpEmRqP42vozdElFHdPNTrWQOlPWC6ks5sOXPvgaJpZM4OZLZ8
.

According to the --trace output, it has been backtracked, but failed with ABORT_INVALIDARGNOTVAR error, first argument to http:parse is no longer a free variable. which I can not understand why, is that related to subprocess?

If you add the new
net:set_socket(S, [block(true)]),

after the net:server call, it now works.
Server sockets are non-blocking by default (to prevent thread starvation). But there is still a problem with non-blocking sockets in this scenario. It will take more looking into.


Generate random password

Fixes https://github.com/go-gitea/gitea/issues/4931

[x] Added a new cli flag -random-password
[x]  Generate a random password with generate.GetRandomString

Thoughts ?

Codecov Report

Merging #5023 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #5023      +/-   ##
==========================================
+ Coverage   37.41%   37.41%   +<.01%
==========================================
  Files         306      306
  Lines       45374    45374
==========================================
+ Hits        16975    16976       +1
- Misses      25945    25946       +1
+ Partials     2454     2452       -2

Impacted Files
Coverage Δ

models/repo_list.go
61.76% <0%> (-1.18%)
:arrow_down:

models/repo_indexer.go
52.11% <0%> (+1.27%)
: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 378af8e...bb7a965. Read the comment docs.

If implemented sending email should probably be optional with special flag

If implemented sending email should probably be optional with special flag

Will add that

@lafriks I couldn't get emails to work... Would work on that and send another PR in the future


New ClassInstantiation sniff to WordPress-Extra.

New sniff to verify that objects being instantiated comply with some basic rules:

Always use parenthesis.
Don't have spaces (or comments) between the class name and the parenthesis.
Don't assign new by reference (PHP only).

Sniffs both PHP as well as JS code.
Auto-fixes missing parentheses and space between class name and parentheses.
Includes unit tests.
Currently doesn't handle cases of object instantiations where the class name is held in a variable variable.
Fixes #919

Looks good. Were you planning to send this upstream?

@jrfnl For the record, is there a particular reason why variable variable class names are not supported?

Were you planning to send this upstream?

@GaryJones Potentially this could be pulled upstream at some point, though without the assigning by reference check.

For the record, is there a particular reason why variable variable class names are not supported?

@JDGrimes Yes there is. Variable variables can take a lot of forms and it would take a lot of code to attempt to reliably detect whether the class is instantiated with or without parenthesis in that case. It also would most likely still lead to false positives with the sniff getting confused over whether parentheses are part of the variable variable or for the object instantiation.
See https://github.com/wimg/PHPCompatibility/blob/master/PHPCompatibility/Tests/sniff-examples/variable_variables.php for some examples of what would need to be covered.


Update english.txt

curl -s 'https://github.com/stopwords-iso/stopwords-iso/raw/master/stopwords-iso.json' | jq '.en' | grep '"' | cut  -d\" -f 2

Thanks, @Alir3z4! Can you push the latest version of https://github.com/Alir3z4/python-stop-words to PyPI?