Cannot fetch artifact 'javax.ws.rs:javax.ws.rs-api:2.1' from Maven

The maven artifact javax.ws.rs-api with version 2.1 uses POM profiles in an exotic way to set the property ${packaging.type} which is used to set the packaging-type (usually JAR or BUNDLE).
As you can see, even the Download-button at mvnrepository.com is broken:
https://mvnrepository.com/artifact/javax.ws.rs/javax.ws.rs-api/2.1
Nonetheless, the POM file seems to be valid and Oracle (the author) has no intention to change the POM file in a way that Gradle can parse it correctly. See the closed issue here: https://github.com/jax-rs/api/issues/571
As the artifact is an extremely common one (just not in this version yet), I am sure this will soon affect a lot of users.
Gradle 4.2 throws this error when trying to retrieve this dependency:

> Could not determine artifacts for javax.ws.rs:javax.ws.rs-api:2.1
   > Could not get resource 'http://OUR_LOCAL_REPO/repository/maven-central/javax/ws/rs/javax.ws.rs-api/2.1/javax.ws.rs-api-2.1.$%7Bpackaging.type%7D'.
      > Could not HEAD 'http://OUR_LOCAL_REPO/repository/maven-central/javax/ws/rs/javax.ws.rs-api/2.1/javax.ws.rs-api-2.1.$%7Bpackaging.type%7D'. Received status code 500 from server: javax.servlet.ServletException: java.lang.IllegalArgumentException: Illegal character in path at index 54: /javax/ws/rs/javax.ws.rs-api/2.1/javax.ws.rs-api-2.1.${packaging.type}

Maven doesn't support this either, it just ignores the fact that it doesn't know what that packaging type means and goes looking for a 'jar' by default. This is probably what we should do as well.
Would you be interested in sending a pull request?
Also, since this POM is broken, even by Maven standards, I encourage you and all other Jax-RS users to ask Oracle for a proper POM in the next patch release.

@ChristianCiach I see you're active in the Swagger group as well. As of the jersey-swagger-2.x-rc2 release I'm seeing the same jax-rs issue. Would it be useful to log an issue in the swagger-api/swagger-core github repository issue tracker here? https://github.com/swagger-api/swagger-core

Actually, I encountered this issues while trying to use Swagger 2 RC2. I don't think it would be much use to log an issue there, as it is absolutely not their fault.

Maven doesn't support this either, it just ignores the fact that it doesn't know what that packaging type means and goes looking for a 'jar' by default. This is probably what we should do as well.

Are you sure about this? I am no maven expert, but according to my research POM supports variable substitution based on conditional profiles.
The stripped down POM of javax.ws.rs-api looks like this:
<project>
    <packaging>${packaging.type}</packaging>
    <profiles>
        <profile>
            <activation>
                <jdk>(,9)</jdk>
            </activation>
            <properties>
                <packaging.type>bundle</packaging.type>
            </properties>
        </profile>
    </profiles>
</project>

As you can see, packaging.type is set to "bundle" when jdk version is < 9. This is surely a very unusual way to determine the packaging type. But broken? I am not too sure about that...

Would you be interested in sending a pull request?

I encounter this issue in a work-related project, so I would rather not spend my spare time on that. Also, at work we are stuck using Gradle >= 2.14 and it doesn't seem like this branch of Gradle is still supported. Looks like I am stuck here :(

Even if it replaces the variable during resolution, it would end up with the unknown packaging type 'bundle'. The Maven bundle plugin has special logic which removes the bundle packaging from the published pom. But that doesn't work on the consumer side, only when publishing. So Maven consumers of this pom will see the unknown 'bundle'  type and default to 'jar'. I tried a pom with packaging type 'foobar' and it downloads the jar.
Unrelated, but please let us know in another issue why you are stuck on 2.14.
If anyone else is intersted in sending a PR, please let us know here.

@oehme
If I were to sending a PR, how do you propose to fix this?
The POMReader already falls back to jar if there is no packaging-element. In this case, there is one, just with the evil value of ${packaging.type}.
If we should fallback to "jar" in this case, it begs the question what the valid packaging-types are. Do you think we should fall back to "jar" if the parsed packaging type is not one of "jar", "ejb", "bundle", "maven-plugin", "eclipse-plugin", as defined in DefaultMavenModuleResolveMetadata.java, constant JAR_PACKAGINGS?

I think that would break 'war' packaging. One backwards compatible way would be to always try the jar if a custom one isn't found. Or be even more specific and only handle the case where the packaging type contains ${ and is thus known to be incorrect.

The second approach would be extremely easy to implement and should be just "good enough" for this special case.
In the long run I would like to see the possiblity to somehow manually define POM-variables inside the gradle files, like this in build.gradle:
dependencies {
	compile (group: 'org.glassfish.jersey.core', name: 'jersey-server', version: '2.26') {
		pomProperties = [
			'packaging.type': 'jar'
		]
	}
}

(I am not too sure about the syntax here. I know next to nothing about Groovy.)
This could be used to workaround similar issues in the future.

With some testing I was able to get jax-rs 2.1 resolved from gradle, but I can't explain why. When using our internal Apache Archiva repository (which fails with packaging-type issue), it attempts to get it from:
http://ourInternalServer:80/#artifact~internal/javax.ws.rs/javax.ws.rs-api/2.1
On the Archiva info tab, it lists "Packaging: bundle" (related?)
When I point point one of these repositories, it works:
https://repo.maven.apache.org/maven2/javax/ws/rs/javax.ws.rs-api/2.1/
or
http://central.maven.org/maven2/javax/ws/rs/javax.ws.rs-api/2.1/

@crizo23
Actually, that could be it! Over at https://github.com/jax-rs/api/issues/571 @ibaca says that he has no problem downloading this artifact from Maven using Gradle. That got me thinking:
I didn't look at the code, but what if Gradle actually falls back to "jar" if the first request returns a 404 (not found)? We are using an internal Maven-Proxy-Repo (Nexus), that doesn't return a 404, but a 501 (internal server error) because of an IllegalArgumentException, caused by the invalid character inside the url (${).
If I am right, the actual bug isn't the missing fallback zu "jar", but the missing URL-encoding of these special characters. This should be an easy fix.

Great analysis! I think you cut right to the problem.
I also looked through the code and see that we are already falling back to jar when we can't find the original packaging.

Sooooo, I guess the url escaping must happen in org.apache.ivy.core.IvyPatternHelper#substituteTokens. If we try to escape the resulting String of this method, it would escape the necessary slashes of the result path, too. This method seems like an odd place to do escaping, but I don't see any other way.

Same problem, to resolve it :
-> I excluded the dependency 'javax.ws.rs:javax.ws.rs-api:2.1' of 'org.glassfish.jersey.core' with :
compile ("org.glassfish.jersey.core:jersey-server:${jerseyVersion}"){
		exclude group:'javax.ws.rs'
}

-> I added manually the dependency 'javax.ws.rs:javax.ws.rs-api:2.1' with :
compile "javax.ws.rs:javax.ws.rs-api:2.1@jar"

I tried compile "javax.ws.rs:javax.ws.rs-api:2.1@jar" but I'm getting the same error. I'm in Eclipse, which I believe is using the Buildship plugin to bridge between Gradle and Eclipse. Perhaps it doesn't know what to do with the "@jar"?

@ChristianCiach IvyPatternHelper is not one of our classes, so we can't change that. But wherever we construct the URL to look for an artifact we should do the necessary escaping. Are you planning to send a PR for this one?

@crizo23 check all your depencies and exclude for all that have javax.ws.rs:javax.ws.rs-api in dependency the group:'javax.ws.rs' like this :
compile ("org.glassfish.jersey.core:jersey-server:${jerseyVersion}"){
    exclude group:'javax.ws.rs'
}

I had do this for all my jersey depencies

@dylanBehetre Thanks! Excluding it for each dependency worked.

Are you planning to send a PR for this one?

@oehme I would love to, but I have a hard time setting up the workspace and debug gradle. It seems I need IntelliJ for this, as I get circular dependency issues with Eclipse. This is fine, but I don't know how to execute Gradle inside a debugger. Could you drop me a hint?

You can debug tests in IntelliJ directly, our integration test infrastructure supports that out of the box.
If you want to do debug Gradle from the command line, you can add -Dorg.gradle.debug=true

@oehme Thanks, I figured it out in the meantime. You can expect a pull request shortly.

Awesome!

On further inspection, this "fault" is more with Tomcat than with Gradle. The URL that Gradle sends to the repository server is http://maven.our-internal-nexus:82/repository/maven-central/javax/ws/rs/javax.ws.rs-api/2.1/javax.ws.rs-api-2.1.$%7Bpackaging.type%7D, which is escaped correctly.
The real problem happens on the server-side. The reverse-proxy running in front of the application unencodes the URL and then passes the unencoded URL to the application. The application (in our case: Nexus Repository) then tries to construct a new URI(unencoded) with the already unencoded string, resulting in an IllegalArgumentException.
The fix that is working for me locally (and that I was about to push) encodes the path segments of the URL before constructing the final URL using these encoded path segments. This results in the path segments of the final URL to be double-encoded. This is working fine for me and likely will not break anything else. But I am not too sure about the last part...

It is not even the reverse-proxy. When I make a request to the nexus-server directly, without any proxy, the issue (IllegalArgumentException) persists:
curl -I http://localhost:8082/repository/maven-central/javax/ws/rs/javax.ws.rs-api/2.1/javax.ws.rs-api-2.1.$%7Bpackaging.type%7D

Unsurprisingly, my fix breaks the M2ResourcePatternTest:
Expected :prefix/##??::/projectA/1.2/ivys/1.2/ivy.xml

Actual   :prefix/%23%23%3F%3F::/projectA/1.2/ivys/1.2/ivy.xml

For reasons I can't comprehend the unit test expects the path segment ##??:: to appear in the final path unencoded. I don't know if this expectation is reasonable.

Disregard that, I have an idea.

Please see my pull request as a proposal. After much consideration I've chosen a very careful approach that hopefully doesn't break anything.
My fix tries to handle characters inside maven coordinates that are considered to be surely invalid by the (very unspecific) Maven naming conventions. This way I can completely avoid to handle any URI-related stuff, as these problems won't even arise with proper maven coordinates.
I've chosen to handle the invalid characters in M2ResourcePattern.java by introducing a CharMatcher that acts as a blacklist for characters that are absolutely not valid to use in any maven coordinates, such as groupId, artifactId and so on. At the moment I've blacklisted three characters: '$', '{' and '}'.
This rises the question: What should we do if we encounter such invalid coordinates? I think these are the options:

Just remove the offending characters.
Replace/escape them with something. But what to escape them with? Percent-encoding is out of the question, as the percent-character surely is invalid itself.
Throwing an IllegalArgumentException.

In general I would prefer the third option, but this should be done much ealier in the workflow, such as inside POMReader.java or when constructing an instance of MavenModuleResolveMetadata. In any way, throwing a RuntimeException would result in the same problem this github-issue tries to solve.
For the ease of implementation and lack of viable alternatives my commit goes with the first option: The offending characters are just removed from all attributes when constructing the path, thus avoiding the IllegalArgumentException thrown by repository server.
What are your thoughts?

Fixed on master

Hello guys,
I'm running in a very similar (probably just a development of the original) problem with Gradle 4.4.1 and Nexus 3.6 - although the offending symbols are URL escaped, the server response refers to an invalid path:
   > Could not determine artifacts for javax.ws.rs:javax.ws.rs-api:2.1
      > Could not get resource 'https://nexus.xxx.net/repository/proxy/javax/ws/rs/javax.ws.rs-api/2.1/javax.ws.rs-api-2.1.$%7Bpackaging.type%7D'.
         > Could not HEAD 'https://nexus.xxx.net/repository/proxy/javax/ws/rs/javax.ws.rs-api/2.1/javax.ws.rs-api-2.1.$%7Bpackaging.type%7D'. Received status code 400 from server: Invalid repository path

The fix was in Gradle 4.5, not 4.4.1. Please upgrade and let us know if that fixes the issue.

Yes, I just upgraded Gradle to 4.5.1 and it works.
Thank you very much! :-)

