Please clarify wildcard behavior with log rotation example file.yml

Description
In reviewing the example file.yml file for infrastructure-agent log configuration I felt the documentation was a bit unclear as to the behavior of the agent when using a wildcard in the file path and when log rotation is enabled. Copied/Pasted section from https://github.com/newrelic/infrastructure-agent/blob/master/assets/examples/logging/linux/file.yml.example...
# WARNING: avoid using wildcards that include the file extension, since
# it'll cause logs to be forwarded repeatedly if log rotation is enabled.
name: log-files-in-folder
file: /var/log/logF*.log

The documentation above states that one should avoid using wildcards that include a file extension when log rotation is enabled but the actual example configuration using a wildcard appears to do just that. To avoid excessive log forwarding should the line above look like this instead?
file: /var/log/logF*

Hi @jjensen-incomm, I shared this question with people that are focused on the Logging forwarder to see if they can help.
You can also visit New Relic Support, where you can engage the New Relic Support Community or open a support ticket depending on your support level. The support team is best positioned to assist with your specific needs. Please provide a link to this github issue when submitting your community post or support ticket.

Hi @jjensen-incomm thank you for your question!
I guess that the answer depends on how your log rotation is configured. If you have something like:
/var/log/logForward.log
logFile.log.2020-09-28
logFile.log.2020-09-27

the correct is to configure with the file extension: /var/log/logF*.log since file: /var/log/logF* will be forwarded repeatedly


Add an API that does not require user to write a project_id.

Changes Unknown when pulling 053ef2a50659153b0ba6e3af4a7d2bb0d6a7b528 on bogdandrutu:projectid into ** on census-instrumentation:master**.

Codecov Report

Merging #589 into master will decrease coverage by 0.17%.
The diff coverage is 0%.

@@             Coverage Diff              @@
##             master     #589      +/-   ##
============================================
- Coverage     78.53%   78.35%   -0.18%
  Complexity      701      701
============================================
  Files           127      127
  Lines          3173     3179       +6
  Branches        289      290       +1
============================================
- Hits           2492     2491       -1
- Misses          615      621       +6
- Partials         66       67       +1

Impacted Files
Coverage Δ
Complexity Δ

...xporter/trace/stackdriver/StackdriverExporter.java
26.47% <0%> (-5.68%)
3 <0> (ø)

...census/implcore/trace/export/SpanExporterImpl.java
90% <0%> (-1.67%)
6% <0%> (ø)

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 e8e4d4b...053ef2a. Read the comment docs.

Changes Unknown when pulling b6d732e6fd8b4fd377757dd84b5705241dc55d40 on bogdandrutu:projectid into ** on census-instrumentation:master**.

Changes Unknown when pulling 92960af609c99a43d7a9cc0fcedd956f3fbdb05a on bogdandrutu:projectid into ** on census-instrumentation:master**.


Use latest version of testenv from Polaris SDK

Using testenv@latest pulls in the old version of the repository which doesn't contain testenv. The solution is to continue using a fixed version.


fixed regex to support RAW

you can on -- > check https://regex101.com/
using --> ^https://.+?/(?P<account_id>.+?)/(?P<repo_id>.+?)(?:/blob/|/tree/|/)(?P<branch_id>.+?)/(?P.*?)$


Old fields and tags show up after dropping measurement and rewriting

Using version influxdb-1.5.2, if I drop a measurement, and then write again using the same name, the measurement is recreated but it contains all the tags and keys from the previous measurement.
I noticed this after writing a measurement with an identifier as a field, then deciding to make it a tag.  I could no longer query the data without a ::tag cast because the database still retained the old field key.  I started playing around with arbitrary keys and values, and dropping the measurement.  Every thing I've sent is retained across 'drop measurement's
I've even tried to drop the measurement, stop the database and rebuild the index, but this doesn't work either.

@cheribral could you provide some steps for us to reproduce this issue?

This is using the disk based tsi1 index.
This came right after I deleted the measurement and let it sit for a day before writing again.
I went back to make a test measurement to copy and paste the steps, and I can't reproduce it for some reason.  I have no idea what the difference is other than that I don't have writes coming in to the measurement while I delete.
I'll see if I can get it happen again tomorrow.

@cheribral thanks, we will need example data and steps so we can follow along and understand the issue better.

Im having the same issue. Here is an example:
> drop measurement memory
>show field keys from memory
returns nothing
> insert memory,host=test,type=memory value=0
> show field keys from memory
name: memory
fieldKey       fieldType
--------       ---------
buffered       float
cached         float
free           float
heap_usage     float
non_heap_usage float
slab_recl      float
slab_unrecl    float
used           float
value          float
> select * from memory limit 10
name: memory
time                buffered cached free heap_usage host non_heap_usage slab_recl slab_unrecl type   used value
----                -------- ------ ---- ---------- ---- -------------- --------- ----------- ----   ---- -----
1531445331027521830                                 test                                      memory      0

All these fields shown are old fields I am not using anymore but I can't seem to get them to go away.  I have gotten them to go away before by running this:
nflux_inspect buildtsi -database graphite -datadir /var/lib/influxdb/data/ -waldir /var/lib/influxdb/wal/
This is not fixing this issue this time.
Hope this helps.

Im having the same issue. Here is an example:
> drop measurement memory
>show field keys from memory
returns nothing
> insert memory,host=test,type=memory value=0
> show field keys from memory
name: memory
fieldKey       fieldType
--------       ---------
buffered       float
cached         float
free           float
heap_usage     float
non_heap_usage float
slab_recl      float
slab_unrecl    float
used           float
value          float
> select * from memory limit 10
name: memory
time                buffered cached free heap_usage host non_heap_usage slab_recl slab_unrecl type   used value
----                -------- ------ ---- ---------- ---- -------------- --------- ----------- ----   ---- -----
1531445331027521830                                 test                                      memory      0

All these fields shown are old fields I am not using anymore but I can't seem to get them to go away.  I have gotten them to go away before by running this:
nflux_inspect buildtsi -database graphite -datadir /var/lib/influxdb/data/ -waldir /var/lib/influxdb/wal/
This is not fixing this issue this time.
Hope this helps.

Thanks @dustin96080,
do you have a set of data to insert that will reproduce this bug?

Also, were you using TSI previous to 1.5.2?

@e-dard We have been using TSI from the beginning (about 1 year).

Same issue for me - why can't we drop and wipe out a measurement; Influxdb - why are you caching the OLD fields .... grr ....
If I insert the same data into a new table, insert goes through; Otherwise I get this error:
influxdb.exceptions.InfluxDBClientError: 400: {"error":"partial write: field type conflict: input field "BLAH_007" on measurement "BB2" is type float, already exists as type integer dropped=1"}

me too have same issue..

What I've found is that If I do a backup, and then restore this backup somewhere else (in other docker container, for example), the new database will work fine.

The only way that I managed to deal with this (very hackish workaround) was creating a backup to the database that I want, drop this database and finally restoring the backup.

Seems I'm going from one issue to another :-( I'm using the docker image influxdb:1.4-alpine.

Yes, it is quite bad here. I think it has to do also with the GO language, such a 'low entry threshold level' language, compared to something like c and c++. Is attracting the 'left over' programmers that were 'unable' adopt to more complex and more effort taking language. This difference is also noticeable with something like php. But that is a personal opinion from years of experience, maybe I was just not to lucky with my contacts.
Here some rookie accepts this as being normal. I guess it is a sign of the times.
https://community.influxdata.com/t/or-rention-policies-are-not-correctly-dropped-or-there-is-something-wrong-with-the-cli/7461/4?u=f1outsourcing

Currently experiencing this issue with InfluxCloud - really painful as I can't even try the backup/restore option someone else mentioned

We think this could be fixed with the 1.7.2 release, where we have fixed a few bugs to do with concurrent writes and deletes.
@nibynool please drop a ticket into support where you will be assisted.

Just experienced this same problem, on Influx 1.7.3 in the influx-1.7.3-alpine container from dockerhub.
I created a new measurement. Added some data to it. Then realized I need to change the datatype on one of the value fields.
I dropped the Series, then dropped the while measurment.
Recreated the measurement with the same name, then tried re-adding the values with a new datatype. Getting error saying the value field is the wrong type.
Influxdb (the index?) is still holding onto the old datatype from the old measurement, and trying to apply it to the new values in the new measurement.

I am also experiencing this bug. It is very annoying during development. Is someone working on solving this ?

I meet the same bug.how to solve it....

Issue still occurs
InfluxDB version: 1.7.3
Did someone found any workaround?

@kordianslowacki They way I worked around it in my project was to create the new measurement with a slightly different name than the old one. That ensures it does not pick up any cached field properties from the deleted measurement because that only happens when you use the same name.

The only workaround seems to be making a snapshot of the database, and restoring it.
https://docs.influxdata.com/influxdb/v1.7/administration/backup_and_restore/
Seeing this kind of issues opened for so long, without feedback from the maintainers, is a little worrying about the project as a whole

Same here:
$ influxd version
InfluxDB v1.7.4 (git: 1.7 ef77e72f435b71b1ad6da7d6a6a4c4a262439379)

I am wondering if this has something to do with telegraf?  I have several measurements, a few of them come from telegraf that I am just now experimenting with.  It seems like the measurements that were created from telegraf cannot be dropped but I am not certain of that yet.  It might just be a coincidence.

@sslupsky Definitely not telegraf related. We've replicated it on multiple databases (both InfluxCloud and our own) without telegraf data present.

@shakefu  Good to know.  Thanks for the feedback.   I stopped ingesting data into few measurements several days ago.  I still cannot drop them.

Issue still occurs
InfluxDB version: 1.7.3

We're also affected by this.

I just noticed this is still happening on 1.7.5. Dropped a measurement with 6 fields and rewrote it with just 1, and the other 5 came back with null values

Just tested on 1.7.6 without any luck. We are storing automated test run results, so before each run we want to have a clean state, but after one insert old fields keys show up again with null values. Tried with DELETE, DROP SERIES and DROP MEASUREMENT, with the same outcome.

Mee too, drop measurement wit 5 fields, re-create measure with 1 field.
Select show 6 fields.
InfluxDb version 1.7.5,
InfluxShell version 1.7.4

I can reproduce that behaviour with InfluxDb 1.7.6, I can provide data if anyone's interested, just tell me what you need.

Well, this is quite an obnoxious bug.
As @derrix060 mentioned above, the only hackish workaround is to drop a database and restore it. But it has an interesting twist to it. It has to be restored as a new database (may or may not have the same name).
Thus the routine is as follows:
# Backing up the database
influxd backup -portable -database "${DATABASE}" /path/to/backup

# Droping the database
influx -username $USERNAME -password $PASSWORD -execute "DROP DATABASE \"${DATABASE}\""

# Restoring the database
influxd restore -portable -db "${DATABASE}" -newdb "${DATABASE}" /path/to/backup

