Update Learn modules for Key Vault

This issue is to review the learn modules in https://docs.microsoft.com/en-us/learn/ that are for Java developers in the area of Key Vault and update them if they are not using the latest version of the Key Vault package

Closing in favor of the change in scope in https://github.com/azure/azure-sdk-for-js/issues/12369


Recordings seem to be corrupted or incomplete.

First, thanks for writing this amazing project. Makes me want to learn and work with go myself.
Everything seems to be working fine and the recordings seem to be complete and valid. But when I start the game using the "replay <IP_ADDRESS>:9000 ..." command I get the following error:
<unknown>(0xa98101c0):  ERROR| Failed to extract information from command line string for normal game mode
If I try running it with the "spectator <IP_ADDRESS>:9000 ..." command the replay starts at the last 30 seconds of the game and then ends.
In both cases I'm getting the following compression error at the start:
/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Common/ChunkCompression.cpp:50: Error: unsupported compressor 8 /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Libraries/CompressData/CompressData.c:353: Error: Unknown compression scheme encountered for file '/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/Exceptions.plist' /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Common/ChunkCompression.cpp:50: Error: unsupported compressor 8 /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Libraries/CompressData/CompressData.c:353: Error: Unknown compression scheme encountered for file '/System/Library/CoreServices/CoreTypes.bundle/Contents/Library/AppExceptions.bundle/Exceptions.plist'
Any idea on how to solve this?

Ah, you might be running the command line arguments a bit off? I'm not too sure, I haven't used my program in a long while, primarily because the League client has replays officially. Your best bet is to copy the OP.GG spectator script and modify it to contain the appropriate replay string.
Here's one for example:
cd /Applications/League\ of\ Legends.app/Contents/LoL/RADS/solutions/lol_game_client_sln/releases/ && cd $(ls -1vr -d */ | head -1) && cd deploy && chmod +x ./LeagueOfLegends.app/Contents/MacOS/LeagueofLegends && riot_launched=true ./LeagueOfLegends.app/Contents/MacOS/LeagueofLegends 8394 LoLLauncher "" "spectator f2.spectator.op.gg:80 RMrUoCOQaz3SPT+fo6/CWvds1N3FjXFe<PHONE_NUMBER> NA1"

I think when using spectator and it starts at the last 30 seconds is normal, because the client tries to seek as far forward as possible to be "realtime". In older versions of my code I supported using spectator by throttling the rate at which the client can retrieve the chunks so it starts at the start. Now, I use replay mode because it allows you to seek anywhere in the replay without having to wait for the throttling.

Hi @1lann, thanks for the answer!
I have already tried using the op.gg command as a base. That's where I got the idea of using the spectator client.
I'm running fish so the command is a little different:
cd /Applications/League\ of\ Legends.app/Contents/LoL/RADS/solutions/lol_game_client_sln/releases/; and cd (ls -1vr -d */ | head -1); and cd deploy; and chmod +x ./LeagueofLegends.app/Contents/MacOS/LeagueofLegends; and env riot_launched=true ./LeagueofLegends.app/Contents/MacOS/LeagueofLegends 8394 LoLLauncher "" "replay <IP_ADDRESS>:9000 RAF8SGZj9X0TFvzZkbIKlYivY7hcqOQN<PHONE_NUMBER> BR1"
Maybe this is a problem with MacOS? I will try to run the server from a docker container to see if solves the problem.
Another thing that I noticed is that during the recording the server does not identify the type of game being recorded.
The error mentions a "normal game mode" but it is actually a ranked game. I don't know if that's what "normal game mode" is referring to but could be a lead.
 It seems like there is no way to use the replay client to run the recordings. OP.GG is using the spectator client and it seems to be having the same issue of games being incomplete and not starting at the start.
This is a core feature for my project. I need to be able to save and replay third party games, so it's not possible to get .rofl files. Maybe this is a roadblock for this project... Do you think there's anything I can do to make it work?

The ROFL file format is actually standardized and developed before Riot Games made them AFAIK. I kinda unfortunately in this case decided to not use the ROFL file format, but perhaps it is possible to encode the data into the ROFL format? Although I semi-doubt it at the same time because this issue implies that Riot changed something partly fundamental to the spectator endpoint.
You can try to reverse engineer the protocol yourself, that is afterall how I developed this project in the first place. I did this by using Wireshark, and spectating someone normally. Then I looked at the data sent in Wireshark and wrote some code to try to replicate the HTTP endpoint behavior.  I did a partial write-up about how it works here: https://gist.github.com/1lann/885f6b85b99d19b88bec
If you're not already on the Riot Games API Discord server, you can drop in and ask, there are lots of people there with different experiences in working with replays who may have more up to date knowledge about the spectator endpoints now: https://discord.gg/uYW7qhP

Thank you, for taking your time to write this project and answer me.
I think reverse engineering the API is beyond me, but I'll dig into it anyway.
It seems that even the normal client is having some issues with the spectator endpoint, I will wait to see if this is a patch bug or if they indeed changed something fundamental.


Update config to enable docfx v3

Docs Build status updates of commit f5a6e7e:
:warning: Validation status: warnings

File
Status
Preview URL
Details

:warning:Warning

Details

.openpublishing.publish.config.json
:white_check_mark:Succeeded

.openpublishing.redirection.json
:white_check_mark:Succeeded

docs/index.md
:white_check_mark:Succeeded

[Warning-UserDefinedServiceAccountOAuthScopeInsufficient] User defined service account 'o365devx' cannot be used to build repository https://github.com/OfficeDev/open-xml-docs due to lack of correct OAuth Scopes. The Build will fallback to use the repository owner's account to continue the build. To resolve this warning, please log onto the Docs Portal (https://ops.microsoft.com) with the account 'o365devx' or ask the repository admin(s) to go to Docs Portal and update user defined service account list.

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


Reference tests loopMul failure

Description
I've re-implemented retesteth tests executor for our usecase and the only test failing is vmPerformance/loopMul, same as on retesteth's website
I did the analysis of why it happens usind debugger and I found the following:

Gas limit is set to Long.MAX_VALUE in the genesis file
Transaction's expected gasLimit is set to the same value
When a new block is mined by test_mineBlocks method, gas calculator is trying to get closer to the desired gas limit, which is hardcoded to 10M
Since parent's (genesis file) gas limit is higher than the target gas limit, gas limit for the next block is set as Long.MAX_VALUE - AbstractGasLimitSpecification.DEFAULT_MAX_CONSTANT_ADMUSTMENT_INCREMENT which is less than transaction's gas limit.
Transaction is not included in the block, the mined block doesn't contain the expected transaction

Steps to Reproduce (Bug)

Run retesteth with besu -t GeneralStateTests -- --all --lowcpu -j1, as specified here. More info on retesteth here