com.alibaba.fastjson.JSONException: parse enum org.gitlab4j.api.models.AccessLevel error, value : 50


fix(challenges): Implement Help Dialog

Pre-Submission Checklist

[x] Your pull request targets the staging branch of freeCodeCamp.
[x] Branch starts with either fix/, feature/, or translate/ (e.g. fix/signin-issue)
[x] You have only one commit (if not, squash them into one commit).
[x] All new and existing tests pass the command npm test. Use git commit --amend to amend any fixes.

Type of Change

[ ] Small bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds new functionality)
[ ] Breaking change (fix or feature that would change existing functionality)
[ ] Add new translation (feature adding new translations)

Checklist:

[x] Tested changes locally.
[x] Addressed currently open issue (replace XXXXX with an issue no in next line)

Addresses #12755
Description

This PR applies changes from following commits:

https://github.com/freeCodeCamp/freeCodeCamp/commit/78e86f514f90dc3fd392a52fa52feb180a91f3af introduces Help Dialog which is the main purpose of this PR.
https://github.com/freeCodeCamp/freeCodeCamp/commit/aefcf9c2acf9def066947ce5c55196fab1ab3e00 changes the forum post template, which has been partially applied but may still require a further review
https://github.com/freeCodeCamp/freeCodeCamp/commit/52edcedb61ab57d9201d4b4bcf865caf80d894de is non-applicable since new release discourages use of links in modal headers.

Changes in this PR may be easier to follow as separate commits:
https://github.com/mpontus/freeCodeCamp/commit/30ca57210e263dcc0a2d031a7dda0c7139530fbe - add new button and new dialog
https://github.com/mpontus/freeCodeCamp/commit/08f7a93effb7ac1168bf1092c3e2dfc7bafb792b - refactor dialogs to reduce duplication of logic
https://github.com/mpontus/freeCodeCamp/commit/8930e1fa993696f17097808d31efc1664e96a4ee - merge Help button (which used to open Gitter Chatroom) with the new Button (which opens the dialog which now includes link to Gitter Chatroom)
Here's the screenshot of the new Dialog:
https://i.imgur.com/z3faX2E.png

One more change and the changes will be ready.

When I reach a stopping point I'll pull this down and give it a quick run through. Otherwise if anyone else wants to give this a QA and merge go ahead as the code LGTM.

All done :)

@mpontus Thank you for your efforts. Please try to add two things :
1- The close button should have " close and closing-x " classes so it matches the design in production.
2- "Read-Search-Ask" should be a link to " https://forum.freecodecamp.org/t/the-read-search-ask-methodology-for-getting-unstuck/137307 " forum page.

@KhaledSamir those two points have already been implemented, unless I'm not seeing what you are?

@Bouncey Aha!.  Can you please confirm if this latest => https://i.imgur.com/U9ES2GM.png

I admire @mpontus's attention to detail in implementing this. @KhaledSamir's looks better in my opinion. I don't think we should move away from modal headers - they look good.
Also, we are encouraging just one option for getting help - the forum.freecodecamp.org/c/help section. This simplifies getting help, since in most cases, campers are asking a question that has been asked before, and the forum software is smart enough to figure this out and show them the right answer.
So while we may be to merge this and keep some of this code, we ultimately want the modal to look like what @KhaledSamir has implemented on https://github.com/freeCodeCamp/freeCodeCamp/pull/16307
@Bouncey Could you merge these and reconcile them?

@mpontus @Bouncey @QuincyLarson So let me connect the dots here again as per my understanding.
In my PR #16307 , I didn't change anything related to the Modal , my focus was on the buttons that related to any lesson which are " Run Tests , Reset your Code , Get a hint or Ask for help on the forum " so to be clear , I have no changes for the modal in my changes. My changes just to make the button stretched and be like that (Figure 1-1)

(Figure 1-1)
I hope this was clear. Now for what @mpontus has done , he changed the look of the modal for this issue and this what was missing on my PR but I think he missed two things here that need to be added/modified in this PR.
I'm looking at the latest pic that he shared as final result here :
https://i.imgur.com/U9ES2GM.png
If this is the latest changes so, my two points that I previously mentioned are still valid because if we looked at the Modal design in production, there is a slight difference (Figure 1-2)

(Figure 1-2)
I wish this was clear to point out to the differences. Again well-done @mpontus.

@KhaledSamir Thanks for bringing this up. I based my modals on how Bug modal looked on Beta. If the modals need look more similar to the stable version, then I can make this happen.

Changes carried over to #16313
Thanks @mpontus

@Bouncey Thanks looking into this.


Background rounded rectangle in main panel doesn't extend to contain the whole content of a page

Hi,
Thanks for your work. Very useful to highlight the headers, mainly in my journals.
I've found the following behaviour (you can see it in the attached picture):

In the right side bar, the rounded rectangle that is at the background fits the whole extent of the page content.
But in the main panel, this rounded rectangle more or less fits the height of the window, but the content of the page exceeds the area of this background.

Hope I explained it clear enough.
Thanks again and regards,
Pepe

Hey!
Glad you like ;)
I think I could somehow reproduce your issue.
You dont use the banner plugin, right? cause somehow this fixes the issue for me
I will take a more in-depth look at it and try to fix it
Greetings
Matthias

Hi, and thanks for the quick response.
No, I'm not using the Banner plugin.
Thanks and regards,
Pepe

Bug should be fixed, you can update via marketplace.
Let me know if you still have the issue.
Greetings
Matthias

Hi Matthias,
The background is extended vertically fine... but now the width of the contents has shrunk quite a lot. My screen is not very big, and there is a lot of margin in both sides (specially compared to the previous behaviour).
Please find attached a snapshot with the current version, that you can compare with the margins in the previous image I posted.

Regards,
Pepe

Okay this is not so easy to fix in the code that it looks good for everybody.
But you can overwrite the css by yourself.
Just add in Settings-> Edit custom.css

:root {
  --ls-main-content-max-width: 100%;
}

Nice! Works beautifully!
Thanks,
Pepe


Profile pages

Profile Pages for fellows.
close #9

This looks great! I don't seem to be able to click the fellow names to load the profile pages - any ideas?

Yes this issue was due to other merged stuff. It is now fixed.


Add Billing Logic

Add 7 day trial with 30 day recurring billing logic

Added basic logic to bill. Need to handle uninstall.

Added


Integrate js api changes from taskrabbit

Tooltip can now be applied to any child element passed by the caller, not hardcoded to  only.
Abstracted the logic used to show the tooltip from the caller. The caller can now simply pass in a list of actions to be displayed on press or long press, as specified.
Preserved a global callback (onActionSelected) which accepts the command string that was selected.
Kept ES5 syntax for the most part. Some things such as the ES6 export default make it a bit harder to consume the component from ES5.

@jrichardlai thoughts?
@sevachb @jrichardlai I can add you guys as collabs if interested

Oops! forgot about it imma make a PR for tonight!

awesome. Let's merge the two codebases.

Oops didn't see this was a PR, well this PR will remove the previous usage of ToolTipText, I was planning on keeping the previous Api, but this is fine if you think its okay.

I thought your fork removes the usage of ToolTipText. isn't it?

It does, and I think its better if we only keep one usage, but its up to you. I'm making a PR now. let you comment over there :).

Hey guys, so I basically brought back jrichardlai's change here with 2 small changes (described above).

Stuck with ES5 for the most part
Preserved a global callback

Can we accept this PR as a starting point? It's all good to go.

@sevachb Thanks for putting it all together. I think we all should agree on api once and just ship it once rather than doing it twice.

Sure thing. What are the things in the current PR that you have in mind?

@sevachb https://github.com/chirag04/react-native-tooltip/pull/8 just landed on master.


fzf-tmux with --color=bg: doesn't cover the sides of the border fully

[X] I have read through the manual page (man fzf)
[X] I have the latest version of fzf
[X] I have searched through the existing issues

Info

OS

[X] Linux
[ ] Mac OS X
[ ] Windows
[ ] Etc.

Shell

[ ] bash
[X] zsh
[ ] fish

Problem / Steps to reproduce
Hi again @junegunn and ty for maintaining this amazing project.
When using fzf-tmux in conjunction with the background color option --color=bg:... the right and left sides of the border within the tmux popup have a narrow border colored by the terminal bg color (rather than the one specified by the --color flag).
Example: when calling fzf-tmux without a background color uses the terminal bg color for background:

fzf-tmux -p80%,60%

Note that the different background color in my tmux panes comes from having neovim open with a different colorscheme than the terminal one.

But when adding a background color, there are visible narrow columns to the sides of the border with the incorrect color (the terminal bg color):

fzf-tmux -p80%,60% -- --color=bg:red

Another example when using fzf-tmux inside neovim where you can clearly see the issue:

Can't reproduce the problem.
FZF_DEFAULT_OPTS= fzf-tmux -p80%,60% --color bg:\#663300 --preview 'cat {}'

I'm on tmux 3.3a.
Not reproducible on Vim/Neovim either.
colo blue
call fzf#run({'window': {'width': 0.5, 'height': 0.5}, 'options': '--color bg:red'})

Can't reproduce the problem.

Alright let me do some more digging about the exact combo to reproduce, will keep you posted.

Did some digging and I'm now even more confused than before.
No need for neovim, I set tmux popup background color to something visible (green) with:
tmux setw -g popup-style bg=colour2

I added debug output of the tmux popup commaind to line fzf-tmux:212:
echo "tmux popup -d \"$PWD\" $opt \"bash $argsf\" > /dev/null 2>&1"  # << ADDED LINE
tmux popup -d "$PWD" $opt "bash $argsf" > /dev/null 2>&1

Now I ran:
fzf-tmux -p50%,50% --ansi --height=100% --color=bg:red

And this was the result has the border issue:

I then ran (almost) the same command (output by fzf-tmux debug print) directly and the result does not have the border issue:

I'll keep on digging, any hints as to why this is happening only with the fzf-tmux script would be appreciated :-)

Ok, I was able to find the culprit, it seems that fzf-tmux adds --margin at the sides:
https://github.com/junegunn/fzf/blob/96c3de12eb717e33b175fd01a9aaaac84ea8d6af/bin/fzf-tmux#L181-L182
Which I'm then able to override by appending --margin=0,0 at the end of the command so I guess that solves it.
Any particular reason this is hardcoded into fzf-tmux?