@wollew do you have shards/dbs that you would be willing to upload to us, along with repro steps? Alternatively, can you reproduce from scratch by inserting, deleting and querying in a certain way?

I cannot reproduce with a database from scratch but I can upload a database and steps to reproduce. Which files do you need, contents of folders wal and data?

@wollew that would be great. Please email me<EMAIL_ADDRESS>and I will provide you with some credentials where you can securely upload data to our company SFTP server. If that doesn't work for you we can figure something else out.

I have spend quite some time to find a sure way to reproduce the problem. It did not work. The same procedure (with little data) only seldomly reproduced the problem. However, I have a large number of larger datasets where I almost always found the problem.
Therefore, I have the feeling that this only occurs if large amounts of data are accumulated, e.g. a datapoint every 5 or 10 seconds for several days or weeks (maybe if data is spread over different files or shards?).
Thanks for looking into this, this gives us a huge headache as somtimes datapoints are written with the wrong datatype and we have to rename the values and keep the old fields. Currently, the only way is to copy the whole measurement without the wanted fields, drop the measurements, copy it back and then backup and restore the whole database. Can take hours just to get rid of a single field.

@wollew that would be great. Please email me<EMAIL_ADDRESS>and I will provide you with some credentials where you can securely upload data to our company SFTP server. If that doesn't work for you we can figure something else out.

I just emailed you, hope that helps.

Any news on this issue?

Just got slammed with this in production. Really really frustrating.

Same here with InfluxDB 1.6.6 on Linux
I wrote some fields as strings instead of float. Old schema survives a "drop measurement" if you reuse measurement name. It is really surprising a database company:

fails to test a fundamental feature
fails to recreate a simple and dire bug

We are actively investigating this issue. Thanks for your patience, and to those of you who have provided me with data to reproduce the issue.

Update
Hello everyone affected by this issue. Firstly, I would like to apologise that it's been almost a year since this issue was filed. Yesterday I was able to really dig into what was causing this issue, mainly due to the .influxdb directly that @ragnarkurmwunder sent me a while back.
This is a pretty difficult issue to reproduce without an existing dataset. Triggering the issue relies on duplicates of a new series being inserted into a database using the inmem index within the same batch. Further, it looks like they need to sit inside of the WAL so that when the database is restarted they will be replayed in and the problem will continue...
The cause of the issue is that the inmem index, in this rare case over counts how many series belong to the measurement (it counts the duplicate points for the same series as different series). Then, when you go to delete the measurement, the index thinks there are still some series around for the measurement and it does not clean up the fields.idx file. This file contains mappings from measurements to field keys, and if it's not cleaned up properly, then those old field keys can be returned in some cases.
I believe I have fixed this issue in https://github.com/influxdata/influxdb/pull/14266
The fix will be available in the 1.8 release, and also in a future 1.7.8 release.
Operational Mitigation Steps
Here are some operational steps you could take to try and resolve this issue without waiting for 1.8 or 1.7.8.
Use the TSI index
I was unable to reproduce this issue using the TSI index. Even when I triggered the issue on the inmem index, and then upgraded to the TSI index, I saw the issue disappear. Whilst we will of course continue to support the inmem index on the 1.x line, from 2.x onwards the TSI index will be the main index InfluxDB uses, and all our development effort will continue on that.
You can find out more information about how to upgrade to TSI here. In the simplest case, you bring your server down and then do something like:
influx_inspect buildtsi -datadir ~/.influxdb/data -waldir ~/.influxdb/wal

