Remove the FromHexStr trait

The FromHexStr trait is used to parse integer-like types, however we can achieve the same using inherent methods.
Move the hex parsing functionality to inherent methods, keeping the same behaviour in regard to the 0x prefix.
Patch 1 is trivial preparatory cleanup.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

-1 of 46 (97.83%)  changed or added relevant lines in 6 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.06%) to 84.052%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

bitcoin/src/parse.rs
7
8
87.5%

Totals

Change from base Build<PHONE_NUMBER>:
0.06%

Covered Lines:
19432

Relevant Lines:
23119

💛  - Coveralls

I think we ought to accept the 0x prefix. If anything I am tempted to require it.
from_str_radix is a bad comparison because it can't use a prefix due to it being overly general (though they did decide to make up an arbitrary character set for radices >16, so there are limits to its generality). They should have instead had methods specifically for parsing binary, octal and hex, using the standard prefixes for those bases. Maybe with a boolean/tristate indicating whether it is allowed or required.

If anything I am tempted to require it.

I'm actually thinking that we should require it too, it would be confusing as hell if there was a string that is both valid hex and valid decimal and the values represented lie on different sides of a threshold (like the LOCK_TIME_THRESHOLD). (I didn't check that such a value exists.)
Anywho, I'm punting the prefix stuff done the path because its non-trivial. As it is this PR is a step forward and maintains the current behaviour. New issue: https://github.com/rust-bitcoin/rust-bitcoin/issues/2498

it would be confusing as hell if there was a string that is both valid hex and valid decimal and the values represented lie on different sides of a threshol

That's actually a great point. Though I think there might be protocols that encode it as hex without 0x already, so we might want to support them?
Maybe have from_hex_str and from_unprefixed_hex_str methods? Though people working with such protocols can just reimplement it themselves. Anyway, I'd certainly not bother with "maybe prefixed".

Though I think there might be protocols that encode it as hex without 0x already, so we might want to support them?

PSBT and the p2p encoding both do this -- but only as part of a larger thing (PSBT also wants a length prefix and the wire encoding wants an entire transaction surrounding it). So they can't directly use from_str/from_hex anyway.
And if somebody does want to parse without the 0x they can always parse a number using from_str_radix, or parse a [u8; 4], and convert.

Maybe have from_hex_str and from_unprefixed_hex_str methods? Though people working with such protocols can just reimplement it themselves. Anyway, I'd certainly not bother with "maybe prefixed".

This sounds good to me, though I'd like to drop the _str prefix on both names. I would ACK either way on including from_unprefixed_hex or making the user implement it theirselves.

PSBT and the p2p

Those are byte-like, so should be out of scope of this discussion.

This PR is a merge candidate as is, please review. The hex prefix stuff is explicitly put off to #2498 - this PR just removes the trait and maintains the current behaviour.

I've added code for all the wrapper types that can be constructed infallibly from an int (ie all of them except the absolute Height and Time types).
The error code for the absolute types is complicated, I'm struggling to detangle it.

Though maybe we should release the trait with #[deprecated("Removed, WARNING: THE INHERENT METHOD HAS DIFFERENT BEHAVIOR!")]

If the errors are good then users should just get an error if they are using from_hex without a prefix and soon see the new API. I'm not bothered eitherway, can add this if @apoelstra also likes the idea.

If the errors are good then users should just get an error if they are using from_hex without a prefix and soon see the new API.

That implies thorough enough testing and although I guess serious applications will trigger it it's still nicer to see the warning upfront.

Since the consensus is to break the behavior of from_hex to make 0x mandatory I'd rather break it in one go (release) so people see the trait as removed.

I agree with this but we can do it in a followup PR since this one has kinda a big diff.
But I would like to do the breakage in the next release alongside the trait removal.
I'm also skeptical that users will notice the error or the change. Lucky users will have their applications immediately break. Unlucky ones will find that they're only parsing hex strings in some obscure corner of their application that they only trigger every several months.
I recently switched a personal project from time to chrono which has slightly different strftime formatting strings, and there was a long tail of places that needed to be changed (particularly in once-a-year tax code which I was not happy about needing to bug-fight while exercising).

Ah, in the last commit this PR does do the "required 0x for sequence/locktime" and "forbidden 0x for target" though it doesn't reuse code and it looks like some more iteration will be needed (and you mention Height and Time are not done ... those ones are also weird since we may want to allow parsing in decimal).
Anyway this PR looks like an improvement as-is.

Yeah, I tried to push forward a bit (by adding the last commit) without getting lost in the weeds (absolute height/time).

Set priority high because this is required for moving the remaining types to units.

Gentle bump please, I'd love to get this in so I can continue with the move of types to units.

Ah @sanket1729, legend! Thanks for reviewing.


TC-RR-1.1 Certification issues (CON-1078)

Describe the bug
We have encountered several different issues in certification related to this test case.
Just gathering them here for anyone interested (which I have seen several different user has reported related issue separately)
1. Sometimes the chip event queue is full and failed to post event