I think that's because fzf-tmux used to use the border from tmux, because back then it was not possible to create a popup without borders.
But since tmux 3.3, we're using --border instead, we can get rid of it.

https://github.com/junegunn/fzf/commit/d826f9e72f4849c43525d7196ecc7adfe3a50a9d
https://github.com/tmux/tmux/blame/master/CHANGES#L155

What do you think?
diff --git a/bin/fzf-tmux b/bin/fzf-tmux
index 44c6051..fd3258f 100755
--- a/bin/fzf-tmux
+++ b/bin/fzf-tmux
@@ -179,9 +179,10 @@ trap 'cleanup' EXIT

 envs="export TERM=$TERM "
 if [[ "$opt" =~ "-E" ]]; then
-  FZF_DEFAULT_OPTS="--margin 0,1 $FZF_DEFAULT_OPTS"
   tmux_version=$(tmux -V)
-  if [[ ! $tmux_version =~ 3\.2 ]]; then
+  if [[ $tmux_version =~ ^3\.2[a-z]?$ ]]; then
+    FZF_DEFAULT_OPTS="--margin 0,1 $FZF_DEFAULT_OPTS"
+  else
     FZF_DEFAULT_OPTS="--border $FZF_DEFAULT_OPTS"
     opt="-B $opt"
   fi

if [[ $tmux_version =~ ^3\.2[a-z]?$ ]]; then

Just tested, works great, ty @junegunn!


Guppy integration

Codecov Report

Merging #3 (a8a20a0) into main (858b2de) will decrease coverage by 1.16%.
The diff coverage is 0.00%.

@@           Coverage Diff            @@
##            main      #3      +/-   ##
========================================
- Coverage   3.70%   2.53%   -1.17%
========================================
  Files          4       6       +2
  Lines        189     276      +87
========================================
  Hits           7       7
- Misses       182     269      +87

Impacted Files
Coverage Δ

src/bin/hamilton_controller.rs
0.00% <0.00%> (ø)

src/bin/hamilton_guppy_controller.rs
0.00% <0.00%> (ø)

src/bin/vehicle_config_test.rs
0.00% <0.00%> (ø)

src/driver/hamilton_lss_driver.rs
7.86% <0.00%> (-0.38%)
:arrow_down:

src/holonomic_controller.rs
0.00% <ø> (ø)

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 858b2de...a8a20a0. Read the comment docs.


Update

Hi!
First of all thanks for your work, it is amazing!
I have a problem, the widget not update itself, only when I run the scipt again.

When you have it set up as widget only iOS knows when it is updated again. You need to wait.
From my experience, you can force update the widget by changing the provided parameter to an invalid value and then changing it back to a valid value. So every time you change a the parameter, it updates directly afterwards.
If you have the newest version of the script you might have to run the script once while the variable overwritePersistedConfig is set to true.

Thank!
It will update every 20 minutes, I am not patience enought :)

So can i close this issue?

Yes, thanks!


Lis2dw12 fixes from lis2ds12 port

Needs testing, I dont have this device this is just my set of notes from porting. Happy to rebase or remove any commits.
Id especially like to see if self test is still passing for people as it had a few problems still. I dont personally feel like its properly implemented even yet.
AN5038 Section 8 says

The procedure consists of:

enabling the accelerometer
averaging five samples before enabling the self-test
averaging five samples after enabling the self-test
computing the difference in absolute value for each axis and verifying that it falls within
a given range. The min and max values are provided in the datasheet.

And Im not sure I consider the current implementation following that quote
This https://github.com/apache/mynewt-core/pull/948/commits/787e2a2a915b9f3e4da2fce6ea60989b5e6cc1ba is passing for me and my current recommendation, but I dont have your board.

I am a bit concerned about the self test, rest of the changes look good and thank you for adding the comments @jacobrosenthal. I haven't got to test your changes on real hardware yet. I will try to do that but is there a way you can try it yourself ?

Well existing is wrong. It's using the wrong full scale to calculate. I'd
prefer the self test in my repo which works on my boards and follows the
app notes. No I don't have this chip. Lots of other silent people cc'ed
here not speaking?
On Wed, Jun 6, 2018, 6:53 PM Vipul Rahane<EMAIL_ADDRESS>wrote:

I am a bit concerned about the self test, rest of the changes look good
and thank you for adding the comments @jacobrosenthal
https://github.com/jacobrosenthal. I haven't got to test your changes
on real hardware yet. I will try to do that but is there a way you can try
it yourself ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/mynewt-core/pull/1154#issuecomment-395267630,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAb0dMZb5G98c5PDvj6TmE29QSgnDC16ks5t6IeqgaJpZM4UXrrS
.

@jacobrosenthal I tried out your changes on actual hardware, I am getting a return value of -6. Something is broken.

On which commit?
On Thu, Jun 7, 2018 at 11:35 AM Vipul Rahane<EMAIL_ADDRESS>wrote:

@jacobrosenthal https://github.com/jacobrosenthal I tried out your
changes on actual hardware, I am getting a return value of -6. Something
is broken.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/mynewt-core/pull/1154#issuecomment-395521254,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAb0dLvHkeKVz8uifAtXIq_v3YVrEgegks5t6XJVgaJpZM4UXrrS
.

Whatever you have on your branch currently.

I'll but your board I guess let's rebase out self test and do that in a
second pr
On Thu, Jun 7, 2018, 12:13 PM Vipul Rahane<EMAIL_ADDRESS>wrote:

Whatever you have on your branch currently.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/mynewt-core/pull/1154#issuecomment-395533135,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAb0dB-AIJi0T1M-r4Uvm1goYiIlyO35ks5t6XtSgaJpZM4UXrrS
.

All self test changes were squashed, removed and added to https://github.com/apache/mynewt-core/issues/1171

My LIS2DW12 board arrived. My freefall setter was incorrect and has been rebased out in c7f0dfa and also pr'ed to my branch.
One thing I noticed is that the taps are VERY sensitive. I would align with the double tap example as I have done in mine. Shrug...
the only other destructive edit left to argue over in here is the getter
The upstream code
cfg.freefall_dur = 6;
cfg.freefall_ths = 3; /* ~312mg */

and in register 0x36 (dec 54)
lis2dw12 peek 54
008298 reg 0x36(54) = 0x33

IE dur 6, ths 3, So it has a correct setter. but, lis2dw12_get_freefall reads
001055 dur:0x06, ths:0x00

incorrect getter.
And you wont be surprised that in this pr, lis2dw12_get_freefall
002681 dur:0x06, ths:0x03


Add PDF Export Option

Hey @hsw107 , I added support for PDF export.

Thanks @scmyyc ! I will try to review this soon! :)


Govpp update

Issue: https://github.com/networkservicemesh/sdk-vpp/issues/508
The main difference is that MemifSocketFilenameAddDelV2 API doesn't have Namespace now. Instead, we should act like this: @netns:ns0@somename
Signed-off-by: Artem Glazychev<EMAIL_ADDRESS>

@edwarnicke Could you have a look?


involontary replay attack when unshielding