Remove invalid fields.idx files
The bug is caused because the fields.idx files (there is one file per shard directory) are not properly rebuilt when the measurement is deleted. However, InfluxDB will rebuild these files if they're missing. If you are currently suffering from fields that are appearing in queries when they shouldn't be then I recommend that you delete all of the field.idx files for the problematic database/retention policy. You will need to bring down your server to do this, then:
$ rm -i ~/.influxdb/data/<db_name>/<rp_name>/*/fields.idx

That's some great news!
Will we need to do the manual cleanup if we just update to 1.7.8 when it's released?

@1ma that's a great point. We will have to add something to the release notes. You will have to either do a manual cleanup, or the issue will resolve itself if you re-drop the measurement.

officail docker image influxdb:1.7.7 still has this issue.
So I had to drop database

Any news on this ? I am not sure the issue mentioned by @e-dard above is the same as what everyone is encountering here. The issue is not "hard to reproduce", for me it happens systematically with any measurement that I drop.

also experienced this issue on influx v1.7.7.
just now, I'm experimenting using telegraf to convert a csv to my influxdb database.
At first the drop is successful, but after 3 attempts the drops suddenly didn't work. The points are gone from the measurement, but everytime I "show measurements", it's still there. Also when I use "show tag keys" and "show field keys", the tags and fields are still there. Then untill now, the measurement cannot be dropped at all.
I hope there is a continuation from influxdb team to solve this "bug"

This issue should be fixed in 1.7.8. Please open a new issue if you see problems on 1.7.8.

We are having same issue with InfluxDB. We use tag 2.5.1-alpine inside a container.
I have a table where metrics coming from Kafka are inserted there.
Initially the table had three tags and several fields. To make measurement faster i changed telegraf agent config to make some of the fields as tags.
So instead of having measurement like:
tag1,tag2,tag3 field1,field2,field3,field4,field5
I made them
tag1,tag2,tag3,tag4 (name of field1),tag5(name of field2) field3,field4,field5
I dropped old table and Influx seems to work fine.
After some time i wanted to change my dashboards showing the metrics and i redeployed the whole stack (changing only dashboards code). After this one it seemed like Influx brought back somehow the old metrics as well, creating conflict and renaming the new tags to tag_1 etc, of course making the queries not to show anything. Dropping again the tables fixed the problem, till new restart reproduces it.


[Bug] Security vulnerability in<EMAIL_ADDRESS>(used by VSCode & Monaco)

Reproducible in vscode.dev or in VS Code Desktop?

[X] Not reproducible in vscode.dev or VS Code Desktop

Reproducible in the monaco editor playground?

[X] Not reproducible in the monaco editor playground

Monaco Editor Playground Link
No response
Monaco Editor Playground Code
No response
Reproduction Steps
No response
Actual (Problematic) Behavior
Our OWASP scan detected an issue in<EMAIL_ADDRESS>CVE-2024-45801 which seems to be used by the Monaco editor (VSCode): https://github.com/microsoft/vscode/blob/main/src/vs/base/browser/dompurify/dompurify.js
Please update to<EMAIL_ADDRESS>to get rid of that vulnerability.
Thanks
Expected Behavior
There should be no vulnerability issues.
Additional Context
No response

It looks like DOMPurify was bumped here https://github.com/microsoft/vscode/pull/228773/files but not yet vendored like in this other DOMPurify bump PR - https://github.com/microsoft/vscode/pull/189368/files

@rzhao271  Just wanted to at you as you merged in the version update for DOMPurify

Looks like one more CVE is found now CVE-2024-47875

This pr will bump to the currently latest release (3.1.7): https://github.com/microsoft/vscode/pull/230250

Closing as upstream change in VS Code has been merged

@mjbvz thank you for fixing the issue 👍.
Do you happen to know when 0.53 monaco-editor version will be released with the vulnerability fix?

@aleixsuau it is tracked in https://github.com/microsoft/monaco-editor/issues/4738, no idea when it will be released unfortunately


runners:jlink: fail to flash board with protected sector when erase requested

Describe the bug
After change #39734 it is not possible to flash board with protected memory area. When erase of board is requested in jlink runner args, protection of memory cause error during mass erase and flash procedure stops. Issue is visible on stm32wb55 when part of memory that is used by second core is protected against erase.
To Reproduce
Try to flash board with part of memory configured as protected with erase option enabled for jlink runner.
board_runner_args(jlink "--device=STM32WB55xx" "--speed=4000" "--reset-after-load" "--erase")
Expected behavior
Board flashed successfully.
Environment (please complete the following information):)

Zephyr SDK 13.1
Zephyr: 404f67ab5e571b5e209ac59adc99edc15a3475d9

Log
J-Link>connect
Device "STM32WB55XX" selected.
Connecting to target via SWD
Found SW-DP with ID 0x6BA02477
DPIDR: 0x6BA02477
Scanning AP map to find all available APs
AP[2]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x24770011)
AP[1]: AHB-AP (IDR: 0x84770001)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FF000
CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
Found Cortex-M4 r0p1, Little endian.
FPUnit: 6 code (BP) slots and 2 literal slots
CoreSight components:
ROMTbl[0] @ E00FF000
ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT
ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM
ROMTbl[0][4]: E0040000, CID: B105900D, PID: 000BB9A1 TPIU
ROMTbl[0][5]: E0041000, CID: B105900D, PID: 000BB925 ETM
ROMTbl[0][6]: E0043000, CID: B105900D, PID: 005BB906 CTI
SetupTarget() start
WARNING: Secure Firmware detected @ 0x080CA000
Connecting to target AP[0]/Cortex-M4
CORE ID AP[0]:0x410FC241
CORE ID AP[0]/Cortex-M4 halted!
SetupTarget() end
Cortex-M4 identified.
J-Link>erase
Erasing device...
Comparing flash   [100%] Done.
Erasing flash     [100%] Done.
****** Error: Failed to erase chip @ address 0x08000000 (sector is locked)
Failed to erase chip.
Failed to execute RAMCode for chip erase!
J-Link: Flash download: Total time needed: 4.494s (Prepare: 0.025s, Compare: 0.000s, Erase: 4.461s, Program: 0.000s, Verify: 0.000s, Restore: 0.007s)
ERROR: Erase returned with error code -5.
J-Link>

@bbilas @JordanYates FYI

Please revert this commit and put the log without this change + return code of the flash command. Basically that change shouldn't have an impact on that.

@bbilas - can you send a PR to fix?

@cfriedt I don't have such hardware to reproduce that error so I'll try to use MIMXRT1060-EVK with JLink BASE instead. Any information related to it would be appreciated.

@bbilas Did you had a chance to make some progress on this ?

No, I didn't. It seems that I need that HW to be able to reproduce that issue but I'm lacking that.

@bbilas, @erwango  I've checked on 25e6803705b25602eb0b730a03a254c354bfae9e and issue still exist.

@Zzzwierzak Would you mind a try to provide what was suggested in https://github.com/zephyrproject-rtos/zephyr/issues/40201#issuecomment-964219844 ?

My 2 cents on this issue:

There's a protected fw (BLE f/w used on M0) on stm32wb socs (cf trace WARNING: Secure Firmware detected @ 0x080CA000)
The jlink command request a full chip erase from what I can understand( "--erase") which is not possible due to the presence of protected sectors and hence the command fails
Issue wasn't visible before https://github.com/zephyrproject-rtos/zephyr/pull/39734, since the jlink command was continued on the already present erase command error

Based on this, I don't think that present behavior is an actual issue.
There are 2 options:

Don't use --erase command at all
If available, use a sector erase command if possible (or alike). This is what I'm using for this board on our bench with STM32CubeProgrammer tool (STM32_Programmer_CLI -c port=SWD  freq=4000 ap=0 mode=UR  -e [0 255]' > erasing sectors 0 to 255)

@erwango Output from Jlink without change is same( Error -5), but error from erase is discarded silently, after change it is breaking west flash in CI, that cause test fail with flash error.
Unfortunately testing without erase is not stable, and using STM32CubeProgrammer is not possible.

@erwango Output from Jlink without change is same( Error -5), but error from erase is discarded silently, after change it is breaking west flash in CI, that cause test fail with flash error.

I understand the problem on your side, but this doesn't sounds like an actual issue as returning an error on erase error is a sound behavior. Support for your use case would likely require an enhancement :

add support for sector erase
add option not to fail on erase issue

@erwango Both options are good for me.

@erwango Output from Jlink without change is same( Error -5), but error from erase is discarded silently, after change it is breaking west flash in CI, that cause test fail with flash error.

I understand the problem on your side, but this doesn't sounds like an actual issue as returning an error on erase error is a sound behavior. Support for your use case would likely require an enhancement :
* add support for sector erase

* add option not to fail on erase issue

Support for sector erasing is the most suitable solution in my opinion only if it's supported by jlink.

@Zzzwierzak Would you mind testing this https://github.com/zephyrproject-rtos/zephyr/pull/42144 MR? It introduces erasing specified flash range but due to lack of hardware, I'm not able to test it.
Example:
west flash -d build --erase-range 0x60000000 0x607FFFFF

@bbilas Yes, it's working with stm32wb55.

I guess we can close it?

@bbilas Yes.

@Zzzwierzak I don't have any permission to manage this issue, so could you do that as the author?


Is it possible to only run gateway and ingress?

Istio Ingress is awesome, but it's the only part of Istio that I can make work. Is it possible to run only the gateway and ingress portion of Istio? Linkerd2 looks like it can handle the rest. I've seen some docs on this, but they are a year old and I doubt they have much in common with Istio Ingress now.

Yes, that is possible, I think you also need pilot to push config to the gateway.  BTW, istio ingress is deprecated now.

@linsun Thanks for the response. :) I believe the istio ingress being deprecated is the old system, and the new system is the Gateway / VirtualService routing rules, correct? Gateway / VirtualService is what I'm using now and it is absolutely awesome.

@mabushey yes, that is correct.  Gateway / VirtualService replaces the old ingress and routing rules.


Bug fix/fixes 08 07 2019

Scope & Purpose

Remove superfluous warnings when a CAS operation fails when adding/dropping followers. The warnings are superfluous here because the operation is retried anyway, and if it finally fails there will be another warning.
Remove redundant method for finding the most suitable index. Instead, use just one method for it.

[x] Bug-Fix for devel-branch (i.e. no need for backports?)
[x] The behaviour change can only be verified via automatic tests

Testing & Verification
This change is already covered by existing tests, such as all AQL tests.
https://jenkins01.arangodb.biz/view/PR/job/arangodb-matrix-pr/5118/

https://jenkins01.arangodb.biz/view/PR/job/arangodb-matrix-pr/5124/


Telling libclang where to look for system includes

I've had success using bindgen on Windows with MSVC, but in order to do so I have to specify the INCLUDE environment variable as so (minus new-lines):
C:\Program Files (x86)\Microsoft Visual Studio\Shared\14.0\VC\include;
C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt;
C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\um;
C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\shared

Without this definition clang fails to find the system headers. I also have to specify -fms-compatibility-version=19 (not 14) via Builder::clang_arg to get this to work.
Obviously this configuration is specific to this particular version of MSVC and my installation setup, so I'm reluctant to hard-code this into a crate that uses bindgen. Ideally bindgen would be able to, via use of the gcc crate, figure out whether additional configuration of libclang is necessary to match the system headers and ABI of the toolchain decided upon by the gcc crate (this allows bindgen output to match the ABI of, for example, external C++ code built with the cmake crate).
In terms of achieving this, it appears straightforward when the C++ compiler picked is gcc or clang, as they can be queried easily (via a flag) for the system include paths. It looks to be much harder to get this information out of MSVC. There are two "IDE" variables that contribute to the system include directories list by default, VC_IncludePath and WindowsSDK_IncludePath. Their definitions are in separate XML files whose locations vary based on MSVC version and installation. The most robust way of finding their values may be to have a MSVC project (perhaps generated using cmake) that builds an executable that prints them out.
Thoughts? Please note that implementing at least part of this would be of benefit when using gcc or clang, not just MSVC, as it would ensure bindgen matches the standard library implementation.

I agree that this can be a pain, but I don't feel like I personally understand msvc/windows development enough to fully understand the different options available. (Or even an understanding of all the platform differences and little complexities.)
We do have some auto path stuff here: https://github.com/rust-lang-nursery/rust-bindgen/blob/bb315bfa7c23333a2c02374d7b7dbfbd3a97f0b6/src/lib.rs#L1411-L1436
Undoubtedly it is incomplete and/or incorrect in some ways.
Perhaps @emilio has a better grasp of these things.

Apparently the HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\Windows registry key has a subkey for each installed SDK, with an InstallationFolder value. And then the include directory should be something like ./Include from that. Except when it is dependent on the build number. In which case we can maybe crawl that corner of the filesystem.

It would be nice if bindgen had the same behavior for looking up VC++ installs and Windows SDKs as the cc crate: https://github.com/alexcrichton/cc-rs/blob/master/src/windows_registry.rs


Timeout of admin.$cmd in replicasetInquirer is not handled correctly

If you get disconnected from the mongo primary and the replicasetInquirer runs, it sets up a "timeout" and disconnects the first connection in the pool after the "timeout". This triggers a close on the connection but ultimately does nothing since there are 4 other connections on that server that are assumed to be okay. This prevents any ha from ever running again until the actual query finally times out many minutes later.
I cannot use socketTimeout since the default pool of 5 connections would cause the timeout to happen all the time if more than 1 connection isn't need sometimes.
It seems like maybe when a connection is closed all the commands that were sent over that connection should error out. This won't solve the problem since the timeout is just destroying the first connection in the pool instead of actually destroying the whole pool or destroying the connection the actual admin.$cmd was sent over.
Why doesn't the closeHandler in server doesn't have:
    // Flush the connection operations
    if(self.s.callbacks) {
      self.s.callbacks.flushConnection(new MongoError(f("server %s closed", self.name)), connection);
    }

I created a JIRA issue: https://jira.mongodb.org/browse/NODE-665


update samples for interactive csharp

Update the samples and snippets for the Math.Round page to conform to the snippet limitation on C# interactive.
contributes to dotnet/dotnet-api-docs#2539

One question though about this: should we make the same changes to VB and C++ counterparts too? Or is the intention here that we roll these back once we support full snippets?

@mairaw That's an open question. We should coordinate with @LadyNaggaga on the future plans and roadmap to pick the best of those two options.


[enhancement] Add suppot to align class variables and functions in c++ (.h files)

The extension currently won't align in the following example:
class MyClass {
  public:
    int myNum; // Attribute (int variable)
    string myString; // Attribute (string variable)
};

to:
class MyClass {
  public:
    int    myNum;    // Attribute (int variable)
    string myString; // Attribute (string variable)
};

I guess this is because there is no "=" character in the lines.

This has been fixed in v1.4.0


Number formatters - tipFn shortcut for original value

Would like to make it easy to enable a tooltip on formatted numbers that displays the original, full precision value with some improvements.
Right now I believe you can specify tipFn: v => v to output the original value, but would be nice to support a shortcut like tipFn: true that showed the original value in a tooltip with:

Commas inserted if >= 1000
Wrapped in () if ledger formatting also specified
Potentially still cap precision at MAX_NUMERIC_PRECISION in case we get crazy floating point numbers?

The first two in particular could significantly improve the legibility / consistency of the output.  Believe this would be the equivalent of tipFn: numberRenderer({ledger, forceLedgerAlign: false, precision: 12, zeroPad: false})

Would like to consider renaming the param here tooltip to make it a bit more generic, encourage use of any new boolean shortcut. Either way would be great to be consistent with column API additions in #509

Resolved in eee14d6819a1a6b0f3462551d02f52ad30dc11ef


Fix for NPE signature

Leaving as a draft as there can be different resolutions.
After discussing with Pierce, it is highly possible that we received an invalid input from the stream.
As the client side stacktrace shows that there was an attempt to build facts and it has been known that contracts are built with null facts:
        at io.p8e.engine.ContractWrapper.toFactInstance(ContractWrapper.kt:132)
	at io.p8e.engine.ContractWrapper.buildFacts(ContractWrapper.kt:105)
	at io.p8e.engine.ContractWrapper.<init>(ContractWrapper.kt:29)

Thus receiving NPE at signature update time, when testing with HelloWorld contracts this error didn't come about.
Solutions:

Wrap the signature update as in this PR shows and let it error out eventually in the execution lifecycle.
Let the client know at this point P8e received invalid/null stuff to sign.

Also the signature.update method moved from the update input stream method down stream to the sign method because we needed to manually parse the data needed for the signature in order to support other signer types, thats why this issue happened now and not previously.

I tried a number of different ways to try and reproduce the original issue (creating contracts with facts that weren't set, functions with fact inputs that weren't set, both single and multi-step versions of these things), and wasn't able to get the same NPE... got other versions of things like expected hash length 64, got 0 or things like that... so, I guess this should at the very least help us figure out what the actual underlying error might be if one crops up

Did you happen to test the case where you run an update contract that has more than one fact, but only update one of the facts?

Did you happen to test the case where you run an update contract that has more than one fact, but only update one of the facts?

If I did it right, i don't think I got a NPE out of this (tested off of main)


[FLINK-8744][docs] Generate "Common Option" section

What is the purpose of the change
With this PR the "Common Options" section is now generated by the ConfigOptionDocsGenerator.
Brief change log

add ´CommonOption` annotation
annotate a few options with added annotation

I was very conservative as i do not want to discuss in this PR which options should be regarded as common

allow passing in a path prefix for testing purposes; this allows testing against Options* classes residing in the test scope
extend the generator to gather all annotated options and generated a HTML table
replace common section with generated file
extend completeness test to also cover common section
remove advanced section, as subsumed by full reference

Verifying this change

run ConfigOptionsDocGeneratorTest#testCommonOptions
run ConfigOptionsDocsCompletenessTest#testCommonSectionCompleteness

Looks pretty good.
Is there a way we can "sort" the common options? Something like

host:port (for standalone setups)
java memory
default parallelism / slots
fault tolerance
HA
security

they should be sorted alphabetically based on the key, but i now see that this isn't actually the case.
I'm not sure if I can easily add the kind of sorting you're asking for as that would require the generator to know about the semantics of an option ("oh, this is a port option, but that one is about memory!").

@StephanEwen The options are now sorted.

LGTM 👍

merging.


Sometimes netopeer2-cli can't connect to netopeer2-server

Sometimes I get this after reboot. connect in netopeer2-cli takes a long time and timeouts, I then try again and it works without issue. This happens very frequently, and I've also seen it happen on our server instances. When I tried to run strace it's hard to get any information because netopeer2-server seems to be in a polling loop.
root@Inteno:~# netopeer2-cli
get_netconf_dir: Configuration directory "/root/.netopeer2-cli" does not exist, creating it.
load_config: No saved history.
load_config: No saved configuration.
> connect
The authenticity of the host 'localhost' cannot be established.
ssh-rsa key fingerprint is b3:9f:8a:a4:6b:80:30:a5:85:8e:c3:71:6f:5f:74:49:06:49:fb:2c.
Are you sure you want to continue connecting (yes/no)? yes
Interactive SSH Authentication
Type your password:
Password:
nc ERROR: Authentication response timeout.
cmd_connect: Connecting to the localhost:830 as user "root" failed.
> connect
Interactive SSH Authentication
Type your password:
Password:

I have the same issue with docker image sysrepo/sysrepo-netopeer2:v0.7.7
logs
Type your password:
Password:
[2021/03/18 04:36:10.632176, 3] ssh_userauth_kbdint_send:  Sending keyboard-interactive response packet
[2021/03/18 04:36:10.633294, 3] ssh_socket_unbuffered_write:  Enabling POLLOUT for socket
[2021/03/18 04:36:10.633508, 3] packet_send2:  packet: wrote [len=28,padding=14,comp=13,payload=13]
[2021/03/18 04:36:16.766117, 3] ssh_packet_socket_callback:  packet: read type 1 [len=28,padding=11,comp=16,payload=16]
[2021/03/18 04:36:16.766190, 3] ssh_packet_process:  Dispatching handler for packet type 1
[2021/03/18 04:36:16.766202, 3] ssh_packet_disconnect_callback:  Received SSH_MSG_DISCONNECT 11:Bye Bye
[2021/03/18 04:36:16.766213, 1] ssh_packet_disconnect_callback:  Received SSH_MSG_DISCONNECT: 11:Bye Bye
nc ERROR: Authentication response timeout.
cmd_connect: Connecting to the localhost:830 as user "root" failed.
Kindly suggest

You are using a really outdated version that is no longer supported. But my guess would be that your libssh version is at fault, versions 0.9.3 and 0.9.4 are faulty and should not be used.

libssh version is 0.8.0
root@4ef5ad01b42a:/opt/dev/sysrepo# pkg-config --modversion libssh
0.8.0

Hm, that should work but there were too many problems with libssh to be sure so you can try to update to 0.9.5 anyway. Other than that I can only suggest you update at least to sysrepo 0.7.8/0.7.9 or even better to the current 1.x.


idea: terrain generation

http://alteredqualia.com/three/examples/webgl_terrain_dynamic.html

done good work.
still cleanup to do on the API

good enought for now. closing


Better behaviour in the presence of 429s

If a client sends requests at a rate of 40 per second, but the server
demands only 20 per second by sending back 429s, the default behaviour
should be that the server should smooth the client's load down to 20
per second.
Right now this does not work, because we use exponential backoff with
a maximum number of retries, and each call is independent, so each
individual request is as likely to succeed as any other.
What this means is that given sustained attempted load of 40 per second
and a limit of 20 requests per second, eventually some of the calls
will fail.
You can see this most easily right now with an endpoint that takes 1ms
to return with a rate limit of 1 request per second, which will fail
within a few seconds.
This PR attempts to fix the issue. It uses Netflix's concurrency-limits
library to apply a tcp-like strategy to request concurrency; basically
provided a single request per second won't be limited into oblivion,
you can make progress.
I also include a test that will fail immediately unless this concurrency
limiting code exists.
At the moment, the scope is per-endpoint - I don't know how to do
better. We could later on define 'limiting domains' which get somehow
annotated by the service author according to rate limit groupings.
Note that we'd have to modify our internal retrofit codegen to properly
add the path template header.
There is scope to improve this later - particularly to do this on the
server too, and prioritise interactive over batch traffic.
The main downside of this code is that you have to make sure you always
clean up - otherwise you have a resource leak. In order to avoid this,
there is code which cleans up in the case of the resource leak, logging
at the same time. This should avoid the IOException deadlock pain
we've seen in the past.

Note - testing is insufficient right now - this is to get validation on the approach, though I would like to get this merged soon :)

got fixes to this comin in soon

and tests etc

have you seen the concurrency limiting in Dispatcher? https://github.com/square/okhttp/blob/master/okhttp/src/main/java/okhttp3/Dispatcher.java
It also seems like ideally we'd be able to implement the concurrency limiting at the Call level. You'd end up with a ForwardingCall that looks something like:
public Response execute() {
    Limiter limiter = limiters.limit(pathTemplateHeader);
    Response response = delegate.execute();
    if (response / 100 == 2) {
        limiter.success();
    } else if (....) {
        limiter.dropped();
    } else {
        limiter.ignored();
    }
}

which lets you avoid the async extras. Doesn't necessarily need to be exactly this, but probably worth discussing an option like this?

The approach mentioned above is the way Netflix does it in their GRPC implementation as well: https://github.com/Netflix/concurrency-limits/blob/master/concurrency-limits-grpc/src/main/java/com/netflix/concurrency/limits/grpc/client/ConcurrencyLimitClientInterceptor.java


gh-1518 - stopped banner duplicating

Codecov Report

Merging #1521 into develop will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             develop    #1521   +/-   ##
==========================================
  Coverage      66.23%   66.23%
  Complexity      1768     1768
==========================================
  Files            731      731
  Lines          24232    24232
  Branches        3129     3129
==========================================
  Hits           16051    16051
  Misses          6915     6915
  Partials        1266     1266

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 0a4db47...2d06bf9. Read the comment docs.


[FLINK-2561] Adds missing Gelly scala methods and tests

This PR partially address FLINK-2561.

It adds all missing methods to Graph, except the recently added (#1149) fromCsvReader. It is not straight-forward to port this one (e.g. with a simple wrapper), so I suggest we address it with a separate JIRA.
It ports all existing tests to use collect instead of files and adds tests for the new methods.
It adds a completeness test (where fromCsvReader is temporarily excluded)
It adds the Scala version of the GraphMetrics example. For more examples to be added, #1033 and #1152 should be merged.

I will submit a separate PR for the documentation.

Looks good to me!
One style comment: I think that collect() should be written with parenthesis. In Scala, you use parenthesis if the methods are not purely accessing properties. The collect() function as effects.
Minor comment about the serialVersionUID in Scala inline.

Thank you for the review @StephanEwen! I'll address your comments and merge later.


Status of this work item/spec?

Hey @dhh1128 , I've been getting questions about this, and it looks fairly stale, nothing merged in almost a year.  Should we:

Add a little "DEPRECATED; WORK MOVED TO https://..." disclaimer across the top;
Add a similar disclaimer to the root repo readme file; and
Archive the underlying github repo

Or are there systems in product that use this, which would be slandered by such an archiving?  If so, we should call this v1, wrap it up, officially approve it, and maybe still point to ongoing work if v2 is happening elsewhere, in KERI land, etc.
CC @alenhorvat  @peacekeeper

IMO, the peer DID method should be superseded by using KERI DIDs in a particular mode that matches peer DID features, AND/OR by the did:key method when there is no need for endpoints or key rotation. The other latent issue with the spec, IMO, is that we need to update minor details in a couple places now that the DID spec has become a TR.
However, there is no impediment to using this DID method today. There are libraries for it in several programming languages, and they work well. So I don't think it's vital that we give the method a deprecated status. It's just old, not bad.
I don't mind merging (and that means writing, I suppose) a PR that inserts a note to that effect at the top of the document. I've not do so, to date, because I was hoping that did:keri would be a little better documented. But if you'd like to do that now, I'm happy to move ahead.
I would prefer NOT to archive the repo; there are many references to the spec in docs scattered all over the place.

I opened PR #43 with a suggestion about how we could modify the spec. What do you think, @bumblefudge ?

Note merged, suggest closing


Support data from server

Expected Behavior

Filter should fetch new data from the server
Should have paging support

Actual Behaviour
Component expects to receive the complete data set.

This should use - https://github.com/bvaughn/react-virtualized/blob/master/docs/InfiniteLoader.md

@essamor could you document your solution as an example for this?

Solution provided - https://github.com/kenshoo/react-multi-select/pull/89


[release-1.22] Ambient: Fix bug with initial node agent snapshot create

Manual cherrypick required.
#51321 failed to apply on top of branch "release-1.22":
Applying: Fix bug with initial snapshot create
Using index info to reconstruct a base tree...
M	cni/pkg/nodeagent/net.go
M	cni/pkg/nodeagent/server.go
Falling back to patching base and 3-way merge...
Auto-merging cni/pkg/nodeagent/server.go
Auto-merging cni/pkg/nodeagent/net.go
CONFLICT (content): Merge conflict in cni/pkg/nodeagent/net.go
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 Fix bug with initial snapshot create
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Manual cherry merged


Typescript 4.5 doesn't work with yarn 3 pnp linker

https://github.com/yarnpkg/berry/issues/3722

https://github.com/coilhq/web-monetization-projects/pull/2398


"Blocked" wording

This should be updated to stop referring to this as blocking. Setting the SCL to 9 and delivering to the junk folder is NOT blocking. That is treating as spam.
If a tenant admin wants to outright block a sender or domain, this doesn't accomplish that goal (unless high confidence spam is sent to quarantine).
This is also missing information on the fact that the actual action is dependent on the spam policy. That isn't even mentioned here.

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

ID: bbb3daf4-fa28-88d9-4543-89d8ff5ead5d
Version Independent ID: bbb3daf4-fa28-88d9-4543-89d8ff5ead5d
Content: Manage allows and blocks in the Tenant Allow/Block List - Office 365
Content Source: microsoft-365/security/office-365-security/manage-tenant-allow-block-list.md
Product: m365-security
Technology: mdo
GitHub Login: @chrisda
Microsoft Alias: chrisda

@danmyhre, I asked that very question several days ago (about what happens to the message is based on the action for high confidence spam in anti-spam policies). This was the response I got:

Antispam action is for taking action on mail detected as spam. TABL Domains & addresses (sender) block is for blocking the sender of the email. both are different.

So, it sounds like what happens is independent of the anti-spam policy.

Right as you correctly pointed out this is not the correct behavior. We will rectify this behavior by the end of this year.
Today, the email is marked as spam (SCL:9) and then the email gets acted on by the spam policy
Tomorrow, we are looking to move it to admin quarantine as we are doing for URL and file blocks in Tenant allow/block list.

Great - thanks for the info and getting that updated in the content @dhairyya


librealsense v2.38.1 does not work on kernel 5.4

Required Info

Camera Model
D400

Firmware Version
5.12.7

Operating System & Version
Ubuntu 18

Kernel Version (Linux Only)
5.4

Platform
PC

SDK Version
2.38.1

Language
C++

Segment
Robot

Issue Description
I have been running librealsense v2.33 on kernel 5.4 fine but if I upgrade to v2.38.1 I keep getting the
Could not get Frame metadata error
I do not want to build from source, why does 2.33 work but 2.38 does not?

Hi @fiorano10   I could not find information about any error by that name.  Is it the Frame metadata isn't available! that you are receiving?
Also, can you confirm which method you are using to build librealsense 2.38.1 with please (source code or packages).

Yup, that’s the error I get. Just installed via apt
sudo apt install librealsense2

So you have performed a package installation with sudo apt-get install librealsense2-dkms then?
There are few references about metadata problems with the packages.  Of the two successful conclusions that I have seen, doing a clean reinstall of Ubuntu solved the problem in both cases.

A clean install is not really an option, is there anything else that can done?

If a full clean uninstall is not an option then you could try uninstalling all of the librealsense versions that you have currently got installed that were installed with the distribution package method.
https://github.com/IntelRealSense/librealsense/blob/master/doc/distribution_linux.md#uninstalling-the-packages
The above process will not remove any librealsense versions on your computer that were built from source code.

@fiorano10 , the error you reported "Could not get Frame metadata error" is not in the SDK's source code and is probably generated by external wrapper/app.
I suggest to run Realsense-viewer and validate streaming, controls and metadata to establish whether it is related
sudo apt install librealsense2-utils=2.38.1...
As for the patches DKMS for 5.4 is is not available, so if the kernel is not patched (which sounds unreasonable, as you mention that with LRS 2.33.1 metadata works) then you can invoke the patches scripts from the installation guide.

Hi @ev-mp   Thanks very much for your help.  I think what @fiorano10  meant with that error name in the opening message is that they were actually receiving Frame metadata isn't available!, which they confirm with "Yup, that's the error I got" when I asked about it.  Thanks!

Hi @fiorano10   Do you still require assistance with this case, please?   Thanks!

Yes, no fix was suggested that worked

@fiorano10   You mentioned above that a clean wipe and reinstall of Ubuntu was not really an option.   Combined with your problems with dynamic_reconfigure in https://github.com/IntelRealSense/realsense-ros/issues/1431 it suggests that there are some wider problems in your system than just the kernel, unfortunately.

Hi @fiorano10  Have your problems in this case been resolved yet (bearing in mind that your computer seemed to have more problems than just the kernel).   Thanks!

Case closed due to no further comments received.


[Refactor][UI] Refactor user manage using NSpace component.

Purpose of the pull request

Brief change log

Verify this pull request

This pull request is code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

Codecov Report

Merging #10816 (6646baf) into dev (71f0168) will decrease coverage by 0.01%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                dev   #10816      +/-   ##
============================================
- Coverage     40.64%   40.62%   -0.02%
+ Complexity     4818     4816       -2
============================================
  Files           913      913
  Lines         36306    36306
  Branches       3994     3994
============================================
- Hits          14756    14750       -6
- Misses        20078    20082       +4
- Partials       1472     1474       +2

Impacted Files
Coverage Δ

...er/master/dispatch/host/assign/RandomSelector.java
77.77% <0.00%> (-5.56%)
:arrow_down:

...erver/master/processor/queue/TaskEventService.java
75.00% <0.00%> (-5.36%)
:arrow_down:

...dolphinscheduler/remote/future/ResponseFuture.java
81.96% <0.00%> (-1.64%)
:arrow_down:

...r/plugin/task/sqoop/parameter/SqoopParameters.java
53.33% <0.00%> (-1.34%)
: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 71f0168...6646baf. Read the comment docs.


clear_paths deletes relative to release_path and not to deploy_path

Q
A

Issue Type
Bug

Deployer Version
4.0

Local Machine OS
OSX

Remote Machine OS
Debian

Description
In Deployer 3.3 the clear_path was relative from deploy_path.
In Deployer 4.0 the clear_path was relative from release_path.
In comment of set('clear_paths', []); there is still  // Relative path from deploy_path
Is it bug or change of clear_paths behaviour?

It's a change of behavior. Neet to update docs.


'Understanding Uninitialized Variables' accepts code that breaks the rules

Understanding Uninitialized Variables
Link here
Accepts invalid code
One of the test cases is: "Do not change code below the line." However, you can still pass the challenge if you change code below that line.
Browser Information

Browser Name, Version: Firefox 46
Operating System: Ubuntu 14.04 LTS
Mobile, Desktop, or Tablet: Desktop

Your Code
// Initialize these three variables
var a;
var b;
var c;

// Do not change code below this line

a = a + 1;
b = b + 5;
c = c + " String!";

a = 6;
b = 15;
c = "I am a String!";

// This passes.

Screenshot

@FreeCodeCamp/issue-moderators What do you think? I don't think these kinds of errors are worth fixing because as an optional challenge the only point is for the students learning benefit. If a student chooses to blatantly disregard the instructions they are only harming their own learning potential.

Bah.  This is for truly new coders.  If you're smart enough to do this, you're smart enough to not need what it teachers.
I say leave it as it is.

Cool. With a 3 person consensus I feel fine closing this, hopefully you can understand our reasoning 👍

I am having similar problem. But i tried changing the 's' in string to uppercase 'S', like so: c = "I am a String !". It worked.

a = 5 + 1;
b = 10 + 5;
c = "I am a" + " String!";  this is how i did !  but could not pass "Do not change code below the line"
so tried your solutions and it worked!


[maistra-2.2] Merge Envoy's 1.20 release branch

Merge branch release/v1.20 from envoyproxy/envoy.
This should resolve CI structurally failing as observed in recent pull requests,
by pulling in a change that updates expired certificates: bfb9b978ab6abc6d3605bd40e1cc9290c142e7b6

Annoyingly,  the CI logs have:
[ RUN      ] TestSPIFFEValidator.TestDoVerifyCertChainIntermediateCerts
test/extensions/transport_sockets/tls/cert_validator/spiffe/spiffe_validator_test.cc:313: Failure
Value of: validator().doVerifyCertChain(store_ctx.get(), nullptr, *cert, nullptr)
  Actual: false
Expected: true
Stack trace:
  0x12c783a: Envoy::Extensions::TransportSockets::Tls::TestSPIFFEValidator_TestDoVerifyCertChainIntermediateCerts_Test::TestBody()
  0x33f1fbb: testing::internal::HandleSehExceptionsInMethodIfSupported<>()
  0x33e219d: testing::internal::HandleExceptionsInMethodIfSupported<>()
  0x33ca633: testing::Test::Run()
  0x33cb1fa: testing::TestInfo::Run()
... Google Test internal frames ...

[  FAILED  ] TestSPIFFEValidator.TestDoVerifyCertChainIntermediateCerts (130 ms)

git blame shows that we touched this test in 0150925a30e5773ac9c865e8fc337c6d6efd002c -- and indeed in that commit we modified certificate generation script to generate more certificates specifically for this test.
I'm going to the certificate regeneration script but commit just the four new files related the certs specific to this test. I suspect some inconsistency crept in as generating these may depend on the other certificates, and therefore the new ones need to be regenerated as well.

Ugh, the failure mode for TestSPIFFEValidator.TestDoVerifyCertChainIntermediateCerts was a bit more subtle then I initially thought. 082adf413edcb8f6908f0440d5b4967918b3a270 properly address it with minimal changes (confirmed locally).
Note: I force pushed to keep the list of commits clean.

LGTM


Add relocation statement to readme

Adjust the readme to reflect that active development of metacontroller has moved.

/cc @grzesuav @AmitKumarDas @fedebongio

/lgtm

We are archiving this repo, and for that purpose I'm merging the last PR with the updated new location for Metacontroller in the future.


GH pages: File Management Resource

At the bottom of the file management resource, there used to be a graphic showing the folder structure. However, in the transition, it seems to have lost the folder icon, so that it just says ":open_file_folder: " and stuff like that.

also, when we refer to this as an exercise in prep for class 1 (module 1), there's no easy way to get back to the prep work besides clicking the "back" button in the browser.
A little tricky, maybe, because it is located in the "helpful resources" section, so maybe we either want to include a link somewhere in the text that goes back to prep for class 1, or we make it a link that pops into a new tab.

couscous does not support emojis (like :open_file_folder:) so they will have to be converted to images.


compile_commands in build subdirectory only read if a symlink is added to project root

I have a compile_commands.json generated in a deep subdirectory of my project folder. When I try to use that with coc-clangd by either:

setting clangd.compilationDatabasePath in coc-settings.json
calling coc#config("compilationDatabasePath", path_to_file)

I get:
I[00:25:17.231] Failed to find compilation database for path_to_file
on startup.
If, however, I add a compile_commands.json symlink in the root of my project directory (to the same file which did not work above), it works perfectly. Finds the file on startup and indexes all the linked files.
I would really like to be able to update the path of compile_commands.json dynamically, because I constantly change which build I need to be looking at. I wrote a quick telescope function that allows me to select the file I want to use and then calls coc#config("compilationDatabasePath", path_to_file) with that file, but it's currently not working because of this.
Please let me know what additional data I can provide here to help debug, not sure what would be relevant.

@fannheyward any chance you could take a look at this?

I just stumbled upon this myself in a new project built with Meson where I did not name my build directory build, and I eventually arrived at clangd/clangd#987, making this a clangd problem rather than an issue with coc-clangd.
Reconfiguring to use a build directory (not builddir, build_dir, obj, etc.; it must be exactly build) solved my issue.
I also tried adding symlinks in subdirectories of my project root (e.g. PROJROOT/include/compile_commands.json and PROJROOT/tests/compile_commands.json) to point to PROJROOT/obj/compile_commands.json, and that worked just as if I had a single symlink PROJROOT/compile_commands.json pointing to PROJROOT/obj/compile_commands.json.  If you are working with files generated in your build directory/directories, I'm fairly certain this won't be an option for you, but I thought I'd mention it anyway, just in case.

Huh interesting, really didn't think this was gonna be a clangd problem... Unfortunately outputting to a build directory isn't an option for me here, but that is good to know. Guess I'll close this out since it isn't a coc-clangd issue. Thanks @memreflect!


Frontend - Command history

Could be useful to have a command history feature, at the very least for the last command. It can get tedious fighting monsters and having to repeatedly type strike. I don't foresee it being used too much however, so it might not be worth the effort.

Implemented. Uses Bash-style syntax:

!n runs the nth command in the history
!-n runs the command n before this one
!! is shorthand for !-1
history shows a list of the command history

Default history size is 100 commands, and is unique to the mode.


Updater says 1.6.3 is available, only 1.6.2 beta for download

Just like the subject says - the updater is directing me to download a 1.6.3 version, but the main channel is still 1.6.1, and the beta channel only has a 1.6.2 version for download.
Where is the 1.6.3 release?

Hi there,
that's odd, you should've landed over here:
https://github.com/thorwe/CrossTalk/releases
May I ask which url clicking "ok" brought you to (the 1.6.2 page)?

The popup window inside of TS itself that tells me an update is available redirects me to:
https://jianji.de/crosstalk/
which then redirects to:
https://jianji.de/index.php/crosstalk/
which has the outdated versions. In fact, the beta is older than the release version on those pages! :(

That beta version is updated now, sorry for the inconvenience.
I had compiled an unreleased beta version inbetween, so it slipped my mind that the live version still links there. Was beginning to wonder why there were no downloads on github ;)
Future updates should link to the latest release of the releases page here on github mentioned above.


What to contribute?

Hi, I wanted to contribute to the project but I don't know where to start, could someone recommend some easier stuff for me to work on and add to the project?

Good question.  I've tried to stay on top of simple requests, so there's not much that's easy in the backlog of open issues.  Maybe some of the stuff in https://github.com/peterbrittain/asciimatics/issues/103
I'm sure there are also inconsistencies in which callbacks each widget provides.  Maybe there's some extra logic to be added there?
Or maybe there's a feature you hoped would be present?  I'd be happy to help you figure out how to add that.
Failing that you could try adding a new Widget or Effect (as per the outstanding enhancements).

Great! When I have some time, I'll try to add something simple like divider character selection. Thanks for the quick responses and the great module!

  I'll try to maintain the list of possible work labels going forwards and so close this issue now


Add CODEOWNERS

Change-type: patch
Signed-off-by: Gergely Imreh<EMAIL_ADDRESS>

@balena-ci retest please


[stdlib] Dispatch to concrete implementations of known types for generic BinaryFloatingPoint and FixedWidthInteger initialisers

Since generic functions in Swift cannot behave differently under specialisation, a number of numeric conversion behaviours were producing poor assembly (calling out to the generic _convert methods) in a generic context. This can be seen in scenarios like the following:
@inlinable
func processGeneric<T: BinaryFloatingPoint>(_ x: T) -> Double {
    return Double(x)
}

public func process(_ x: Double) -> Double {
    return processGeneric(x)
}

which produces this when optimised and fully specialised.
This PR explicitly branches and specialises where necessary within the generic conversion methods for both init() and init?(exactly:) for FixedWidthInteger and BinaryFloatingPoint by GYBing the checks for all known types. This ensures that fully specialised code is able to call the concrete conversions, resulting in much better assembly.
This PR will regress performance slightly for non-stdlib types that pass through these generic initialisers and may negatively impact code-size. These are unfortunate consequences of this approach. An alternative approach might be to mark the concrete initialisers as being somehow substitutable for the generic initialiser such that the optimiser is able to substitute in the more-specific conversion in fully specialised code; however, that comes at the cost of potential behaviour differences between specialised and unspecialised code. Both of these options are discussed in the context of this thread: https://forums.swift.org/t/numeric-type-conversion-marking-functions-as-equivalent-for-generic-specialisation/39810
I'm not sure whether the existing benchmarks cover this, since I couldn't see clear differences locally. If it turns out they don't, I'll write and submit a benchmark in a separate PR.
cc @xwu – you mentioned taking a look at this, but hopefully this covers what you were thinking of.

(including improving the optimizer instead of working around it)

The standard library owners explicitly required @_semantics("optimize.sil.specialize.generic.partial.never") for some of these functions, so (a) I'm not sure that these changes would do anything for those functions that are so annotated, and (b) I think the point of the annotation was explicitly so that it wouldn't.

(including improving the optimizer instead of working around it)

Note that this is not fixable with just an optimizer change (barring heroics specific to this one case, which may also be worthwhile). It probably requires either a language change (allowing a function to be marked as a specialization of another), or something like the polymorphic builtins support that has been suggested elsewhere.

(barring heroics specific to this one case, which may also be worthwhile)

@stephentyrone A semantics annotation that this is a numeric conversion routine would be something to explore, I think? Regarding CGFloat, I have some notions in my head about a possible approach.

For the purposes of CGFloat conversions and any "self-conversion," does the following hold?--
Two BinaryFloatingPoint types A and B have the same format if and only if A.exponentBitCount == B.exponentBitCount && A.significandBitCount == B.significandBitCount.

For the purposes of CGFloat conversions and any "self-conversion," does the following hold?--
Two BinaryFloatingPoint types A and B have the same format if and only if A.exponentBitCount == B.exponentBitCount && A.significandBitCount == B.significandBitCount.

It's a white lie, but would be fine in practice.

It's a white lie, but would be fine in practice.

Hmm, tell me more: where does it break down in theory? Could we eliminate any discrepancy between theory and practice by fixing the behavior of any corner cases as a semantic requirement of BinaryFloatingPoint?
Alternatively, is there a "magic" value (say, .pi) that could be compared such that if the raw exponent and significand are the same for two conforming binary floating-point types A and B, then A and B share the same format?

or something like the polymorphic builtins support that has been suggested elsewhere

It may be worth recapping that initiative and where we stand with it on the forums as it’s mostly been point to point discussion.


bug with Warframe

Microsoft PowerToys version
0.70.0
Installation method
PowerToys auto-update
Running as admin
Yes
Area(s) with issue?
General
Steps to reproduce
Play Warframe and try to Tenno dash (ctrl-space).
✔ Expected Behavior
In Warframe (a game by Digital Extremes) while in Tenno form, you Tenno dash by hitting right ctrl-space. This has worked fine for all versions of Warframe and PowerToys. When I upgraded to 0.70.0, the key combo no longer works in game. The individual keys still work fine, but the combo does not work.
What should happen is that I Tenno dash (quick dash across the screen).
❌ Actual Behavior
What actually happens is that it acts as just if just the left ctrl key is hit. While in game and experiencing the problem, I can alt-tab, exit PowerToys, and return to the game and everything works fine again.
I thought this may be due to the new PowerToys Keyboard Manager, but turning it off did not seem to matter - the problem still exists. I have to exit PowerToys altogether to avoid the issue.
Other Software
Warframe.x64.exe version 33.0.11 running on a fully patched Windows 10 system (patched current as of 05/24/2023).

It has to do with the new Peek Integration. It uses ctrl + space.

You have to disable the Peek integration or change its shortcut.

Yes, Ctrl+Shift is also the hotkey to trigger the new function "Peek". This is an extension for File Explorer (like QuickLook). There is a PR to fix this behavior. Until it's released, you can turn Peek off, or change the hotkey.
/dup #26150


Snake speed seems to depend on frame rate

Hello!
The speed of the snake seems to depend on the framerate, which can make the game unplayably fast.
I believe this is because you do not take the delta time between frames into account when computing the speed of the snake. This should be easily fixed by multiplying the speed with the delta time between frames.

Hello, and thanks for that report.
I seen many complaint in this regard. Thanks for that solution.
In all honesty, I think the main issue was that my first queue component is always colliding with the snake head when it is too slow. Since every queue member takes the position of the former one, and the first one the last position of the snake, if the snake didn't move of SNAKE_SIZE (SNAKE_SIZE/2 + QUEUE_SIZE(=SNAKE_SIZE)/2), they will collide.

I think the best (or if you ever have a better one in mind), is to not add "Collider" to the first queue member.

Fixed in https://github.com/nag763/texas-snake/commit/27386534ebffd5e66583c3b223174e13338d715a

Thank you, although I strongly recommend still using the delta time between frames. Otherwise, your game will still be unplayable on sufficiently performant hardware (or particularly slow on less performant hardware).

Hmm makes sense, thanks very much for that tip, much appreciated


⚠ Bofrost.lu has degraded performance

In 405da40, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 2003 ms

Resolved: Bofrost.lu performance has improved in c20d61e after 37 minutes.


Using prebuildify?

Hi,
I've made a fork where I switched to using prebuildify to include the node binaries for each platform. It's been useful for us since we don't have to an run install on a specific platform.
Would this library benefit from this change? I can create a PR if so.
Thanks!

https://github.com/search?q=repo%3AWiseLibs%2Fbetter-sqlite3+prebuildify&type=issues
https://github.com/WiseLibs/better-sqlite3/issues/655


Should we make social links open a new tab?

I vote yes!

Good enough for me! On it!

@AndyLampert  and I did this PR https://github.com/girldevelopit/gdi-new-site/pull/151


Separate Python annotator from Python extension

The Python annotator is a DLL that is both a UIMACPP annotator and a Python module.
That is very clever but causes problems when trying to load multiple version of the UIMACPP annotator or loading them using different multi-threaded configurations.
Instead, the code should build two different DLLs, one for the annotator and another for the Python module.

Hello @DrDub I would also like to help solve this issue, any guidance would be highly appreciated

Hello @tmjoris, mind taking a look at #15 and see if you have luck building the SDK following the instructions? Please comment about that on the PR.
Regarding this issue, it boils down to splitting the file pythonnator.cpp into two file and having the  Makefile builds them.


MapperError consistently raised trying to run qft with 8qubits on melbourne

Information

Qiskit Terra version: Master
Python version: 3.7
Operating system: Linux

What is the current behavior?
Running this script:
import math

from qiskit import QuantumCircuit
from qiskit import QuantumRegister
from qiskit import transpiler

def build_model_circuit(qreg, circuit=None):
    """Create quantum fourier transform circuit on quantum register qreg."""
    if circuit is None:
        circuit = QuantumCircuit(qreg, name="qft")

    n = len(qreg)

    for i in range(n):
        for j in range(i):
            circuit.cu1(math.pi/float(2**(i-j)), qreg[i], qreg[j])
        circuit.h(qreg[i])

    return circuit

n_qubits = 8
qr = QuantumRegister(n_qubits)
circuit = build_model_circuit(qr)

# Manually pulled configuration for melbourne
coupling_map = [[1, 0], [1, 2], [2, 3], [4, 3], [4, 10], [5, 4],
                [5, 6], [5, 9], [6, 8], [7, 8], [9, 8], [9, 10],
                [11, 3], [11, 10], [11, 12], [12, 2], [13, 1],
                [13, 12]]
transpiler.transpile(circuit,
                     basis_gates=['u1', 'u2', 'u3', 'cx', 'id'],
                     coupling_map=coupling_map)

will always raise the following error:
qiskit.mapper.exceptions.MapperError: 'swap_mapper failed: layer 25, sublayer 3'
It's worth pointing out that for any other value of n_qubits (<=14 which is the number of qubits for the backend) it seems to work fine. It on raises an error with 8 qubits.
Steps to reproduce the problem
Run the above script.
What is the expected behavior?
It transpiles the circuit successfully
Suggested solutions
Fix it

You may need to add some ancilla qubits to the circuit to have the mapper succeed.

I just tested it and yeah adding an ancilla qubit to the circuit does make the mapper work. But I still think there is potentially an issue here because the mapper works fine without an ancilla for the same circuit generation function with 1-7 and 9-14 qubits with that coupling map. It only fails when I use an 8 qubit register.

The above example actually works for me using master version.

Hmm, interesting. It fails very consistently on both my laptop and my desktop with the MapperError. Although they both run very similar software versions of everything. Linux x86_64 with Python 3.7.2

I have compiled this circuit 10,000 times with randomly picked seeds and it always works for me.

Grabbing the latest master, the example does not even run anymore:
TranspilerError: 'initial layout not supplied, and cannot be inferred from backend.'

That error is being fixed by https://github.com/Qiskit/qiskit-terra/pull/1883

Actually that error only pops up on Win 10.  On OSX, the latest master now gives the same result you mentioned earlier:
MapperError: 'swap_mapper failed: layer 25, sublayer 3'
I do not know why the same master has two different errors for the same code on different platforms, nor do I understand why it worked previously.

The bug in the mapper was introduced with the merging of #1767.  So @1ucian0 should investigate it.

I think the problem is the lack of ancillas (the MapperError does not make any sense to me, tho). We have a pass to enlarge the layout with ancillas that should be called before swap_mapper in qiskit/transpiler/transpiler.py:222. So the fix can be added after PR https://github.com/Qiskit/qiskit-terra/pull/1862 is merged.

Fixed by https://github.com/Qiskit/qiskit-terra/pull/2023

Is there a test that makes sure the pre bug circuit is the same as the new circuit returned?


SD card access

1. SDK version（SDK 版本）
{
N/A
}
Is there any way to access the SD card without resorting to custom firmware, e.g. via AT commands? There is a unsoldered header on the A9G "pudding" dev board which seems to relate to the SPI interface to the SD card, has anyone ever been able to use that?

@willemneethling did you find anything for this ?
I have connected esp32 to a9g but esp32 is unable to read/write/connect to sd card on a9g.
Is there a way to do it

@Mukund2900 No luck. I did not find any documented way of using the SD slot without resorting to the custom chinese SDK. I also soldered a header onto the exposed SD pins and tried to drive this from the ESP32 without success.


decode() timeout time always reached, even when matrix is found much earlier

Conf:
Raspberry Pi 4 - Raspbian GNU/Linux 10 (buster) 32 bit os, ARM
pylibdmtx (0.1.9)
libdmtx0b (0.7.5-3)
from PIL import Image
from pylibdmtx.pylibdmtx import decode, Decoded, DmtxSymbolSize
import time

img_path = "auxiliaries/peripherals/camera/test.jpg"
img = Image.open(img_path)
for t in [50, 500, 5000, 3000, None]:
    started = time.time()
    res = decode(img, shape=DmtxSymbolSize.DmtxSymbol8x18, timeout=t)
    print(f"timeout: {t/1000 if t else None}, elapsed: {round(time.time() - started, 3)}, result: {res}")

Output on Raspberry:
timeout: 0.05, elapsed: 0.053, result: []
timeout: 0.5, elapsed: 0.502, result: [Decoded(data=b'033757', rect=Rect(left=156, top=65, width=-55, height=131))]
timeout: 5.0, elapsed: 5.003, result: [Decoded(data=b'033757', rect=Rect(left=156, top=65, width=-55, height=131))]
timeout: 3.0, elapsed: 3.001, result: [Decoded(data=b'033757', rect=Rect(left=156, top=65, width=-55, height=131))]
timeout: None, elapsed: 15.503, result: [Decoded(data=b'033757', rect=Rect(left=156, top=65, width=-55, height=131))]
Also tried it on Mac
Output on OSX:
timeout: 0.05, elapsed: 0.051, result: []
timeout: 0.5, elapsed: 0.501, result: [Decoded(data=b'033757', rect=Rect(left=156, top=65, width=-55, height=131))]
timeout: 5.0, elapsed: 5.001, result: [Decoded(data=b'033757', rect=Rect(left=156, top=65, width=-55, height=131))]
timeout: 3.0, elapsed: 3.001, result: [Decoded(data=b'033757', rect=Rect(left=156, top=65, width=-55, height=131))]
timeout: None, elapsed: 4.807, result: [Decoded(data=b'033757', rect=Rect(left=156, top=65, width=-55, height=131))]
I conclude that for such a small pic it takes less than 0.5 sec to process, but timeout is always waited (one core of cpu is maxed out until the end of the timeout).
I cannot achieve high throughput and guaranteed operation. Any ideas of what might be wrong?

)

You'll want to stop scanning after with first result with max_count=1


Indentation and whitespaces

As mentioned in issue #27 poor indentation makes the code harder to read as well as it makes it harder to maintain while being developed.
If everyone agrees to the standard in the industry it makes it easier for everyone

Very nice! Thanks for this!


[rancher-compose] Issues with VPN

Rancher versions:
rancher/server: 1.6.2
rancher/agent: 1.2.2
rancher-compose: 0.12.5
Any idea why I cant use rancher-compose when the route to the rancher server is over a VPN?
Perhaps rancher-compose is bypassing the route table and hooking straight onto the the eth device?
The stack shell gets created but beyond that nothing - no containers...

I can only reason this is a bizarre issue with my vpn that I cannot reason.


Can i more customizing this, how to make the button can't centered?

sure! I always welcome all PR!,
or you can write your code on here more detail.
as soon as i possible, i fix them.

I updated enable Setting button Position.
thnaks.


Excess solver queries during concrete execution

During concrete execution, using --smt none, we see a large number of queries to the solver of the form of remainders:
kore-exec: [2020-01-30 15:38:03.814882846] Warning (LogMessage): Failed to decide predicate:
    \not{_PREDICATE{}}(
        \equals{SortEthereumCell{}, _PREDICATE{}}(
            Var'Unds'32:SortEthereumCell{},
            Lbl'-LT-'ethereum'-GT-'{}(
                Lbl'-LT-'evm'-GT-'{}(
                    Var'Unds'13:SortOutputCell{},
                    Var'Unds'14:SortStatusCodeCell{},
                    Var'Unds'15:SortCallStackCell{},
                    Var'Unds'16:SortInterimStatesCell{},
                    Var'Unds'17:SortTouchedAccountsCell{},
                    Lbl'-LT-'callState'-GT-'{}(
                        Var'Unds'0:SortProgramCell{},
                        Var'Unds'1:SortJumpDestsCell{},
                        Var'Unds'2:SortIdCell{},
                        Var'Unds'3:SortCallerCell{},
                        Var'Unds'4:SortCallDataCell{},
                        Var'Unds'5:SortCallValueCell{},
                        Lbl'-LT-'wordStack'-GT-'{}(VarWS:SortWordStack{}),
                        Var'Unds'6:SortLocalMemCell{},
                        Var'Unds'7:SortPcCell{},
                        Var'Unds'8:SortGasCell{},
                        Var'Unds'9:SortMemoryUsedCell{},
                        Var'Unds'10:SortCallGasCell{},
                        Var'Unds'11:SortStaticCell{},
                        Var'Unds'12:SortCallDepthCell{}
                    ),
                    Var'Unds'18:SortSubstateCell{},
                    Var'Unds'19:SortGasPriceCell{},
                    Var'Unds'20:SortOriginCell{},
                    Var'Unds'21:SortBlockhashesCell{},
                    Var'Unds'22:SortBlockCell{}
                ),
                VarDotVar3:SortNetworkCell{}
            )
        )
    ) []

Given that both sides of this equality are symbolic, I suspect this happens at startup, when we simplify rules. We shouldn't have remainders during concrete execution, so otherwise I can't imagine what is happening.
Related: #1407

Needs to be reproduced.


Not working with VS2019

VSIX installation stops on error:

Hello,
Thanks for the notification. I plan on installing VS2019 RTM on a fresh Windows install this weekend, I'll take a look at making it compatible then.
Thanks again for the issue report!
Regards;
Richard Moss

Below is the excerpt from the log file. I tried installing the 4.6.* targeting packs and SDKs, didn't help:
01/07/2019 17:52:43 - Extension cannot be installed to the following products due to missing prerequisites:
01/07/2019 17:52:43 - 	Microsoft Visual Studio Professional 2019
01/07/2019 17:52:43 - 		-------------------------------------------------------
01/07/2019 17:52:43 - 		Identifier   : Microsoft.Net.ComponentGroup.TargetingPacks.Common
01/07/2019 17:52:43 - 		Name         : .NET Framework 4 ... 4.6 development tools
01/07/2019 17:52:43 - 		Version      : [15.0.26606.0,16.0)
01/07/2019 17:52:43 - 		Error        : The prerequisite version specified does not match the version installed
01/07/2019 17:52:43 -

Just installed version onto VS 2019 Community 16.3 and it seemed to work. Phewf. Moving hundreds of projects into a mono repo and this is a life saver! Thanks ❤

Hello,
Firstly, I apologise for just how long it has taken me to get around to this. I upgraded the project this morning to work with Visual Studio 2019 and the new async extension model. I haven't extensively tested it but it seems to be working - there's a caveat that file filters are being duplicated but this doesn't seem to be a new bug judging from the state of my own configuration file, I'll look into that in due course.
As usual I haven't tried to make one extension work with multiple versions of Visual Studio so this is a brand new extension. It's also not published on the Marketplace yet, I haven't tested it enough, I've forgotten how to code sign packages, and so I need time for that. You can download the VS2019 release from the Releases page in this repository though - I hope it is still useful.
I'm going to leave this issue open until I've published it to the marketplace, but please free free to open new issues if you identify any problems with this new build.


Template path being appended to file location

It seems that for a template entry, the template path is being appended to the file location. For example, if the template path is utils/templates/Cactus.md (btw the plugin isn't auto suggesting my templates/ folder for some reason, only my templater/ folder), and the file folder location is 🍃 leafs (the folder name has an emoji in it), and the file name is {{DATE:YYYYMMDDHHMMSS}} {{VALUE}} I get this error when trying to trigger it :
Error: ENOENT: no such file or directory, open 'C:\PathToVault\🍃 leafs\202106260936 utils\templates\Cactus.md'
However if for the folder I put /🍃 leafs (so as an absolute path with a slash), it seems to solve the issue.
Any clue where the problem might be coming from?

This should be fixed in 0.2.12. Can you check?
Thank you for your report!

It works, well done!


Allow ClientQuery connections

ServerQuery and ClientQuery are pretty similar. The only differences are the commands and  the header send on a new connection. ServerQuery sends "TS3" and ClientQuery "TS3 Client". Custom commands work create, but the connection header was hardcoded.
I moved connectHeader into the Client struct and added an option to set it in NewClient(...).

Thanks for the PR!


[Fix #10625] Restore the specification to TargetRubyVersion: 2.5

Fixes #10625 and reverts part of #10577.
Only the Ruby version (2.5) to runtime should have been dropped, not code analysis.
This PR the specification to TargetRubyVersion: 2.5 So, this keeps it compatible with TargetRubyVersion up to 1.28.2.

Before submitting the PR make sure the following are checked:

[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Wrote good commit messages.
[x] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
[x] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

Thanks!


sequence deserialize error

Some error with sequence deserialization.
message allocated before call rclc_spin_node, used custom rclc_spin_allocatedmsg_node_once(void* already_allocated_msg, rclc_node_t * node, int64_t timeout_ms)
Tested on

joint_trajectory_point.
custom_msg( float64[] )

Subsricber callback give correct message size, but data is incorrect.
any_complex_message__cdr_deserialize(...){
  {
    uint32_t size;
    const size_t capacity = ros_message->array.capacity;
    rv = ucdr_deserialize_sequence_double(cdr, ros_message->array.data, capacity, &size);

    //size of sequence data detected as correct

    ros_message->array.size = size;
  }
}

Probably error in ucdr_buffer_alignment or  ucdr_check_final_buffer_behavior
#26 looks similar, but I'm think there is problem with message allocation.

@Aiven92 Hi! Thank you for your interest in micro-ROS. Notice that we’ll discuss the recent contributions and developments in the next Embedded WG meeting. You’re invited to bring your micro-ROS related issue to this platform. We’ll be very happy to have you join us and discuss your questions with the community.

Solved here: https://github.com/micro-ROS/rosidl_typesupport_microxrcedds/pull/25


disable attestation processing in initial sync

pending answer to “In initial sync, should we disable attestation processing?"

We already have this implemented


document is not available on node.js

https://github.com/crysalead-js/dom-element-css/blob/master/index.js#L2
dom-layer depends on dom-element-css but this line assumes document is also available in node.js global (for server-side rendering)?

Ah fair enough !
I'll change it to:
hasRemovePropertyInStyle = typeof document !== "undefined" && "removeProperty" in document.createElement("a").style

Fixed in https://github.com/crysalead-js/dom-element-css/commit/3799e433b0c673e2d5b89543d07756d30f703a07


Invalid parsing of ISO8601 strings, but only in some range of years

Describe the bug
For some specific year ranges ISO8601 time is offsetted by -6 minutes.
I discovered this behavior when our system was parsing ISO8601-formatted timestamps and presented them on a calendar. Before that, timestamps are 'normalized' to viewer's local timezone offset. We ensure that input data is already in viewer's timezone offset, so the 'normalization' step is actually superfluous, but it is there, and since input/output offsets are the same, it should not damage the data.
However after parsing it via Moment object, resulting value indicated 1 day before than it should.
const m = moment(input, moment.ISO_8601);
console.log(m.format())
-> "1915-08-04T23:24:00+01:30" // why offset changed? why extra -6 minutes?

This 'm' value was then passed around, and later displayed. Since it contained a different offset than local, another component re-normalized it back to local +02:00 and that resulted in 1915-08-04T23:54:00+02:00. This caused a calendar component to display "1915-08-04" instead "1915-08-05" as the date.
The problem does not lie in the fact that timezone offset was changed back and forth, but in the extra change of -6 minutes.
To Reproduce
moment("1916-08-05T00:00:00+01:30", moment.ISO_8601).format()
->     "1916-08-05T00:30:00+02:00"
// CORRECT: offset is shifted by 30mins, so is the time -- it's the same absolute point in time

moment("1915-08-05T00:00:00+02:00", moment.ISO_8601).format()
->     "1915-08-04T23:24:00+01:30"
// WRONG: -36 mins difference, -30 from timezone offset (ok), extra -6 out of nowhere (?!)

moment("1915-08-05T00:00:00+01:30", moment.ISO_8601).format()
->     "1915-08-04T23:54:00+01:30"
// WRONG: no offset change, but got -6 minutes (?!)

// strangely, when zero or negative offsets are parsed properly:
moment("1915-08-05T00:00:00+00:00", moment.ISO_8601).format()
->     "1915-08-05T01:00:00+01:00"
moment("1915-08-05T00:00:00-01:00", moment.ISO_8601).format()
->     "1915-08-05T02:00:00+01:00"
moment("1915-08-05T00:00:00-10:00", moment.ISO_8601).format()
->     "1915-08-05T11:00:00+01:00"
// CORRECT: all 3 above are correct

// but the same 3 cases as above, when changed to 1914 are parsed incorrectly:
moment("1914-08-05T00:00:00+00:00", moment.ISO_8601).format()
->     "1914-08-05T01:24:00+01:30"
moment("1914-08-05T00:00:00-01:00", moment.ISO_8601).format()
->     "1914-08-05T02:24:00+01:30"
moment("1914-08-05T00:00:00-10:00", moment.ISO_8601).format()
->     "1914-08-05T11:24:00+01:30"
// WRONG: all absolute times moved by -6 minutes

// same goes for any earlier year:
moment("1492-08-05T00:00:00+00:00", moment.ISO_8601).format()
->     "1492-08-05T01:24:00+01:30"
// WRONG: time moved by -6 minutes

Expected behavior
When I try to parse a full ISO8601 format with timezone offset information into a Moment object, and when I format it back to ISO8601, I expect to get the same effective point in time.
I expect the Moment object to be set to the date, time, and also to the timezone offset exactly as I specified in the ISO8601 string. However, it would be still OK for the timezone offset to be changed during that roundtrip, if only the absolute time point remained the same.
Desktop (please complete the following information):

OS: Windows 10
Browser: Chrome
Version: most-recent 2.24.0, older versions also exhibit that behavior

Moment-specific environment

The time zone setting of the machine the code is running on
(UTC+01:00) Sarajewo, Skopie, Warszawa, Zagrzeb
and I suppose DST is active, so it's +02:00 now.

The time and date at which the code was run
2019-09-26 17:44

Other libraries in use (TypeScript, Immutable.js, etc)
none in repro cases above, TypeScript in original production system

Please run the following code in your environment and include the output:
console.log((new Date()).toString())
console.log((new Date()).toLocaleString())
console.log((new Date()).getTimezoneOffset())
console.log(navigator.userAgent)
console.log(moment.version)

"Thu Sep 26 2019 17:45:15 GMT+0200 (czas środkowoeuropejski letni)"
"26.09.2019, 17:45:15"
-120
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Safari/537.36"
"2.24.0"

Is it the parsing that's wrong, or the formatting?
Taking one of your 'WRONG' cases, can you check:
moment("1915-08-05T00:00:00+02:00", moment.ISO_8601).format();
moment("1915-08-05T00:00:00+02:00", moment.ISO_8601).toISOString();
moment("1915-08-05T00:00:00+02:00", moment.ISO_8601).utc().format();

moment("1915-08-05T00:00:00+02:00", moment.ISO_8601).format(); //     "1915-08-04T23:24:00+01:30"
// wrong, offsetted by -6mins

moment("1915-08-05T00:00:00+02:00", moment.ISO_8601).toISOString(); // "1915-08-04T22:00:00.000Z"
// ok, same timepoint

moment("1915-08-05T00:00:00+02:00", moment.ISO_8601).utc().format(); //"1915-08-04T22:00:00Z"
// ok, same timepoint

I suppose it's the parsing, because back then, I checked it by reading out properties .date(), .minutes() etc like this:
const  m = moment("1915-08-05T00:00:00+02:00", moment.ISO_8601);
m.hour()      // -> 23
m.minute()    // -> 24

I just noticed that there's a difference between format and toISOString:
moment("1915-08-05T00:00:00+02:00", moment.ISO_8601).format();           // "1915-08-04T23:24:00+01:30"
moment("1915-08-05T00:00:00+02:00", moment.ISO_8601).toISOString();      // "1915-08-04T22:00:00.000Z"
moment("1915-08-05T00:00:00+02:00", moment.ISO_8601).toISOString(false); // "1915-08-04T22:00:00.000Z"
moment("1915-08-05T00:00:00+02:00", moment.ISO_8601).toISOString(true);  // "1915-08-04T23:30:00.000+01:30"

So it seems that toISOString returns expected results, and the problem is with the format(), and properties (m.hour(), m.minute()).

That made me think about one more thing:
const m = moment("1915-08-05T00:00:00+02:00", moment.ISO_8601)
console.log(m.format()); // "1915-08-04T23:24:00+01:30"
console.log(m._d); // "Wed Aug 04 1915 23:24:00 GMT+0124 (czas środkowoeuropejski letni)"

so it turns out that the internal _d date object is initialized to that strange "23:24" time, but in fact that date object has a CORRECT timezone! It's set to +01:24, and that makes the "23:24" time actually present the same absolute time as "00:00:00+02:00" that was parsed.
It's the .format() method that produced its output incorrectly: it apparently took hour and minutes from the _d, but it took timezone offset "+01:30" from somewhere else. Had it taken timezone offset from the _d object as well, it would emit "1915-08-04T23:24:00+01:24" and that would be "more correct"! Strange timezone offset, but at least that would be the same point in time.

Assuming your local timezone is Poland: see polish timezone changes and look at the 1900-1924 period.
Your scenario might be fixed by removing some code that rounds timezone offsets to 15 minutes (originally introduced to fix a firefox issue.)  I'll create a PR for that.

see polish timezone changes and look at the 1900-1924 period.

Thanks! That might be a bit silly of me, but after thinking more and more about that +01:24 it occurred to me that these year range (before 1915) is far enough that either timezone wasn't declared yet, or we may have no information on that, or don't even care -- but what should a library do about this? IMHO, use some astronomical timeoffset more-or-less matching the geographical region.. I checked "local mean sidereal time" and it's result varies somewhere between +0120..+0210 depending on which geographical place I pick within our TZ. So, +0124 might even be OK, it lies somewhere on the eastern edges of this TZ. Fun fact, another TZ mystery solved, probably.


Unable to build 1.0.2k on Solaris 10 using no-bf, no-camellia or no-mdc2 options

I'm unable to build 1.0.2k on Solaris 10 (both Sparc and x86) when using either the no-bf, no-camellia or no-mdc2 options. We were previously able to build 1.0.2j without any problems.
We build OpenSSL using these commands:
./config no-asm no-bf no-camellia no-capieng no-gmp no-jpake no-md2 no-mdc2 no-rc5 no-zlib no-shared fips  --prefix="${TARGET}/local/ssl" ${OPTS}
make depend
make
This now causes a series of errors like this (the errors changes slightly based which of the options I include)
make[2]: Entering directory /home/jon_h/3rdparty/openssl/src/crypto/evp' make[2]: *** No rule to make target ../../include/openssl/blowfish.h', needed by e_bf.o'.  Stop. make[2]: Leaving directory /home/jon_h/3rdparty/openssl/src/crypto/evp'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/jon_h/3rdparty/openssl/src/crypto'
make: *** [build_crypto] Error 1
I believe this was caused by the recent change to util/domd file as /bin/sh on Solaris 10 does not understand "if !" syntax.

This is a known issue. Fixed in 0d37bd8058.


rinkeby faucet is not working. Do you have an alternative? Thanks.

https://faucets.chain.link/rinkeby


feat(opentelemetry-js): infer zipkin service name from resource

Which problem is this PR solving?
Fixes #919
Short description of the changes
Zipkin service name is set to resource 'service.name' if it's not specified in the config.

I signed it

@googlebot I signed it!