Please find this link for more detail logs (https://github.com/project-chip/connectedhomeip/issues/32481)
Found solution from jonsmirl fixing it by increasing the size of event queue to 50 (https://github.com/espressif/esp-matter/issues/313)
Not sure why the default size is 25, and we didn't have this problem in another project with earlier stack version (548ef58).
Anything related to this to share? Otherwise we will just increase it to 50 since we got a lot of static DRAM unused at the moment.

2. Node label 32 bytes constraint error

There is a new issue these recent days and espressif guys have confirmed there is a fix. (d481fa9)
Referenced issue: https://github.com/espressif/esp-matter/issues/862
We will implement the fix to see if the same error occurs.

3. Group Key management command error

Found a suggested fix (https://github.com/espressif/esp-matter/issues/765) to increase the "nvs" partition to 48K size
The problem is, we already increased it to 48K since the beginning of our project and we are still seeing this issue
Please find this issue for more detail logs (https://github.com/project-chip/connectedhomeip/issues/32481)
Is there any further suggested fix for this?  or more information?

Environment

ESP-Matter Commit Id: 2f692ac1
ESP-IDF Commit Id: v5.1.2
SoC (eg: ESP32 or ESP32-C3): ESP32S3
Host Machine OS: Linux
...

Sometimes the chip event queue is full and failed to post event

Matter will post all the UDP messages with specific destination port numbers(5540- Default port for Matter protocol, 5353- Port for mDNS) to Matter task. Each packet will consume an entry in chip event queue. So if your devices are in an environment with lots of mDNS broadcast packets(even the packets are not related to Matter), the event queue will be used up very quickly. This PR might help.

Group Key management command error

Looks like the error code is https://github.com/project-chip/connectedhomeip/blob/master/src/app/clusters/group-key-mgmt-server/group-key-mgmt-server.cpp#L528 . Could you add some log to print the error(or change the LogDetail to LogError in the following codes) so that we can know what happened there?

@eme-bennytang Can you please provide the requested details? Or close the issue if resolved

@dhrishi  Sorry for late response.
I do figure out the problem a while ago, we have split the nvs partition with another partition for factory data, and this partition is much smaller than the nvs partition (48k).
Once I move the KVS and COUNTERS name space back to nvs as below and it solved the issue.

Thanks for the reply anyway
I will close the issue


Migrate protobuf-csharp-port to google/protobuf

Code is now in https://github.com/google/protobuf/tree/csharp


[@prisma/instrumentation] Version 15.14.0 onwards using non existing generic in InstrumentationNodeModuleDefinition form @opentelemetry/instrumentation Library

Bug description
When adding @prisma/instrumentation to a repository and using esbuild I was getting failed to bundle errors. The error message was the following:
node_modules/@prisma/instrumentation/dist/PrismaInstrumentation.d.ts:8:13 - error TS2315: Type 'InstrumentationNodeModuleDefinition' is not generic.

8     init(): InstrumentationNodeModuleDefinition<unknown>[];
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Found 1 error in node_modules/@prisma/instrumentation/dist/PrismaInstrumentation.d.ts:8

The @opentelemtry/<PACKAGE> packages in the package.json dependencies are the following:
  "dependencies": {
    "@opentelemetry/api": "^1.8",
    "@opentelemetry/instrumentation": "^0.49 || ^0.50 || ^0.51 || ^0.52.0",
    "@opentelemetry/sdk-trace-base": "^1.22"
  },

Looking at the definitions directly in the @opentelemetry/instrumentation package, there is no support for a generic in InstrumentationNodeModuleDefinition on supported versions:
export declare class InstrumentationNodeModuleDefinition implements InstrumentationModuleDefinition {
   ...
}

and
export interface InstrumentationModuleDefinition {
  ...
}

I checked all of the versions outlined in dependencies and none of them could support the generic.
Link to file in repo
I am currently explicitly running the following versions in my package.json:
"@opentelemetry/api": "^1.8.0",
"@opentelemetry/sdk-trace-base": "^1.24.1",

and<EMAIL_ADDRESS>is being used as the implicit dependency in my dependency tree.
All of the dependencies seem to be in line minus sdk-trace-base, however the issue is with @opentelemetry/instrumentation. I have changed the version of the package multiple times to no success.
The only solution was to revert @prisma/instrumentation back to version 15.13.0 where everything worked again.
Current instrumentation file imports and relevant call to registerInstrumentations:
import * as otel from '@opentelemetry/api';
import * as semcon from '@opentelemetry/semantic-conventions';
import * as logsapi from '@opentelemetry/api-logs';
import {
  LoggerProvider,
  SimpleLogRecordProcessor,
  ConsoleLogRecordExporter,
} from '@opentelemetry/sdk-logs';
import {
  ConsoleSpanExporter,
  NodeTracerProvider,
} from '@opentelemetry/sdk-trace-node';
import {
  BatchSpanProcessor,
  SimpleSpanProcessor,
} from '@opentelemetry/sdk-trace-base';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { OTLPLogExporter } from '@opentelemetry/exporter-logs-otlp-http';
import { Resource } from '@opentelemetry/resources';

import { registerInstrumentations } from '@opentelemetry/instrumentation';
import { AwsLambdaInstrumentation } from '@opentelemetry/instrumentation-aws-lambda';
import { HttpInstrumentation } from '@opentelemetry/instrumentation-http';
import { DnsInstrumentation } from '@opentelemetry/instrumentation-dns';
import { NetInstrumentation } from '@opentelemetry/instrumentation-net';
import { WinstonInstrumentation } from '@opentelemetry/instrumentation-winston';
import { PrismaInstrumentation } from '@prisma/instrumentation';

/** Skipping rest of file */

registerInstrumentations({
  instrumentations: [
    new DnsInstrumentation(),
    new HttpInstrumentation(),
    new NetInstrumentation(),
    new AwsLambdaInstrumentation(),
    new WinstonInstrumentation(),
    new PrismaInstrumentation(),
  ],
});

How to reproduce

Install @prisma/instrumentation version 15.14.0 or over along with @opentelemetry/api at ^1.8.0"
and @opentelemetry/sdk-trace-base at version ^1.24.1
Create otel intsrumentation file with the configuration above.
Exclude all prisma and otel packages from esbuild bundler

[
  '@prisma/client',
  '@opentelemetry/api',
  '@opentelemetry/api-logs',
  '@opentelemetry/resources',
  '@opentelemetry/semantic-conventions',
  '@opentelemetry/sdk-trace-base',
  '@opentelemetry/sdk-trace-node',
  '@opentelemetry/sdk-logs',
  '@opentelemetry/exporter-trace-otlp-http',
  '@opentelemetry/exporter-logs-otlp-http',
  '@opentelemetry/instrumentation-aws-lambda',
  '@opentelemetry/instrumentation-http',
  '@opentelemetry/instrumentation-dns',
  '@opentelemetry/instrumentation-net',
  '@opentelemetry/instrumentation-winston',
  '@opentelemetry/winston-transport',
  '@prisma/instrumentation',
  'winston',
]

Bundle code

I suspect that this error might happen regardless of bundling as the generic does not exist in the supported versions of @opentelemetry/instrumentation
Expected behavior
Code should be able to build and compile with the listed supported versions of @opentelemetry/instrumentation on version 15.14.0 onwards.
Note: Everything works with 15.13.0 and below and I have the exact same setup in another repository that worked because it was using 15.12.0.
Prisma information
Issue is not with the client, as the client works properly, adding the base prisma.schema configuration here as it was asked.
generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["tracing"]
  binaryTargets   = ["native", "rhel-openssl-3.0.x"]
}

datasource db {
  provider = "postgresql"
  url      = env("IS_PG_DB_URL")
}

No errors using prisma client at all, excluding client use.
Environment & setup

OS: Ubuntu 22.04.4 LTS x86_64
Database: Amazon RDS Instance Postgres 16.1
Node.js version: nodejs20.x

Prisma Version
prisma                  : 5.15.1
@prisma/client          : 5.15.1
Computed binaryTarget   : debian-openssl-3.0.x
Operating System        : linux
Architecture            : x64
Node.js                 : v20.12.2
Query Engine (Node-API) : libquery-engine 5675a3182f972f1a8f31d16eee6abf4fd54910e3 (at<EMAIL_ADDRESS>Schema Engine           : schema-engine-cli 5675a3182f972f1a8f31d16eee6abf4fd54910e3 (at<EMAIL_ADDRESS>Schema Wasm             : @prisma/prisma-schema-wasm 5.15.1-1.5675a3182f972f1a8f31d16eee6abf4fd54910e3
Default Engines Hash    : 5675a3182f972f1a8f31d16eee6abf4fd54910e3
Studio                  : 0.501.0

<EMAIL_ADDRESS>has this generic and<EMAIL_ADDRESS>does not. Looks like we were too generous with our version ranges (but also, looks look otel people did a braking change in semver-minor). Meanwhile, I can confirm that the next Prisma version (5.16.0, planned for next Tuesday, June 25) will not have this generic anymore.
I'll keep this issue open so we won't forget to revise and test our supported ranges.

Thank you for the prompt reply and analysis @SevInf
I will update to 5.16.0 on the 25th!

Prisma everything version is 5.22.0
Also had this problem
Solved by adding to package.json file
"@opentelemetry/instrumentation": "^0.57.0", - this exact version has removed problem generic usage


⚠ Bofrost.es has degraded performance

In 29372ce, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 2266 ms

Resolved: Bofrost.es performance has improved in 7314706.


Consolidated Part 1 Test 26 Data Stream J1939-84 Model Text

Part 1 Step 26 Test: provide a consolidated specification text model for all data stream tests before adding NOx Binning GHG Tracking specific tests.
Cloned from j1939-84 created by ericthomasswenson: Equipment-and-Tool-Institute/j1939-84#985

Unconsolidated issues may now be closed.  Implementation issues for future enhancements will refer to this issue.

6.1.26 Data stream support verification
<IP_ADDRESS> Actions:
a. Create a list of expected SPs and PGs from the DM24 response, where the data stream support bit defined in SAE J1939-73 5.7.24 is 0.
b. Add any omissions from Table A-1, excluding those SPs noted (as CI or SI) for the opposite fuel type provided by the user.
c. Omit the the following SPNs (588, 976, 1213, 1220, 12675, 12691, 12730, 12783, 12797) which are included in the list. Display the completed list noting those omitted SPs, supported SPs as ‘broadcast’ or ‘upon request’, and additions from Table A-1. Save the list for reuse in Part 2.
d. Gather broadcast data for all SPNs that are supported for data stream in the OBD ECU DM24 responses, and the added SPNs from Table A-1. This shall include the both SPs that are expected to be queried with DS queries (in step <IP_ADDRESS> for SPs supported in DM24) and SPs that that are expected without queries.
e. Gather/timestamp each parameter that is observed at least three times to be able to verify frequency of broadcast.
<IP_ADDRESS> Fail/Warn Criteria
a. Fail if no response/no valid data for any broadcast SPN indicated as supported by the OBD ECU in DM24.[26]
b. Fail if any parameter is not broadcast within ± 10% of the specified broadcast period.27
c. Fail/warn if any broadcast data is not valid for KOEO conditions as per Table A1, Minimum Data Stream Support.28
d. Fail/warn per Table A1, if an expected SP from the DM24 support list is provided by a non-OBD ECU.
e. Fail/warn per Table A1 if two or more ECUs provide an SP listed in Table A1.
<IP_ADDRESS> Actions2
a. Identify SPs provided in the data stream that are listed in Table A-1, but are not supported by any OBD ECU in its DM24 response.
<IP_ADDRESS> Fail/Warn _Criteria2
a. Fail/warn per Table A-1 column, “Action if SP provided but not included in DM24”.
<IP_ADDRESS> Actions3:
a. DS messages to ECU that indicated support in DM24 for upon request SPs and SPs added from Table A-1, regardless of whether the SPs were or were not observed in step 1. [Where a PG contains more than one SP (to be queried), that PG need only be queried one time].
b. If no response or NACK for any SPN requested in <IP_ADDRESS>.a, send global message to request that SPN(s).
<IP_ADDRESS> Fail/warn criteria3: [Refer to footnotes 23 and 24 for a and b, respectively].
a. Ignore NACK received for any SP added from table A-1, whose PG does not contain any SPs listed as supported in DM24.
b. Fail if no response or NACK for any SP indicated as supported by the OBD ECU in DM24. Downgrade the failure to a warning where an upon request SPN was received in <IP_ADDRESS>, and the request was not replied to with a NACK.
c. Fail if any parameter in a fixed period message, upon request, is not broadcast within ± 10% of the specified broadcast period.
d. Fail if any parameter in a variable period broadcast message exceeds 110% of its recommended broadcast period.26
e. Fail/warn if any data received (that is supported in DM24 by the subject OBD ECU) is not valid for KOEO conditions as per section A.1Table A-1, Minimum Data Stream Support.
f. Warn/info per Table A-1, if an expected SPN from the DM24 support list is provided by a non-OBD ECU.
g. Fail/warn per Table A-1, if two or more ECUs provide an SPN listed in Table A-1.
h. Fail/warn per Table A-1 column, “Action if SPN provided but not included in DM24”.

Proposed Part 2 Test 17 Text
6.2.17 KOER Data Stream Verification
<IP_ADDRESS> Actions
a. Display the completed list noting those omitted SPs, supported SPs as ‘broadcast’ or ‘upon request’, and additions from Table A-1.
b. Gather broadcast data for all SPNs that are supported for data stream in the OBD ECU DM24 responses, and the added SPNs from Table A-1, using the SPN list from Part 1. This shall include the both SPs that are expected to be queried with DS queries (in step 5 for SPs supported in DM24) and SPs that that are expected without queries.
<IP_ADDRESS> Fail Criteria
a. Fail if no response/no valid data for any broadcast SP indicated as supported in DM24.
b. Fail/warn if any broadcast data is not valid for KOER conditions as per Table A1, Minimum Data Stream Support.
c. Fail/warn per Table A1 if an expected SP from the DM24 support list is provided by a non-OBD ECU.
d. Fail/warn per Table A1 if two or more ECUs provide an SPs listed.
<IP_ADDRESS> Actions2
a. Identify SPs provided in the data stream that are listed in Table A1, but not supported by any OBD ECU in its DM24 response.
<IP_ADDRESS> Fail/Warn Criteria2
a. Fail/warn per Table A1 column, “Action if SP provided but not included in DM24.”.
<IP_ADDRESS> Actions3
a. DS messages to ECU that indicated support in DM24 for upon request SPs and SPs added from Table A-1, regardless of whether the SPs were or were not observed in step 1. [Where a PG contains more than one SP (to be queried), that PG need only be queried one time].
b. If no response or NACK for any SPN requested in <IP_ADDRESS>.a, send global message to request that SPN(s).
<IP_ADDRESS> Fail/Warn Criteria3 [Refer to footnotes 23 and 24 ].
a. Ignore NACK received for any SP added from table A-1, whose PG does not contain any SPs listed as supported in DM24.
b. Fail if no response or NACK for any SP indicated as supported by the OBD ECU in DM24. Downgrade the failure to a warning where an upon request SPN was received in <IP_ADDRESS>, and the request was not replied to with a NACK.
c. Fail if any parameter in a fixed period message, upon request, is not broadcast within ± 10% of the specified broadcast period.
d. Fail if any parameter in a variable period broadcast message exceeds 110% of its recommended broadcast period. [see foot 26].
e. Fail/warn if any data received (that is supported in DM24 by the subject OBD ECU) is not valid for KOER conditions as per Table A-1, Minimum Data Stream Support.
f. Warn/info per Table A-1, if an expected SPN from the DM24 support list is provided by a non-OBD ECU.
g. Fail/warn per Table A-1, if two or more ECUs provide an SPN listed in Table A-1.
h. Fail/warn per Table A-1 column, “Action if SPN provided but not included in DM24”.

SecondChanceClarification3.docx
Provides related information

Rewrite complete as shown


Replace gettext with 'polib' and add test for 'fix_style' function

gettext dependency replaced with Python polib.
Added test for fix_style function.
Added type hints for boolean optional arguments.
Some reformatting to match flake8 and black style.

Closes #76

Hi thanks for contributing, and thanks for your time!
I'd love to see a Python implementation of the msgcat/poedit wrapping sadly there's not.
If we apply this PR, projects using powrap will be entierly rewrapped (meaning a colossal diff), while powrap is here to lower the diff in project histories by unifying wrapping convention.
I tried on https://github.com/python/python-docs-fr, a powrap *.po */*.po:
$ git diff | wc -l
243576

So no, polib is not an acceptable replacement.
(Yes we really need to stick to msgcat / poedit wrapping as there's a lot of contributors using poedit, so they don't have to care about powrap at all. On the other hand there's nobody editing files with a polib-compatible wrapping convention).
If you're still interested in dropping msgcat dependencies, I started https://github.com/JulienPalard/powrap/tree/from_msgcat that could be a way of doing it.


Provide more information about errors

Example:
{
  "level": "error",
  "ts": "2023-03-09T17:39:57.859Z",
  "logger": "event-server",
  "msg": "failed to send notification",
  "reconciler kind": "Kustomization",
  "name": "flux-system",
  "namespace": "flux-system",
  "error": "postMessage failed: failed to execute request: context deadline exceeded"
}

With a bit of guess-work I could deduce it to be about Slack notifications. More information (provider name, timeout value, etc) could/would help a lot in pinpointing the exact underlying issue(s).

Agreed. I cannot get Slack to work as this error provides no information. I create the secret with the token didn't work, created secret with the address including all its needed info in URL params didn't work, finally used the deprecated method and that works


Add Stem Creator v<IP_ADDRESS>

Stem Creator tool from Native Instruments for the new Stems audio format.
Signed-off-by: Daniel Bayley<EMAIL_ADDRESS>

There's one slight problem with this; the artifact doesn't seem to work as it should, and I'm not sure why?

It seems like you’re not using it for its purpose, for one. Are you trying to copy a directory? Why?

Ok, I've made those tweaks.

It seems like you’re not using it for its purpose, for one. Are you trying to copy a directory? Why?

I was… as the .dmg contains a Documentation folder (but no .pkg to put it anywhere). I own a bunch of Native Instruments products and they all store things in ~/Library/Application Support/Native Instruments/… so I thought it should go in there. I was going off a previous cask formula (touchosc-editor);
artifact "touchosc-editor-#{version}-osx/layouts", :target => Pathname.new(File.expand_path('~')).join('Library/Application Support/TouchOSCEditor/layouts')

Changes aren’t made. Did you forget to push?

Nope; I just hadn't gotten round to re-testing after the local changes. Sorted, and all working now, thanks.

Thank you for the contribution. It was merged directly as 17fad16dadf3d28cce5353f948b3886a6e408a13 to keep commit history cleaner. Your contribution is still credited to you.


studio: Add DVC Studio commands to documentation

You may disregard these recommendations if you used the Edit on GitHub button from dvc.org to improve a doc in place.

❗ Please read the guidelines in the Contributing to the Documentation list if you make any substantial changes to the documentation or JS engine.
🐛 Please make sure to mention Fix #issue (if applicable) in the description of the PR. This causes GitHub to close it automatically when the PR is merged.
Please choose to allow us to edit your branch when creating the PR.
Add guides for dvc studio login feature introduced in  dvc: https://github.com/iterative/dvc/pull/10074
Closes #4979

@yathomasi I thought we had a way to deploy forks after an approval, but I don't see it anymore? was it deleted?

@amritghimire could you please create PR from a branch so it's deployed automatically?


React-tiles: Upgraded to SPFx 1.16.1

Category

[ ] Bug Fix
[x] New Feature
Related issues: fixes #X, partially #Y, mentioned in #Z

What's in this Pull Request?
Upgraded solution to SPFx 1.16.1, upgraded pnp spfx controls to the latest version and fixed ESLint warnings after upgrading.

merged to v3, thank you for the submission.


doc: op guide for install, uninstall etcd operator

fix https://github.com/coreos/etcd-operator/issues/735
[skip ci]

Once kubernetes supports deployment hook (https://github.com/kubernetes/kubernetes/issues/14512), we can make use of that as well.

fixed

fixed

LGTM


Exported shell functions create noise when running pants

I define a utility functions in my ~/.bash_profile, and export -f it:
function run_testdb () {
    docker run --rm -it \
        -e POSTGRES_HOST_AUTH_METHOD=trust \
        -e POSTGRES_DB=django \
        -e POSTGRES_USER=django_user \
        -p 5432:5432 \
        public.ecr.aws/docker/library/postgres:12 \
        -c max_locks_per_transaction=512 \
        -c fsync=false \
        -c synchronous_commit=off \
        -c full_page_writes=false \
        -c shared_buffers=256MB \
        -c autovacuum=off
}
export -f run_testdb

When I run the scie-pants binary in a shell after loading this profile, I see logs:
Could not interpret env entry run_testdb () . Skipping.
Could not interpret env entry { . Skipping.
Could not interpret env entry }. Skipping.
Could not interpret env entry run_testdb () . Skipping.
Could not interpret env entry { . Skipping.
Could not interpret env entry }. Skipping.

I'm not sure if it's possible to detect & silently skip exported functions (while preserving the log for non-functions). If not, it'd be nice to hide these behind some sort of "debug" logging option.

Looks like there's a set flag to have it omit functions from the output. Will set up a PR.

Ergh - set -o posix prevents functions from being printed as part of subsequent sets, but it also prevents newlines from being escaped in the values of vars like IFS, so it breaks the parser in a different way 🤔

Yeah, and forcing posix mode would not be faithful to the current source .pants.bootstrap in the ./pants script. I think that's a non-starter. I avoiding invoking /usr/bin/env since its another external assumed dependency. Current this has none - it only assumes bash and that's part and parcel of using .pants.bootstrap at all. I can take a quick look, but I think just adding a second binary to the crate that prints env vars is easy enough. I can have that ship in the scie and arrange bash to call it. Will also work on Windows.

Right, that doesn't work since it only handles exported variables. As the current ./pants sourcing arrangement stands, you need not export vars; you only need set them.

In this case it turns out the export -f isn't needed for my use-case (I thought it was for some reason - probably scarred from the days of running complex hacks in GNU parallel). So I'm ok closing this as a "won't do" if all the easy ideas are non-starters.

This was a worthwhile find anyhow @danxmoran. I have a fix out for review.


Updating message for validation timeout and increasing timeout period…

Updating message for validation timeout and increasing timeout period for private extensions

@trevorsg Request you to please review

@trevorsg Updated the changes as per suggestions


Libertarian Communism renders improperly

 (The top)

Huh! That's probably easily fixable with a slight font size reduction. Since I don't know how to do that code currently, I think I will leave that up to one of the other contributors or admins. Good find though!


MUMUP-1930 update README re providing endpoint.properties .

If you don't provide an endpoint.properties, the /web war file will not Spring applicationContext init, and so fails to come up under e.g. jetty:run.
This PR updates README.md to document that one needs to do this before building.
Went for documentation of the step rather than just going ahead and providing an empty endpoint.properties, since a .gitignore had carefully excluded endpoint.properties.

:+1: Way favor this over an empty endpoint.properties. :)


feat(tutorial): complete step 3

Closes #
{{short description}}
Changelog
New

{{new thing}}

Changed

{{change thing}}

Removed

{{removed thing}}

The Netlify error:

9:33:31 AM: error An unexpected error occurred: "https://eu.artifactory.swg-devops.com:443/artifactory/api/npm/mss-npm-virtual/@types/zen-observable/-/zen-observable-0.8.1.tgz?dl=https%3A%2F%2Fregistry.npmjs.org%2F%40types%2Fzen-observable%2F-%2Fzen-observable-0.8.1.tgz: Request failed "401 Unauthorized"".

I recommend you ask in #carbon-tutorial to see anybody has insight. Do you have an npmrc file somewhere which caused that package to be installed from IBM's artifactory instead of the npm registry?


fix(win): take border into account for window position

Description

The window position is not correctly centered when position is set to float and border isn't none. I found a similar issue in lazy.nvim along with your fix there, so I have applied the same fix here. Thank you for your work!
Related Issue(s)
https://github.com/folke/lazy.nvim/issues/812

Screenshots

Before

After

ty


Solr hostname changes

This changes solr hostnames. These changes
are already present in the DNS.

I've tested this locally in the Vagrant environment and changing these names didn't cause any issues.
I will try this out in the -test environment to see if causes problems when the playbook is ran against an
existing server.


Discussion for new design requirements

I have mentioned a few bugs and suggestions in this video. Please take a look at it.
@johnumarattilbb _a
cc: @labeebklatif , @karthiknmenon , @praveen-murali-ind

@amaldinesh7 @karthiknmenon
Let's not skip any features we had with older editor? Implement same way as dropdown in the editor top bar?
I will share the mocks including downsized editor panel.

@amaldinesh7 Marking this as closed.


Fix code analysis breaks

Fixes some code analysis breaks caused by my previous PR #111

@jafletch,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot


How does the Push Enabled Push Disabled work ?

Hello ! I'm not sure this question belongs here but I con't find documentation on that.
I do not understand how the Push Enable & Push Disable is set on customerio.  I have 80% of my users with device that are Push Disabled, trying to understand why.
I have a device with the installed app, and its said I have Push Disabled, but I did not do anything on the phone. If I send push notif, it works well.

Also I did another test with an iphone. Installed, uninstalled and reinstalled. That makes 2 device token (that I understand). Why is the first one Enabled, and the second (newer) one Disable. (I see a weird SDK version as well, it was from the same build I swear, might be an expo version vs RN version)

Thanks 😇

Hi @Samox
Apologies for the inconvenience.
Our SDK automatically collects device attributes during device registration. This feature is enabled by default and captures information like platform, version, push_enabled etc.
However, in iOS push notification permission requires explicit user consent (it's off by default), there might be a lag in getting the actual push_enabled value.
Initially, when the device registers (typically at app launch, and assuming it is first time app launch), the SDK fetches device attributes, and push_enabled will likely be false because push permission hasn't been requested yet.
Later, when your app requests for push authorization and the user grants permission, the push_enabled status will be updated, but only on the next app launch or when device attributes are refreshed.
This is why you see that the first app you installed initially had disabled but later enabled and the second one as disabled as I assume that you did not relaunch the app.
I realise that the docs do not mention any of the points that I just highlighted. I am adding a note internally to talk about this with our docs team. Thanks for your question.

Oh ok I think I get it. Thanks !

@ami-aman I tried to force a refresh of the device after the user's permission, but if I understand correctly, the app must be restarted in order to have the right "push enabled" value in the sdk right ? Just want to make sure there is no other way to get the data right at first launch :D .
Also I see this update on my users. Is there a way to prevent it ? It is kind of noisy
cio_sdk_version: {
from: "1.0.0-beta.15"
to: "2.12.3"
}


Allow passing flags to let the Java profiler keep profiling new processes even after encountering errors

Superseded by https://github.com/Granulate/gprofiler/pull/248

Closing as was (or will be) superseded.


Getting error.

Uncaught TypeError: Cannot read property 'children' of null
Getting this error in console.
This is the code .
<paper-carousel items="3" responsive="600:2, 460:1" controls="true" dots="true" dotText="false">

</paper-carousel>

Hi @sp1rs,
This issue has already been discussed in #11.

@oscarsolas got it, thanks.


move relative humidity measurement cluster to seperate xml file

Problem
https://github.com/project-chip/connectedhomeip/pull/7224 moved the temperature measurement cluster to a separate xml file. This PR does the same for the relative humidity measurement cluster. This PR also addresses a similar issue as https://github.com/project-chip/connectedhomeip/pull/7810. It sets spec complaint defaults to min / max measured values.
Change overview

move relative humidity measurement cluster to separate xml file
set spec compliant min / max measured values default values

Testing
Locally tested with zap.

The 0xFFFF default doesn't really make much sense to me, but ok...

Currently there is

@saurabhst @msandstedt @LuDuda @andy31415 ?

So 0xFFFF indicates that the value is not defined

That's not how Matter represents "not defined", is the point.

That's not how Matter represents "not defined", is the point.

Well, since matter has no spec for relative humidity measurement yet. This is the best we can do for now. At least in my opinion.

This is the best we can do for now

This is why I marked approved and said "but ok", yes?
What we should do is have an issue tracking this.


Images Shouldn't Offer Masking

Bug Description
There is no point of masking an image on an image.

Expected Behaviour
Dragging an and hovering an image over another image shouldn't trigger the masking feature
Steps to Reproduce

Put an image on the page
Drag and hover another image over that image as if you are trying to mask it

Screenshots

Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance Criteria
QA Instructions

/cc @samitron , this might be true now but not in the future when shadows/other styles are added to the image and you'd wanna preserve them and replace the content

I think @samitron7 explicitly wanted this kind of "image" replacement to exist.

I spoke with Sam and this is not a bug.


Zipkin dependency issue with spring-boot2

We are using Armeria with Spring-boot 2 and Gradle.
Since spring-boot 2.0, spring-boot gradle plugin no longer add group name to the name of jar.
https://github.com/spring-projects/spring-boot/issues/10778
As a result, conflict zipkin artifacts used by Armeria in jar.
Jar file contains two BOOT-INF/lib/zipkin-2.5.1.jar in our project.
Also application booting up failed sometime.... (result depends on build env)
2018-03-27 15:45:37.940 ERROR 18459 --- [           main] o.s.boot.SpringApplication               : Application run failed
java.lang.IllegalStateException: Error processing condition on com.linecorp.armeria.spring.ArmeriaAutoConfiguration
    at org.springframework.boot.autoconfigure.condition.SpringBootCondition.matches(SpringBootCondition.java:64)
...
    at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:51)
Caused by: java.lang.TypeNotPresentException: Type zipkin2.Span not present

Looks Armeria depends io.zipkin.java:zipkin which depends on io.zipkin.zipkin2:zipkin.
However, io.zipkin.java:zipkin seems just a alias artifact of zipkin2.
If armeria depends on io.zipkin.zipkin2:zipkin, this issue might be resolved.
|    +--- com.linecorp.armeria:armeria-zipkin-shaded:0.59.0
|    |    +--- com.linecorp.armeria:armeria-shaded:0.59.0 (*)
|    |    +--- com.google.code.findbugs:jsr305:3.0.2
|    |    +--- io.zipkin.brave:brave:4.17.2
|    |    |    +--- io.zipkin.zipkin2:zipkin:2.5.1
|    |    |    \--- io.zipkin.reporter2:zipkin-reporter:2.4.1
|    |    |         \--- io.zipkin.zipkin2:zipkin:2.5.1
|    |    +--- io.zipkin.java:zipkin:2.5.1
|    |    |    \--- io.zipkin.zipkin2:zipkin:2.5.1
|    |    \--- org.slf4j:slf4j-api:1.7.25

Thanks for reporting!

https://search.maven.org/remotecontent?filepath=io/zipkin/java/zipkin/2.6.1/zipkin-2.6.1.pom
https://search.maven.org/remotecontent?filepath=io/zipkin/zipkin2/zipkin/2.6.1/zipkin-2.6.1.pom
It seems like io.zipkin.java:zipkin is not just an alias. If I replace io.zipkin.java:zipkin with io.zipkin.zipkin2:zipkin, it fails to compile:
/home/trustin/Workspaces/armeria/zipkin/src/main/java/com/linecorp/armeria/internal/tracing/SpanTags.java:25: error: package zipkin does not exist
import zipkin.Constants;
             ^
/home/trustin/Workspaces/armeria/zipkin/src/main/java/com/linecorp/armeria/internal/tracing/SpanTags.java:26: error: package zipkin does not exist
import zipkin.TraceKeys;
             ^
/home/trustin/Workspaces/armeria/zipkin/src/main/java/com/linecorp/armeria/client/tracing/HttpTracingClient.java:140: error: cannot access Endpoint
        span.remoteEndpoint(Endpoint.newBuilder().serviceName(remoteServiceName).ip(address).build());
            ^
  class file for zipkin.Endpoint not found
/home/trustin/Workspaces/armeria/zipkin/src/main/java/com/linecorp/armeria/internal/tracing/SpanTags.java:38: error: cannot find symbol
            span.tag(TraceKeys.HTTP_HOST, log.host());
                     ^
  symbol:   variable TraceKeys
  location: class SpanTags
/home/trustin/Workspaces/armeria/zipkin/src/main/java/com/linecorp/armeria/internal/tracing/SpanTags.java:51: error: cannot find symbol
            .tag(TraceKeys.HTTP_STATUS_CODE, String.valueOf(log.statusCode()));
                 ^
  symbol:   variable TraceKeys
  location: class SpanTags
/home/trustin/Workspaces/armeria/zipkin/src/main/java/com/linecorp/armeria/internal/tracing/SpanTags.java:50: error: cannot find symbol
            .tag(TraceKeys.HTTP_URL, uriBuilder.toString())
                 ^
  symbol:   variable TraceKeys
  location: class SpanTags
/home/trustin/Workspaces/armeria/zipkin/src/main/java/com/linecorp/armeria/internal/tracing/SpanTags.java:49: error: cannot find symbol
            .tag(TraceKeys.HTTP_PATH, log.path())
                 ^
  symbol:   variable TraceKeys
  location: class SpanTags
/home/trustin/Workspaces/armeria/zipkin/src/main/java/com/linecorp/armeria/internal/tracing/SpanTags.java:48: error: cannot find symbol
        span.tag(TraceKeys.HTTP_METHOD, log.method().name())
                 ^
  symbol:   variable TraceKeys
  location: class SpanTags
/home/trustin/Workspaces/armeria/zipkin/src/main/java/com/linecorp/armeria/internal/tracing/SpanTags.java:54: error: cannot find symbol
            span.tag(Constants.ERROR, responseCause.toString());
                     ^
  symbol:   variable Constants
  location: class SpanTags
9 errors

If I understood the issue correctly, it's a limitation of spring gradle plugin or an artifact naming issue with Zipkin. Did you try this workaround? https://github.com/spring-projects/spring-boot/issues/10778#issuecomment-372573514

I tried the workaround, and it works well.
BTW, the brave library only depend on zipkin2, so I thought we can replace with zipkin2 completely.
But it seems difficult...


Added in a dist blog post draft #21

As per the comments in #21:

[x] explain the goals of the page (one stop place for all official binaries we distribute)
[~] have screenshots (github blog style gifs may be nice)
[x] describe criteria for something being added (i.e. should be a product of the IPFS community, should have high quality UX, should be well maintained, anything else?)
[x] mention multiple platform (os, arch) downloads
[x] mention smart browser user-agent driven button
[x] mention site + all binaries are hosted via ipfs itself
[ ] mention dedup in the resulting dag
[ ] maybe include a graphmd graph of the site, ideally showing dedup
[~] mention how site is hosted with IPFS (dnslink, maybe link to a guide)
[x] mention that you can view it on ipfs itself, on the local gateway
[~] mention using site in local node will make it faster to download versions in the future.
[x] mention that it's used by ipfs-update itself to update ipfs.
[~] mention that you can view it with the browser extensions
[~] mention future goal of code signing
[x] mention future closer integration with package managers
[x] mention future things to be added (like ipget, any others?)
[x] mention future goal of having {screenshots, gifs, asciinemas} in the page
[ ] mention dedup on the binaries themselves, if there's any. (add it with ipfs add -s rabin for higher likelihood of matches?)
[x] mention future goal of importing binaries smartly to enhance chance of dedup
[x] invite readers to contribute and file issues at the repo https://github.com/ipfs/distributions

I've mentioned what I could, but I'll need some help with the unchecked and begun marks above. @dignifiedquire, can you help? I've added some sections in the draft as note to highlight where I was a bit unsure about my wording.
I'm not sure what @jbenet means by "github blog style gifs".

I'm not sure what @jbenet means by "github blog style gifs".

He means small inline gifs showing the described interaction: example https://github.com/blog/2097-improved-commenting-with-markdown

@RichardLitt just two comments left, then we can ship this I think.

@dignifiedquire Added two commits. Look alright?

@RichardLitt screenshot is already out of date now that ipget was added

Will update it when everything else is good to go.

Updated screenshot. It is in no way optimized. I haven't found a good workflow for optimizing images for one-offs like this. Anyone know of one?

+1 LGTM

@RichardLitt I use https://imageoptim.com/

@richardlitt on last comment then LGTM

on the topic of optimizing pngs, i've found this to work quite well: http://optipng.sourceforge.net/


[SPARK-20395][BUILD] Update Scala to 2.11.11 and zinc to 0.3.15

What changes were proposed in this pull request?
Update Scala to 2.11.11 and zinc to 0.3.15
How was this patch tested?
Existing tests.

Test build #76933 has started for PR 17982 at commit 2028dbd.

Test build #76933 has finished for PR 17982 at commit 2028dbd.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

@ScrapCodes it's good you're here because this might be something you can help with. (CC @dragos as well)
I'm updating to scala 2.11.11, and it looks like the loadFiles method that SparkILoop hooks into was removed in 2.11.9. I think it's about the same to hook into process() instead and do Spark init after it's done. Do you know of any reason that's a bad idea? I'm pushing the change anyway to see.

Test build #76936 has started for PR 17982 at commit 794d18d.

Hi Sean,
Taking a quick look at the changes that removed loadFiles. changes
It seems startup is the correct alternative, i.e. just before the call to printWelcome.
See startup.

@ScrapCodes ah I should have pointed out the other constraint: we want this to still work with 2.11.8. Right now Spark would not run vs Scala 2.11.9+ at runtime, but if we tried to hook into startup it wouldn't work with 2.11.8 because that method didn't exist. That's why I was looking at process.

Actually, now I am wondering, how would it work without createInerpreter is executed. You constraint, makes things a bit tricky. I will think more before I reply.

If I am not able to come up with the better alternative, then following not so ideal option exist.

we can do a scala version check and have two different code paths based on scala version.
In scala 2.11.8+ we can hook out init just before printWelcome()
In scala 2.11.11 we can do it just before loopPostInit().

If I'm not mistaken the current patch will fail on files passed via -i to spark-shell, since Spark is initialized after process is done (the SparkContext is not available during initialization, when -i files are loaded).
I'm not sure if there's a better way, especially one that works on all 2.11 series. Mea culpa for not adding a comment on loadFiles in the Scala REPL when I worked on the Spark Shell. Maybe @som-snytt has a suggestion for inserting initializeSpark in the initialization pipeline?

Test build #76936 has finished for PR 17982 at commit 794d18d.

This patch fails from timeout after a configured wait of `250m`.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

The contract was never well-defined.
sbt overrides createInterpreter and runs its initialCommands before returning. So that runs before REPL finishes init in loopPostInit: no $intp, power mode not entered, start code and -i not run yet.
I can't tell just by looking if that suits your needs here, but it's the most ancient hook enshrined by sbt.
https://github.com/sbt/sbt/blob/0.13/compile/interface/src/main/scala/xsbt/ConsoleInterface.scala#L27
@adriaanm is taking executive action to modularize/make API for REPL reuse. Possibly you're aware or he's only just started and is in stealth mode. That will address the issue in future.

Yeah, this was always a bit of a hack as this isn't an API. createInterpreter sounds like a promising place to hook into for now as it exists across these versions, and would mean Spark is initted a little earlier, before instead of after this middle block in here:
  def process(settings: Settings): Boolean = savingContextLoader {
    this.settings = settings
    createInterpreter()

    // sets in to some kind of reader depending on environmental cues
    in = in0.fold(chooseReader(settings))(r => SimpleReader(r, out, interactive = true))
    globalFuture = future {
      intp.initializeSynchronous()
      loopPostInit()
      !intp.reporter.hasErrors
    }
    loadFiles(settings)
    printWelcome()
...

Test build #76946 has started for PR 17982 at commit e1482c3.

Test build #76946 has finished for PR 17982 at commit e1482c3.

This patch fails from timeout after a configured wait of `250m`.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Test build #3728 has started for PR 17982 at commit e1482c3.

Test build #3741 has started for PR 17982 at commit e1482c3.

Test build #77096 has started for PR 17982 at commit b5a7035.

Test build #3741 has finished for PR 17982 at commit e1482c3.

This patch fails from timeout after a configured wait of `250m`.
This patch merges cleanly.
This patch adds no public classes.

Test build #77096 has finished for PR 17982 at commit b5a7035.

This patch fails from timeout after a configured wait of `250m`.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Darn. I don't know if this is going to work. I'm closing this for now.

Thanks for the effort. I'll take a hack soon. If it's hopeless, I'll at least try to track developments with the new REPL API.

@som-snytt @srowen what about 2.11.12?

Unless it changed the internals of the interpreter to afford a different place to hack in the init, don't think it is any different. However the build and most tests already work with 2.12.d

2.12 would be even better. I haven't seen a ticket related to 2.12 upgrade. I can give it a try.


Script to make palette for R-G-colorblindness

This produces an adjusted Solarized palette that evenly spaces hues
between blue & yellow, keeping everything else the same. It gives the
highest possible contrast for Deuteranopia.
SOLARIZED HEX
--------- -------
yellow    #b58900
orange    #cb4916
red       #dc2f51
magenta   #bb36d3
violet    #6c76c4
blue      #268bd2
cyan      #2aa189
green     #189900

I am not colorblind, but tested this out on a coworker. He says he's keeping it :).

I had the script also print the colors to the terminal. And my best guess at what it looks like flattened.

(I say 'flat' to mean that I'm remapping colors on the green side to the red side of the color wheel.)


Fix databricks

Needs 1 change and 1 explanation.
I assume you ran all the tests with at least mysql+postgresql+databricks?

@erezsh No, I did not. Don't they run on our CI/CD?

@pik94 They do not. We don't have a proper way to set it up for tests.

@pik94 They do not. We don't have a proper way to set it up for tests.

@erezsh , ok, i will run them locally then. For now move a PR to draft then.

Sorry, I caused a small conflict. It should be easy to resolve, but let me know if you need help with it.

Sorry, I caused a small conflict. It should be easy to resolve, but let me know if you need help with it.

@erezsh np, resolved it.

Thanks. Please rebase and reduce commits before removing the 'draft' flag.

Thanks. Please rebase and reduce commits before removing the 'draft' flag.

@erezsh done. Also ran unit-tests for Databricks vs Databricks, Databricks vs PostgreSQL, Databricks vs MySQL, they were passed after some fixes.

Just one small thing.
Also don't forget to run black -l 120 data_diff/databases/databricks.py

Done. :)


NetworkError from Maxthon browser

We use segment.io on a production application to track download events.
We have a user who apparently uses the Maxthon browser. We get "NetworkError" exceptions sent to Honeybadger when they use Maxthon. The same user, after switching browsers and performing the same actions, does not cause the same errors to be emitted.

This is still occurring.

@jchesterpivotal can you list reproducible steps here if this is still an issue? What are the "actions" being performed?

I wish I could, however it looks as though Honeybadger has dropped our copy of the original report. From the notes we kept at the time, it seems as though the user is attempting to download software from Pivotal Network (our downloads site). This sends an event to segment.io -- or tries to, then fails on a NetworkError.
The same user then switches to Firefox and successfully downloads that product.
Our code does nothing fancy -- literally sends a single event, Clicked Download, which then blows up somewhere in the segment.io code we pull in.

And you've confirmed that without the .track() event, the user can successfully download using Maxthon?

I can't say either way. What I can say is that the same user switches to Firefox and successfully downloads, meaning that the same tracking code is invoked in the same way.
This is why we suspect it's specific to Maxthon. We have not seen this error on any other browser.

If you can reproduce it on your own computer or have multiple user reporting the same user with that browser, we can dig into this but right now we don't have much context here nor reproducible steps :/
I'll close the issue for now but if you do some isolated testing on your end with Maxthon such as removing the track call and checking the behavior. For all we know it could be any number of reasons ;)
Once those are ready just reopen this issue. Thanks!

Given that this particular user just switches to Firefox, we'll accept your position that it's a known bug that won't be fixed.

The same user came back, again with Maxthon, again with the same error.
{
  "DO_NOT_TRACK" => "1",
  "ON_LINE" => true,
  "COOKIE_ENABLED" => true,
  "VENDOR_SUB" => "",
  "VENDOR" => "Maxthon Asia Ltd.",
  "PRODUCT_SUB" => "20030107",
  "PRODUCT" => "Gecko",
  "PLATFORM" => "Win32",
  "LANGUAGE" => "zh-CN",
  "APP_VERSION" => "5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Maxthon/<IP_ADDRESS>0 Chrome/30.0.1599.101 Safari/537.36",
  "APP_NAME" => "Netscape",
  "APP_CODE_NAME" => "Mozilla",
  "HTTP_USER_AGENT" => "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Maxthon/<IP_ADDRESS>0 Chrome/30.0.1599.101 Safari/537.36",
  "HTTP_REFERER" => "[redacted]"
}

Backtrace
https://cdn.segment.io/analytics.js/v1/1upaeldra0/analytics.min.js:6 :in `i`
https://cdn.segment.io/analytics.js/v1/1upaeldra0/analytics.min.js:6 :in `e.w.send`
https://cdn.segment.io/analytics.js/v1/1upaeldra0/analytics.min.js:6 :in `e.w.ontrack`
https://cdn.segment.io/analytics.js/v1/1upaeldra0/analytics.min.js:6 :in `i.<anonymous>`
https://cdn.segment.io/analytics.js/v1/1upaeldra0/analytics.min.js:1 :in `i.n.emit`
https://cdn.segment.io/analytics.js/v1/1upaeldra0/analytics.min.js:1 :in `i.emit`
https://cdn.segment.io/analytics.js/v1/1upaeldra0/analytics.min.js:6 :in `i._invoke`
https://cdn.segment.io/analytics.js/v1/1upaeldra0/analytics.min.js:1 :in `i._invoke`
https://cdn.segment.io/analytics.js/v1/1upaeldra0/analytics.min.js:6 :in `i.track`
https://cdn.segment.io/analytics.js/v1/1upaeldra0/analytics.min.js:1 :in `i.track`


Is it possible to implement the login to meteor from react-native without eject

Hi,
Sorry in advance if the question seems very basic but is it possible to implement the login to meteor without ejecting?
I am very new to react-native this is my first application but I have been working with meteor for several years. I think my DDP is not correctly set because I couldn't follow the instructions from here https://github.com/inProgress-team/react-native-meteor/blob/master/docs/Install.md as I don't have AndroidManifest.xml.
The error I am getting is:Cannot read property 'method' of null in Call.js line 9 that is why I thought the DDP is not initialized correctly.
I added console logs in the index.js from the app folder near the Meteor.connect line but they don't show up so I don't think I quite get the folder structure and the automatic importing yet.a
Let me know if you need any more details.

No need to eject as Expo/Create React Native App already have the android.permission.ACCESS_NETWORK_STATE permission.
I'm not sure what's causing the error you're experiencing. Can you share a simple reproduction of it?


Feature proposal: Switch boot order on Advanced device by holding user button during start-up

Would possibly help in scenarios where the eMMC gets stuck during boot: Take a fresh image on an external storage and flip the boot order without requiring serial console usage.
As this overlaps with the usage of the button for #102, we will likely also have to think about a proper indication to the user so that the button is release prio to actually starting the boot.

Will need integration into U-Boot, but a working prototype exists now: hold the user button during boot until the status LED turns orange. Release the button, and the system will boot while ignoring the eMMC as option.
PS: Automatic cross-reference to the shutdown issue is misleading.


[NS-44] Vectorize Merge

Fix for NS-44 (Replace bitwise merge with vectorized merge):
nullable_scalar_vector and nullable_varchar_vector now use cyclone_utils::fast_validity_merge for vectorized merge of validity bits.
I'd love to know, if it's any faster now...

Cherry picked to start from a clean main in #585.


Support indices preceding the base symbol, revamping #699

Hi this PR adds native support for attaching indices preceding the base symbol ("prescripts", "left index"). This is very useful in denoting isotopes, etc. and mirrors the composition capabilities offered by Latex. For a demo, please see the modified test images.
The modified function signature is attach(base, top, bottom, topleft, bottomleft, topright, bottomright).
This PR fixes https://github.com/typst/typst/issues/690. This PR is the same as the most recent version of my #699, which addressed the comments there, but with a cleaner git history.

Looks good. One thing I've only just realized is that top-left (the usual naming convention) isn't a valid identifier in math. So we have to decide whether to change that (probably not because of e.g. $pi-2$), keep the current names (hmmm), or say that in math we use something shorter (e.g. attach(base, t, b, tl, bl, tr, br), maybe not that bad?)

Hi - I'm okay with whatever you decide on. I would slightly prefer not to use short names, and I think the long, full names are acceptable because the backward-compatible attach(base, top:..., bottom:...) is enough for most usages -- but not a strong opinion.

I don't have a problem with the long names, per se, just with their lack of hyphens as that is the standard naming convention in Typst. That's why I think the shorthands might be good: They are consistent with the idea that math does things in shorter ways.

How about topl, topr, bottoml, bottomr?

There was some discussion on Discord. The results are as follows:

Consensus that none of the solutions is particularly great
A few people expressed a preference for clarity instead of abbreviations
Kebab case (bottom-left) would be possible, but would make the math arguments parsing even hackier
Just one word (bottomleft) of course works, but is inconsistent with the usual naming conventions in Typst
Abbreviations like tr have precedence with arrow.tr

I lean relatively strongly towards one of the following two options:

The abbreviations. It's (a) consistent with the math symbols like arrow.tr, (b) doesn't conflict with the normal kebab-case convention, (c) is compact; all at the price of a little bit of clarity.
Kebab case with a parser change. This would also be consistent, but require some smartness on the lexer side and make third-party grammars even harder to write. (They are already pretty tricky to write, so one more thing might not matter all that much.)

Regardless of all this, we concluded that top/bottom should automatically become limits if top-right/bottom-right is given (instead of being ignored).

Thanks all for putting thoughts into this.
I'll follow the conclusion and adapt the PR to (1) use abbreviations attach(base, t, b, tl, bl, tr, br) (note it will rename the existing params top and bottom, so it will be a breaking change -- could you confirm? @laurmaedje), and also (2) top/bottom should automatically become limits if top-right/bottom-right is given (instead of being ignored).

Make no mistake; I am almost always in favor of explicit names over abbreviations, especially ones that may be particularly opaque. We are long past the days of 80-line teletypes and extremely limited storage for text files. My opinion here should not be taken as precedent without also taking my reasoning as precedent :)
However, I believe there are many use cases that warrant additional terseness here. Chemistry first came to mind; they love placing superscripts and subscripts all over their chemical symbols. I have also seen them in physics, and (while this is sample size n=1) I’ve had a professor that has some ungodly affinity for them in mathematical logic. For this reason I am in favor in the abbreviated argument names; more than anything, if they’re used at all they are going to be used a lot. I think maybe t and b could afford to be top and bottom for the sake of clarity on the two most common options, as giving at least something a full name provides some context hints for the others.
Have we considered special syntax here, for outside of the function? After all, ^ and _ exist. I propose ^(a)_(b)C^(d)_(e) as a first draft (I hope it is obvious where everything goes, or the notation is bad), but I also don’t like drowning the more important character. Using ^^ or __ for pre-(super|sub)scripts also popped in my head. If some syntax is adopted, I would be in favor of the more explicit names for the functions.

Wouldn't the parser change also be backwards-incompatible? I know I have documents that do stuff like $a-b$.

I thought this is a settled conclusion on Discord..

Wouldn't the parser change also be backwards-incompatible? I know I have documents that do stuff like $a-b$.

Because typst is beta software, I don’t think we’re going to reject a change that moves the language forward solely for backwards compatibility, though it is a consideration. Though this is, of course, something I say with complete deference to the opinions of the founders.
Part of the advantage of typst over latex right now is that we can change things and do stuff right instead of just what was decided (no matter how right it seemed) ages ago. LaTeX moves at a glacial pace, and for good reason; there’s no situation more terrifying than “my paper doesn’t compile anymore and I need it submitted tomorrow aaAaaaAAAA”. Such situations would likely cause someone to lose faith in the maintainers of LaTeX, but because typst is firmly beta software, I imagine this is less of an issue.

I thought this is a settled conclusion on Discord..

Yeah, me too, but new points means further discussion is warranted.

Just uploaded a new patch where users can freely position the attachments at one or more of the six positions (top-left, top, top-right, bottom-left, bottom, bottom-right).
The previous commit "Satisfy maintainer #issuecomment-1516330763" does satisfy the two requirements prescribed by https://github.com/typst/typst/pull/825#issuecomment-1516330763, but users are not able to achieve certain configurations, e.g. top-left + top-above.
The new commit "one step further: put attachments freely at all 6 possible positions" addressed this problem. Users can freely put attachments at the six positions, while the special syntax a^b_c and lim^b_c are still smartly rendered as "scripts" or "limits", just like before. If this new commit is not desirable, we can go back to the previous commit.

Well I'm just saying that out of the two proposed solutions I prefer the one that isn't a breaking change.

I think maybe t and b could afford to be top and bottom for the sake of clarity on the two most common options, as giving at least something a full name provides some context hints for the others.

I'd prefer to not do that in the name of consistency, especially with $arrow.t$.

Have we considered special syntax here, for outside of the function?

Not yet, but that shouldn't block this PR.

Wouldn't the parser change also be backwards-incompatible? I know I have documents that do stuff like $a-b$.

The parser change would have only affected named arguments in math calls, other math identifiers would have been untouched. That's why it would probably have ended up being a bit hacky. Changing top to t is of course also a breaking change (although I assume very few people use explicit attach in favor of the syntax.) But the bar for improvement to warrant a breaking change is still quite low for now.
All things considered, I'm confident in the abbreviations now and would conclude the discussion. :)

Just uploaded a new patch where users can freely position the attachments at one or more of the six positions

Very nice! I've looked at the changes and the output looks great! Why did you add a new SmartAttachElem though? The idea was to keep just AttachElem and t and b behave smartly by default.

Thanks!

Very nice! I've looked at the changes and the output looks great! Why did you add a new SmartAttachElem though? The idea was to keep just AttachElem and t and b behave smartly by default.

The snag mentioned above "users are not able to achieve certain configurations, e.g. top-left + top-above" actually lies in the original behavior "t and b behave smartly by default". Specifically, if user writes attach(a, tl: x, t: y) then y will appear at the top-right corner, not directly above the base symbol.
To address this issue, we need an attach() that is deliberately "not smart", i.e. it puts the attachments where it was told to (as an extra bonus, it could also reduce some user confusion). However, I think we do really want the "smart behavior", especially with the special syntax a^b_c/lim^b_c, so we need to keep it. My way to keep the smart behavior is letting a SmartAttachElem to handle the special syntax, and the original AttachElem to handle the "not smart" behavior of faithfully positioning the attachments.
I also considered attach(base, smart, ...) where smart is a boolean, but that seems to be a bit confusing and unccessary.

attach(a, tl: x, t: y) is indeed a special case. note though that you can force the t to go up with attach(limits(a), tl: x, t: y).

we could also go full in and have eight arguments, tl, t, tr, bl, b, br plus two smart ones whose name would again need bikeshedding.

We could also go full in and have eight arguments, tl, t, tr, bl, b, br plus two smart ones whose name would again need bikeshedding

I'd like to mention that in addition to bikeshedding the names of the "smart" attachments, we also need to figure out what happens if any of the "smart" ones is set and any of the "non-smart" ones is set at the same time. Especially, people may have different opinions with the expected behaviors e.g. when (1) "smart top" and non-smart-but-conflicting t are set or (2) "smart top" and non-smart-and-not-conflicting tl are set. All of this could compound the complexity..

I really don't want a second element. I think I'm in favor of attach(limits(a), tl: x, t: y). The situation should be relatively rare.

Sure, I'll update the PR to reflect that.


[TACHYON-1668] Tachyon UI is broken because of security checking

JIRA: https://tachyon.atlassian.net/browse/TACHYON-1668
Bug fixed. Check whether security is enabled at first. If not, which is the default conf in Tachyon, the if branch should be bypassed.
@apc999 , @yupeng9 , @sundapeng

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Tachyon-Pull-Request-Builder/8273/
Test PASSed.

Thanks for the fix. Are you interested in https://tachyon.atlassian.net/browse/TACHYON-1670, adding a Web Server test to ensure the endpoints not broken?

@yupeng9 , thanks for the review. Patch updated.
About the Web Server test, needs some investigation. A quick question is in the tests what we want is to simulate each servlet (corresponds to tabs) instance, send mock request, and verify the response. Right?

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Tachyon-Pull-Request-Builder/8277/
Test PASSed.

Yes, the web server test is beyond the scope of this PR. What you described is correct: launch the server, mock an HTTP request, and verify the response type.

LGTM

Both two tabs are viewable now---see snapshots attached.

+1 LGTM!
Thanks for the patch!


Drop ping log message severity

Description
Reduce the Ping() log message from INFO level to DEBUG level.
This means we can run the Dobby daemon at INFO level in VBN builds without spamming the log with Ping() messages. Ping() messages can still be seen when running with debug level logging
Test Procedure
Run DobbyDaemon with INFO level logging and observe the Ping() messages are no longer present.
Run DobbyTool set-log-level debug. Observe Ping() messages.
Type of Change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] Other (doesn't fit into the above categories - e.g. documentation updates)

Requires Bitbake Recipe changes?

[ ] The base Bitbake recipe (meta-rdk-ext/recipes-containers/dobby/dobby.bb) must be modified to support the changes in this PR (beyond updating SRC_REV)

LGTM


Issue with waitKey function

When cv2.waitKey(0) is disabled, result(True/False) is showing but image is not showing,
But when cv2.waitKey(0) is enabled, result is not showing but image is showing.
See the code at:
https://github.com/Nishant2907/Godseye/blob/main/initialCode.py

This should not happen as there is no dependencies between waitKey and Compare function.

Exactly, that's what I'm thinking.

After running the code several times, I observed a few points:

when I run the code, two images pop up but result don't show in the terminal
but when I close those images, I'm getting the result in the terminal

Here you were calling the cv2.imshow() before the prediction. Call the function before showing the image.
I have pushed a pull request #5. Check that out.

@HarshitRuwali Yes, showing the result before showing the image solved this issue.
I think the issue was not related to waitKey function.
As python code executes line by line, maybe that's why the result was not showing while images were showing.
Closing this issue as we got the solution.


Update version: CorsixTH.CorsixTH version 0.67

Pull request has been created with WinGet Automation 🪟📦🤖
Microsoft Reviewers: Open in CodeFlow

@wingetbot waivers Add Validation-Executable-Error


Excluding drives with unknown capacity in Zone listing

Coverage increased (+0.003%) to 92.384% when pulling 59e98fc888cc416a55a49bbc1dfc1a226cf59e2f on manali-deshmukh:vcf-bug-fix into 7a1ba41377db827be1f13ac76ce13756c09ff549 on HewlettPackard:master.


Should Clap support environment variables?

In some similar libraries, one can specify environment variables from which the value of some command-line arguments can be read if those arguments are not specified (or in addition?).
This seems rather straightforward to implement and could thus be useful.

I think it would be a good idea. I believe it is better when the CLI library supports this since it is easier to maintain the documentation for the user.
However, I wonder what should be the semantics on some corner cases such as:
If with clap I use Clap.flag declaring two CLI flags --set-foo and --no-set-foo. Clap allows the application to be run with ./app --set-foo --no-set-foo and the latter has the priority. With environment variables, we could have something like: NO_SET_FOO=true ./app --set-foo or SET_FOO=true NO_SET_FOO=true ./app.
In that case, what semantics would be the best for the user? I suppose we always want the CLI to have the priority over environment variables, but for the second example I don't think we can rely on the environment variables to be ordered. An easy solution is to say it is unspecified and since it is a corner case I don't think it matters much.

For flags I think we don't want to have 2 variables SET_FOO and NO_SET_FOO, but only one, e.g. FOO, that would contain true or false. (We may want to support yes and no, and 1 and 0 as well… I'm not sure.)


Add  to the allowlist

Dear Team,
We've made some exciting improvements to our shopping app. Now, we have integrated RTL language support into our designs to make our app more accessible and user-friendly for right-to-left languages. To achieve this, we've found a plugin that effortlessly converts the layout from right to left while maintaining the text format.   This will be a huge boost to our productivity!
Please find the below link.
https://www.figma.com/community/plugin/1081525609675954053/Just-RTL
Could please whitelist the above plugin?
Thank you.

That's ok for me, thanks @bavaajith!


Page with list of online games we play at MeiliSearch

To help other companies looking for fun games to play while remote.

So far, we tried

http://ww25.scribbl.io
https://www.innersloth.com/gameAmongUs.php
http://pink-cell.com/codenames (French only)
https://garticphone.com


Update SeqLSTM.lua [changed = to == in comparison]

Fixed typo with comparisons.

@willfrey Thank you!

@nicholas-leonard No problem! Happy to be able to contribute back even if it's just catching typos for now.


https://crazytime.app/  I want to make a site like this. Can you develop the same site?

https://crazytime.app/  I want to make a site like this. Can you develop the same site?
Originally posted by @IsSorkar in https://github.com/moul/assh/issues/687

Hi @IsSorkar, thanks for your interest in Cloudflare products! For usage questions, please use the Discussions tab or join our Discord server. I'll go ahead and convert this to a discussion. Thank you!


[SPARK-25387][SQL] Fix for NPE caused by bad CSV input

What changes were proposed in this pull request?
The PR fixes NPE in UnivocityParser caused by malformed CSV input. In some cases, uniVocity parser can return null for bad input. In the PR, I propose to check result of parsing and not propagate NPE to upper layers.
How was this patch tested?
I added a test which reproduce the issue and tested by CSVSuite.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Test build #95848 has started for PR 22374 at commit c9ccbee.

Test build #95848 has finished for PR 22374 at commit c9ccbee.

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

Merged build finished. Test PASSed.

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

This line below possibly returns null?
https://github.com/apache/spark/blob/77c996403d5c761f0dfea64c5b1cb7480ba1d3ac/sql/core/src/main/scala/org/apache/spark/sql/DataFrameReader.scala#L510

Test build #95904 has started for PR 22374 at commit bd4ebe4.

ok, thanks for the check!

Test build #95904 has finished for PR 22374 at commit bd4ebe4.

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

Merged build finished. Test PASSed.

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

Test build #95939 has started for PR 22374 at commit 2a0dac4.

Test build #95939 has finished for PR 22374 at commit 2a0dac4.

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

Merged build finished. Test PASSed.

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

thanks, merging to master/2.4!


Optimize WebP images

Using https://squoosh.app/ with default WebP settings
Images are 9 to 21% lighter

@tannerdolby I didn't optimize all images because it looks like default MozJPEG settings for JPEG images in Squoosh increases the weight of your JPEG images.
I think it should be possible to enhance this with better settings.
This might be why Lighthouse reports a possible optimization. I don't know how they compute this.

@nhoizey Thank you for optimizing those images. After merging this PR and running a Lighthouse audit on the live site, the weight is a bit smaller on the home page (900KB - 1000KB). I will look into possible enhancements. For now I'm happy 👍

Great, happy to help!


feat: allow solve_by_elim to use projections of hypotheses

This powers up solve_by_elim by allowing it to use projections of hypotheses. It does so by saturating the context with let-bindings for projections (recursively).
For interactive use of solve_by_elim, this is on by default, but not on by default for non-interactive use. There is a flag solve_by_elim (config := {letProjs := false}) to disable it.
As a simple example, this allows
example (x : P ∧ Q) : P := by
  solve_by_elim

which  previously would fail.
It also powers up exact? (example from Mathlib):
example (p : ℕ) [Fact p.Prime] : 1 < p := by exact? says exact Nat.Prime.one_lt Fact.out

[ ] depends on #582
[ ] depends on #548

I will check this against Mathlib.

apply_rules should probably turn this off, as it is non-terminal.

apply_rules should probably turn this off, as it is non-terminal.

Done.

I will check this against Mathlib.

Mathlib reveals a nasty problem, which is that somehow we are now generating proofs with additional, unused, universe variables in them!

Checking what this does to Mathlib in https://github.com/leanprover-community/mathlib4/pull/10266.


ACR Updates for Parity with Storage

Fixes https://github.com/Azure/azure-sdk-for-net/issues/34722

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.Containers.ContainerRegistry

Closing in favor of https://github.com/Azure/azure-sdk-for-net/pull/34940


[Bug]: Built-in database in the datasource still belongs to the previous project when unbind a project

ODC version
4.2.3
OB version
any
What happened?
I create a data source and bind a project. Then I manually add the built-in database oceanbase to the project. Now I unbind the datasource to the project, but the oceanbase database is still bound to the previous project.
What did you expect to happen?
The interal database should unbind the previous project.
How can we reproduce it (as minimally and precisely as possible)?
(see above)
Anything else we need to know?
No response
Cloud
No response

pass


Basic Scryfall Search

Implemented the command "!scryfall" that accesses the Scryfall API to get its images.
Fixes #1246
Fixes #1132
Fixes #682
Known issue: cannot currently look up cards such as Séance or Lim-Dûl's Vault.

There was a dead simple merge issue here (single quotes is our standard on strings and I brought some of the strings in command.py up to date while the branch was being worked on). I've fixed it.
We definitely can't merge while diacritical marks cause search errors, though :)

Now with 100% more đïàcřïtïçs. Lim-Dûl rejoice!
I just discovered that there might be a more elegant way to handle flip and meld. Functionality is there, but another revision might improve code quality.


set_output with timecodes is broken

I generated a timecode file with vspipe on the very same clip I'm trying to output.
vspreview.set_output(clip, timecodes="timecodes_1.txt")
I get the following error (timecodes_1.txt):
FramesLengthError: (set_timecodes) timecodes file length mismatch with clip's length! (timecodes=158, clip=159)
Weirdly, manually adding one line to the timecodes file reports one less frame. (timecodes_2.txt)
FramesLengthError: (set_timecodes) timecodes file length mismatch with clip's length! (timecodes=157, clip=159)
Adding one more line jumps to 160 frames. (timecodes_3.txt)
FramesLengthError: (set_timecodes) timecodes file length mismatch with clip's length! (timecodes=160, clip=159)

Switching to the vstools implementation fixed it on my end, can't reproduce it.
Please reopen the issue if it's not fixed in your setup.


[HOLD for payment 2024-02-20] [$500] LHN - User navigated on the workspace overview page when created workspace

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

Version Number: 1.4.36-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4281765&group_by=cases:section_id&group_id=306202&group_order=asc
Email or phone of affected tester (no customers<EMAIL_ADDRESS>Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
Action Performed:
Precondition: user should be Signed In

Open app
Tap on "Expensify" icon on top left corner
Tap on plus button

Expected Result:
User should be navigated on workspace settings page
Actual Result:
User navigated on the workspace overview page
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Native
[ ] Android: mWeb Chrome
[x] iOS: IPAD
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/3c344a16-5eca-4c41-9c8f-4dd60d707d4c
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~018f365ee4965dd88d
Upwork Job ID:<PHONE_NUMBER>143000576
Last Price Increase: 2024-02-05

We got couple of these iPad specific bugs cc @adamgrzybowski

SWM is looking into these

This issue is fixed by another PR. Could you help to confirm this issue is resolved then we can close this one

Lets consolidate payments on this issue https://github.com/Expensify/App/issues/35752


nixos/netdata: add config option for disabling analytics

Add services.netdata.enableAnalyticsReporting (default true), an option that sets a DO_NOT_TRACK environment variable to inform Netdata that it should not send usage statistics.
Motivation for this change
Netdata sends usage statistics to Google Analytics by default. There is an opt out mechanism that requires either placing a file called .opt-out-from-anonymous-statistics in Netdata's config directory, or setting the DO_NOT_TRACK environment variable; the latter seemed like the easier solution.
There is no way to opt out via the config file, so this necessitates a new option. The option defaults to true for consistency with upstream.
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

I checked if the systemd unit is configured with the environment variable properly, but did not try to verify whether or not Netdata actually sends or doesn't send analytics according to it.

merge. anyone? :)

merge. anyone? :)

As a note, Netdata is now switching from Google Analytics to a self-hosted solution. This seems to apply to versions 1.29.4 and up. The current version in nixpkgs master is 1.29.3, so it would still send to Google Analytics as far as I can tell, but I'll make note of it in the option description.

@ofborg test netdata

Sorry for the thousands of roundtrips!


Fix: nextest cleanup race condition

fixes #2123 #[sqlx::test] should play nicely with nextest
Nextest provides a NEXTEST_RUN_ID that we can use to clear up tests belonging to the same cargo invocation.
See for a more general fix for cargo test runners.
Currently I haven't implemented support for mysql and sqlite, I'm looking for feedback before going ahead and doing that.

@bonega another thought is, instead of generating an arbitrary database name, we could generate one based on the path of the test function that's running. If the database name is always the same, then there's no real extra cleanup step necessary besides dropping and recreating the database before running the test and dropping it afterward. And it would make it a lot easier to find and inspect the database in question.
I would honestly make it always clean up the test database afterward unless an environment variable is set; the existing behavior seems to just confuse and annoy people more than anything. Bikeshedding: SQLX_TEST_KEEP_DB?
Do you know of any test runners that execute the same function multiple times concurrently? I think we could even handle that by holding a lock on the row in the test-databases table as a mutex. Arguably though, that table wouldn't even need to exist.
I think the main reason I didn't just do this originally was because I didn't want to have to think of a way to convert a path to a database name. However, as it turns out, MySQL and Postgres both allow (quoted) database names to contain any character besides NUL (\0) so we don't really have to come up with any special mapping scheme; we could just use the fully qualified path of the text function itself.
The biggest potential issue is that both databases have a length limit of 64 and 63 characters, respectively, so we'd have to either abbreviate or just truncate. I guess truncating makes the most sense. 63 characters is quite a lot for a path, it's unlikely to collide in most situations. If there is a collision, the mutual exclusion would just make the tests execute serially. And we could always make the attribute take an argument to override the database name.

Hey, just giving a heads-up that I am super busy with moving apartment, will take a closer look on this in a couple of days.

@bonega do you have time to look at my last comment?

@bonega do you have time to look at my last comment?

It is starting to wind down now, think I will have time today or tomorrow

@abonander
I think it seems to be a generally good idea.
Though I worry a bit about the truncating/locking. I have seen some very long test names before.
I will do some prototyping and see if it seems workable.

To get the module path you'll probably need to make #[sqlx::test] emit a recursive invocation of itself with module_path!() in its arguments. It's very fortunate that arguments to attributes are expanded eagerly now.

Hey, Sorry for being unresponsive.
I have checked around a little.
The test path can easily get long since it also includes the modules.
Also I don't want to impose naming requirements on the end-users.
By doing a truncate and lock I fear that we might regress the performance for some of the current users.

@bonega we could instead hash the path. A SHA-256 hash is incredibly unlikely to collide and can be encoded in 64 hex characters, so in Base64 (with dash and underscore) would be more like... 40?
I think deterministic naming is the right answer here, because then each test function can be wholly responsible for its own database and doesn't need any sort of memoization.

@abonander Hey, I am getting back into shape now.
Is this in the direction of what you wanted?
I think we will be able to remove the test database also.
Will do some more refactoring if it looks.

@abonander  I still can't run the tests locally but I see that this is passing in CI.
Mysql is finished and from what I can see sqlite already does a database per test path.

@s373r Thank you.
I imported what I think was the gist of your changes.

@abonander , could you please merge the PR?

@abonander how could we help getting this PR merged?


installation: setuptools fix

Adds compatibility with setuptools 18.4.

Fixes some PEP257 errors.

Signed-off-by: Lars Holm Nielsen<EMAIL_ADDRESS>

:shipit:


Disable outputing bug traces in infer bug report

Hi,
I am wondering is it possible (a command flag or something) to disable outputting bug traces, such as those shown in the screenshot below, in infer bug report?

Thanks!

There is no such option at the moment. Can you say more about why you'd want to do this? You can post-process the json to get rid of them (for example using jq) but these bug traces are generally needed to understand infer reports.

Currently Sarif Viewer extension has some incompatibility with SARIF files with bug traces. We have to disable it to unblock us from deploying InferSharp on some platforms. I have created this PR to disable outputting bug traces in SARIF files through a -no-sarif-codeflows flag.

PR has been closed, issue seems resolved.


Add support for Xiaomi Curtain Driver E1

Device model
lumi.curtain.agl001
Device name
Xiaomi Curtain Driver E1
Does the device require a MiCloud connection?
Do not know
Anything special about the device?
The Xiaomi E1 looks like the Aqara Zigbee curtain driver but is BLE only

Is this is a Zigbee or BLE device?

Its a BLE Mesh device (like most of the newer Xiaomi / Mija devices)

Did you try to already add it to the plugin? Did it work? (please note that BLE mesh devices require a Gateway/Hub so you need to specify the Gateway ip and the deviceid and model of your device.)

The curtain driver is connected with a Xiaomi Gateway (in Mija app it works flawless, but has no homekit integration).
I have connected the gateway with the plugin with ip, token and id - it recognizes the gateway perfectly and i can see in the homebridge logs that it sees a new unrecognized device (the curtain driver).
The plugin adds a button for the curtain in homebridge but it has no function.
Already checked the motor controll checkbox with curtain specific settings, not working

The device should already be detected as a curtain device, so it seems for that you specifying something wrong.
The ip and token needs to be the one from your Hub, the model and deviceid needs to be from your curtain device. Did you specify it like that?

Seems my device model code was wrong -  the curtain device is sold in China only, so information rare.
Here is the update.
Device Model: MJSGCLBL01LM (can‘t find information about the unique model code on the net)
Device Name: Xiaomi Mija Curtain Companion
Gateway is a lumi.gateway.mgl03 > curtain device
The plugin connects the gateway, but doesn‘t recognize the curtain device

No this is wrong! lumi.gateway.mgl03 is your gateway model! You should specify your curtain model and deviceid.
It should look as follows:

ip -> gateway ip
token -> gateway token
deviceid -> curtain device id
model -> curtain model

Then it should work. The curtain also needs to be paired with your gateway. As your curtain device is a BLE mesh device, direct connection is not possible, so it has to go over the gateway.

Marcin, thanks for coming back, but i think we are talking cross purpose.
The ble device is paired with the gateway in the Xiaomi/Mija app and fully working.
The gateway is fully loaded in miot plugin, but the curtain device is not recognized here.

ip ->  yep, recognized & loaded miot plugin with „Discover all devices via Micloud“

Token -> gateway token - yep, this one is recognized & loaded by miot plugin „Discover all devices via Micloud“

deviceid -> my curtain device is not supported by the plugin, so no deviceid is loaded/shown here. Unfortunately i can‘t even find a device id on the internet with the model number MJSGCLBL01LM

model -> curtain model no. is MJSGCLBL01LM

Again, the data what you enter are wrong! The plugin tries to control your gateway because you entered wrong data.
MJSGCLBL01LM is not the model, I guess lumi.curtain.agl001 is the model as you provided in the first post.
And the deviceid you need to manually enter as the "Discover all devices via Micloud" will enter the gateway deviceid which is incorrect.
To control your device you need to manually adjust the settings in the config.json for your device!

Thanks , found a solution with your Link: https://github.com/merdok/homebridge-miot/discussions/348
Mixing the gateway's ip with gateway's token and curtain device's id and curtains device's model was the solution to connect the BLE curtain driver.

Yeah, so this is what i was talking about from the beginning.
So does the device already work?

lumi.curtain.hmcn02 works even it is recognized as unknown device - so lets close

thanks for the info, full support will be added in the next update.


[WIP] Bump versions of the console and HA admin gem

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1544854
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1418080
https://www.pivotaltracker.com/story/show/135779733
https://www.pivotaltracker.com/story/show/141523501
https://www.pivotaltracker.com/story/show/121849185
@NickLaMuro @jvlcek I tried to find other tracker urls that this may fix. Let me know if there are more that I should add here.
I'm pretty sure I missed some from @NickLaMuro

@carbonin From me:

https://bugzilla.redhat.com/show_bug.cgi?id=1535345 (allow taking DB backups and dumps from console)
https://bugzilla.redhat.com/show_bug.cgi?id=1586186 (allow table exclusions in dumps)

@NickLaMuro Will those be finished after this (i.e. should I put Fixes <bz> in the commit or is there still work to be done?

@carbonin yes, or I would not have sent them to you 😉
The ones you SHOULD NOT ADD and are still very much in development are:

https://bugzilla.redhat.com/show_bug.cgi?id=1586176 (file splitting dumps/backups)
https://bugzilla.redhat.com/show_bug.cgi?id=1586187 (FTP support for dumps/backups)

Setting WIP until we get the repmgr v4 rpm built for the upstream ManageIQ copr build.
Will need sign-off from @simaishi as well for the downstream packaging.

Adding the content of https://github.com/ManageIQ/manageiq-appliance/pull/197 to this PR as well.

@carbonin LGTMl You already have  the one I was working on listed.
https://www.pivotaltracker.com/story/show/121849185

repmgr 4.0.6 rpm is built so this should be good to merge @gtanzillo
ref: https://copr.fedorainfracloud.org/coprs/manageiq/ManageIQ-Master/packages/


[FLOC-3188] Make remote_logs.log JSON

Fixes https://clusterhq.atlassian.net/browse/FLOC-3188

I think this also fixes https://clusterhq.atlassian.net/browse/FLOC-2097
I guess ideally this should be a thing that's in eliot, since extracting mangled logs from systemd is a general problem. However, happy to start with this.

Thanks for doing this. I've wanted to do this pretty much since I started at ClusterHQ (but fell over at the first hurdle).
I've made one optional suggestion. Feel free to merge without further review whether or not you do it.


Question - usage with remark-gfm

Hi, thanks for the great project.
I use remark-gfm to display markdown (via react-markdown) already, and I'm looking into importing the GFM to lexical now. The first thing I noticed was that I need to add a Handler for strikethrough, which looks to be pretty straightforward, but I thought it was worth asking if there's an existing lexical-remark-gfm thing already. If not, I guess the path is to write a handler for each one of the parts?
Thanks!

Actually, looks like strikethrough is the only part of GFM that I need. Hm, I'm not sure how to apply the Handler approach to it yet though. I don't see an obvious analog to Emphasis
https://github.com/syntax-tree/mdast-util-gfm-strikethrough
https://github.com/micromark/micromark-extension-gfm-strikethrough

I tried this, but it didn't have an effect.
import { Delete } from "mdast";
import { Handler } from "lexical-remark";

export const strikethrough: Handler<Delete> = (node, parser) => {
  parser.formatting.push("strikethrough");
  node.children.forEach((child) => {
    parser.parse(child);
  });
  parser.formatting.pop();
};

...
          $convertFromMarkdownViaRemark(md, {
            handlers: {
              strikethrough,
            },
          });

I noticed that handlers is not actually hooked up to anything:
export function remarkLexify(handlers = {}) {
    const compiler = (tree) => {
        const parser = new Parser();
        return parser.parse(tree).getChildren();
    };
    Object.assign(this, { Compiler: compiler });
}
export function $convertFromMarkdownViaRemark(markdownString, options) {
    const root = lexical.$getRoot();
    root.clear();
    const file = unified()
        .use(remarkParse)
        .use(remarkYoutube)
        .use(remarkAttachment, { prefix: options?.attachmentPrefix ?? '' })
        .use(remarkLexify, options?.handlers)
        .processSync(markdownString);
    root.append(...file.result);
}


Is it possible to create Administor groups in hygieia dashboard.

Hi,
As per now who ever created the dashboard that only person has full rights his dashboard other users only view the dashboard.
We need one user that have all privileges means read/write of all user dashboard's like a admin.
Is it possible to create admin group under all the user have admin rights??
Regards,
Vetrivelan T

Nope. Perhaps #1031 will address that.
@rob-miller-777

Correct @MarkRx, we will be making admin a "role", so you can have multiple admin accounts.  We do not intend on adding functionality to add new admins with #1031 however, we felt that was beyond the scope of the pull request.  We just wanted to get it back to the current state with backend security.  We did lay the groundwork to make it possible though.

@vetrivelan25 Not at this time.