unshielding suffers from replay attacks, even without bad intentions:
If more than one worker is registered for a shard, these workers all send the unshield_funds(account, amount, shard) extrinsic. The pallet has no way to know that these are results of the same TrustedCallSigned::unshield() (which suffers another replay attack until we solve #89)
Of course, an adversary could also expoit this replay attack.
Mitigation: keep track of all confirmed TrustedCallSigned.
The substratee_registry::confirm_call(<TrustedCallSigned>) keeps a registry of confirmed calls. This registry could be a storage_map(Hash) -> u32  and counts the number of confirmations N per call.
If N > 0, we don't unshield because it has already been done
We might merge the confirm_call and unshield_funds extrinsic into one for that purpose. No need to spend two transactions for a single purpose
Please update the book too

In fact, we need to merge the unshield and the confirm_call extrinsic. Otherwise, we mitigate nothing as the worker could simply withhold the confirm_call extrinsic.

Thoughts on keeping a registry of unconfirmed calls instead:

what happens with failing TrustedCalls? throw a way after N blocks?
could save state space because it's not ever-growing
might actually be a better idea....

In fact, we need to merge the unshield and the confirm_call extrinsic. Otherwise, we mitigate nothing as the worker could simply withhold the confirm_call extrinsic.

The current implementation partly solves the above mentioned issue of having two separate extrinsics, as the enclave checks the inclusion of all enclave generated extrinsics.

I would be in favour of keeping track of unconfirmed calls instead. I think it is more elegant and it does not matter for the client because:

In both cases the client will see that a call is unconfirmed either because it is in the list of unconfirmed extrinsics or because we have the number of confirmations == 0.
In both cases the client will receive an CallConfirmed event.

no need for that additional event I think.
We can do the purge logic later as part of on_initialize() (at beginning of block generation)

Has been fix with the pallet-substratee-registry update in #147.
As it was more straight forward to implement, we currently keep track of confirmed extrinsics instead of unconfirmed extrinsics.


Bump sbt to 1.0.3, update sbt-pgp

This pull request updates the build to sbt 1.x; it relies on sbt 1.0.3, which will be published shortly.
Also see:
https://github.com/sbt/sbt-standalone-build/issues/15
https://github.com/sbt/sbt/pull/3669
Please wait for 1.0.3 to be available before merging.

retest this please

break 2.13.0-M2 builds https://github.com/sbt/sbt/issues/3427

Think the title should change to include sbt 1.0.4.


SCons not defining VCINSTALLDIR or VSINSTALLDIR in env['MSVS'] per documentation

This issue was originally created at: 2015-02-13 15:22:03.
This issue was reported by: dirkbaechle.
dirkbaechle said at 2015-02-13 15:22:03

As reported by Andrew C. Morrow, the 'MSVS' Environment variable contents appear
to be out of sync with their documentation.
The SCons 2.3.4 docs state:
MSVS
When the Microsoft Visual Studio tools are initialized, they set up
this dictionary with the following keys:
And then lists several keys, including PLATFORMSDKDIR.
However the documented variables do not actually appear to get set. The string
PLATFORMSDKDIR, for instance, appears nowhere in the SCons 2.3.4 sources.

dirkbaechle said at 2015-02-13 15:22:34

Added keyword

On a fully setup Visual Studio environment, it populates the MSVS dictionary only with two keys: PROJECTSUFFIX and SOLUTIONSUFFIX.  Looks like quite a bit of the rest of the MS* construction variable setting differs from the manpage too.

Okay, for the first part of this, why would it matter which one you use?  Supplying a path that we wouldn't have looked at otherwise seems fine, although it appears if you have any product that can be scanned with vswhere, it will have installed vswhere in the known places.

I thought only VS 2017+ installed vswhere? Imagine that I have a VS 2015 only machine, and I want to use vswhere to locate the runtime redistributables. It would be nice to be able to pull down the chocolatey version, and then specify VSWHERE=... on my command line (having made a Variable decl for it in my SConstruct). On other platforms, where SCons will find vswhere, I don't need to do this (SCons would populate it for me from the expected location), but I can still read out the discovered location for vswhere from VSWHERE. So any tooling I need that wants vswhere can be made independent of its actual install location. The same code will work with VS 2017 and VS 2019. Another reason would be if the "system" version of vswhere had a bug and you could get the newer chocolatey version and override which one SCons would use to fix a bug. Overall, it just seems smart to be able to let the user have control over this as an input parameter, the same way MSVC_VERSION works. Or any other number of situations where the default search for vswhere proves to not work as advertised, this gives the user a path forward.

vswhere can detect some "legacy" versions older than 2017. So there is value.

Or, look it as future proofing for when Microsoft in their wisdom decides to move vswhere somewhere new in a future version.

Fair enough.
As to it working on pre-2017 - as I said in discord, my system that has 2015/2017/2019 all installed doesn't have vswhere "see" anything about the 2015 edition.

Given that this feature appears to have been broken for some time, I think it is worthwhile considering what we would like the fix to look like. I'm not sure that simply re-introducing the prior MSVS dictionary is the right fix.
Let's look at each in turn:

MSVS.VERSION: This says it is the version in use, which can be set by MSVS_VERSION, which in turn is deprecated in favor of MSVC_VERSION. If we already have MSVC_VERSION why do we need this additional form? I'd propose eliminating it.

MSVS.VERSIONS: I'm not sure how useful it is to expose this to users. Typically, either they requested an explicit version by setting MSVC_VERSION during initialization, in which case they know what they wanted, or they didn't, in which case they are happy with latest. So, I also propose eliminating this.

MSVS.VCINSTALLDIR: This seems useful, and should be kept in some form.

MSVS.VSINSTALLDIR: Ditto.

MSVS.FRAMEWORK*: I'd propose that either all of these be dropped, or, if there is real use for knowing these, that they be simplified and renamed. I'd drop FRAMEWORKVERSIONS under the same argument as MSVS.VERSIONS. I'd also stick DOTNET in front of the name of each.

MSVS.PLATFORMSDK: This seems useful. I wonder, in fact, whether it ought to be in/out like MSVC_VERSION is, so that you could potentially point to a newer SKD installation? But on the other hand, MSSDK_DIR and MSSDK_VERSION already exist.

MSVS.PLATFORMSDK_MODULES: No idea here. But if MSSDK_DIR and MSSDK_VERSION obsolete MSVS.PLATFORMSDK*, then I'd propose just making this a top-level MSSDK_MODULES.

Finally, I think I'd propose hoisting all of these out of the MSVS dictionary. Having these things inside a dictionary isn't great, because it makes it difficult to set them via the command line and Variables objects.
My suggestion is that we end up with top level variables as follows:

New top-level MSVS_INSTALLDIR and MSVC_INSTALLDIR. We could optionally make that INSTALL_DIR.
A new top-level MSSDK_MODULES to replace MSVS.PLATFORMSDK_MODULES, if that makes sense.

I'm open to suggestions on what to do with the .NET stuff.

@bdbaddog - Any thoughts on my comments above? And should we tag it for 4.0? It seems worth fixing - there was definitely a regression somewhere along the line, and exposing the installation directories is handy for things like locating the vcredist files.

May or may not make it for 4.0.0 but tagging for now.

Or, look it as future proofing for when Microsoft in their wisdom decides to move vswhere somewhere new in a future version.

Note VSWHERE env variable has been implemented for some time at present.

Populating the MSVS dictionary with most of the values listed in the documentation appears to have been removed prior to the release of scons-2.0.0-final.0.  The function responsible for populating the dictionary was present in scons-1.2.0 and is shown below.
It appears that starting with SCons 2.0, most of the detection routines were moved into dedicated modules.  Some of the dictionary elements are available now via (possibly internal) module functions.
All of the content appears to be "pure detection" via register queries and file system examination rather than the result of running the vcvars batch files.  The vcvars batch files produce many of the variables of interest but are not necessarily preserved in the resulting environment.  For example, when running the vcvars batch files,  VCINSTALLDIR is propagated to the resulting ENV dictionary while VSINSTALLDIR is not.
Note: scons-1.2.0 appears to have supported vs versions 6.0 (and possibly earlier), 7.0 (2002), 7.1 (2003), and 8.0 (2005).
VC/VS:

VERSION
VERSIONS
VCINSTALLDIR
VSINSTALLDIR

.NET Framework:

FRAMEWORKDIR (r'Software\Microsoft.NETFramework\InstallRoot')
FRAMEWORKVERSIONS (filtered os.listdir(rv['FRAMEWORKDIR']))
FRAMEWORKVERSION
FRAMEWORKSDKDIR (r'Software\Microsoft.NETFramework\sdkInstallRoot' + ver)

Platform SDK:

PLATFORMSDKDIR (r'Software\Microsoft\MicrosoftSDK\Directories\Install Dir')
PLATFORMSDK_MODULES (r'Software\Microsoft\MicrosoftSDK\InstalledSDKs')

Detection functionality largely moved to independent source modules:

VS: scons-master/SConst/Tool/MSCommon/vc.py
VC: scons-master/SConst/Tool/MSCommon/vc.py
.NET Framework: scons-master/SCons/Tool/MSCommon/netframework.py
Platform SDK: scons-master/SCons/Tool/MSCommon/sdk.py

scons-1.2.0/engine/SCons/Tool/msvs.py
get_msvs_install_dirs function (lines: 1340-1521)
def get_msvs_install_dirs(version = None, vs8suite = None):
    """
    Get installed locations for various msvc-related products, like the .NET SDK
    and the Platform SDK.
    """

    if not SCons.Util.can_read_reg:
        return {}

    if not version:
        versions = get_visualstudio_versions()
        if versions:
            version = versions[0] #use highest version by default
        else:
            return {}

    version_num, suite = msvs_parse_version(version)

    K = 'Software\\Microsoft\\VisualStudio\\' + str(version_num)
    if (version_num >= 8.0):
        if vs8suite == None:
            # We've been given no guidance about which Visual Studio 8
            # suite to use, so attempt to autodetect.
            suites = get_visualstudio8_suites()
            if suites:
                vs8suite = suites[0]

        if vs8suite == 'EXPRESS':
            K = 'Software\\Microsoft\\VCExpress\\' + str(version_num)

    # vc++ install dir
    rv = {}
    if (version_num < 7.0):
        key = K + r'\Setup\Microsoft Visual C++\ProductDir'
    else:
        key = K + r'\Setup\VC\ProductDir'
    try:
        (rv['VCINSTALLDIR'], t) = SCons.Util.RegGetValue(SCons.Util.HKEY_LOCAL_MACHINE, key)
    except SCons.Util.RegError:
        pass

    # visual studio install dir
    if (version_num < 7.0):
        try:
            (rv['VSINSTALLDIR'], t) = SCons.Util.RegGetValue(SCons.Util.HKEY_LOCAL_MACHINE,
                                                             K + r'\Setup\Microsoft Visual Studio\ProductDir')
        except SCons.Util.RegError:
            pass

        if not rv.has_key('VSINSTALLDIR') or not rv['VSINSTALLDIR']:
            if rv.has_key('VCINSTALLDIR') and rv['VCINSTALLDIR']:
                rv['VSINSTALLDIR'] = os.path.dirname(rv['VCINSTALLDIR'])
            else:
                rv['VSINSTALLDIR'] = os.path.join(SCons.Platform.win32.get_program_files_dir(),'Microsoft Visual Studio')
    else:
        try:
            (rv['VSINSTALLDIR'], t) = SCons.Util.RegGetValue(SCons.Util.HKEY_LOCAL_MACHINE,
                                                             K + r'\Setup\VS\ProductDir')
        except SCons.Util.RegError:
            pass

    # .NET framework install dir
    try:
        (rv['FRAMEWORKDIR'], t) = SCons.Util.RegGetValue(SCons.Util.HKEY_LOCAL_MACHINE,
            r'Software\Microsoft\.NETFramework\InstallRoot')
    except SCons.Util.RegError:
        pass

    if rv.has_key('FRAMEWORKDIR'):
        # try and enumerate the installed versions of the .NET framework.
        contents = os.listdir(rv['FRAMEWORKDIR'])
        l = re.compile('v[0-9]+.*')
        installed_framework_versions = filter(lambda e, l=l: l.match(e), contents)

        def versrt(a,b):
            # since version numbers aren't really floats...
            aa = a[1:]
            bb = b[1:]
            aal = string.split(aa, '.')
            bbl = string.split(bb, '.')
            # sequence comparison in python is lexicographical
            # which is exactly what we want.
            # Note we sort backwards so the highest version is first.
            return cmp(bbl,aal)

        installed_framework_versions.sort(versrt)

        rv['FRAMEWORKVERSIONS'] = installed_framework_versions

        # TODO: allow a specific framework version to be set

        # Choose a default framework version based on the Visual
        # Studio version.
        DefaultFrameworkVersionMap = {
            '7.0'   : 'v1.0',
            '7.1'   : 'v1.1',
            '8.0'   : 'v2.0',
            # TODO: Does .NET 3.0 need to be worked into here somewhere?
        }
        try:
            default_framework_version = DefaultFrameworkVersionMap[version[:3]]
        except (KeyError, TypeError):
            pass
        else:
            # Look for the first installed directory in FRAMEWORKDIR that
            # begins with the framework version string that's appropriate
            # for the Visual Studio version we're using.
            for v in installed_framework_versions:
                if v[:4] == default_framework_version:
                    rv['FRAMEWORKVERSION'] = v
                    break

        # If the framework version couldn't be worked out by the previous
        # code then fall back to using the latest version of the .NET
        # framework
        if not rv.has_key('FRAMEWORKVERSION'):
            rv['FRAMEWORKVERSION'] = installed_framework_versions[0]

    # .NET framework SDK install dir
    if rv.has_key('FRAMEWORKVERSION'):
        # The .NET SDK version used must match the .NET version used,
        # so we deliberately don't fall back to other .NET framework SDK
        # versions that might be present.
        ver = rv['FRAMEWORKVERSION'][:4]
        key = r'Software\Microsoft\.NETFramework\sdkInstallRoot' + ver
        try:
            (rv['FRAMEWORKSDKDIR'], t) = SCons.Util.RegGetValue(SCons.Util.HKEY_LOCAL_MACHINE,
                key)
        except SCons.Util.RegError:
            pass

    # MS Platform SDK dir
    try:
        (rv['PLATFORMSDKDIR'], t) = SCons.Util.RegGetValue(SCons.Util.HKEY_LOCAL_MACHINE,
            r'Software\Microsoft\MicrosoftSDK\Directories\Install Dir')
    except SCons.Util.RegError:
        pass

    if rv.has_key('PLATFORMSDKDIR'):
        # if we have a platform SDK, try and get some info on it.
        vers = {}
        try:
            loc = r'Software\Microsoft\MicrosoftSDK\InstalledSDKs'
            k = SCons.Util.RegOpenKeyEx(SCons.Util.HKEY_LOCAL_MACHINE,loc)
            i = 0
            while 1:
                try:
                    key = SCons.Util.RegEnumKey(k,i)
                    sdk = SCons.Util.RegOpenKeyEx(k,key)
                    j = 0
                    name = ''
                    date = ''
                    version = ''
                    while 1:
                        try:
                            (vk,vv,t) = SCons.Util.RegEnumValue(sdk,j)
                            # TODO(1.5):
                            #if vk.lower() == 'keyword':
                            #    name = vv
                            #if vk.lower() == 'propagation_date':
                            #    date = vv
                            #if vk.lower() == 'version':
                            #    version = vv
                            if string.lower(vk) == 'keyword':
                                name = vv
                            if string.lower(vk) == 'propagation_date':
                                date = vv
                            if string.lower(vk) == 'version':
                                version = vv
                            j = j + 1
                        except SCons.Util.RegError:
                            break
                    if name:
                        vers[name] = (date, version)
                    i = i + 1
                except SCons.Util.RegError:
                    break
            rv['PLATFORMSDK_MODULES'] = vers
        except SCons.Util.RegError:
            pass

    return rv

generate function (lines: 1732-1790, fragment: 1766-1776)
def generate(env):
...
    try:
        version = get_default_visualstudio_version(env)
        # keep a record of some of the MSVS info so the user can use it.
        dirs = get_msvs_install_dirs(version)
        env['MSVS'].update(dirs)
    except (SCons.Util.RegError, SCons.Errors.InternalError):
        # we don't care if we can't do this -- if we can't, it's
        # because we don't have access to the registry, or because the
        # tools aren't installed.  In either case, the user will have to
        # find them on their own.
        pass
...

scons-master/Scons/Tool/MSCommon/netframework.py
Notes:

The current source code is largely unchanged from the source code in scons.2.0.0.final.0.
It does not appear that the find_framework_root and query_versions functions are called from anywhere else in the source tree(s) since 2.0.0.final.0.

netframework module (lines 33-76):
...
# Original value recorded by dcournapeau
_FRAMEWORKDIR_HKEY_ROOT = r'Software\Microsoft\.NETFramework\InstallRoot'
# On SGK's system
_FRAMEWORKDIR_HKEY_ROOT = r'Software\Microsoft\Microsoft SDKs\.NETFramework\v2.0\InstallationFolder'

def find_framework_root():
    # XXX: find it from environment (FrameworkDir)
    try:
        froot = read_reg(_FRAMEWORKDIR_HKEY_ROOT)
        debug("Found framework install root in registry: %s", froot)
    except OSError:
        debug("Could not read reg key %s", _FRAMEWORKDIR_HKEY_ROOT)
        return None

    if not os.path.exists(froot):
        debug("%s not found on fs", froot)
        return None

    return froot

def query_versions():
    froot = find_framework_root()
    if froot:
        contents = os.listdir(froot)

        l = re.compile('v[0-9]+.*')
        versions = [e for e in contents if l.match(e)]

        def versrt(a,b):
            # since version numbers aren't really floats...
            aa = a[1:]
            bb = b[1:]
            aal = aa.split('.')
            bbl = bb.split('.')
            # sequence comparison in python is lexicographical
            # which is exactly what we want.
            # Note we sort backwards so the highest version is first.
            return (aal > bbl) - (aal < bbl)

        versions.sort(versrt)
    else:
        versions = []

    return versions
...

scons-master/SCons/MSCommon/sdk.py
...
def get_installed_sdks():
    global InstalledSDKList
    global InstalledSDKMap
    debug('get_installed_sdks()')
    if InstalledSDKList is None:
        InstalledSDKList = []
        InstalledSDKMap = {}
        for sdk in SupportedSDKList:
            debug('trying to find SDK %s', sdk.version)
            if sdk.get_sdk_dir():
                debug('found SDK %s', sdk.version)
                InstalledSDKList.append(sdk)
                InstalledSDKMap[sdk.version] = sdk
    return InstalledSDKList
...
def get_sdk_by_version(mssdk):
    if mssdk not in SupportedSDKMap:
        raise SCons.Errors.UserError("SDK version {} is not supported".format(repr(mssdk)))
    get_installed_sdks()
    return InstalledSDKMap.get(mssdk)
...
def get_default_sdk():
    """Set up the default Platform/Windows SDK."""
    get_installed_sdks()
    if not InstalledSDKList:
        return None
    return InstalledSDKList[0]
...


The product text expound a word problems

问题描述
When I was using drag and drop events, met the article drag drag words writing errors.
重现链接
https://antv-g6.gitee.io/zh/docs/api/Event/#通用交互事件
重现步骤
Basis of common events dragstart method described, drag and drop the dragged into a drag, so the words wrong
预期行为
Basis of common events dragstart method described, drag and drop the dragged into a drag, so the words wrong
平台

操作系统: [macOS, Windows, Linux, React Native ...]
网页浏览器: [Google Chrome, Safari, Firefox]
G6 版本: [4.5.1 ... ]

屏幕截图或视频（可选）
Basis of common events dragstart method described, drag and drop the dragged into a drag, so the words wrong.
补充说明（可选）
No response

Did not get the problem you met, please give me an online reproducing demo.


composer.locks breaks app depending on php version

Some history: We removed the lock file in https://github.com/symfony/symfony-standard/commit/58ae85a406409b86a313de22d17d706e5a8823b2 because the installation depends on the icu version. As we removed our icu library, the lock file was reintroduced in https://github.com/symfony/symfony-standard/commit/847d37cfbb868ce979bd16adc37ae5f60f467c74
But we still have a similar problem: The installation depends on the PHP version that is used.
Symfony 2.x is compatible with PHP >= 5.3.9. So we would need to make sure the installation actually works with this PHP version. But I'm sure it fails now (have not tried it) because the recent symfony release now locks in ORM 2.5 which is only compatible with PHP >= 5.4, see https://github.com/symfony/symfony-standard/blob/v2.7.4/composer.lock#L715
So people using PHP 5.3 will not be able to run our locked in release. We could work-around this by fixing the PHP version inside our composer.json that is used to update the lock file with https://getcomposer.org/doc/06-config.md#platform
But that could in theory also fail for people that use a newer PHP version. E.g. there could be a library that releases different versions for PHP 5.x and PHP 7. So if we lock in the one for 5.3.9, a user coming with PHP 7 might not be able to run symfony as well.
The only solution I see is to remove the lock file again.

Seems (unfortunately) reasonable.

We can use config: {php: 5.3.9} in the composer.json, as done in the Symfony demo. We should remove it in the installer though, to avoid forcing all Symfony projects to resolve deps in a 5.3-compatible way later (as we hope that most projects are not deployed on 5.3 anymore)
Removing the lock file will not help much: the installer is downloading an archive with vendors included, so the deps resolution still does not happen on the PHP version of the user.

@stof

We can use config: {php: 5.3.9}

But that could in theory also fail for people that use a newer PHP version. E.g. there could be a library that releases different versions for PHP 5.x and PHP 7.

@Tobion the only solution for that would be to provide multiple downloads for the SE and then choosing the right one in the installer. Too complex IMO.

The installer must not include the vendors in the archieve. Or it must only include the vendors that we can control and can ensure it works undependly of which PHP version like symfony/symfony.

@Tobion the installer has to include the vendors. That's what it makes it blazing fast.

It could be better to check what are the real "changes" made by different versions of PHP when installing the vendors.
Making a comparison of the different composer.lock generated under different PHP versions can be a good start.
And then, if it's not "too big", we may, for example, include all dependencies in the vendors that are compatible with each version, even if some will be unused by other versions.

@Pierstoval you cannot install multiple versions of the same package at the same time

That's not what I'm talking about, it's more something like
if PHP_VERSION < 5.4 then install ICU ; if PHP_VERSION > 5.6 then install another_package
etc.
As I said:

Making a comparison of the different composer.lock generated under different PHP versions can be a good start.

@Pierstoval the issue here is that the composer.lock file should lock Doctrine 2.4 for PHP 5.3 compatible branches, not Doctrine 2.5 (which requires PHP 5.4+)

Related: https://github.com/symfony/symfony/issues/17056

@WouterJ not sure. the user seems to have a corrupted lock file (maybe a lock file updated manually in a wrong way)

Then the deploy script should be run on an environment with PHP 5.3 so the lock file is correct for anyone, and therefore the orm requirement should be changed from ^2.5 to ^2.4 for users to be able to run a composer update in their own environment.

@Pierstoval the 2.8 branch has ^2.4.8 as constraint

Oh, yeah, right, I don't know where I saw ^2.5, but you're right.
The rest of my comment still seems pertinent to me :)