Expected behavior:
vmPerformance/loopMul test should pass
Actual behavior:
It fails with
[0;31mError: StateTest::FillTest: TR hash not found in mined block! (Check that tr is properly mined and not oog) (vmPerformance/loopMul, fork: Berlin, TrInfo: d: 0, g: 0, v: 0, TrData: `:label add-10M

Proposed solution:
Instead of using the hardcoded value of 10M we can

Use Long.MAX_VALUE instead so gas limit calculation always would took a step upwards which would make the tests more permissive in terms of gas limit
Take gas limit from blockchain.getChainHeadHeader().getGasLimit() which would make gas limit constant for a test chain from block to block and equal to the value in genesis file. This option makes more sense to me.

Frequency:
This issue is not flacky. It happens all the time
Versions (Add all that apply)

Software version: 22.4.1
OS Name & Version: Whatever is in Besu's docker image (hyperledger/besu:develop-openjdk-latest)
Docker Version: 20.10.17

Additional Information (Add any of the following or anything else that may be relevant)

Besu setup info - reference tests setup
System info - 4 Cores (8 hyperthreaded) 2.4 hz Intel i7, 32 GB RAM

Sounds reasonable.  I prefer #2, where the gas limit comes from the gasLimit in the genesis block of the test or currentGasLimit from the env where the test is not block based.  This opens up the tests to test behavior when gas limits are violated, setting it to Long.MAX_VALUE prevents block OOG from tripping.

@shemnon The PR is ready, please take a look


uuid alternative

Hi, I don't have time to do a fork and make a pull request, but here is code which might interest you, it provide an alternative to uuid -v4 (or to /proc/sys/kernel/random/uuid )
# generate an uuid -v4 using pure bash
function uuidBash ()
{
    local N B C='89ab'

    for (( N=0; N < 16; ++N ))
    do
        B=$(( $RANDOM%256 ))

        case $N in
            6)
                printf '4%x' $(( B%16 ))
                ;;
            8)
                printf '%c%x' ${C:$RANDOM%${#C}:1} $(( B%16 ))
                ;;
            3 | 5 | 7 | 9)
                printf '%02x-' $B
                ;;
            *)
                printf '%02x' $B
                ;;
        esac
    done
}

Thanks for this!

Added. :+1:


Fix retained msg persistence/replication race issue

Persisting retained messages to plumtree is handled within the
vmq_retain_src gen_server by folding over the ?RETAIN_UPDATE ets
table. After this fold is complete all objects in the ?RETAIN_UPDATE
table are deleted.
This creates a race-condition as new retained messages are inserted
into the ?RETAIN_UPDATE table outside of the vmq_retain_src
gen_server and it is therefore possible that rows are inserted between
the fold has finished and the objects are deleted, thus some updates
will be forgotten and never persisted (and therefore never replicated
to remote nodes!)
The naïve approach would be to move the insertions into the ETS table
into the vmq_retain_src gen_server, but having to call into a
gen_server for each retained message would likely quickly become a
bottleneck.
Another approach would be to only delete the entries from the
?RETAIN_UPDATE table we've persisted. But even that is prone to a
race-condition because a new update could happen between reading from
the table and deleting the entry. This race-condition would be much
more rare than the one above where all objects are deleted in bulk.
The solution is to use a counter. Each update  a counter
and every time an object is persisted the counter is
decremented. After the persist fold we delete all elements which have
a counter of zero (no pending updates).
This approach means we may write the same value more than once, which
is a good tradeoff compared to losing the value entirely.

I just realized there is a corner case if the same key is written to many times. This would make the counter increase to some value X and only be decremented by one in each persist loop. That's a pretty nasty problem. Looking into how to overcome that.

Pushed a fix for the corner case mentioned (squashed)

@larshesel  since I am not familiar with erlang, as what you mentioned that, the approach means same value will be written more than once, will there be a chance for the second record is overriden by the first record?

@edwinAtWiz no. It's just we may end up writing the same value an extra time if we should trigger this race condition window. But this window has been reduced dramatically due to other changes as well.


docs(api) add resources to GlobalInsights + more

Structure of GlobalInsights changed to allow return more of global
resources
Signed-off-by: Bart Smykla<EMAIL_ADDRESS>

This is an API break; is that intended?

@bartsmykla how do we want to address James's question?

yes it is, but it's within the same version, as the one before was not released


Updating to RHEL 8 and 9 and removing Ubuntu patch

Product Version(s):

Issue:

Link to docs preview:

SME review:

[ ] An SME has approved this change.

DOCS review:

[ ] A member of the docs team has approved this change.

Additional information:

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Closing this duplicate, fix will be in https://github.com/tigera/docs/pull/500


KEEP THE SCREEN ON

The cameraApp screen turns off after a short while, even in the middle of detection.
Need to add a config to keep it on.

Now fixed.


Add allocation percentage change info string

Purpose
This quick PR improves the allocation percentage change info string. I personally find the percentage increase/decrease easier to understand than the delta.
Content

Updated the @info string showing an allocation percentage increase or decrease

Review checklist
I have:

followed the codebase contribution guide: https://clima.github.io/ClimateMachine.jl/latest/Contributing/
followed the style guide: https://clima.github.io/ClimateMachine.jl/latest/DevDocs/CodeStyle/
followed the documentation policy: https://github.com/CliMA/policies/wiki/Documentation-Policy
checked that this PR does not duplicate an open PR.

In the Content, I have included

relevant unit tests, and integration tests,

appropriate docstrings on all functions, structs, and modules, and included relevant documentation.

[x] I have read and checked the items on the review checklist.

LGTM, should we change $percent_alloc_change" to $percent_alloc_change %" and change percent_alloc_change = (1 - Δallocs) * 100?

Done! Thank you

bors r+

bors r+

Hey @charleskawczynski , I'm not sure why this PR would fail the allocation test since it's only adding a string print. Should I modify the reference value?

@valeriabarra this could be because this is testing a threaded run, and the allocations can fluctuate a little. We can connect tomorrow to address it.

Yes, we use a buffer in ClimaAtmos to make the test more robust

bors r+


New Account - Pin Concierge conversation for new accounts

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Create a new account in New Expensify

Expected Result:
Concierge conversation should be pinned so the user has easy access.
Actual Result:
Concierge conversation is not pinned.
Workaround:
None needed.
Platform:

Where is this issue occurring?

Web
iOS
Android
Desktop App
Mobile Web

Version Number: 1.1.8-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL:
Issue reported by: @quinthar
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1634498878398600
View all open jobs on GitHub

Proposal
In SidebarScreen.js
Subscribe SidebarScreen to reports (ONYXKEYS.COLLECTION.REPORT)
For a new user, find the Concierge chat report, and toggle the pin for it.
import {isConciergeChatReport} from libs/actions/Report
import {togglePinnedState} from libs/reportUtils

if (isFirstTimeNewExpensifyUser) {
    const conciergeChatReport = _.find(this.props.reports, (report) => {
        return isConciergeChatReport(report);
    });
    togglePinnedState(conciergeChatReport);
}

https://github.com/Expensify/App/blob/628306aa7a6f926b15696414c2f6325be0fe5cd7/src/pages/home/sidebar/SidebarScreen.js#L70
Result
https://user-images.githubusercontent.com/29673073/138575363-43e13cf6-c667-4a5b-a2cf-45c75ece5e0e.mp4

This issue has not been updated in over 15 days. @luacmartins eroding to Monthly issue.
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

PR merged 23 days ago. Closing issue.


chore: small generalization of finsupp lemmas

Noticed whilst doing my other PR about char_zero. Leaves statements that create data alone.

bors r+


tch dependency is out of date

The current release 0.6.1 targets tch 0.12.0. The project has been updated to tch 0.16.0, but this has not been published yet. I would love to have an up-to-date release of the crate.

I would be happy to accept a PR

This doesn't require a code change, it requires publishing a new release of the crate.

I've published a new version (0.6.2) than contains the desired changes


Add custom oEmbed finders for Facebook and Instagram

Thanks for contributing to Wagtail! 🎉
Before submitting, please review the contributor guidelines https://docs.wagtail.io/en/latest/contributing/index.html and check the following:

Do the tests still pass? (https://docs.wagtail.io/en/latest/contributing/developing.html#testing)
Yes
Does the code comply with the style guide? (Run make lint from the Wagtail root)
Yes
For Python changes: Have you added tests to cover the new/fixed behaviour?
Yes
For front-end changes: Did you test on all of Wagtail’s supported browsers? Please list the exact versions you tested.
No front end changes
For new features: Has the documentation been updated accordingly?
Yes.

This incorporates code from @originell on issue #6391 (and information from his blog post)

Merged in 28cee081b2743acd05706504016aaae5025d8c33 (master) and 2fdb2e8aef5932be118d9e277397f25115ea588a (stable/2.11.x).


Check for successful Reinterop init before calling into C++ static methods

Fixes #230
Actually I'm not totally sure it does, because I can't reproduce #230, but I can see how it might happen. This PR makes sure reinterop is initialized before calling into any static C++ methods. If the C# and C++ code are out of sync, the initialization will throw an exception, rather than calling a function pointer using possibly the wrong signature and crashing.

I think this worked, it's no longer crashing for me! 🎉


Support Node shebang scripts

Fixes #69.

I've added the features of #107 to this PR, without making the shebang explicit in the API and instead just passing it through in the code source as suggested.

@guybedford can you re-base please?

Rebased.


No launch feedback

VSCode Version: 1.47.3
OS Version: Manjaro Linux KDE Plasma edition 20.03

When launching any application, I get a loading animation on the app icon and a bouncing app icon under my cursor. It's called "Launch Feedback". When launching VSCode, there is no launch feedback. Here is the screenshot taken while launching an application:

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

@ARTech-7
Did you install it using snap? If so, the icon doesn't show up for me, so perhaps it's a problem with how snap runs it?

@CoffeeFueledPanda Snaps are not good. I never use Snaps. I installed it through AUR on Manjaro.

@CoffeeFueledPanda Snaps are not good. I never use Snaps. I installed it through AUR on Manjaro.

Understood, did a little test, seems to just be a problem in general.

So, this issue is being worked on, right?

Same issue in Kubuntu 20.04, both for snap and deb installations.

No launch feedback on kubuntu 20.10 as well. Plasma 5.19.5, Framework 5.74

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.
If you wonder what we are up to, please see our roadmap and issue reporting guidelines.
Thanks for your understanding, and happy coding!


IP Camera Motion detection - "json obj data unvalid"

Hi,
first of all I would like to thank you for this cool project.
I am using a tuya IP camera and would like to trigger an event if motion is deteced.
Unfortunately I also have the problem that the device returns "json obj data unvalid" if I try to get the schema.
Is there a another way to get the list of dps or an event?

json unvalid is a known issue #14  .
Can you double check that either ip or vitual id is used. ?


How to select db for cluster ？

How to select db for redis cluster

Jedis cluster supports select db

From Redis website - link

Redis Cluster does not support multiple databases like the stand alone version of Redis. There is just database 0 and the SELECT command is not allowed

From Redis website - link

Redis Cluster does not support multiple databases like the stand alone version of Redis. There is just database 0 and the SELECT command is not allowed

Some cloud services support cluster selection db, should we also support it?


Fix bundle build workflow

Porting of the changes from https://github.com/Kuadrant/authorino-operator/tree/v0.9.0 to fix the release workflow and manifests building.

Sure latest commit added where I ran make manifests bundle CHANNELS=stable DEFAULT_CHANNEL=stable

Actually, maybe I should set CHANNELS=stable by default in the Makefile, the default with --overwrite behaviour from operator-sdk is to set it to alpha when not defined

Oh maybe the same should be true for DEFAULT_CHANNEL - verify fails as it does not set either of these by default

Codecov Report

Merging #153 (b1a13fa) into main (aee73cf) will increase coverage by 1.36%.
The diff coverage is n/a.

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

@@            Coverage Diff             @@
##             main     #153      +/-   ##
==========================================
+ Coverage   62.85%   64.21%   +1.36%
==========================================
  Files           1        1
  Lines         735      735
==========================================
+ Hits          462      472      +10
+ Misses        222      213       -9
+ Partials       51       50       -1

Flag
Coverage Δ

unit
64.21% <ø> (+1.36%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.
see 1 file with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

I have changed the behaviour to default to alpha on the main branch. When we provide the DEFAULT_CHANNEL and CHANNELS as part of the release workflow the bundle.Dockerfile and bundle annotations will be updated to the correct channels.
If we want to build catalogs from main branch and test the upgrade from a previously released bundle version we need to specify stable for the channels above when building the bundle from main.


Add sonarcloud.properties file to root

Per discussion in Security WG 17-July-2019 we need to capture a SonarCloud report and analysis for the edgex-go repo. In order to do that, we need to add a .sonarcloud.properties file to the root of the project with default settings. This should include exlcusion of *_test.go files. A default template provided by Ernesto @ Intel looks like this
sonar.exclusions=.git,**/*_test.go,**/vendor/**
sonar.tests=.
sonar.test.inclusions=**/*_test.go
sonar.test.exclusions=**/vendor/**

This is for evaluation purposes of SonarCloud. This may be rolled back if we decide the tool's output isn't sufficient.

Adding more information about this configuration approach
https://sonarcloud.io/documentation/autoscan/


Revert "Revert "LinearGradient and RadialGradient RTL""

Reverts flutter/flutter#12209, restoring https://github.com/flutter/flutter/pull/12204.
It wasn't the cause of the regression after all.

TBR=@abarth

Great!  LGTM


coral_web: Add is_available check to tools

Description

filter out tools that have a false is_available value
add tool error_message as tooltip

I think we want to show the ones that have is_available=False, but perhaps just make them red (or some other indicator that they're not selectable) and to show their error_message. And the tooltip message should use description if it's available, but use error_message if its not available. Lmk if that makes sense


fix(helm): add --description flag to helm

fix(helm): add --description flag to 'helm install', 'helm upgrade', and 'helm uninstall'
Since this feature was present on helm 2, and some existing pipelines rely heavily on it, I believe is better adding it here instead of modifying a lot of existing scripts.
When added, this flag allows us to add a custom description to the release. E.g.:
--description "my custom description"
Closes #7033
Signed-off-by: Juan Matias Kungfu de la Camara Beovide<EMAIL_ADDRESS>

There are a few formatting errors causing the CI build to fail. Mind fixing those up?

@bacongobbler  Finally I submitted the PR... sorry I'm not a go developer (neither a developer, now I'm a devops), so I lack some knowledge... I tried to add some tests but I couldn't... I tested this change using it... hope it is ok

+1 for this. Really need ability to set description (put there commit sha from CI/CD)


mamba --version reports conda version

...which is useful information but maybe mamba should also report it's own version - e.g.
> mamba --version
mamba 0.2.7
conda 4.8.3

xref: #248

Done in #253


Adapt to Python3.6+ and Matplotlib 3.8+

When running on python 3.6+ dnaplotlib fails on open("filename", "rU"), the use of U is redundant in Python3 and since Python 3.6 is officially deprecated, on the currently support versions it leads to an error.
Minor fixes to some gallery scripts (after changing dnaplotlib I ran the examples to see if they still work
Upgrade to Matplotlib 3.8 along with minor changes

Tested on Python 3.11.4 by running the galery scripts

I have just realized that sbol  (python lib for version1 of the standard) lib not available for Python3 at all, so both of the sbol gallery examples do not work on python3. Lemme see how hard it is to adapt it.
@chofski  which SBOL version do you aim to support - v2 or v3?

@chofski I added the necessary adaptations to make sbol_visual example to work (updated to work with sbolv3 standard and pysbol3 lib). Some remarks:

the original Gene Cassete example skipped one of the subcomponents due to SO number mismatch, now the visualization looks different, as it shows all four.
I did not adapt the sbol_viewer gallery example, this one is MUCH bigger, a material for a separate PR.

All looks good. Thanks for the updates.


std::thread issue

Hello. When compiling for Windows on Linux make, i got this error:
threadinterrupt.h:29:10: error: ‘condition_variable’ in namespace ‘std’ does not name a type      std::condition_variable cond;           ^ threadinterrupt.h:30:10: error: ‘mutex’ in namespace ‘std’ does not name a type      std::mutex mut;           ^ In file included from alert.cpp:10:0: net.h:496:10: error: ‘condition_variable’ in namespace ‘std’ does not name a type      std::condition_variable condMsgProc;           ^ net.h:497:10: error: ‘mutex’ in namespace ‘std’ does not name a type      std::mutex mutexMsgProc;           ^ net.h:502:10: error: ‘thread’ in namespace ‘std’ does not name a type      std::thread threadDNSAddressSeed;           ^ net.h:503:10: error: ‘thread’ in namespace ‘std’ does not name a type      std::thread threadSocketHandler;           ^ net.h:504:10: error: ‘thread’ in namespace ‘std’ does not name a type      std::thread threadOpenAddedConnections;           ^ net.h:505:10: error: ‘thread’ in namespace ‘std’ does not name a type      std::thread threadOpenConnections;           ^ net.h:506:10: error: ‘thread’ in namespace ‘std’ does not name a type      std::thread threadMnbRequestConnections;           ^ net.h:507:10: error: ‘thread’ in namespace ‘std’ does not name a type      std::thread threadMessageHandler;
How can I fix it?
P.S g++ -v is 5.4.0

Looks like incorrect compiler version without std thread support, or including wrong std headers. Look at this SO question, for example, - https://stackoverflow.com/questions/27939393/getting-error-mutex-in-namespace-std-does-not-name-a-type-in-mingw-mysys-pr#27939484

I encountered the same problem and didn't fixed it by install the new version. Can anyone  give some more details on how to fix it?

Closing as solution has been given ^


Reconsider package names

Now that we change the artifact name, there's an opportunity to do binary breaking changes. (Though maybe it's a bad idea, and we should only consider it when we release a 3.0.0.)
In particular, I'm thinking of the inconsistency in the packages used for backported library classes, for example

scala.collection.compat.immutable.LazyList, vs
scala.util.Using

I assume the motivation to put LazyList in a compat sub-package was to avoid split packages, i.e., to ensure that this module doesn't add any classes into packages that exist in the 2.11 / 2.12 standard library? Since it's not done consistently I think we should just use the original package name for backports (like scala.util.Using does).
A small but maybe still realistic issue is that the recommended import scala.collection.compat._ brings an immutable into scope which is not scala.collection.immutable.
The scala.collection.compat package object still makes sense for extension methods (import scala.collection.compat._; xs.to(List)). Though, given that this is now library-compat, should it just be scala.compat._ instead? There might be backports of non-collection extension methods in the future. I'm not sure.

just for reference, I put LazyList in that package because ArraySeq was already there. it's possible there were reasons for ArraySeq that don't apply to LazyList, so it shouldn't have been there

AFAICT, ArraySeq has been moved to package collection.compat.immutable in this PR: #31. The goal was to fix an issue with OSGI (#30). IIRC we have disabled OSGI support? So, we don’t anymore have a good reason to use this package?

Thanks for digging these out, I didn't remember. My brain seems to be suppressing all memories of OSGi related work.

Now that we change the artifact name, there's an opportunity to do binary breaking changes. (Though maybe it's a bad idea, and we should only consider it when we release a 3.0.0.)

Lukas and I discussed this last week.
Using a different artifact name doesn't make binary breaking changes harmless, and bumping the version number to 3.0.0 doesn't make them harmless, either. In order not to send any users to dependency hell, we must either:

Keep bincompat.

Note that this was the original plan, that this library would never, ever break bincompat. We only did it going from 1.x to 2.x because we caught the motivating problem so early that we thought it was safe that nobody was using 1.x yet. But people are definitely using 2.x now.

make the old library and the new library have no potentially incompatible classes at all in common, so that 2.x and 3.x can be on the same classpath no problem

Lukas, is that an accurate summary of our discussion?
Option 2 seems hairy and not-worth-it to me. I'm certainly not eager to tackle it, it will annoy and confuse users, and it's not clear to me that the benefit is so great, anyway. 98% of Scala OSS has already added 2.13 to their crossbuilds, so there is value in just leaving things alone.
So I suggest we go with option 1. That would mean:

all collections stuff continues to live in scala/collection/compat; bincompat forces this for existing stuff, and if we add more stuff, it would be confusing for everyone to have it in a different location, better to stay consistent
everything else can live in its natural location, as we've already done with @nowarn and Using

wdyt?

Changing the artifact name will potentially cause issues even with the proposed solution here. Due to transitive dependencies, one may end up with both in the classpath resulting in NoSuchMethodErrors if the newer version was used in compilation while the older version was used at runtime. Do we want to revert the artifact name change perhaps?

Yeah... Seth said

make the old library and the new library have no potentially incompatible classes at all in common

That prevents classes from evolving. Let's say there's
class A { def f: Int }

in scala-collection-compat, and that it evolves to
class A { def f: Int; def g: Int }

in scala-library-compat. If it was the same module, sbt would pick the newest version. But with a different artifact name, both end up on the classpath, and behavior depends on which classfile is loaded first by scalac (compile-time) and the JVM (run-time).
Also moving a class (LazyList) from scala.collection.compat.immutable to scala.collection.immutable would not work with the two versions on the classpath. Let's say a project uses two libraries that depend on collection-compat
class Lib1(ll: comp.imm.LazyList)   // v1
class Lib2(ll: comp.imm.LazyList) { // v1
  new Lib1(ll)
}

now Lib1 migrates to library-compat
class Lib1(ll: imm.LazyList) // v2

This is not binary compatible comp.imm.LazyList is simply not the same class as imm.LazyList, so Lib2 v1 doesn't work with Lib1 v2.

So I only see two ways forward

break binary compatibility
rename back to scala-collection-compat and remain binary compatible forever

Before we decide to go back, I'd like to convince myself that breaking binary compatibility once is really not an option.
The thing is, the compat library has great potential because the Scala 2.13 standard library is locked down by the forwards binary compatibility constraint. Scala 2.13 will have a very very long lifetime and 3.0 is planned to use the 2.13 library too. The compat library allows extending the standard library during that time. It's quite unfortunate that we have to explain to all users "for historical reasons, this library has a weird name and the package structure is inconsistent".
Do we have a chance to find the direct users of scala-collection-compat and somehow make a coordinated effort to move everyone to the new artifact that breaks bin compat?

Maybe one solution to rename the artifact without ending up with two artifacts in the classpath, would be to keep scala-collection-compat, and to create an empty artifact named scala-library-compat that depends on scala-collection-compat. This way, dependency resolvers would eventually only select one scala-collection-compat artifact, even if your project depends on two libraries that depend on different versions of scala-collection-compat/scala-library-compat.
That doesn’t solve the question of breaking binary compatibility or not, though…

Maybe the library for extending 2.13/3.0 could be scala-library-compat. It could use different package/class names and be a longer term thing. Or maybe the name should not even include compat, if that's the goal.
scala-collection-compat would continue to be used for bridging 2.11, 2.12 and 2.13. For reference, Apache Kafka no longer supports Scala 2.11. If/when we add support for 3.0, we will likely drop support for 2.12. This is just one project, but the overhead of supporting more than two versions of Scala is pretty high and I don't think it's uncommon for projects to stick to 2 versions.

In the end, I don't think breaking binary compatibility is an option. Browsing through GitHub search, the library is used too widely, and fixing dependency conflicts will be too hard for users (figure out which of their depdendencies is built against an old collection-compat, check if there's a new version, ping maintainers, etc). So the packages have to remain what they are; as Seth said

collections stuff continues to live in scala/collection/compat, also new backports
everything else can live in its natural location, as we've already done with @nowarn and Using

For changing the artifact name, Julien's idea sounds plausible to me (but we'd have to do some testing). So we could release a new scala-library-compat:1.0.0 that is binary compatible with scala-collection-compat:2.1.6. To avoid having both scala-library-compat:1.0.0 and scala-collection-compat:2.1.6 on the classpath, the new scala-library-compat:1.0.0 would depend on a completely empty scala-collection-compat:2.2.0.
About including new classes for 2.13, we can either do it in this library, or in a completely new one. I'm fine either way. The 2.13 artifacts of scala-collection-compat are currently empty except for two package objects (scala.collection.compat and scala.collection.compat.immutable) that contain type and val aliases, which is a clean enough starting point. If we do that, I think we should rename the library to scala-library-future.
To summarize, let's vote on these options (please comment for feedback / other suggestions):

🎉 rename back to scala-collection-compat. Continue adding backports for 2.11 and 2.12, keep 2.13 empty.
Pro: least breaking change, nobody needs to change the dependency.
Con: misleading name, the library contains backports outside collections.
😄 keep scala-library-compat or rename to scala-library-backports. Continue adding backports for 2.11 and 2.12, keep 2.13 empty.
Pro: better library name.
Con: users need to find the new artifact name (breaks scala steward), ghost dependency on empty scala-collection-compat:2.1.7.
🚀 move to scala-library-future. Continue adding backports, also add new features for 2.13/2.12/2.11.
Pro: a single place for standard library extensions.
Con: same as above.

If we pick 🎉 or 😄, we can at any point start a new library scala-library-future that contains extensions for 2.13 (and backports of them for 2.12 / 2.11).

users need to find the new artifact name (breaks scala steward)

Feels viable to teach Scala Steward this, at worst non-generically.

IMO, for maximum ease, we should keep the new scala-library-compat at the same version as scala-collection-compat (i.e. start it at 2.2.0).

To avoid having both scala-library-compat:1.0.0 and scala-collection-compat:2.1.6 on the classpath, the new scala-library-compat:1.0.0 would depend on a completely empty scala-collection-compat:2.2.0.

something about that doesn't sound right to me. the "outer" dependency (i.e. the one that depends on the other) needs to be the one that's empty. so either collection-compat is empty, and depends on library-compat, or library-compat is empty, and depends on collection-compat. as described, if someone upgrades to collection-compat:2.2.0, they will end up with a broken dependency lacking contents (and it would thus, technically speaking, not be binary-compatible).

IMO, for maximum ease, we should keep the new scala-library-compat at the same version as scala-collection-compat (i.e. start it at 2.2.0).

Why would that make things easier? Dependency resolution systems (e.g., coursier) will consider anyway that the two artifacts, scala-library-compat et scala-collection-compat are independent from each other so they won’t even compare their revision numbers.

as described, if someone upgrades to collection-compat:2.2.0, they will end up with a broken dependency lacking contents (and it would thus, technically speaking, not be binary-compatible).

Right, good catch! My initial proposal was to keep the content of scala-collection-compat as it is (so that it remains backward binary compatible in the next versions, and to put new stuff (unrelated to the collections) into a new artifact, scala-library-compat, that depends on scala-collection-compat (or, we could put everything into collection-compat and have library-compat an empty artifact that depends on it). Does that sound correct?

Why would that make things easier?

my thought was that it makes it easier for the end user to switch from the "deprecated" collection-compat to the preferred library-compat whenever they want to, since they will have the same version

My initial proposal was to keep the content of scala-collection-compat as it is (so that it remains backward binary compatible in the next versions, and to put new stuff (unrelated to the collections) into a new artifact, scala-library-compat, that depends on scala-collection-compat

I thought some of the new stuff had already been released in scala-collection-compat. if not, I'm fine with it being in scala-library-compat, but if so, I feel like it might be weird for some of it to be in one artifact and some in another? idk. it probably doesn't make a huge difference either way

Looking at the changelog and Git history, it seems that the content not related to collections has not been released yet, so we still have a chance to move it to a separate artifact.

regarding scala-library-future - I think it should be a separate library, and I think we should version the packages (e.g. scala.future.v1.collection.NewThing), so that we can evolve things cleanly without breaking bincompat (e.g. we determined that the initial API for NewThing wasn't great, so now we have scala.future.v2.collection.NewThing). older versions (e.g. s.f.v1) could be deprecated in newer releases (e.g. s.f.v2), thus allowing smooth evolution without ever breaking bincompat. and for things that haven't changed/don't need deprecation, we could either leave as is in the old package, or alias the new package to the old package.

Looking at the changelog and Git history, it seems that the content not related to collections has not been released yet, so we still have a chance to move it to a separate artifact.

except for @nowarn, but that's a small enough thing that I don't think we should ruin the package separation over it

keep the content of scala-collection-compat as it is and put new stuff into a new scala-library-compat artifact that depends on scala-collection-compat

That might make things more confusing, I feel that it's better to keep all classes in the same artifact. The standard library also doesn't have a split between collections and the rest.

That might make things more confusing, I feel that it's better to keep all classes in the same artifact.

In that case, I think we should make library-compat the primary artifact, and collection-compat the empty artifact.

Have we thought about transitive dependency situations? Say I depend on collection-compat and a separate library depends on library-compat. Depending on how the build tool resolves conflicting dependencies (say the explicit dependency is the current released version, before the introduction of library-compat), this can result in some weird situations. Is that worth it just for a cosmetic module name issue?

It seems like Maven has something for changing group ids, not sure if it also works with artifact ids: http://maven.apache.org/guides/mini/guide-relocation.html
The discussion linked from that page seems to indicate that it's under-tested though.

Have we thought about transitive dependency situations?

sbt would emit an eviction warning if there is a transitive dependencies conflict.

That's good for SBT users. Thoughts on Maven and Gradle?

Thoughts on Maven and Gradle?

I don't really use them so I'm not an expert, but dependency conflicts are not specific to this artifact, so I'm sure a solution exists. maybe the enforcer plugin for Maven? not sure

Have we thought about transitive dependency situations?

sbt would emit an eviction warning if there is a transitive dependencies conflict.

It does, but it's routinely ignored because there are so many totally inconsequential ones.

The vote is 2-2-2 so far.
But it's 4:2 against using this library for new 2.13 additions. So if it continues to be a backports-only library, I'm really in favor of keeping the old name. Sure, it's a bit confusing, but we can explain. And it avoids messing with empty or split artifacts, introducing a faux dependency, wondering what will happen on various build tools, explaining why there are two artifacts. The usage of this library will fade out over time (when people migrate off 2.12).

Good call.

I don't understand all the in and outs of this discussion but would like to add a few points.

To me having this library was a godsend as I was easily able to support 2.13 along with a bunch of changes as things are getting more strict.
Getting my library to compile from 2.11 - Dotty was possible with just tightening things up a bit more.
Adding stuff to 2.12/2.11 from 2.13 means I can use them and they work just from cross compiling.
I can see this library continuing as 2.11, 2.12 are dropped when 3.1, 3.2 are added.
Having standard library and collection compatibility is a good thing.

Overall, this is so good I can't imagine that it can't continue until the point it is not need via Tasty or whatever.

I reallllly wanted the new name, as evidenced by my premature renaming of the repository, but after reading through all this discussion, I must regretfully conclude that it isn't worth the weirdness and trouble, so we should go back to scala-collection-compat :-(
And we have consensus that scala-library-future will be separate.

I would like to just depend on scala-compat-compat.

should we create a scala-library-future repo?

Also make clear that scala-library-future is not just for Future fixes. Maybe we need scala-future-future.

I renamed the repo back to scala-collection-compat, and I'm working on merging open PRs and publishing.
I will make the scala-library-future repo soon.

https://github.com/scala/scala-library-next

:100: We definitely need a separate module just for Iterators. They are so hard to get right. Calling it next is quite elegant.

scala-library-next(), though, or I'll get a warning


Student ID Card: Increase brightness to 75% or greater

Increase screen brightness when barcode screening is needed.

Or is it instructions for users to take?

Done on branch feature/barcode-brightness

Initial testing passes on iOS and Android. Merged into student-id-card

This work has been completed, closing.


cleanup/lots

Yeah there is always lots to cleanup
+I guess I could put some Ideas here
+Seeing how this helps me think

Branched off this PR and merged in the new one so gonna close this


Add pundit authorization

Proposed Changes

Migrate all authorization in controllers to using Pundit

Merge Checklist

[x] Check if route, query, or mutation authorization looks correct.

Otherwise looks good to me!


Update to latest version of gpii-launcher to address Synk warnings with transitive dependencies

Synk is currenty reporting several upstream security issues that stem from gpii-launcher's dependency on an old version of Kettle.
@the-t-in-rtf has updated gpii-launcher to the latest version of Kettle, which in turn has updated to patched versions of the ws and qs dependencies. We should upgrade to 1.0.0-dev.20170712T140305Z.aa60d4a.

@the-t-in-rtf, when I upgrade to the latest development release of gpii-launchers, I get the following errors when running flocking-midi-router:
2:14:00.271:  Registering module flocking-midi-router from path /Users/colin/code/flocking-midi-router
YError: Too many arguments provided. Expected max 1 but received 2.
at module.exports (/Users/colin/code/flocking-midi-router/node_modules/yargs/lib/argsert.js:31:13)
at Object.Yargs.self.array (/Users/colin/code/flocking-midi-router/node_modules/yargs/yargs.js:184:5)
at /Users/colin/code/flocking-midi-router/node_modules/gpii-launcher/src/js/launcher.js:41:23
at Object.fluid.each (/Users/colin/code/flocking-midi-router/node_modules/infusion/src/framework/core/js/Fluid.js:517:17)
at gpii.launcher.launchComponent (/Users/colin/code/flocking-midi-router/node_modules/gpii-launcher/src/js/launcher.js:40:11)
at togo (/Users/colin/code/flocking-midi-router/node_modules/infusion/src/framework/core/js/FluidIoC.js:1794:33)
at Object.fire (/Users/colin/code/flocking-midi-router/node_modules/infusion/src/framework/core/js/Fluid.js:1494:40)
at Object.fluid.initComponent (/Users/colin/code/flocking-midi-router/node_modules/infusion/src/framework/core/js/Fluid.js:2671:30)
at Function.creator [as launcher] (/Users/colin/code/flocking-midi-router/node_modules/infusion/src/framework/core/js/Fluid.js:1925:30)
at Object. (/Users/colin/code/flocking-midi-router/launcher.js:50:19)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.runMain (module.js:604:10)
at run (bootstrap_node.js:394:7)
at startup (bootstrap_node.js:149:9)
at bootstrap_node.js:509:3
node . [options]

It seems like a yargs error, but I haven't updated the version of yargs in ages.  What version of gpii-launcher did you have before?  Also, do you have a branch somewhere with this update that I could try out?

See above ;)
https://github.com/colinbdclark/flocking-midi-router/commit/bc8df85acc631c952226bdbf492ae690539af7b2

Sorry for the extreme delay.  I have tracked this down and filed GPII-2592.  There is a workaround in the linked issue, which you should only need if the problem is an underlying issue with yargs.  More in a bit.


Create category that links to installations of another category

I've just spotted a pattern in the data.  It relates to an organisational grouping of installations.
There is an instance where there is country has a category that just contains a page of descriptive text. It has a list of installations by category, but each is a link to the installation in its real category.  So, there's just the one page in the folder, but opening that page gives link to existing installations that can act as that category.

Handled. via ns-countries.


mupx deploys successfully but when accessing site displays "This site can’t be reached"

I recently created a new amazon instance and deployed with mupx which was successful. When I navigate to the root url however no content is shown and the page never loads. Eventually it display

This site can’t be reached

I have Kadira setup with it and kadira shows that it is up and running.
Also mupx logs show:
[<IP_ADDRESS>] => Starting meteor app on port:80
[<IP_ADDRESS>] Kadira: completed instrumenting the app
[<IP_ADDRESS>] Kadira: Successfully connected

.

Maybe the ports blocked. There should be some panel in their interface for ingress I think they call it.
If you SSH into the target and use curl to test its working, but it doesn't work from outside it's the port being blocked.

I'm kind of confused about how to test with curl. Should I curl localhost or something to see if there is any code that is returned?

Yeah that was it.


Suggestion regarding codeigniter 4

Dear CI devs congratulations for CI4 from the bottom of my heart.
As the php 7.1 have huge performance comparatively to php 5.x there is a new project for asynchronous  php on github which is equivalent to Nodejs.
please find below official link
https://reactphp.org/
github repos:
https://github.com/reactphp
framework equivalent to express.js
https://github.com/CapMousse/React-Restify
please have a look so the CI4 can be able to use full asynchronous features of php within the framework.
you did nice job as always.
with regards,
deepak bawa

I see you have raised this as a thread on our forum, which is the proper place for suggestions.


Mention launching from the precompiled archive

Starting imagepy from the pre-compiled archive available in the release tab was not yet mentioned in the readme.

thanks very much, I am a little busy these days, I would build win32/win64 and mac archive later, and design the imagepy.org website.


chore(book): first Logo's handbook version

Codecov Report

Merging #319 (3505631) into master (b1406db) will decrease coverage by 0.81%.
The diff coverage is 0.00%.

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

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##           master     #319      +/-   ##
==========================================
- Coverage   20.88%   20.08%   -0.81%
==========================================
  Files          32       34       +2
  Lines        2049     2131      +82
==========================================
  Hits          428      428
- Misses       1621     1703      +82

Impacted Files
Coverage Δ

logos/examples/brainfuck.rs
0.00% <0.00%> (ø)

logos/examples/json.rs
0.00% <0.00%> (ø)

logos/src/lexer.rs
76.05% <0.00%> (-2.21%)
:arrow_down:

logos/src/lib.rs
33.33% <ø> (ø)


prefix matching not working on  Ubuntu 18.04.6 LTS (GNU/Linux 5.4.0-1063-aws x86_64)

Describe the bug
OS:   Ubuntu 18.04.6 LTS (GNU/Linux 5.4.0-1063-aws x86_64)
zsh version: zsh 5.4.2 (x86_64-ubuntu-linux-gnu)
I installed zsh-autosuggestions w/ manual installation method. it can autosuggest things when I type, but if I press UP and DOWN to scroll history, it only show plain history but not prefix history.  Is there a config to force the prefix match?
my .zshrc
autoload colors && colors

##### enable auto-suggestion & syntax-highlight
 source ~/.zsh/zsh-autosuggestions/zsh-autosuggestions.zsh
 source /home/xianggao/.zsh/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh

bindkey "^[[A" history-beginning-search-backward
bindkey "^[[B" history-beginning-search-forward

I checked using zsh -df and in it, the history prefix match can work normally.  But as you can see I don't have too many things in my zshrc.   Not sure where the issue is...
thank you!

if I press UP and DOWN to scroll history, it only show plain history but not prefix history

This plugin doesn't have any control over this behavior. I think you may be looking for this? https://unix.stackexchange.com/a/97844


Report an error when UNKNOWN_TAG is found #55

The cause of the error was the method p_unknown_tag
in parsers/tagvalue.py. Due to the incorrect context-free grammar specification defined in the method, the line after the unknown_tag was not taken into consideration. The
context-free grammar specification was rectified and tests
were corresponding tests were added.
Signed-off-by: Yash Nisar<EMAIL_ADDRESS>

Review required @pombredanne @krysnuvadga :)

@yash-nisar can you update or rebase this branch?

@pombredanne Updated the branch :D


Querying by Range

Once data has been imported, is there any way to query a range of data?  So if there is a column that has several years between 1960 and 2010, is there a way to specify a range to get information between 1970 and 1975 for example?

We recently published a new version of dat that closes this issue. This would be a great feature to have in dat, but right now it's only available in the lower-level hyperdrive API. It's on the todo list, though.
Would you mind trying out the new dat with npm install -g dat? You can read about the new dat announcement on the website and how it works in the docs.


Added and implemented a basic config system and a default logger

Config system seems pretty easy and convenient.
I declared a logger and even tried using it, however the default handler of stderr doesn't appear in our python console output.  Would be nice to figure out something that does.

Also, look at that, attempting to parse requirements.txt in setup.py actually breaks travis builds.  Lets fix that in this pull request.

Ah, derp, forgot to update MANIFEST.in..  Fixing

Fixes #6

I don't see the change that fixes the requirements parse for travis builds. I do see that travis runs ok though.


<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>

Bug, feature request, or proposal:
What is the expected behavior?
What is the current behavior?
What are the steps to reproduce?
Providing a Plunker (or similar) is the best way to get the team to see your issue.
Plunker template: http://plnkr.co/edit/o077B6uEiiIgkC0S06dd
What is the use-case or motivation for changing an existing behavior?
Which versions of Angular, Material, OS, browsers are affected?
Is there anything else we should know?

See #849


[Bug] fav pull bug collection

Describe the bug

ctrl-c not handled
error hints mess progress bar
unknown network error
sets not saved if quit

#75 #76 #77 #78

@Silicon7921
If bug fixed after v0.2.19, let me know here, thanks a lot!

seems fixed properly. thank you.


Added missing logData for vectorSignals

cc @GiulioRomualdi @carloscp3009 @giotherobot

Before setting it ready for review, I want to understand why in a dataset we ended up having all the timestamps for the RGBD cameras, and only one data point for all the other signals. Maybe a race condition somewhere? 🤔

Before setting it ready for review, I want to understand why in a dataset we ended up having all the timestamps for the RGBD cameras, and only one data point for all the other signals. Maybe a race condition somewhere? 🤔

This was due to the check on the time difference between two acquisitions.
In any case, with https://github.com/ami-iit/bipedal-locomotion-framework/pull/869/commits/c460237de7cb0206f0f93f517477aff4afc26e44 I reduced the chances that the run method remains stuck due to the waiting to some mutex for the exogenous signals.
I wanted to check the same with the text and I noticed that:

in theory it is not necessary to lock any mutex. Eventual race conditions due to the connections should be handled by yarp itself internally
there was a missing call to save the data also here

I implemented a fix for these two points in https://github.com/ami-iit/bipedal-locomotion-framework/pull/869/commits/cb5531d7a61414dcb64bb5a113e0ce1597b4ba55

I think this is ready for review. There are a few additions I would like to implement (e.g. check if the metadata is ready before asking), but I prefer to do it in a subsequent PR


HTLM in-page anchors displayed in headings - ref  #387

Good day team.
I found another occurrence of the recently solved #387.
Anchors' refs are displayed in the heading on this page:

Could this be a more extended behavior, affecting even more pages, due to any mis-configuration on the anchors rendition logic?
Issue in ./help/profile/merge-policies/overview.md

This is an Experience League bug that is currently being worked on. Closing the issue.


Allan: Agile Development: 4 weeks

Learning Objectives
0. Developing HTML & CSS

🥚 VSCode: you can ...

[x] use the LiveServer extension to launch an HTML page in the browser
[x] use autocomplete to begin a new HTML document, create new tags, and much
more
[ ] use the HTML CSS Support and IntelliSense fo CSS class names
extensions to make writing HTML & CSS more efficient

🥚 Formatting HTML & CSS: You can ...

[ ] use VSCode configurations to format your code on save
[x] use npm run format to format all the code in your repository

[x] 🥚 Linting CSS: You can use the npm run lint:css script to find
mistakes in your CSS, and you can fix the mistakes.
[ ] 🥚 Validating HTML: You can use the npm run validate:html script to
find mistakes in your CSS, and you can fix the mistakes.
🥚 Browser Developer Tools: You can ...

[ ] inspect the source code of a web page using the Sources tab
[ ] find any part of the web page in the Elements tab of your Dev Tools DOM
inspector
[ ] find the styles for any element in the Elements tab
[ ] make temporary changes in a web page from the Elements tab to see how
they will look

[1. Following Plans]

[x] 🥚 Project Definition and Scope: As a group, you can agree on what you
are trying to build, and can clearly describe the project using a README
and a repository description.
🥚 Project Constraints: As a group you can define project constraints by
discussing your strengths, weaknesses and context. You can set these types of
constraints:

[x] External: constraints that come from outside your group
[x] Internal, Involuntary: constraints that come from within your group,
but your group did not decide to have.
[x] Internal, Voluntary: constraints your group decides on to improve the
quality of your development process and final software.

[x] 🥚 Communication Plans: You can work with your group mates to agree on
a communication plan to follow during development.
[x] 🥚 Communicating Challenges: During development you can discuss with
your group when ...

you are blocked and need help the agreed channels of communication.
your schedule or availability changes
you are having trouble getting along with each other

[x] 🥚 Using a Backlog: You can develop from a backlog of features
organized by priority:

must-have
should-have
could-have

[ ] 🥚 Follow a Development Strategies: You can follow a development
strategy to understand the code required for must-have user stories.
[ ] 🥚 Create Issues From a Dev Strategy: You can create issues for user
stories in your project based on the development strategy.
🥚 Retrospective: Your group can complete a retrospective to ...

[x] assess how well you worked as a group
[x] find ways to improve in the next project
[ ] compare your plan to the reality of developing your website

🐣 Claiming and Completing Issues: You can claim issues from the TODO
column of a project board and ...

[ ] track your progress with the project board
[ ] develop your code locally on a separate branch
[ ] send a PR that passes CI checks and meets the requirements

[x] 🐣 Code Review: You can both review a group mate's PR, and
productively participate in a review of your own code.
[ ] 🐣 Match a Design & Acceptance Criteria: When developing your tasks,
you can write code that matches the project's Wireframe and meets your
issue's Acceptance Criteria.

[2. Writing Plans]

[x] 🥚 Write User Personas: As a group you can describing your site's
users with User Personas, and you can use the personas to plan your
website from the user's perspective.
[x] 🥚 Write User Stories: Given a working web page, you can describe it
with user stories and acceptance criteria for each user story.
[x] 🐣 Write a Backlog: After listing all the user stories for a web page,
you can organize them into a Backlog by priority: must-have,
should-have and could-have
[ ] 🐣 Create a Prioritized Design: Using your backlog and the original
site as a guide, you can create a Wireframe of the site your group will
build. You can use different colors and comments to indicate a priority
for each component in the Wireframe.
[ ] 🐣 Write a Development Strategies: You can translate your Wireframe
and Backlog into a Development Strategy for the must-have user stories.

[3. Adapting Plans]

[x] 🐣 Adjusting the Backlog: As a group you can agree to changes in the
backlog when necessary.
[x] 🐣 Adjusting the Design: As a group you can agree on changes to the
design during the development process when it becomes clear your old
design needs updating.
[x] 🐣 Updating the Project Board: You can manage the project board by
adding, removing or updating issues when necessary. This includes changing
labels, milestones, or assignees when necessary.

Week 1 Check-In
I Need Help With:
being given more examples of our assignments so i could better understand what is expected from me. i need practical tasks and guidance in VS code because I'm not yet confident enough
What went well?
Working in teams and dividing tasks, and also receiving help from team mates, it made things a lot easier,
what do you think went will with you?
I learnt more through the practical work, as it also helped me refresh my memory on what we have learnt so far especially in git hub, it helped me get more familiar with how to use git hub,
What went less well?
Gathering all team-mates at the same time, due to our different schedules
what do you think went less will with you?
I was a bit behind in this module, so i had to try and catch up real quickly with my team mates as a result i don't think i fully understood everything, as it was a bit fast. i would have to go the parts i don't fully understand again, especially in wire frame design
Lessons Learned
what have your learned from the first week?
I learnt about agile development still more to learn, how to work i teams and dividing tasks
Sunday Prep Work
what have you prepared for next Sunday class?
I will read through articles and watch videos related to Sundays class
Week 2 Check-In
I Need Help With:
Nothing for now
What went well?
Working in teams and dividing tasks, and also receiving help from team mates, and coaches
what do you think went will with you?
getting more familiar with how to write planning, but i still need to practice more especially how to write a development strategy and backlog
what do you think went less will with you?
i don't yet fully understand how to write the development strategy and backlog as a result im a bit slow on this part
Lessons Learned
learnt about the different parts of coding as !doctype, head, body, divs etc but there is still alot more to learn
Sunday Prep Work
what have you prepared for next Sunday class?
I will read through articles and watch videos related to Sundays class

@AllanSaku  You will get used to the planning because for every project you build you will need the planning.


Docker fixing base url

@bloodbare same as the other, right? We'll have to port it / fix it in Volto.


Allow user to change to use their chose JDK and document (multiple repos)

We should provide a means for user to change the build to use a JDK of their choice; tat is, we need a means to configure the JDK location (dynamically or statically) and create user documentation telling them how to. These instructions and process should be the same for all repos. that use a JDK (e.g., main openwhisk, apigateway and runtime java).
This problem surfaced and is related to issue: https://github.com/apache/incubator-openwhisk-release/issues/167

Note: related to issue https://github.com/apache/incubator-openwhisk-release/issues/153

@markusthoemmes @rabbah Do you know what could be the reason?

@houshengbo can you post a PR to see how you switched to openjdk?


End to End testing with Spectron

Resolves #275

@tbarlow12 - Let's create a new PR from the cleanup branch with all the new tests.


error entry not found in chache

Does this occur consistently?
Repro steps:

Action: appService.Deploy
Error type: Error
Error Message: Entry not found in cache.
Version: 0.18.0
OS: win32
OS Release: 10.0.17134
Product: Visual Studio Code
Product Version: 1.48.1
Language: en

Call Stack
s.createError extension.js:16:58035
b.<anonymous> extension.js:393:41330
extension.js:393:35925extension.js:393:35925
extension.js:243:74572extension.js:243:74572
extension.js:243:72553extension.js:243:72553
extension.js:243:72173extension.js:243:72173
i.find extension.js:243:106705
extension.js:243:53427extension.js:243:53427
processTicksAndRejections task_queues.js:85:5

As a workaround you could try reloading your window or signing out and signing back in to your Azure Account using the command palette.
Unfortunately there's not much we can do in this extension, but this is being tracked upstream here: microsoft/vscode-azure-account#53

the problem solved after restart vocoder
thanks
On Mon, Aug 31, 2020, 21:43 Eric Jizba<EMAIL_ADDRESS>wrote:

As a workaround you could try reloading your window or signing out and
signing back in to your Azure Account using the command palette.
Unfortunately there's not much we can do in this extension, but this is
being tracked upstream here: microsoft/vscode-azure-account#53
https://github.com/microsoft/vscode-azure-account/issues/53
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-azureappservice/issues/1748#issuecomment-683959480,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEAFUJPBE6THLKCLHB36ON3SDPVONANCNFSM4QPNVLKQ
.


Try to open a transaction before disconnecting

This could avoid leaving misconfigured resources in the cloud if a disconnect occurs during a commit

So this change consistently breaks the test suite here during disconnect, erroring out because it can't get a transaction lock. It may be better if it tries to get a transaction lock and if that fails to still continue with the disconnection?


nbgrader-exchange volume is never mounted

Hello,
I noticed that the exchange volume is defined but never mounted on the students' countainers. Here is the result of kubectl get pod/jupyter-student1 -o yaml
best regards
apiVersion: v1
kind: Pod
metadata:
  annotations:
    hub.jupyter.org/username: srtudent1
  labels:
    app: jupyterhub
    chart: jupyterhub-3.0.3
    component: singleuser-server
    heritage: jupyterhub
    hub.jupyter.org/network-access-hub: "true"
    hub.jupyter.org/servername: ""
    hub.jupyter.org/username: srtudent1
    release: nbgrader
  name: jupyter-srtudent1
  namespace: default
  resourceVersion: "178209"
  uid: 66c587ec-152e-44ad-b375-158719f1a57c
spec:
  containers:
  - args:
    - jupyterhub-singleuser
    - --SingleUserNotebookApp.max_body_size=6291456000
    env:
    - name: CPU_GUARANTEE
      value: "0.2"
    - name: CPU_LIMIT
      value: "1.0"
    - name: JPY_API_TOKEN
      value: 343dfa0290e64d6096fcba9bbe6b69bd
    - name: JUPYTERHUB_ACTIVITY_URL
      value: http://hub:8081/hub/api/users/srtudent1/activity
    - name: JUPYTERHUB_ADMIN_ACCESS
      value: "1"
    - name: JUPYTERHUB_API_TOKEN
      value: 343dfa0290e64d6096fcba9bbe6b69bd
    - name: JUPYTERHUB_API_URL
      value: http://hub:8081/hub/api
    - name: JUPYTERHUB_BASE_URL
      value: /
    - name: JUPYTERHUB_CLIENT_ID
      value: jupyterhub-user-srtudent1
    - name: JUPYTERHUB_DEBUG
      value: "1"
    - name: JUPYTERHUB_DEFAULT_URL
      value: /lab
    - name: JUPYTERHUB_HOST
    - name: JUPYTERHUB_OAUTH_ACCESS_SCOPES
      value: '["access:servers!server=srtudent1/", "access:servers!user=srtudent1"]'
    - name: JUPYTERHUB_OAUTH_CALLBACK_URL
      value: /user/srtudent1/oauth_callback
    - name: JUPYTERHUB_OAUTH_CLIENT_ALLOWED_SCOPES
      value: '[]'
    - name: JUPYTERHUB_OAUTH_SCOPES
      value: '["access:servers!server=srtudent1/", "access:servers!user=srtudent1"]'
    - name: JUPYTERHUB_SERVER_NAME
    - name: JUPYTERHUB_SERVICE_PREFIX
      value: /user/srtudent1/
    - name: JUPYTERHUB_SERVICE_URL
      value: http://<IP_ADDRESS>:8888/user/srtudent1/
    - name: JUPYTERHUB_USER
      value: srtudent1
    - name: JUPYTER_IMAGE
      value: bpfrd/nbgrader-student:latest
    - name: JUPYTER_IMAGE_SPEC
      value: bpfrd/nbgrader-student:latest
    - name: MEM_GUARANTEE
      value: "2147483648"
    - name: MEM_LIMIT
      value: "2147483648"
    image: bpfrd/nbgrader-student:latest
    imagePullPolicy: IfNotPresent
    lifecycle:
      postStart:
        exec:
          command:
          - bash
          - -c
          - |
            echo -e "envs_dirs:\n  - /home/jovyan/my-conda-envs/" > /home/jovyan/.condarc;
    name: notebook
    ports:
    - containerPort: 8888
      name: notebook-port
      protocol: TCP
    resources:
      limits:
        cpu: "1"
        memory: "2147483648"
      requests:
        cpu: 200m
        memory: "2147483648"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      runAsUser: 1000
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    **volumeMounts:
    - mountPath: /etc/jupyter/
      name: nbgrader-config-global
      readOnly: true
    - mountPath: /home/jovyan
      name: srtudent1-home-default-pv**
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: master-01.novalocal
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  restartPolicy: OnFailure
  schedulerName: default-scheduler
  securityContext:
    fsGroup: 100
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoSchedule
    key: hub.jupyter.org/dedicated
    operator: Equal
    value: user
  - effect: NoSchedule
    key: hub.jupyter.org_dedicated
    operator: Equal
    value: user
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  **volumes:
  - configMap:
      defaultMode: 420
      name: nbgrader-config-global
    name: nbgrader-config-global
  - name: srtudent1-home-default-pv
    persistentVolumeClaim:
      claimName: srtudent1-home-default
  - name: nbgrader-exchange
    persistentVolumeClaim:
      claimName: nbgrader-exchange**
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2023-12-18T20:24:05Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2023-12-18T20:24:06Z"
    status: "True"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2023-12-18T20:24:06Z"
    status: "True"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2023-12-18T20:24:05Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - containerID: containerd://8c0c7fa2ce805cf2ea182b0d9fdac85498bb64a0f29a689d9d8e6cfa12fdc760
    image: docker.io/bpfrd/nbgrader-student:latest
    imageID: docker.io/bpfrd/nbgrader-student@sha256:598fb4a896dee9c5e533eaa591ddb6b8c0565b333a5178949a313ecc33c85dd4
    lastState: {}
    name: notebook
    ready: true
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2023-12-18T20:24:06Z"
  hostIP: <IP_ADDRESS>
  phase: Running
  podIP: <IP_ADDRESS>
  podIPs:
  - ip: <IP_ADDRESS>
  qosClass: Burstable
  startTime: "2023-12-18T20:24:05Z"

I also get the below error while the spawner is loading:
2023-12-18T20:09:11.656075Z [Warning] 0/1 nodes are available: 1 Insufficient memory. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod..
best regards,

Hey @bpfrd
0/1 nodes are available: persistentvolumeclaim "nbgrader-exchange" is being deleted. preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling
While you were testing something, you probably tried to delete the PVC "nbgrader-exchange". The problem is, that when you do that, you also have to delete all the jobs/pods, that are tied to that PVC. Until then the PVC itself is not going to get deleted. Then you probably tried to start a new pod, which wants to mount the PVC, that is marked for deletion. If you are just testing, delete the PVC and also all the pods, that it's used by.

I was wondering how I can manage the resource parameters if I have 16Gi memory and 4 cpus and let's say 10 students

0/1 nodes are available: 1 Insufficient memory. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod
You will have to set the resources.limits (maximum resources, that could be allocated for each student) settings correctly. If you have only 10 students, then something like this should work for your setup:
resources:
  limits:
    cpu: 300m
    memory: 1Gi

Have in mind, that you also have to modify the resource limits for the "hub" and "proxy" pods. The sum of the resources of all your pods (10 singleuser + hub + proxy) should not exceed 4CPU & 16Gi memory.


refactor: 248 nnnnat checkout login

Resolves #248
Impact: major
Type: refactor
Issue
When a customer enters checkout without an email or account they'll be redirected to a login page. This happens on the client and can take a few seconds causing a flash of the Checkout before the redirect.
Solution

Updated checkout page component to check if a customer has an account/email in a componentDidMount lifecycle method and replace Router.pushRoute with Router.replaceRoute. Using .replaceRoute should preserve the intended back button behavior.
Updated login page component to also check if a customer has an account/email in componentDidMount.
Fixed import paths in a few component tests.
Fixed a "missing key" warning in _document <Head />

Breaking changes
N/A
Testing

As an anonymous customer select a product and add it to the cart.
Navigate to the /checkout page.

The page should redirect to the /login page.
There should be no flash of the "Checkout" view before the redirect happens.

Click the browsers back button.

The storefront should return to the last page before navigating to the /checkout page.

Merging this to get the other changes in. We can do another fix for the redirect if it's still happening.


Add analytics

Resolved in:
https://github.com/Yutsuten/Yutsuten.github.io/commit/b8577de23ce81a7ecdaa55494207fabbef50c605
https://github.com/Yutsuten/Yutsuten.github.io/commit/34a771a92b1877a1226a832e34302207632a03aa


AWS Sagemaker Deployment Instructions Incomplete

on the page https://course.fast.ai/deployment_amzn_sagemaker.html# there are missing instructions.

where the PyTorchModel object is created there is not an import statement included and you will get an exception if you do not include:

from sagemaker.pytorch import PyTorchModel

The class definition for ImagePredictor is not clear and will not build the class as written.

class ImagePredictor(RealTimePredictor):
     def __init__(self, endpoint_name, sagemaker_session):
          super().__init__(endpoint_name, sagemaker_session=sagemaker_session, serializer=None,
                         deserializer = json_deserializer, content_type='image/jpeg')

An exception is thrown that says NameError: name 'RealTimePredictor' is not defined
I believe the import statement needed here is related to the sagemaker SDK and should be:
from sagemaker.predictor import RealTimePredictor

a comment or two on this would be super helpful for those new to SageMaker's SDK.  Many of these classes/methods in the sagemaker SDK are not intuitive and require poking around the docs a lot. here's a link to where the object call is referenced: https://docs.aws.amazon.com/sagemaker/latest/dg/ex1-deploy-model.html

The example function script that provides the four functions for the entry point to deploy a model appears to have some syntactical errors as well.  The returned values for the predict_fn are not correctly stated for a dict object to be returned.  class is a reserved word in python and therefore cannot be used as stated, but more importantly the formatting for creating dict objects is 'key0': value, 'key1': value, etc. etc..  The below is incorrect and the keys need to be strings and the = needs to be a colon, i believe.

    return dict(class = str(predict_class),
        confidence = predict_values[predict_idx.item()].item())

Corrected may look like
    return dict('class':  str(predict_class),
        'confidence': predict_values[predict_idx.item()].item())

it would be helpful if there was some mention of the framework_version parameter in the PyTorchModel() creation step that at least identifies the latest or references when this was created. Not a big deal, but it's not clear if it is a sagemaker thing or maybe a PyTorch thing (i'm new to PyTorch)

Appears that RealTimePredictor has been renamed to simply Predictor.


Error "Cannot find static asset", but asset exists

I'm experiencing a strange issue with one Nuxt instance: it reports 404 error for recently uploaded static assets.
curl http://_ip_/_nuxt/DxbZ5qu6.js (_ip_ is IP, so directly to server without proxy) responds with:
{"url":"/_nuxt/DxbZ5qu6.js","statusCode":404,"statusMessage":"Cannot find static asset /_nuxt/DxbZ5qu6.js","message":"Cannot find static asset /_nuxt/DxbZ5qu6.js","stack":""}%

When I check file on server, it exists:
ls -l public/_nuxt | grep Dxb
-rw-r--r-- 1 root root 199500 Dec 16 10:06 DxbZ5qu6.js

Same issue happens with all files recently uploaded.
Nuxt runs on port 80, so there is no proxy.
File permissions are identical for assets that do work and don't work.
I have restarted Nuxt after files were uploaded, also restarted server after finding out issue. No change, still getting 404 for recently uploaded assets.
Any ideas where to look?
I also have identical server in another datacenter with identical set of files, it runs without any issues, so I suspect it is not a Nuxt issue but rather a server issue.

It does seem to be a weird Nuxt bug, not server issue.
Basic fs functions show that file exists, but Nuxt cannot see it:
> fs.readdirSync('public/_nuxt').filter(name => name.includes('Dxb'))
[ 'DxbZ5qu6.js' ]

Is there a cache of public files somewhere that Nuxt reads or something like that?

Found it: list of assets is stored in server/chunks/nitro.mjs, so it does not always match actual contents of public directory.
Which I think is a problem.
When deploying a new version, assets change, old assets are no longer served by Nuxt even if they do exist in public.
Deployments are never instant. There are situations when visitor gets html file from old deployment, then new version is deployed, but user tries to fetch assets linked from old page. If user only connects directly to Nuxt instance, this can occur very rarely, but add to this mix various caching methods, like Cloudflare, and situation can become a real issue.
Is there a way to force Nuxt to read contents of public directory on startup?

Thanks!


downgrade guava to prevent hbase errors

Guava version 18 causes HBase, which relies on Guava 12 currently, to throw StopWatch exceptions during read/write operations.  Downgrading Guava to version 16 appears to eliminate these errors.  A Jira was opened against HBase to upgrade the version of Guava supported there, but that won't be ready for quite a while.

I'm not convinced this is safe.  The Guava version is extremely delicate.  We worked around breaking changes to Stopwatch in the past by adding ./titan-hbase-parent/titan-hbase-core/src/main/java/com/google/common/base/Stopwatch.java (which is still in the tree).
Can you share the steps to reproduce the problem, e.g. what test to run and what Maven command?

Hi Dan,  Didn't miss this.  Thanks for replying. Will get back to this and reproduce and let you know soon.

Hi Dan,  We probably need to move this conversation into a Jira or something and out of here.  I get the sense that you don't want this particular pull request, so I am going to close this and open a Jira to capture the conversation on StopWatch.  Thanks !


Add Kapacitor 1.6.4 release notes

Add release notes
https://docs.influxdata.com/kapacitor/v1.6/about_the_project/releasenotes-changelog/
and related docs as needed
per Kapacitor 1.6.4 changelog
cc @samhld @timhallinflux @docmerlin @dgnorton

@lwandzura, the following feature will be going into this Kapacitor release: https://github.com/influxdata/kapacitor/pull/2677
please work with @docmerlin
cc @samhld for docs review and release announcement

branch for this is kapa-v1.6.4-release-notes

Very excited about this. 🙌


ci: add semantic-release/npm to bump package version

:tada: This PR is included in version 0.14.0 :tada:
The release is available on:

Visual Studio Marketplace
GitHub release

Your semantic-release bot :package::rocket:


UI-test

Codecov Report

Merging #24 (b40db9b) into main (b35726f) will increase coverage by 1.09%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main      #24      +/-   ##
==========================================
+ Coverage   80.40%   81.50%   +1.09%
==========================================
  Files          14       14
  Lines         638      638
==========================================
+ Hits          513      520       +7
+ Misses        125      118       -7

Impacted Files
Coverage Δ

webapp/worker.py
82.75% <0.00%> (ø)

webapp/models.py
90.90% <0.00%> (+1.29%)
:arrow_up:

webapp/views.py
56.36% <0.00%> (+10.90%)
:arrow_up:

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


UnhandledPromiseRejectionWarning in Windows 10

Description
Bug
Expected behavior
npm start

should not return a UnhandledPromiseRejectionWarning
Actual behavior
cschroeter@pc:~/workspace/my-first-react-app$ npm start

><EMAIL_ADDRESS>start /home/cschroeter/workspace/my-first-react-app
> react-scripts start

(node:1863) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 2): TypeError: "listener" argument must be a function
(node:1863) DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Environment
Run these commands in the project folder and fill in their results:

npm ls react-scripts (if you haven’t ejected):

cschroeter@pc:~/workspace/my-first-react-app$ npm ls react-scripts
<EMAIL_ADDRESS>/home/cschroeter/workspace/my-frist-react-app
└──<EMAIL_ADDRESS>

node -v:

v7.7.2

npm -v:

4.3.0

Then, specify:

Operating system:
Windows 10 in Linux Bash Shell Build 15048 (Creator Update)

To Reproduce
$ create-react-app my-first-react-app
$ cd my-first-react-app
$ npm start

Can reproduce in Linux Mint 18.1 with the same node/npm versions.
Problem can be resolved by downgrading node to 7.7.1 or older. The problem appeared after upgrading node to 7.7.2.

This problem seems to be caused by detect-port:1.0.1, used by react-scripts. It causes an error in detect-port/lib/detect-port.js on line 61 socket.connect(...).
detect-port is currently at version 1.1.0 which features a different approach of port detection. This version resolves the error for node v7.7.2, and also works with 7.6.0 and 7.7.1.
The Travis build test of version 1.1.0 of detect-port seems to fail, because the test is using node v4.8.0. On node 7.6.0, 7.7.1 and 7.7.2 the tests complete without any problems.
As the minimum node version of react-scripts is >=4 I am not sure if upgrading the version of detect-port in package.json in react-scripts is an acceptable solution as detect-ports:1.1.0 only passes its test on node version `>=6'.

We do not support Node 7, so the official recommendation would be to downgrade to the latest LTS.
Currently, that is Node v6.10.0.
However, we understand this might be desirable. Would one of you like to send a PR adding Node 7 to the CI (only one of the test cases) and resolving this issue?
Thanks!

(We definitely should support Node 7 tho)

I get the same error in MacOS El Capitan and Ubuntu (both node 7). Weird thing is that in Ubuntu it still runs and starts the server, but doesnt detect any changes to files. In MacOS, it just quits.

(We definitely should support Node 7 tho)

We should probably run all test cases on Node 7 then. 🤷♀

I don't think we should skip supported versions, it would be confusing.

It can be bug of Node 7.7.2 and if it is, it should be fixed by https://github.com/nodejs/node/pull/11762

Ah, brilliant @vhain! This definitely looks like a regression then. 😄

After upgrading detect-port in react-scripts to 1.1.0,  I can run create-react-app without any issues on node 4.8.0, 6.10.0 and 7.7.2. So upgrading it could still be a solution, without impacting the minimal node version.
Travis/tests failing on detect-port:1.1.0 with node <6 as mentioned earlier, seem to be related to its test dependency only. It doesn't withhold the package from working on node <6 when used with react-scripts. Though, I'm not sure if this may influence any other create-react-app tests somehow.

Want to send a PR enabling tests on Node 7 + bumping the version?

@whelmich yeah, it's because of this line of commit removed code occurring issue of Node 7.7.2

Workaround merged in #1783.

0.9.5 is out with the fix.
https://github.com/facebookincubator/create-react-app/releases/tag/v0.9.5

@gaearon Is it possible for CRA not to run on so-much-random ports? Previous behaviour was great - start with port 3000 and pick first available port.

@Andreyco
I didn’t realize that changed. Filed as https://github.com/node-modules/detect-port/issues/15—let’s see what the maintainer says.

Thanks for filling the issue. Will follow the other thread as well.

That's going to be a lot of code to re-introduce (https://github.com/node-modules/detect-port/pull/13), maybe we should fork it.

or maybe we can pin it to 1.0.7 https://github.com/node-modules/detect-port/blob/1.0.7/lib/detect-port.js#L45 meanwhile

I’m curious what was the reasoning behind that change.

Probably just less to maintain and pushing the responsibility onto the Node internals.

I wanted to mention that I have the same error happening for me on Win10, node 6,9.0 and 6.10.0 when I run yarn test.
I've recently updated the CRA to 0.9.5.
I can confirm that the clean CRA app doesn't show that error. Would it be possible to have a bit more precise report?

@mnemanja must be issue with dependency definition on your end then.
// Run on existing app
yarn remove react-scripts
yarn add react-scripts --dev
`

That's some fast response. Thanks! :)
The remove and add didn't help unfortunately.
Adding catch helped, but the "UnhandledPromiseRejectionWarning:" message is still here.

I wanna state that for me this isn't a blocking problem, just a pesky one :)

If the problem persists after that, please run npm ls detect-port and we can see what version[s] are installed.
Be sure not to use yarn ls detect-port, as it's buggy.

@gaearon
Thanks,
removing node_modules completely and installing all the dependencies fixed the issue for me.

Looks like we need to bump detect-port to 1.1.1: https://github.com/node-modules/detect-port/pull/16#issuecomment-287391497
PR, anyone?

cc @gaearon PR opened #1861

For any newbies running into this bug, I fixed it by downgrading NPM to the LTS (latest stable version) of 6.11.2.

Had a similar issue using npm to install.  Fixed by removing both npm-modules and package-lock.json (a variant of @gaearon's comment above)

hehhehhehhe

说中文撒大佬们


Discard fast methods coming from trace_methods

Closes elastic/apm-agent-java#440
Made a few decisions:

Never discard transactions
Never discard branches leading to async branches so not to break span parent referencing
Off by default (config option set to 0)
When on (ie threshold > 0) - branches leading to spans ending with Exceptions are not discarded

The last one is explicitly related to a threshold setting, however, it makes sense that if someone opts to lose non-interesting, error traces are still valuable

Codecov Report

Merging #577 into master will increase coverage by 0.72%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master     #577      +/-   ##
============================================
+ Coverage      62.3%   63.03%   +0.72%
  Complexity       68       68
============================================
  Files           187      188       +1
  Lines          7064     7271     +207
  Branches        814      843      +29
============================================
+ Hits           4401     4583     +182
- Misses         2394     2418      +24
- Partials        269      270       +1

Impacted Files
Coverage Δ
Complexity Δ

...astic/apm/agent/metrics/builtin/ThreadMetrics.java
100% <100%> (ø)
0 <0> (?)

.../apm/agent/concurrent/ExecutorInstrumentation.java
39.58% <0%> (-5.88%)
0% <0%> (ø)

...va/co/elastic/apm/agent/impl/ElasticApmTracer.java
82.92% <0%> (+0.11%)
0% <0%> (ø)
:arrow_down:

...tic/apm/agent/configuration/CoreConfiguration.java
100% <0%> (+0.69%)
0% <0%> (ø)
:arrow_down:

...astic/apm/agent/impl/transaction/TraceContext.java
90.95% <0%> (+1.22%)
0% <0%> (ø)
:arrow_down:

...bci/methodmatching/TraceMethodInstrumentation.java
64.93% <0%> (+5.36%)
0% <0%> (ø)
:arrow_down:

...apm/agent/impl/transaction/TraceContextHolder.java
56.86% <0%> (+6.86%)
0% <0%> (ø)
:arrow_down:

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 5dce160...98d93ce. Read the comment docs.

I think this approach may not be generic enough as there might be async spans without a prior wrapping.

Isn't this the same with reference counting, which relies on wrapping as well?

Also, async spans which don't outlive their parent can safely be discarded when they are fast.

May not be consistent - can sometimes outlive parent and sometimes not.
In general, this PR is an enhancement for trace_methods users that use it with wildcards. It is still not the recommended way of using this feature.

Jenkins run the tests


Output graphics need labels in Pro

For ArcGIS Pro the Distance and Direction tools do not show labels for output graphics the same way that ArcMap does. Now we get the graphics drawn on the map, but no labels to tell about the geometry's construction:

In ArcMap (10.4.1 in the example below) the tools give us the following:
For Lines:

Bearing (angle)
Distance

For Circles:

Radius/Diameter

For Ellipses:

Major axis length
Minor axis length
Orientation angle

Still an issue at Build 1057 (1/5/2017 @ 9:07 AM) on ArcGIS Pro <IP_ADDRESS>97

@pHill5136 Based on the work that was done for the webinar is this something that we could fix?

Labels are still a limitation in Pro.

@kgonzago @pHill5136 - Pro does have a TextSymbol (at least in the latest) - can you explain a little more about the limitation?
https://pro.arcgis.com/en/pro-app/sdk/api-reference/index.html#topic12379.html

Adding @csmoore comment from duplicate issue #479 on 2/22/2018:
I saw in the Symbology section of "What's new at Pro 2.1" that "Text elements are now supported within marker symbol layers." so that may also be an option.
Here is an example of how to configure in Pro - not sure how to do programmatically:

This has been addressed. This issue can be closed.

@lfunkhouser


SYSLIB1051 documentation is wrong

This is the error I'm getting:

SYSLIB1051	Runtime marshalling must be disabled in this project by applying the 'System.Runtime.CompilerServices.DisableRuntimeMarshallingAttribute' to the assembly to enable marshalling this type. The generated source will not handle marshalling of parameter 's'.

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

ID: f9effd79-dc69-b250-965b-eb878b21a41b
Version Independent ID: 3517eb7a-2f72-5941-d207-e2febee88306
Content: SYSLIB diagnostics for Microsoft.Interop.LibraryImportGenerator - .NET
Content Source: docs/fundamentals/syslib-diagnostics/syslib1050-1069.md
Product: dotnet-fundamentals
GitHub Login: @gewarren
Microsoft Alias: gewarren

@elinor-fung It looks like there's a bunch of different messages you can get for SYSLIB1051. Where is the "title" used, and should I be documenting these diagnostics differently on this page?

I believe the title for diagnostics is only part the ID used when suppressing it in source and the (formatted) message is what is actually shown as the description. For the *WithDetails messages, it looks like we only include the detailed reason (in this case the runtime marshaling) a type is not supported, without the generic 'type is not supported by source-generated p/invokes' message.
@AaronRobinsonMSFT @jkoritzinsky maybe we should always have the generic issue in the message followed by the details?


remove redundant blank line before test run outcome

Description
The blank line before the test outcome bloats the line count (especially when many test runs are performed in a single build) and has little value.
Before
Starting test execution, please wait...

Test Run Successful.
Total tests: 63
     Passed: 63
 Total time: 1.6310 Seconds

After
Starting test execution, please wait...
Test Run Successful.
Total tests: 63
     Passed: 63
 Total time: 1.6310 Seconds

@adamralph while the fix is not major, my only concern is that it could break people who are parsing the console output for vstest.console, which is why I would be reluctant to take this.
@singhsarab for additional input.

@mayankbansal018 the changes introduced by this issue, and released in SDK 2.2.300, are way more likely to break anyone than the removal of a blank line: https://github.com/microsoft/vstest/issues/1836

@adamralph yeah that's actually more disruptive, & I had totally forgotten about that change 😢.

In which version of the .NET SDK can we expect this change?

In which version of the .NET SDK can we expect this change?

In which version of the .NET SDK can we expect this change?

You change is included in 16.2.0 onwards, so that would be sdk 3.1.100 and newer.

Thank you @nohwnd.
Would it be a good idea to assign milestones? Then I wouldn't have to ask.

@nohwnd it's still there in 3.1.200

@adamralph you are right, the space is still there. And I can see the line you removed is still gone in the master. Looking at the code it only affects situations when we have attachments (say a code coverage log), so I am guessing it is not impacting this situation.
I will be revisiting the console output in the next sprint in the other issue. We can polish it there. 🙂

Would it be a good idea to assign milestones?

I am adding milestones, but the mapping between our release and dotnet/sdk is not that easy. We don't control what they take, and where they take it. I am monitoring this, and believe me, it is also my goal to get this more transparent. Because right now it is very hard to see where each fix will end up and how to update to that version.


Notifications update

I updated missing data for 10 notifications and added my name to the contributors.

I assume you meant the indentations of the  tag. its now in line with the others :-)

TY! :D


Double clicking on search result should open the file with that line active

Check for existing issues

[X] Completed

Describe the feature
This is how it works in VSCode.
If I double click on this line

It will open the file with cursor on the line:

In zed however, double clicking this:

Does nothing. It's super annoying.

I'm aware i can press the little arrow all the way on the right

But that is pretty far, i just want to double click on the line.

Hey @nikitavoloboev, this is a duplicate of

https://github.com/zed-industries/community/issues/374

Check that issue out for more info on why this change is a bit awkward within Zed.
Also, just to mention it, we also allow jumping to the original files if your cursor is in the excerpt and you use opt-enter.  A neat trick is having multiple cursors in multiple excerpts and running that command - all associated files will be opened up.