This is causing issues for some users (e.g. this StackOverflow question).
In theory Symfony 2.8 works with PHP 5.3.9. In practice, Symfony 2.8 requires PHP 5.5+ because of Doctrine.

@javiereguiluz At work I'm developing an app on Symfony 2.8 with PHP 5.4.45 and it works perfectly :confused:

Actually I think that SensioLab need to update its build script or environment in order to install the vendors with PHP 5.3 as expected by everyone for compatibility reasons. And for Symfony3, build it with PHP 5.5.
I know it's quite cumbersome but actually it can be done by changing the composer config.platform parameter. Maybe think about something similar on runtime?

@Pierstoval if you open for instance Doctrine\Common\Proxy\ProxyGenerator, you'll find this code incompatible with PHP 5.4 in line 61:
    protected $placeholders = [
        'baseProxyInterface'   => Proxy::class,
        'additionalProperties' => '',
    ];

@javiereguiluz I know, but if you run composer update with PHP 5.4 or if you specify the config.platform with php: "5.4.45", this version of doctrine/common won't be installed. That's why I think the build script from SensioLab must be run with PHP 5.3 to avoid any incompatibility. Promise is made over PHP 5.3, so IMO it should be built with 5.3.

I confirm that using:
"config": {
    "platform": {
        "php": "5.4"
    },
    "bin-dir": "bin"
},

Solved the problem too (I am also using 5.4.45 on Debian)

I think adding PHP 5.3 as the platform configuration in the standard edition is the way to go. If someone has a newer version, he just has to update the default composer.json. That should fix almost all problems.

@fabpot: I think you're right, I've been thinking about a solution for Composer, but there's nothing possible right now. What would be good is for Composer to allow some options to be overridable (like extras, scripts, config or even autoload).

Done in d0e9308e807aae02c332897d610ad5eb49d81c1e

This does not fix the issue fully as I explained initially. There can still be libraries that are for example compatible with PHP 5.3 but not with PHP 7 (e.g. phpunit). So the lock would install stuff that won't work for some users. The only solution is to remove the lock file.

And even worse people must remember to update this part of the composer.json from SE every time. Otherwise it will cause hard to find bugs when they add a dependency but it doesn't actually work in their environment.

@tobion There's a discussion about bringing this user-logic into the installer here: symfony/symfony-installer#234

So if we lock in the one for 5.3.9, a user coming with PHP 7 might not be able to run symfony as well.

This does not fix the issue fully as I explained initially. There can still be libraries that are for example compatible with PHP 5.3 but not with PHP 7 (e.g. phpunit).

That is what's happening in https://github.com/symfony/symfony-demo/issues/343 when installing additional packages, only the other way round.
The use of config.platform.php in addition to require: php>=5.3.9 prevents the packages (which only exist for php >5.5) from being installed unless composer.json is required due to https://github.com/symfony/symfony-standard/commit/d0e9308e807aae02c332897d610ad5eb49d81c1e.

This causes some very confusing issues when installing a new project via composer rather than than the Symfony installer. It should probably at least be noted in the docs.


http/get freezes in d/chain

I was running a simple example from the Aleph README and changed the url from google to jsoup
@(d/chain (http/get "http://jsoup.org/cookbook/introduction/parsing-a-document")
         :body
         bs/to-string)

When I run this (repl or in a main function) it blocks forever.  The same thing happened with
@(d/chain (http/get "http://en.wikipedia.org/wiki/International_Olympic_Committee")
         :body
         bs/to-string)

but google works.  I have no idea what is going on and how to debug?

This is because bs/to-string is a blocking operation, and in this case is blocking the thread which would pull down the rest of the request.  Doing the to-string call outside of the chain after it's been dereferenced will fix this, as will doing it like this:
@(d/chain (http/get "http://jsoup.org/cookbook/introduction/parsing-a-document")
         :body
         #(d/future (bs/to-string %)))

However, this is a really ugly leakage of the execution model, which you shouldn't have to work around.  There are a few ways I can fix this, I'm going to leave this issue open until I figure out the right one.  Sorry for the trouble, and thank you for the report.

Your original code should work as expected now.

Working perfectly, thanks for the quick fix.


Deploy Solution fails

PS /home/andrew/ProvisionGenie/Deployment/Scripts> ./Deploy-Solution.ps1
cmdlet Deploy-Solution.ps1 at command pipeline position 1
Supply values for the following parameters:
Location: westeurope
tenantURL: https://iprds.sharepoint.com/
DataverseEnvironmentId: https://orgf99ae585.crm4.dynamics.com/
WelcomePackageUrl: https://iprds.sharepoint.com/sites/M365LP
Active Subscription is bde94792-7a97-4c4d-bbcd-07c4f67bf39b (Development & Test)
Validating deployment location
WARNING: This command or command group has been migrated to Microsoft Graph API. Please carefully review all breaking changes introduced during this migration: https://docs.microsoft.com/cli/azure/microsoft-graph-migration
Removing old client secrets from ProvisionGenieApp
WARNING: This command or command group has been migrated to Microsoft Graph API. Please carefully review all breaking changes introduced during this migration: https://docs.microsoft.com/cli/azure/microsoft-graph-migration
This command or command group has been migrated to Microsoft Graph API. Please carefully review all breaking changes introduced during this migration: https://docs.microsoft.com/cli/azure/microsoft-graph-migration
Generating ClientSecret for AzureAD application
WARNING: This command or command group has been migrated to Microsoft Graph API. Please carefully review all breaking changes introduced during this migration: https://docs.microsoft.com/cli/azure/microsoft-graph-migration
WARNING: The output includes credentials that you must protect. Be sure that you do not include these credentials in your code or check the credentials into your source control. For more information, see https://aka.ms/azadsp-cli
Creating Resource Group
Ensuring current user has contributor permissions to ProvisionGenie resource group
WARNING: This command or command group has been migrated to Microsoft Graph API. Please carefully review all breaking changes introduced during this migration: https://docs.microsoft.com/cli/azure/microsoft-graph-migration
WARNING: This command or command group has been migrated to Microsoft Graph API. Please carefully review all breaking changes introduced during this migration: https://docs.microsoft.com/cli/azure/microsoft-graph-migration
ERROR: argument --assignee: expected one argument

The script continues but no Resource Group is created.
To Reproduce
Steps to reproduce the behavior:

Deploy using the script (https://provisiongenie.com/deploymentguide/3-deployazureresources/#deploy-using-the-script)
Open Azure cloud shell at shell.azure.com
This guide assumes the use of a PowerShell environment.
Change the working directory to the ProvisionGenie/Deployment/Scripts folder
cd ./ProvisionGenie/Deployment/Scripts
Execute the script ./Deploy-Solution.ps1

Expected behavior
The script should run and provision the Resource Group and Resources.

Hi, thanks for raising this - will look into this :-)


[SIMPLE] this console.log doesn't seem to do anything

also inlined a var since... why bother?
@dmitrig01

I would prefer to keep constants separate from code - but perhap we should change it to COOKIE_MS or something?

that way we don't have any 'magic numbers', but instead they are labelled

cool idea!

Done :)
@dmitrig01


jasypt password visible when passed as argument or System property

When an application is started in a way that is demonstrated below
java -jar target/jasypt-spring-boot-demo-0.0.1-SNAPSHOT.jar --jasypt.encryptor.password=password

java -Djasypt.encryptor.password=password -jar target/jasypt-spring-boot-demo-0.0.1-SNAPSHOT.jar

a linux user can see it by listing currently running processes. I belive that it could be solved with command:
export MY_PASSW=password
however currently required variable is 'jasypt.encryptor.password' that is not valid name for environment settings. Could that be replace with name like:
jasypt_encryptor_password

yeah, sorry, I wish Spring Boot property sources would be smart enough to automatically replace _ with . for ENV variables since . is not permitted in ENV variables.
You can solve this quickly by creating application.properties or application.yml and adding:
jasypt.encryptor.password=${JASYPT_ENCRYPTOR_PASSWORD:}

or in YAML
jasypt:
    encryptor:
        password: {${JASYPT_ENCRYPTOR_PASSWORD:}

basically what this does is to define the jasypt.encryptor.password property that points to a different property JASYPT_ENCRYPTOR_PASSWORD that you can inject any way you want (environment or system property). This technique can also be used to translate property name/values for any other library you need.

HI,
That will work then. Looks like a good solution.
On 18 December 2015 at 02:03, Ulises Bocchio<EMAIL_ADDRESS>wrote:

yeah, sorry, I wish Spring Boot property sources would be smart enough to
automatically replace _ with . for ENV variables since . is not permitted
in ENV variables.
You can solve this quickly by creating application.properties or
application.yml and adding:
jasypt.encryptor.password=${JASYPT_ENCRYPTOR_PASSWORD:}
or in YAML
jasypt:
encryptor:
password: {${JASYPT_ENCRYPTOR_PASSWORD:}
basically what this does is to define the jasypt.encryptor.password
property that points to a different property JASYPT_ENCRYPTOR_PASSWORD
that you can inject any way you want (environment or system property). This
technique can also be used to translate property name/values for any other
library you need.
—
Reply to this email directly or view it on GitHub
https://github.com/ulisesbocchio/jasypt-spring-boot/issues/17#issuecomment-165642274
.

--
Regards,
Bartosz Jablonski

I've tried this and it is not loading the password


Update Various Versions

swift-tools 5.2 -> 5.7
macOS 10.15 -> 13
iOS -> minimum 13
async-http-client from 1.2.0 -> from 1.18.0
jwt-kit from 4.0.0 -> from 4.13.0

The two dependencies shouldn't have needed a bump but I've noticed that SPM tends to be inconsistent with its version resolution and will randomly change the minor/patch version on different invocations of swift package update. This just pins the minimums to the current stable releases according to the swift tools and macOS version updates.
This would constitute a major version bump of this package, but seeing as it's currently only 1.0.0-rc.* it might be an opportunity to just release 1.0.0

Fixes #51

cc @Andrewangeta or @NathanFallet


[WIP] Tokyo CFP

What does this PR do?
Prepare the CFP page in Tokyo 2020 site.
How to see the site on my laptop?
$ git clone git@github.com:k8sjp/kubernetes-community-days.git && cd kubernetes-community-days
$ git checkout spesnova/tokyo-cfp
$ yarn
$ hugo server --buildDrafts --buildFuture
$ open http://localhost:1313/events/2020-tokyo/cfp

Motivation
We're going to start the CFP process soon. Then we need the CFP page and routing for it.
To-dos

[ ] Update cfp_deadline in _index.md
[ ] Add description to route people to the CFP page in _index.md (Overview page)
[ ] Update description in cfp.md  (e.g. How to submit?)

@Ladicle May I ask you to take over this PR since you are assigned to procced CFP part.

Sure, I'll take it.

_index.md

cfp.md


HTTP Cache Factories do not have correct names in /confMgr

Required Information

[x] AEM Version, including Service Packs, Cumulative Fix Packs, etc: 6.4.3
[x] ACS AEM Commons Version: 4.0.0-SNAPSHOT (master)
[ ] Reproducible on Latest? On master

Expected Behavior
The names in /system/console/confMgr should be accurate and meaningful.
Actual Behavior
The names in /confMgr are the same for several
Steps to Reproduce
Install latest from master and goto  /system/console/confMgr

Links
Looks like this is because OCD definitions are shared between impl's. Im not sure how to remedy this without copying the impl and updating the keys. In the case of the KeyValueConfig it seems odd these 4 HttpCacheConfigExtension would use the same one; ie I think this is a bug in the move to new OSGi annotations for HTTP Cache. Not sure about the first duplication.
/cc @niekraaijmakers

Fixed via and closing due to revert back to SCR: https://github.com/Adobe-Consulting-Services/acs-aem-commons/pull/1741


Adding support for ARMv6 on linux

This change expands on the work by @hpux735 to support ARMv6, not just ARMv7.
While making the change I noticed the ArchSubType class (which already has a bunch of ARM architectures listed).  That might be a more robust change...but ArchSubType doesn't look like its used anywhere, so I did this quicker solution that I know works.
Thoughts on whether it is worth it to try an implementation with the arm ArchType, and manage the v6 or v7 in the ArchSubType?  It makes things more complicated (have to add a subarch to Target, etc), so maybe better just use ArchType only (as I have done here)?

This successfully built on the un-official swift-arm CI infrastructure.  It should be NFC on any other arch.   LGTM.

@swift-ci please test

Just to make sure we didn't mess something up for the other build platforms, I'll kick off a CI run.


Fix weight initialisation for pretrain from scratch

Last commit (396bae5) on pretrain.py refactored model initialisation to use nn.Module reset_parameters functions but omitted a call to reset for pretraining from scratch (resume=False).
A simple fix is to add something after lines pretrain.py#L193-L195:
    if resume:
        fabric.print(f"Resuming training from {resume}")
        fabric.load(resume, state)
    else:
        def reset_weights(mod):
            if hasattr(mod, "reset_parameters"):
                mod.reset_parameters()
        model.apply(reset_weights)

Also... as the pretrain.py module is evolving towards generality, it may make sense to move the setting of initial weight distributions elsewhere. The prepare_weight_initialization function currently hard-codes initial weight distributions and specific handling of modules (e.g., LLaMAMLP). This current approach may be a burden for maintenance as more models are supported and doesn't support simple customization of initial weights.
A couple of ideas: Default initial weight distributions could be stored with the modules in model.py. It may be worth considering exposing a way to set the initial weight distribution in the model Config or TrainArgs.

Hey @tobylightheart
I made this change to speed up initialization since Fabric+FSDP can use the meta device effectively. There is no need to call reset_parameters() manually, since FSDP will do that under the hood automatically when materializing the model on the GPUS.
One possibility why it might not work for you is that you changed the code and the order of the setup maybe?
FYI the initialization is hardcoded on purpose right now for simplicity and for reproducibility. But as LitGPT will evolve I agree we need to make it configurable. It's a good idea. Same with other parameters in the script that are not exposed yet, like FSDP settings.

Thanks for the extra context. I'm currently running on a single GPU, so the pretrain setup is picking strategy = "auto". I haven't looked too deeply into it, but I suspect that the "auto" strategy for a single GPU (SingleDeviceStrategy?) doesn't automatically call reset_parameters().

Oh yeah, I forgot about that because for pretraining I was somehow locked onto FSDP as being the default. But yes we should handle the single gpu case, you're right!


on-click for paper buttons doesn't work with event.stopPropagation

This issue was originally filed by<EMAIL_ADDRESS>
I am using a PolymerJS <paper-icon-button> with an AngularDart backing model.
I have a simple AngularDart decorator that stops event propagation on the elements with the decorator.
This is the entirety of the class (imports omitted):
@Decorator(selector: '[stop-click-propagation]')
class StopClickPropagationDecorator {
  StopClickPropagationDecorator(Element element) {
    element.onClick.listen((MouseEvent event) => event.stopPropagation());
  }
}
I have a <paper-icon-button> that I would like to apply this decorator to. Something like:
<paper-icon-button stop-click-propagation on-click="doSomething()"></paper-icon-button>
Expected result:
The event stops propagating because of the decorator, but the on-click in the button still fires.
Actual result:
The event stops propagating, but on-click does not fire and doSomething() is not called.
If I change the on-click to an Angular ng-click, then doSomething() is triggered as expected.
Please include the following information:

Dart SDK version: 1.6.0-dev.9.0
polymer package version: v0.2
Operating system: Goobuntu Trusty
Browser (if any): Chrome Version 38.0.2125.111 (64-bit)

This issue has been moved to dart-lang/polymer-dart#333.


Convert to Module - Allow IntegratedSecurity to be empty

I have converted this to a powershell module, and allowed for IntegratedSecurity to be null.
I had done this a while back, just remembered it :)

Thanks for the contribution, an unexpected pleasant surprise!
I think everything in this PR and more has been done in PR #9 so I've taken that one instead of this one. Please go ahead and check the result and let us know if there's any problems or if you have any improvements.


Add datasign and related websites

Thanks for the submission @dnakagome.
You will need to sign the Contributor License Agreement before we can merge. See https://github.com/GoogleChrome/related-website-sets/pull/722/checks?check_run_id=34783325317 for more info thanks!


[DO NOT MERGE] Grabbag of various cleanups

Just a PR to hold various cleanups waiting on a more meaty PR to land

StringBuilderLong is actually a tiny bit faster for me locally, probably noisy here. Others likely are as well.

This is no longer applicable


Update README.md and CONTRIBUTING.md with Quick Install instructions and reorganize sections

Purpose

Description

Added 'Quick Install' section under 'Getting Started with Co Op Translator' in README.md with pip and Poetry installation commands.
Moved 'Prerequisites' section before 'Quick Install' for better logical flow in README.md.
Improved overall structure and readability of the README.md.
Moved environment setup options (GitHub Codespaces and VS Code Dev Containers) to CONTRIBUTING.md to keep README.md concise.
Renamed 'docs/' directory to 'getting_started/' for clarity.
Updated CONTRIBUTING.md to include development environment options previously in README.md.

Does this introduce a breaking change?
When developers merge from main and run the server, azd up, or azd deploy, will this produce an error?
If you're not sure, try it out on an old environment.
[ ] Yes
[x] No

Type of change
[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[x] Documentation content changes
[ ] Other... Please describe:

I have reviewed the changes and everything looks good.


Update readme with demo

Hey @NullSense this is really cool, but since the video is private I'm afraid it may be archived after a week, see the blog post.
I don't know this for sure, but I'm just cautioning you as I've seen it happen recently.

Hey @NullSense this is really cool, but since the recording is private I'm afraid it may be archived after a week, see the blog post.
I don't know this for sure, but I'm just cautioning you as I've seen it happen recently.

Yeah, it actually happened to my last recording, it says the vid is linked to my account, but private, I will try and make it public.

made it public, now it should be fine for sure.

Nice, but the README still has the private version. I found the public one here: https://asciinema.org/a/390806, so you should update the readme with that one.


Fix resolution of absolute pkg-config dependencies

According to pkg-config specification and implementation, if a dependency name ends in .pc, the name should be treated as an absolute file path.
The issue can be reproduced by trying to wrap Gtk+3 into a system library package. gobject-2.0.pc in the pkg-config dependency chain has a private dependency as a file path:
prefix=/usr/local/Cellar/glib/2.64.3
libdir=${prefix}/lib
includedir=${prefix}/include

Name: GObject
Description: GLib Type, Object, Parameter and Signal Library
Version: 2.64.3
Requires: glib-2.0
Requires.private: /usr/local/opt/libffi/lib/pkgconfig/libffi.pc >=  3.0.0
Libs: -L${libdir} -lgobject-2.0
Libs.private: -lintl
Cflags:-I${includedir}

The issue started appearing in Swift 5.2 when SPM started parsing Requires.private.
This PR aligns implementation in PkgConfig.swift with the official pkg-config implementation.

Thanks for the fix!  It would be good to also extend the test case in PkgConfigTests.swift (and associated test fixtures) to cover this case.

@swift-ci please test

@srdanrasic Thanks for this fix!  Could you please also update the unit test case in PkgConfigTests.swift (and associated test fixtures) to cover this case, so that we don't lose ground on unit test coverage?  After that we can merge this.  Thanks!

Hey @abertelrud, I apologise for the slow response.
I was about to add testing, but after rebasing I found out that this problem has already been fixed on master. Following is the commit that fixes the problem, albeit in a different, probably better, way: https://github.com/apple/swift-tools-support-core/commit/1a31e5c1b2e7c17d7cd6b50dc84318b0fb55c39d#diff-fb61758d0f0fda4ba867c3d5a46c16a7
I guess it would make sense to close this PR then.

@srdanrasic thanks for the reference!  I didn't realize that this had been changed.  If you are satisfied with the other fix, then yes, this can be closed.  But if you feel that there are aspects of yours that should be incorporated into the other fix, you could just modify the PR to add those (or open a new one if you wish).

I'm not an export on PkgConfig, but the other solution looks good to me and solves the problem I had so I'll close this PR. Thanks anyway 🙂


Edit collections

Allow to create and edit Collection of IDs dynamically via Rollout UI
@GonchuB what about it?.. The only command that I can't use was the contain_exactly, because it was included on rspec >3

This one is good to good, just the very little comments. You should wait for the restorando/rollout pull request is merged to master to update the gemfile (remove branch: "") and gemfile.lock. But this one is a :+1:


feat: Deprecate API keys methods on Index in favor of Client ones

Summary
As discussed with @maxiloc and @julienbourdeau, the API key methods are supposed to only be implemented at the client level, not at the index level anymore. This is due to the fact that per-index keys are not available via the dashboard and we do not want users to use them anymore.
Result
N/A

We can do another pass later to remove tests :)

Deprecated method are still part of the public API so I'm not sure about removing tests. If you do, you need to make sure it would get broken later. 👌


Keyboard Shortcuts for TM:PE

GUI settings page for keyboard shortcuts.
TMPE main window and 6 most used tools can be used with keyboard.
Settings are automatically saved by ColossalFramework.
Tooltips are shown on the menu buttons for the current keyboard shortcut.
FIXME: Tooltip on main crown button is not shown.
Stay in lane Shift+S shortcut does work

Working to add another commit to this, which will also allow customizing Shift+S stay in lane key shortcut. At the time of writing, it works if it is not Shift+S for me, so something else is blocking it.

I think you forgot to add KeyMapping.cs to csproj because our CI is failing 😉

I need some help with Shift+S shortcut, it seemed to not work for me.
It works if I use something other than Shift+S though.

I'm not sure how the game's own keymapping system works. Maybe it treats every shortcut as globally unique, rather than tool specific?

I will try to check what is going there when I'll be back home :wink:

Ok, I think I found possible cause... https://github.com/krzychu124/Cities-Skylines-Traffic-Manager-President-Edition/blob/1f671ed2d0025b7f3a0be551d4e8c5d5c0dcf4bc/TLM/TLM/UI/SubTools/LaneConnectorTool.cs#L191
This Event.current is not the same even as that triggered in OnGui() method... Inside OnGui() Event has KeyCode.S but this Event.Current doesn't (it has character field set to 83'S', instead of KeyCode enum).
Main part of source code of public bool IsPressed(Event e)
// keyCode is our KeyCode to test against
// e.keyCode comes from Event
return keyCode != KeyCode.None && e.keyCode == keyCode && ... //and more checks there

Another issue, when I switched to Polish lang, tabs are wider and Keybinds tab is not accessible/not visible at all. (I will try to change translation of Maintenance tab in Polish)
Additionally sometimes some key combination Ctrl+Alt+C is locking in-game movement with WASD and mouse middle button - I can't rotate camera. Maybe not related with this PR

Fixed Shift+S shortcut now works, also done Delete/Bkspace in the same way, but did not add a new saved inputkey for it.

Just pushed a commit that renames "Policies & Restrictions" tab to just "Policies". This should solve the issue with not enough space on the tab bar.
I haven't changed the locale key, that can wait until we do the transition to xml locale files. See commit description for more infos.

@kvakvs Can you check through the list of changed files on this PR and see if any of them are also altered by PR #260 (Migration to Harmony) - if so this PR #382 will need to wait until after the harmony update is done IMO.

@aubergine10 Harmony PR changes 237 files and 10k lines, but i don't see a significant overlap.
There is overlap of course but in a few minor locations.

Which minor locations specifically? We need to assess what the impact will be of merging this PR 382 prior to Harmony. If it's not going to cause much pain then I think this PR 382 could potentially get rolled in to the v10.21 milestone (next planned release).

Is there a way to remove shortcuts I don't use? For example, if I rarely use timed traffic lights, I don't want keyboard shortcut lingering for that, so I'd want some way to clear it. Maybe a small ( x ) button at side of the current shortcut box to clear a shortcut?
Also, I think we should be defaulting to not defining the shortcuts - there are lots of other existing mods with customisable shortcuts so pushing a TM:PE update with pre-defined shortcut keys could conflict and cause problems for users. It might be better to leave the shortcut boxes empty by default so users can define their own and will thus know the reason for any shortcut conflicts.
For the TM:PE menu bar, however, I think we could potentially pre-define its shortcut. When I thought about shortcuts a few months back, I was thinking of maybe using Shift + ; (in other words: : like the colon in TM:PE) - I haven't seen anything else using that so it should be conflict-free. Of course, users can easily change it to something else if they want.

To remove it, instead of it being a button, do what most games do and when you click on it to change it allow the user to press "ESCAPE" to remove the shortcut

Yup, that would work (especially as we don't want Esc to ever be used as it's the hard-coded "exit from (sub)tool" button). But then user would have to know about pressing Esc to clear shortcut, so I still think a ( x ) button would also be useful as a visual cue (it's tool tip could mention the "Esc to clear a shortcut" maybe?)
One other thing I just realised (while working on docs for this feature)... I assume at a later date we will extend that Keyboard tab in mod options to include all the sub-tool shortcuts as well? If so, they would likely get their own sections what would become a scrolling panel. That being the case, I think we should rename the "Keyboard" section heading to "Toolbar" or "Tools". And then at later date tool specific shortcuts would get their own sections like "Lane Connector Tool" or whatever.

And... This tab will become the go-to reference for users in terms of shortcuts. Is it possible to add a read-only shortcut to the top of the current list:

Exit from active tool or sub-tool  [ Esc         ]

@aubergine10 I've tried merging this onto master and then merging Harmony PR onto of it, besides of the fact that I could not compile the end result, i did not find any overlaps or conflicts in the code which I have edited. There were Harmony branch vs master branch conflicts though.

@kvakvs don't forget to sync RedirectionFramework submodule, and switch to customization/TMPE branch there before building mod

TODO: We probably want to categorize our keys too, and only find conflicts within same category. Example: Lane connector uses Shift+S, i want to only check for conflicts within other Lane Connector keys and other tools are welcome to share the key.

Can you add a blank line between the text and the name of the other shortcut to aid readability?

Added categories to the keys.
Now if the key belonged to anything other than "Global", like Lane Connector key, it will only search for conflicts within the Global and its own category, which will allow us to reuse same key in multiple tools.

Solved the merge conflicts by joining all additions to translations together.

Finally got round to doing some testing on this PR...
The main TMPE button doesn't have a tooltip (thus doesn't display keybind):

Stating 'None' when there is no keybind looks weird:

If no keybind it would be better to just not output the keybind line of the tooltip.
Looks like a locale string is missing for this keybind:

Also, note that most Mac keyboards don't have a Delete key. As such, we should always treat Delete and Backspace as synonymous.
I noticed that the only way to delete an existing keyboard shortcut is to go in to 'define mode' and then press Delete (pressing Esc merely cancels 'define mode'). I still think having a little x button next to defined keybinds would be a better way to remove them.
Can we treat ; and : as synonymous? And have : shown as the default shortcut for the TM:PE main menu?
Upon adding a shortcut for a tool (S for speeds) I expected that just pressing S would enter that tool, even if main menu wasn't open, but the main menu needs opening first before it can be used (I agree with this approach btw). So I was wondering if some sort of indenting would help clarify what's going on:
// note: I'm using [whatever] to denote read-only fields

* = Can be repeated to cycle through options

Toggle TM:PE menu bar                   :
  Toggle Traffic Lights
    Toggle lights                    [Click]
  Lane Arrows
    (wait for PR #391)
  Lane Connections
    Select node/lane                 [Click]
      Stay in lane *                Shift + S
      Reset to default               Delete
      Exit node/lane              [Right Click]
  Priority Signs
    Select node                      [Click]
      Change sign *                  [Click]
      Apply to route              Shift [+ Click]
      Exit node                   [Right Click]
  Timed Traffic Lights
    Select node                      [Click]
  Junction Restrictions
    Select node                      [Click]
      Toggle restriction *           [Click]
      Exit node                   [Right Click]
  Speed Limits
    Select / apply speed             [Click]
    Apply between junctions       Shift [+ Click]
  Vehicle Restrictions
    Toggle restriction *             [Click]
    Apply between junctions       Shift [+ Click]
  Parking Restrictions
    Toggle restriction *             [Click]
    Apply between junctions       Shift [+ Click]
  Exit tool or menu bar               [Esc]

When a key modifies a click, we should append  + Click to the keybind to make it obvious what the user has to do.
Note that the [Right Click] could be [Left Click] depending on OS mouse button settings. The game somehow automagically handles this by silently swapping left/right clicks so there must be a way to detect how the mouse is configured.
The indentation not only acts as an interaction guide for users, but it also indicates keybind scoping for developers.

The UI uses a template object from the game, with a label and a button for keyboard shortcut. Modifying it will require recreating each row instead of instantiating that template.
Adding a second alternate shortcut might be a good idea, then we can bind Delete and Backspace.
Changing how just keyboard bindings are converted to string is not a good idea, not worth it in general without reworking the whole thing with table of keys and localization and everything.

Adding a second alternate shortcut might be a good idea, then we can bind Delete and Backspace.

Yes, this would be good.

The UI uses a template object from the game, with a label and a button for keyboard shortcut. Modifying it will require recreating each row instead of instantiating that template.

If we modify layout so that there are three columns (label, main key, alt key) could we use the alt key column for static '+ Click' on those click modifiers?

Changing how just keyboard bindings are converted to string is not a good idea, not worth it in general without reworking the whole thing with table of keys and localization and everything.

Is this relating to keybind table or the tooltips?

The UI uses a template object from the game, with a label and a button for keyboard shortcut. Modifying it will require recreating each row instead of instantiating that template.

If we modify layout so that there are three columns (label, main key, alt key) could we use the alt key column for static '+ Click' on those click modifiers?

I think so? I need to rethink this today after work. Modifier editor will be something different from a keyboard combination editor.

Changing how just keyboard bindings are converted to string is not a good idea, not worth it in general without reworking the whole thing with table of keys and localization and everything.

Is this relating to keybind table or the tooltips?

Both actually. It is that to localized string call which displays the tooltip, i do not want to go and replace single keys in that algorithm because it is large with large localized lookup tables for the whole keyboard.

For the tooltip, is it possible to alternate choice of what type of tooltip is used depending on presence of keybind?
Specifically, having "None" shown after a tool name, for example Junction Restrictions \n None makes it look like "there's no junction restrictions".

For the tooltip, is it possible to alternate choice of what type of tooltip is used depending on presence of keybind?
Specifically, having "None" shown after a tool name, for example Junction Restrictions \n None makes it look like "there's no junction restrictions".

Of course it is possible. I'd like some way of saying that there could be a tooltip but you didn't set it, instead of it just disappearing. Disappearing is probably fine too.

I have a feeling that the options GUI only allows adding one object per row. So there might be some fancy programming required to make a Unity GUI template with the elements we want, to have it laid out horizontally.

For scrolling and layout in general, see IncompatibleModsPanel.cs in PR 333 (it could probably be tidier, but it should give general gist):
https://github.com/krzychu124/Cities-Skylines-Traffic-Manager-President-Edition/pull/333/files#diff-9a8fe4814d86ff2f1a6af2df21667314
I assume for settings panel to scroll we'd have to just work out the width/height or something. The Ambient Sounds Tuner (git repo) mod has a scrolling settings panel.

I have a feeling that the options GUI only allows adding one object per row

I am not sure what do you mean, but I've just checked sources and for example ContentPanel/Savegames uses scrollpanel and list of items (each item has a lot of different buttons and labels).
In ModTools each entry is visible as SaveEntryTemplate(clone) which suggest that they supply tab template with saves list and then they clone entryTemplate internally for each entry. Each ContentPanel/Options tab layout seems to be defined by template of particular Package.AssetType.
All option templates were probably designed and built in Unity and game only loads those templates and fill them with data.
We have to do that manually so I think there is no limit what we could create there.

Untabified files affected by this PR, looking better in general

[x] Translations: added missing one, added missing lines to the template
[x] Having no key will not show "None" in tooltips
[ ] 👑 button tooltip is missing
[ ] Change keybinds GUI

[ ] Add delete button to the keybinds GUI like ❎
[ ] Dual keybinds for some shortcuts
[ ] Add "+ Click" support for some shortcuts (allow to only select control keys)

Got something brewing here

Will test later tonight.
For the ones with two keys, is it possible to put them side by side?
Clear lane connections          Delete    Backspace

@aubergine10

Current problem: Scroll panel is not really scrolling or showing any scroll elements.
Also i don't have enough scroll elements for it, so can fix that later.

We can do the extra keybinds stuff in a later PR to give some more time to get the scrolling working properly and wire the other shortcuts in etc.
Will be testing in about 1 hour or so.

I'm currently resolving the merge conflicts from recent PR merges....

Found an issue, just trying to replicate...

It's possible to close the content manager while mod options screen is still open, resulting in un-closeable mod options screen.
Steps to reproduce:

Main Menu > Content Manager > Mods > TM:PE > Options
Select keybinds tab
Click a keybind button (I chose one captioned None, specifically the Toggle Traffic Lights keybind, but I'm not sure if that matters)
Button shows Press any key
Press Esc - this is where stuff starts getting weird:

Button seems de-selected, but continues to show Press any key

It seems that at this point the mod options modal ceases trapping keyboard or mouse input
I can click through it on right side to select mods in the content manager behind it
I can close the content manger, but the mod options dialog stays open

It's a bit hit and miss. Also, I just managed to get same sort of issue by assigning a keypress - I tried a few keys first that were already assigned to stuff; the "already assigned" warning appeared (correct) and the button went back to None after closing the warning (correct). However, I then choose a key that wasn't assigned to anything - the button remained Press any key and the entire options dialog became non-responsive (no longer trapping keyboard or mouse).
output_log.txt

Minor issue: Superfluous X text label over the "remove keybind" buttons.

I think i've managed to fix the button stuck in press any key, by adding a callback on modal pop (the edit keybind button temporarily becomes a modal, and now when it closes, the edit mode will be ended).

I've got a new bug. The same problem as @aubergine10 but other trigger.
I've set the same key shortcut C or N (not used by game itself) for more than one feature.
No warning about keybind duplicate. Couldn't close options dialog
NullReferenceException: Object reference not set to an instance of an object
  at TrafficManager.State.Keybinds.KeybindSetting.NotifyKeyChanged ()

and then:
InvalidOperationException: Trying to close a modal panel not on the top of the modal stack
at ColossalFramework.UI.UIDynamicPanels.Hide()

I've just noticed with the mod incompatibility checker that if you Esc out of it, back to main menu, you can't Esc to exit the game. So maybe something changed in the modal popup system recently?

@aubergine10 so far, it is due to terrible modal stack handling by me. I am fixing it.
Does incompatible mods dialog set modal and not clear it at the right time? Might be a similar problem.

Looking at the code, the mod checker should be clearing the modal properly, and it certainly works from a visual perspective most of the time, however @krzychu124 is going to be digging in to that tomorrow to make sure. He discovered today that sometimes the modal is blurred, like it has the wrong z-order and appears behind the "blur" effect thing.

Just reviewing changed files and noticed the Russian translations were updated - was that you Kvakvs? (for changelog mention)

One of the German locale strings is too long:

Keybind options tab UI feels very solid. Tried everything I can think of and so far not been able to break it. It feels nice and responsive too, and looks really great.
I noticed in code some stuff about row striping, but didn't see any on the UI? (not important, just mentioning it in case the rows were supposed to be striped)

@aubergine10

I noticed in code some stuff about row striping, but didn't see any on the UI? (not important, just mentioning it in case the rows were supposed to be striped)

The row striping code is still there. But in the old dialog the default background was grey-ish, and row striping code just cleared texture on some lines. In the new dialog i've no idea what the background sprite name is, so they are all black (i.e. not striped). Have to go into ModTool or UIHelper source and find the background sprite name which is used in other dialogs.

LGTM!
@kvakvs Think we can merge this now - but there's some inline tasks (eg. in OP) - do you want to carry those over to another issue (eg. #402 )?

Resolved merge conflict that was caused by #400

@aubergine10 You've already moved that +click task into #402 so that kind of removes it from here


chore: bumped up go-kong and added changelog updates

I have added all changelog updates together here.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 29.58%. Comparing base (6798b91) to head (ce39ed8).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1401      +/-   ##
==========================================
+ Coverage   29.52%   29.58%   +0.05%
==========================================
  Files          59       59
  Lines        5138     5138
==========================================
+ Hits         1517     1520       +3
+ Misses       3512     3510       -2
+ Partials      109      108       -1

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