Set Default Proof Mode is ignored in 8.20

I am working in a project that uses a mixture of ltac1 and ltac2 tactics, with ltac1 wrappers for the latter. Because of this, we often use Set Default Proof Mode "Classic". at the top of files and use the ltac1 tactics and wrappers, which worked fine so far on 8.18 and the latest version of the plugin. However, since upgrading to 8.20 (and not touching the plugin version), it seems that this plugin ignores that line, breaking all the scripts, while coqide handles it as usual. Here is a simple example to demonstrate the problem:
From Ltac2 Require Import Ltac2 Message.

Ltac2 test () := print (of_string "test").
Ltac test := ltac2:(test ()).

Set Default Proof Mode "Classic".
Test Default Proof Mode.

Goal True.
Proof.
  test.
  split.
Qed.

Running this in vim with the plugin gives Default Proof Mode: Some(val='Ltac2') for line 7, immediately showing that the setting didn't persist, but continuing further, I get This expression should have type unit but has type unit -> unit. [not-unit,ltac2,default] for line 11, so it indeed doesn't work. Running the same script in coqide, line 7 gives Current value of Default Proof Mode is "Classic", and line 11 gives the expected test. Piping the script to coqtop gives the same result as coqide, so the issue is not there.
While the usual workarounds, such as starting the proof with Proof Mode "Classic"., or using ltac1:(test). or test (). work, it would be nice to have this issue fixed, so I don't need special scripts compared to the rest of the team.

Interesting, this seems to be specific to Default Proof Mode because other options that take a string argument work fine on 8.18-8.20:
Test Mangle Names Prefix. (* Mangle Names Prefix: Some(val='_') *)
Set Mangle Names Prefix "a".
Test Mangle Names Prefix. (* Mangle Names Prefix: Some(val='a') *)

Test Loose Hint Behavior. (* Loose Hint Behavior: Some(val='Lax') *)
Set Loose Hint Behavior "Warn".
Test Loose Hint Behavior. (* Loose Hint Behavior: Some(val='Warn') *)

I don't have any ideas as to what's going wrong and the debug logs aren't revealing anything useful, so I'm trying to track down when exactly it broke using git bisect. From what I've seen so far, it stopped working somewhere between 8.18+alpha and 8.18.0.

This is the commit where it stopped working. It seems to have something to do with a change to how and when certain vernacular statements get executed. I'll have to dig into this more, but I probably won't be able to get to it until January.
Possibly related: #345.


feat(crypto): Identity Proofs

This PR introduces two new main crates:

identity_crypto

The place for all cryptographic utilities. Common traits, types, etc.
All other identity_* crates should rely on this crate for their crypto needs (prefer common traits over any concrete implementations)

identity_ldp

An implementation of Linked Data Proofs and various types/traits to implementation signature suites
Missing a few canonicalization algorithms but still usable with canonical JSON

Concrete implementations of various behaviours can be implemented as needed (several LD signature suites will follow in a subsequent PR) and identity_crypto types and traits can be used immediately in definitions.
Supported proofs will likely extend beyond the scope of Linked Data Proofs; the identity_crypto::Proof trait is intended to reflect this.

Notes on LD Proofs

The LD Proofs standard is still changing at a fairly frequent pace and no concrete version has been released yet.
Some examples of unclear/inconsistent behaviour in the current standard:

input options expected by various signature suites are not clearly defined
properties in LD proof JSON object are not clearly defined/implemented
reference implementations using incorrect jws alg param (eg. RsaSignature2018)

Cryptographic Suite Registry and Security Vocabulary are used to determine requirements/structure.
Security Vocabulary v3 (unstable)
Most registered suites are "provisional" but several settled on a JWS signatured-based proof structure - JWS is NOT the only way going forward and future JWS LD proofs will most likely all use JwsSignature2020.

The JWS stuff was an experiment to see if we could unify the JOSE community and the Linked Data Security community. The attempt has failed for this cryptosuite, but the work is being carried on in JwsSignature2020... so we'd like to push all JOSE stuff to that cryptography suite and keep the Ed25519 stuff simpler and more auditable.

So there will be requirements to support JWS and non-JWS versions of the same cryptographic functions. Not too big of a deal as the SignatureSuite trait in this PR is flexible enough to support a variety of signature suite algorithms.
~Note: A few things are missing to fully support legacy signature suites~

~proofValue should be one of jws, proofValue, or signatureValue. Signature suites need more control here~
~Additional proof properties should be supported and "flattened" in the JSON representation. Trivial with identity_common::Object~

A high-level example of how this might be used with the SignatureProof wrapper and an implementation of Ed25519Signature2018.
// signer

let credential = ...
let seckey = ...

let klass = SignatureProof::new(Ed25519Signature2018);
// OR
let klass = SignatureProof::with_options(Ed25519Signature2018, my_options);

let proof = klass.create_proof(credential, seckey);
let json = serde_json::to_string(json);

// verifier

let credential ...
let pubkey = ...

let suite = ProofManager::get(credenital.proof["type"]);
let klass = SignatureProof::new(suite);
let valid = klass.verify(credential, credential.proof, pubkey);

Notes on cryptography libraries

Ursa

Lots of useful functionality that could be used to build our own suites or for other use-cases besides LD Proofs. Only provides cryptographic support for 3 of the existing signature suites
Fairly large dependency chain and some versions outright failed to compile with stable rust
Functionality is heavily aimed towards supporting Hyperledger projects (eg. Indy)

Overall ursa is nice and easy to use but probably not worth the dependencies

Rust Crypto

Lots of great functionality in pure Rust
Missing some more exotic algorithms but provides solid building blocks

JSON Web Tokens
The state of JSON web tokens in Rust is not great...
rust-jwt - Missing ES256K and more
biscuit - Missing ES256K and more; based on rust-jwt
jsonwebtoken - Missing ES256K and more
josekit - Incredibly new, openssl-based, and supports all algorithms currently needed
There are many more implementations, but these seemed to be the most complete/supported. I personally thought josekit looked like the most promising option.

Update
Spent some time getting familiar with ring - it's pretty nice and I suspect it would cover most needs alongside Rust Crypto.
jsonwebtoken was missing support for a few minor things (the crit header param, signing non-str values) but already have open PRs; also nice that it also uses ring. Unfortunately it's missing three of the algorithms needed for some of the older jws signature suites - without modifications it would only provide support for RsaSignature2018. ES256K is missing due to lacking support for secp256k1 in ring so that's probably a bit more involving.
~jsonwebtoken and only RsaSignature2018 should be sufficient for now..~

Regarding potential cryptography libraries; when I was building stronghold, I found sodiumoxide to be pretty solid.  Uses the lib-sodium C library as its core.  rust-crypto is also pretty battle tested, but again not sure if it contains all of the algorithms we will need.  Another would be ring which is the most widely used rust crypto lib to my knowledge.  I've heard decent things about josekit but as you pointed out its pretty naive and immature right now.

I found sodiumoxide to be pretty solid

Thanks, will check it out - nice to see it supports no_std.

rust-crypto is also pretty battle tested

Forgot to add a note on this but we'll definitely use it for building blocks and hopefully more

Another would be ring

Cool, I'll check this out today 👍

@tensor-programming This is ready for review now - Signatures are in another PR (https://github.com/iotaledger/identity.rs/pull/35) but that's still a draft. Ended up using ring and sodiumoxide instead of a JWT library

Alright, will look at it tomorrow.

Fixed the merge conflicts for you.


usePickerWithSelectedValues doesn't refresh validation when source table changes

Description
The usePickerWithSelectedValues hook updates validation checks as the user types, but it doesn't update if / when the source table changes.
Supports DH-15572
Steps to reproduce
An easy place to see this is in the ACL Editor in Enterprise

ACL Editor → Users tab
In the users table, click on “add users to group” action icon
Type in a group name that doesn’t exists (e.g. “aaa”). Should see “Add” button enable.
Click add.
Type the group name again in the search box. Should see validation error “User is already assigned to this group”
Click the trash icon in the bottom list to remove user from the group
After a short delay, validation incorrectly updates to “This group name cannot be created since it matches an existing user name”. The component is unaware that the group has been deleted on the server

Expected results
Validation error should clear after group has been deleted and table updated.
Actual results
Validation error “This group name cannot be created since it matches an existing user name” is shown
Versions
Version 1.20230512.086beta (868b868f)
Web Client (e68173a2)

Edge case, unlikely to run into, moving to Backlog.


Could not load the token provider for AccountProvider GitHub

activating extension ms-vsonline.vsonline failed. Seems to only happen in extension development host?

I'm currently not able to reproduce this, let me know if you still see this and I will reopen.


Bucket sort and Radix sort

Hey,
Bucket sort is not included . I would like to include it too.
Also according to issue #36 radix sort is still not there, I would like to add that too.

Can I contribute to this? This would be first open source contribution and it would be great if you could tell me how to go about it.

BucketSort is already contributed by me with PR #64 . You may work on Radix sort.

Okay, I will do the Radix Sort.

I have submitted a pull request named "Created Radix Sort" with the Radix Sort code. Please review it.

@faheel  is the owner of this repository. He will review and merge it @Rajiv2605 .
:)

@faheel  is the owner of this repository, So only he can review and merge it @Rajiv2605 :)

Closing being unappropriated.


Reverse Proxy not working

Hi,
I've setup the reverse proxy on nginx as suggested in the docs and I end up with page loaded but the spinning wheel in the left corner is loading and loading. After few minutes it turns to X with error: Server disconnected 1006.
Can you please check if it works? Or provide more detailed config?
Here is my proxy config:
host (synology nas): <IP_ADDRESS>
mapped port: 6800
proxy port: 5880 (I redirect to this port in rev proxy setup)
map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
}

upstream docker-filezilla {
        # If the reverse proxy server is not running on the same machine as the
        # Docker container, use the IP of the Docker host here.
        # Make sure to adjust the port according to how port 5800 of the
        # container has been mapped on the host.
        server <IP_ADDRESS>:6800;
}

server {
        listen 5880;

        server_name filezilla.home;

        location / {
                proxy_pass http://docker-filezilla;
        }

        location /websockify {
                proxy_pass http://docker-filezilla;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection $connection_upgrade;
                proxy_read_timeout 86400;
        }
}

Thank you!
Kris

Closing this issue.  Please re-open if needed.


Modified getStackData function to also work with partial data

I just created a PR so we can further discuss the code. I am not sure if I misunderstand something, but the tests fail while the changes render the example stacked charts nicely. It also works well with a bunch of data on my project (gives the result I have shown in the Issue).
I am not sure if there is a difference between VerticalBarSeries and HorizontalBarSeries regarding the stackBy value, but from my understanding setting stackBy='y' on HorizontalBarSeries doesn't make much sense, thus the following test code will not work correctly:
 let children = [
    (<HorizontalBarSeries
      data={yData[0]}
    />),
    (<HorizontalBarSeries
      data={yData[1]}/>),
    (<div> i think i will by that lamp </div>)
  ];
  let results = getStackedData(children, 'y');
  let expectedResults = [[
    {x: 10, y: 2},
    {x: 5, y: 4},
    {x: 15, y: 5}
  ], [
    {x: 12, y: 4, y0: 2},
    {x: 2, y: 8, y0: 4},
    {x: 11, y: 10, y0: 5}
  ], undefined];

It is also weird how the HorizontalBarSeries is imported.
import HorizontalBarSeries from 'plot/series/vertical-rect-series';

As nothing is rendered and basically HorizontalBarSeries is used just as a plain object, we can ignore that. Still, to me it seems that the tests are wrong, and the above test should instead be:
   let children = [
    (<HorizontalBarSeries
      data={xData[0]}
    />),
    (<HorizontalBarSeries
      data={xData[1]}/>),
    (<div> i think i will by that lamp </div>)
  ];
  let results = getStackedData(children, 'y');
  let expectedResults = [[
   {x: 2, y: 10},
   {x: 4, y: 5},
   {x: 5, y: 15}
  ], [
   {x: 2, y: 22, y0: 10},
   {x: 4, y: 7, y0: 5},
   {x: 5, y: 26, y0: 15}
  ], undefined];

This applies to all the tests for getStackedData. It is possible that I haven't understood the use case well, so I will be waiting for any of the maintainers' discussion.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Radevski, Stevche a | Steve | ECBD seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

After looking at the tests I realized that they were in fact wrong based on the definition of what stackedBy means as written in the documentation. More specifically,
stackBy (optional)
Type: string
Stack the chart by the given attribute. If the attribute is y, the chart is stacked vertically; if the attribute is x then it's stacked horizontally.
Let's take an example from before and analyze it.
 const yData = [
    [
      {y: 2, x: 10},
      {y: 4, x: 5},
      {y: 5, x: 15}
    ],
    [
      {y: 2, x: 12},
      {y: 4, x: 2},
      {y: 5, x: 11}
    ]
  ];

  let children = [
    (<HorizontalBarSeries
      data={yData[0]}
    />),
    (<HorizontalBarSeries
      data={yData[1]}/>),
    (<div> i think i will by that lamp </div>)
  ];
  let results = getStackedData(children, 'y');
  let expectedResults = [[
    {x: 10, y: 2},
    {x: 5, y: 4},
    {x: 15, y: 5}
  ], [
    {x: 12, y: 4, y0: 2},
    {x: 2, y: 8, y0: 4},
    {x: 11, y: 10, y0: 5}
  ], undefined];
  t.deepEqual(results, expectedResults, 'should find the correct results for stacking by y');

Stacking by y-axis means the segments are stacked vertically. Since all of the x values are different, there should be no stacking happening. What the expected result should be is
let expectedResults = [[
    {x: 10, y: 2},
    {x: 5, y: 4},
    {x: 15, y: 5}
  ], [
    {x: 12, y: 2},
    {x: 2, y: 4},
    {x: 11, y: 5}
  ], undefined];

Although I know it is not the best of ideas to change a "working" tests, since the tests were wrong in the first place they didn't test anything, at least not correctly.


CodeArea.getStyleSpans(from, to).append(...) does not append

Hi Tomas,
I'm getting an issue with using the above method like so:
StyleSpans<Collection<String>> styleSpans = codeArea.getStyleSpans(startIndex, startIndex + text.length());

StyleSpansBuilder<Collection<String>> spansBuilder = new StyleSpansBuilder<>();
spansBuilder.add(Collections.singleton("class1"), text.length());
spansBuilder.add(Collections.singleton("class2"), text.length());

spansBuilder.create().forEach(styleSpans::append);

After this code executes, styleSpans still has a length of 0. If it was unmodifiable I'd assume it would've thrown an exception, but I believe that is not the case.
Is there anything I'm doing wrong?
Thank you.

Hi, StyleSpans is indeed unmodifiable. append returns a new instance. The original one remains intact.
Anyway, if styleSpans has length 0, that would mean that text.length() is 0.

Closing this as this is not an issue.


Sample for Cash Drawer which is connected to a supported POS Printer

I current need to open the cash drawer which is connected to an Epson TM-T88V.
According to the following link
https://msdn.microsoft.com/en-us/library/windows/apps/mt426650.aspx
in the Remarks section, it says:

Additionally, cash drawers that don’t have network or Bluetooth capabilities can be connected via the DK port on a supported POS printer

So I guess I may be able to use PointOfService API.
Do you have a sample using PointOfService API, and will it work on Windows Phone or other device family?

There is a CashDrawer sample.

Thank you @oldnewthing , but your sample doesn't work.
I mean I tapped "Initialize Drawer" I got an error saying "Cash drawer not fund. Please connect a cash drawer." Apparently, this sample is not for the cash drawer I have.
Like I said earlier, my cash drawer is connected to an Epson TM-T88V printer.
The Sample code I got works fine. It is using Epson SDK.
The code is actually sending a pulse command to the printer, and the printer opens the cash drawer.
I was wondering, do you have a sample using your PointOfService API which can open this type of cash drawer (connected to a printer)?

I guess I didn't understand your original question. Your original question appeared to be "Is there a PointOfService API for cash drawer?" and the answer is "Check the CashDrawer sample for an example."
Your new question appears to be "The sample doesn't work for my cash drawer." It's not immediately clear to me whether this is a problem with the cash drawer or with the sample, but this is not my area of expertise either. I'll ask the CashDrawer people if they have any ideas.

How is your TM-T88V connected?  A Network / Bluetooth TM-T88V should work.
We're working on improving the cash drawer sample, which currently makes the assumption that the cash drawer is already paired with the system.  (You should be able to set up a pairing manually from the "Settings" App, "Devices" category, "Connected devices" tab.)  The sample will be updated to use DeviceWatcher with CashDrawer.GetDeviceSelector() to discover cash drawers on the network + Bluetooth.
If you're writing an app right now, do consider using DeviceWatcher to find the cash drawer + using CashDrawer.FromIdAsync() to open it.

Thanks @oldnewthing and @mchen-msft
The printer is connected via network connection, whilst the cash drawer is connected to the printer through something like a phone jack.
Anyway, I'll give the DeviceWatcher a go.


Resolve SSR bundle failed errors during gatsby build

We are getting the following errors during build:

This issue is said to be resolved in<EMAIL_ADDRESS>(see Gatsby issue) but we are still seeing the error in<EMAIL_ADDRESS>I have added<EMAIL_ADDRESS>as a dev dependency to rely on npm to dedupe this dependency at 7.12.1 (which fixes the issue).
To do: investigate the purported fix in<EMAIL_ADDRESS>and determine why we're still seeing the error in 2.32.7.
Note, once resolved<EMAIL_ADDRESS>is to be removed from the dev dependencies.

obsolete, closing


update is_js_ident to cover most cases

Closes #37
Added new test case for validation
Validation: cargo test

@madonoharu Can you look over this PR and see if this could be merged?

@madonoharu it'd be great if we could get this merged

@Pistonight did you find a way around this, since the PR hasn't been accepted in so long?

FYI, this will result in a lot of false negatives for what is a valid JS identifier (e.g. many, many Unicode characters are valid in JS identifiers). I took a different approach in #46 by letting the user handle quoting with a new attribute. Sorry, I didn't look hard enough at the PRs to see this one was already open before doing my work.
Hopefully one of these two PRs will be accepted soon 😄

That's what the "most cases" is about :) Quoting a false positive is better than missing one though, since it would still be functional

@Pistonight did you find a way around this, since the PR hasn't been accepted in so long?
I for one ended up creating a build script to fix the types with sed after building using wasm-pack

I essentially did the same thing


test issue

testing
Testing again

[x] foo
bar
[ x ] bar
[ ] bar
[] foo

Commenting on this issue to test


Add SFINAE-friendly version of std::common_type

It should help to improve uses of SFINAE like the one from #295 and fix #289 for MSVC 14.0 (VS2015) for good.
Copied from Boost.Hana.
Rationale
Simply, SFINAE using std::common_type turned out to be insufficient, at least it was still not working well with VS2015. The issue was revealed by matrix3x2 tests added in #293 for which VS2015 build jobs failed (e.g. https://ci.appveyor.com/project/mloskot/gil/build/job/c7xrfsikib6la83g).
Since the std::common_type is a very useful trait and it may be suitable in future cases where common type needs to be calculated, it is a good idea to have a solid SFINAE-friendly version available.
References

Refines #295 which was based on the idea from https://github.com/boostorg/gil/pull/294#issuecomment-486805343

Tasklist

[ ] Ensure all CI builds pass
[ ] Review and approve

All CI builds pass, apart form https://ci.appveyor.com/project/stefanseefeld/gil/builds/24206885 due to issues unrelated to this change:

@stefanseefeld Could you re-start the AppVeyor builds for this PR?


Add mz

mz modernizes the node.js API to current ECMAScript standards by providing promisified versions of most of node.js's methods.
This is similar to a couple of projects on the list like fs-jetpack and sander, but I think it's better because it promisifies the whole node.js API, doesn't try to change the node.js API and seems to have a lot more usage.
I'll let you decide if anything should be removed.

I think it's better to just promisify the methods yourself. It's easy enough and it works with any API, not just the core ones.

http://bluebirdjs.com/docs/api/promise.promisifyall.html
https://github.com/sindresorhus/pify


[kwokctl] set/remove current-context after cluster create/deletion

What would you like to be added?
When a user creates a cluster using kwokctl, it's better to automatically switch the current-context to the newly created one.
⇒  k ctx -c
kwok-k2

⇒  kwokctl create cluster --name k3
...
Cluster is created                                                                                cluster=k3 elapsed=1s
You can now use your cluster with:

    kubectl config use-context kwok-k3

Thanks for using kwok!

⇒  k ctx -c
kwok-k2 <- I'd expect it switches to kwok-k3 automatically

The same story applies to cluster deletion. I'd like to unset the current-context.
Why is this needed?
For better UX. When a user creates/deletes a cluster, their instinct is to use/not use that cluster right away.

/triage accepted

/good-first-issue

/assign


case-insensitive search in laravel, mongo with jenssegers/mongodb 3.0

Hey,
I need to select data that matches value in case-insensitive.
if a collection looks like the below :-
{     "_id" : "00LJVY3EBQWERTYPK59F",     "username" : "demo1" }
then i can search this user by demo1, Demo1, DEMO1` without like because, There can be a another user like below
{     "_id" : "00LJVY3EBQWERTYPK59F",     "username" : "demo12" }
and in this case it can return 2 records.
any hint or help will be appreciated.
Many Thanks.

@yashpalchhajer, use regex for this cases

Hi @Smolevich
with regex if any we search demo instead of demo1 it will return two record. but, there is no record with username demo.
It should return empty set in these type of cases;

@yashpalchhajer,
Test documents:
{"_id":"5dad5934153d15343c36ce93","user":"demo"}
{"_id":"5dad593e153d15343c36ce94","user":"demo12"}
{"_id":"5dad5946153d15343c36ce95","user":"demo1"}

Query:
db.collection.find({user: /demo$/i})

return only one document

Hey @Smolevich ,
thanks..! it's working fine.


Code Assistant in VSCode Recipe Fixes

Per #51:

Install 8b and 3b on Ollama as well as 20b
Fix the title of the Replicate connection (8b)

@fayvor do you want me to merge this?

@fayvor do you want me to merge this?

@deanwampler yes, please. I'm blocked from merging.

Done! Thanks for letting me know that one of us needs to do the merges for you.


pyrender.constants.RenderFlags.FACE_NORMALS flag while rendering images for FID calculation

Hi. Thanks for your great work!
I'm trying to compute FID score based on your codes of rendering fid images from given mesh.
Checking rendered images, I observed the rendered images looks like below.

And I found the normals are rendered because of the code below.
(Specifically, because of the flag pyrender.constants.RenderFlags.FACE_NORMALS)
https://github.com/JRyanShue/NFD/blob/main/nfd/neural_field_diffusion/metrics/render_utils.py#L183
What I want to ask is, why we need normals while computing FID scores.
Is it right to get the images as above and compute FID score with them?
Thanks

Refer to the link in below guys!
https://github.com/Zhengxinyang/SDF-StyleGAN/issues/16


Parameter description must start with phrase 'The ', 'A ' or 'An '

Each parameter description, except for unused parameters, must begin with the phrase The .
Unused parameters must be reported as Unused. Those parameters shall be ignored.

Note: out parameters shall not be insepected.

Note: Also accepted is A or An

Note: boolean parameters might also start with <see langword="true" /> or <see langword="false" />.

Enums should be excluded.

Question: Shall the phrase Specifies  be accepted?

Regarding the open question:  Shall the phrase 'Specifies' be accepted?
That phrase is not accepted.


Resolve symlinks for Dockerfiles / .ci-operator.yaml

Codecov Report

Merging #514 (4c5bd50) into master (5417e4e) will increase coverage by 30.41%.
The diff coverage is 0.00%.

@@             Coverage Diff             @@
##           master     #514       +/-   ##
===========================================
+ Coverage        0   30.41%   +30.41%
===========================================
  Files           0       41       +41
  Lines           0    10154    +10154
  Branches        0     2167     +2167
===========================================
+ Hits            0     3088     +3088
- Misses          0     6870     +6870
- Partials        0      196      +196

Impacted Files
Coverage Δ

doozerlib/cli/images_streams.py
0.00% <0.00%> (ø)

doozerlib/cli/rpms_build.py
59.39% <0.00%> (ø)

doozerlib/rpm_builder.py
72.12% <0.00%> (ø)

doozerlib/exectools.py
41.75% <0.00%> (ø)

doozerlib/source_modifications.py
65.16% <0.00%> (ø)

doozerlib/util.py
55.65% <0.00%> (ø)

doozerlib/brew.py
41.76% <0.00%> (ø)

doozerlib/assertion.py
100.00% <0.00%> (ø)

doozerlib/rhcos.py
71.42% <0.00%> (ø)

doozerlib/rpmcfg.py
54.60% <0.00%> (ø)

... and 32 more

Continue to review full report at Codecov.

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


Integrate new bidi-library dependency

I'd merge this PR without the .gitignore commit.

Thank you, merged now. I removed the two commits for .gitignore from the git history.


Refactor kinesis exporter to be aligned with Kafka Producer behaviour

Description:
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.>
Updating the kinesis exporter to aligned with the behaviour of the Kafka exporter.

This removes the third party Kinesis Producer Library and  allows for the internal exporter pipeline to allow for things like retries and better reporting of data that is unable to be sent to Kinesis.

**Link to tracking Issue:** Currently a draft, will link the issue when it is ready.

**Testing:** Unit testing has been adding throughout where code has been updated.

**Documentation:**

My git habits got in the way so I have squashed my local and pushed it up here. Have also rebased with main so I am hoping the issue with linting is resolved.


A Whale of a Tale soft lock

On stage 5 of the quest you need to have the fishing rod you get from the fisherman in kuanti.
The quest will not let you progress if you use split the 2 fishing rods from 1 spot to  2 spots.
2 on each other in 1 inventory slot = works
1 in 2 different inventory slots = doesnt works
no picture since it might spoil the quests starting location

You also need 10 Dive Balls, did you, or the player, have those?

yes

So if the rods are not stacked the quest can't move on? So what we do is edit a warning into the clue. That's all we can do since it's a fundamental coding problem here. Gonna tag Hiro in on this to see if he can do anything about it

Probably some bad logic in that condition type, I'll need to take a look at it

I can just remove the condition to have both rods, since they only need to give one to the sailor.


First tile of a tilesset causes trouble if it's solid

When using "tiles" layers and just placing the whole tilegrid in the map. Collisions are all over the place when the first tile is solid.
Steps to reproduce

Create a new layer or if the PR hasn't been merged yet, just replace the "current auto-layer layer with a tiles layer.
Place the complete grid like so:

Notice collisions are all over the place.

Weird behaviour
When removing the "solid" tag from the first tile, lot's of collisions seem to be OK again.

This issue is also discussed in the PlaydateLDtkImporter .

Fixed in 1.12.0!


JK-B2A24S20P hardware 10.X-W, software 10.02

Hi,
After being able to integrate your amazing pipsolar package for my axpert max I aka PIP8048, now I am trying your JKBMS Integration.
Actually it's plugged on the hardware UART0 GPIO01/GPIO03.... Unfortunatly absoluptly no oommunication is logged :(
Here is my little yaml
esphome:
  name: test_clapet
  platform: ESP32
  board: esp32dev

external_components:
  - source: github://syssi/esphome-jk-bms@main

# Enable logging
logger:
  #baud_rate: 0
  #baud_rate: 0
#  level: VERY_VERBOSE
  # logs:
    # uart: VERY_VERBOSE
    # api.service: WARN
    # ota: WARN
    # sensor: DEBUG

# Enable Home Assistant API
api:

ota:

wifi:
  ssid: !secret esphome_ssid
  password: !secret esphome_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Geothermie Fallback Hotspot"
    password: "sebydocky"

captive_portal:

time:
  - platform: homeassistant
    id: homeassistant_time

uart:

 ######### UART for the JKBMS ######

  - id: uart1
    tx_pin: GPIO03 #GPIO18
    rx_pin: GPIO01 #GPIO19
    baud_rate: 115200
    rx_buffer_size: 384

jk_modbus:
   id: modbus1
   uart_id: uart1

jk_bms:
  id: bms0
  jk_modbus_id: modbus1

sensor:
  - platform: jk_bms
    min_cell_voltage:
      name: "test min cell voltage"
    max_cell_voltage:
      name: "test max cell voltage"
    delta_cell_voltage:
      name: "test delta cell voltage"
    cell_voltage_1:
      name: "test cell voltage 1"
    cell_voltage_2:
      name: "test cell voltage 2"
    cell_voltage_3:
      name: "test cell voltage 3"
    cell_voltage_4:
      name: "test cell voltage 4"
    cell_voltage_5:
      name: "test cell voltage 5"
    cell_voltage_6:
      name: "test cell voltage 6"
    cell_voltage_7:
      name: "test cell voltage 7"
    cell_voltage_8:
      name: "test cell voltage 8"
    cell_voltage_9:
      name: "test cell voltage 9"
    cell_voltage_10:
      name: "test cell voltage 10"
    cell_voltage_11:
      name: "test cell voltage 11"
    cell_voltage_12:
      name: "test cell voltage 12"
    cell_voltage_13:
      name: "test cell voltage 13"
    cell_voltage_14:
      name: "test cell voltage 14"
    cell_voltage_15:
      name: "test cell voltage 15"
    cell_voltage_16:
      name: "test cell voltage 16"
    power_tube_temperature:
      name: "test power tube temperature"
    temperature_sensor_1:
      name: "test temperature sensor 1"
    temperature_sensor_2:
      name: "test temperature sensor 2"
    total_voltage:
      name: "test total voltage"
    current:
      name: "test current"
    capacity_remaining:
      name: "test capacity remaining"

Of course I trried my swapping TX/RX GPIO definition without more success....

Where did you buy the BMS? Could you ask the seller about some specifications?

Please avoid the first UART it's used by the logger. If you disable the serial logging by setting the baud rate to 0 the ESP still writes some messages to the UART on boot-up (bootloader etc.). Just use any other GPIO. "All" GPIOs of an ESP32 can be used as hardware UART.

Please avoid the first UART it's used by the logger. If you disable the serial logging by setting the baud rate to 0 the ESP still writes some messages to the UART on boot-up (bootloader etc.). Just use any other GPIO. "All" GPIOs of an ESP32 can be used as hardware UART.

Yes I know I should avoir the UART and I disable the baud_rate: 0.... but the problem is I am using the two other UARTs of the ESP32.... and in order to let work, one of the three must be an hardware as far I understood.... Now I am doing some test with a standalone ESP32... I will check via software UART. What GPIO are you advised ?

There is no software UART implementation (in Esphome) if you use a ESP32. The ESP32 supports 3 hardware UARTs (auto-assigned by some internal matrix).
Software serial is a thing if you use a ESP8266. The ESP8266 doesn't have a "matrix" to wire some features (UARTs) internally. The hardware UARTs are assigned to some selected GPIOs. If you use another GPIOs (which doesn't support hardware UART) the software serial implementation is used (automatically).

I prefer this setup for poking around on a D1 Mini ESP32:
uart:
  id: uart0
  baud_rate: 115200
  rx_buffer_size: 384
  tx_pin: GPIO14
  rx_pin: GPIO4
  debug:
    direction: BOTH

In other words: If you use vanilla ESPHome + ESP32 the maximal number of UARTs is limited to 3.

Ok :) ...Actually I am testing on a vanilla ESP32 with one unique softUART (04/14) as in your yaml.
and it's working ....  Even the choice of GPIO04 is not perfect since the ESP32 don't boot correctly. I need first to disconnect the UART connexion :)

Hummm seems I wrote too fast... I had two data sequence ... then anything more :(

Do you see anything at the logs? If the ESP32 reboots/crashs please try to reduce the number of sensors.

Update ...
I am receiving some data but completly dalse ...
[14:20:34][D][sensor:125]: 'test min cell voltage': Sending state 100.00000 V with 3 decimals of accuracy
[14:20:34][D][sensor:125]: 'test max cell voltage': Sending state -100.00000 V with 3 decimals of accuracy
[14:20:34][D][sensor:125]: 'test delta cell voltage': Sending state -200.00000 V with 3 decimals of accuracy
[14:20:34][D][sensor:125]: 'test power tube temperature': Sending state 0.00000 °C with 0 decimals of accuracy
[14:20:34][D][sensor:125]: 'test temperature sensor 1': Sending state -22089.00000 °C with 0 decimals of accuracy
[14:20:34][D][sensor:125]: 'test temperature sensor 2': Sending state -22089.00000 °C with 0 decimals of accuracy
[14:20:34][D][sensor:125]: 'test total voltage': Sending state 465.76999 V with 2 decimals of accuracy
[14:20:34][D][sensor:125]: 'test current': Sending state 0.00000 A with 2 decimals of accuracy
[14:20:34][D][sensor:125]: 'test capacity remaining': Sending state 252.00000 % with 0 decimals of accuracy
[14:20:39][I][jk_bms:061]: Status frame received
[14:20:39][D][sensor:125]: 'test min cell voltage': Sending state 100.00000 V with 3 decimals of accuracy
[14:20:39][D][sensor:125]: 'test max cell voltage': Sending state -100.00000 V with 3 decimals of accuracy
[14:20:39][D][sensor:125]: 'test delta cell voltage': Sending state -200.00000 V with 3 decimals of accuracy
[14:20:39][D][sensor:125]: 'test power tube temperature': Sending state 0.00000 °C with 0 decimals of accuracy
[14:20:39][D][sensor:125]: 'test temperature sensor 1': Sending state -22089.00000 °C with 0 decimals of accuracy
[14:20:39][D][sensor:125]: 'test temperature sensor 2': Sending state -22089.00000 °C with 0 decimals of accuracy
[14:20:39][D][sensor:125]: 'test total voltage': Sending state 465.76999 V with 2 decimals of accuracy
[14:20:39][D][sensor:125]: 'test current': Sending state 0.00000 A with 2 decimals of accuracy
[14:20:39][D][sensor:125]: 'test capacity remaining': Sending state 252.00000 % with 0 decimals of accuracy

I guess I need to recompile in very_verbose for the logger :)

Please check your wiring and try to swap the wires again.
Another user had success using GPIO16 and GPIO17: https://github.com/syssi/esphome-jk-bms/issues/35

And please make sure GND is connected properly.

Another user having trouble to interface this BMS model: https://github.com/syssi/esphome-jk-bms/discussions/12

Ok first very_verbose in GPIO04/GPIO14
http://pastebin.fr/102039

Could you provide a photo of your setup?

Going to wire with GPIO 16/17

Could you provide a photo of your setup?

Ok I will try...... coz the BMS is in woodbox.

Please try to make your log less noisy by:
logger:
  level: VERY_VERBOSE
  logs:
    api.service: WARN
    ota: WARN
    sensor: WARN

uart:
  id: uart0
  baud_rate: 115200
  rx_buffer_size: 384
  tx_pin: GPIO14
  rx_pin: GPIO4
  debug:
    direction: BOTH

UART cannot work if you use 2 wires only. You have to attach RX, TX and GND!

api.service: WARN
ota: WARN
sensor: WARN

Of course there are 3 :)

Ok here are the log as you asked :
INFO Waiting for result...
INFO OTA successful
INFO Successfully uploaded program.
INFO Starting log output from test_clapet.local using esphome API
INFO Successfully connected to test_clapet.local
[14:49:07][I][app:102]: ESPHome version 2022.3.0-dev compiled on Feb 15 2022, 14:47:50
[14:49:07][C][wifi:491]: WiFi:
[14:49:07][C][wifi:353]:   Local MAC: 3C:71:BF:A1:F0:80
[14:49:07][C][wifi:354]:   SSID: [redacted]
[14:49:07][C][wifi:355]:   IP Address: <IP_ADDRESS>
[14:49:07][C][wifi:357]:   BSSID: [redacted]
[14:49:07][C][wifi:358]:   Hostname: 'test_clapet'
[14:49:07][C][wifi:360]:   Signal strength: -63 dB ▂▄▆█
[14:49:07][V][wifi:362]:   Priority: 0.0
[14:49:07][C][wifi:364]:   Channel: 12
[14:49:07][C][wifi:365]:   Subnet: <IP_ADDRESS>
[14:49:07][C][wifi:366]:   Gateway: <IP_ADDRESS>
[14:49:07][C][wifi:367]:   DNS1: <IP_ADDRESS>
[14:49:07][C][wifi:368]:   DNS2: <IP_ADDRESS>
[14:49:07][C][logger:233]: Logger:
[14:49:07][C][logger:234]:   Level: VERY_VERBOSE
[14:49:07][C][logger:235]:   Log Baud Rate: 115200
[14:49:07][C][logger:236]:   Hardware UART: UART0
[14:49:07][C][logger:238]:   Level for 'api.service': WARN
[14:49:07][C][logger:238]:   Level for 'ota': WARN
[14:49:07][C][logger:238]:   Level for 'sensor': DEBUG
[14:49:07][C][uart.arduino_esp32:107]: UART Bus:
[14:49:07][C][uart.arduino_esp32:108]:   TX Pin: GPIO19
[14:49:07][C][uart.arduino_esp32:109]:   RX Pin: GPIO18
[14:49:07][C][uart.arduino_esp32:111]:   RX Buffer Size: 384
[14:49:07][C][uart.arduino_esp32:113]:   Baud Rate: 115200 baud
[14:49:07][C][uart.arduino_esp32:114]:   Data Bits: 8
[14:49:07][C][uart.arduino_esp32:115]:   Parity: NONE
[14:49:07][C][uart.arduino_esp32:116]:   Stop bits: 1
[14:49:07][C][jk_modbus:095]: JkModbus:
[14:49:07][C][homeassistant.time:010]: Home Assistant Time:
[14:49:07][C][homeassistant.time:011]:   Timezone: 'CET-1CEST,M3.5.0,M10.5.0/3'
[14:49:07][C][jk_bms:462]: JkBms:
[14:49:07][C][jk_bms:463]:   Address: 0x4E
[14:49:07][C][jk_bms:465]: Cell Voltage 1 'test cell voltage 1'
[14:49:07][C][jk_bms:465]:   Device Class: 'voltage'
[14:49:07][C][jk_bms:465]:   State Class: 'measurement'
[14:49:07][C][jk_bms:465]:   Unit of Measurement: 'V'
[14:49:07][C][jk_bms:465]:   Accuracy Decimals: 3
[14:49:07][C][jk_bms:466]: Cell Voltage 2 'test cell voltage 2'
[14:49:07][C][jk_bms:466]:   Device Class: 'voltage'
[14:49:07][C][jk_bms:466]:   State Class: 'measurement'
[14:49:07][C][jk_bms:466]:   Unit of Measurement: 'V'
[14:49:07][C][jk_bms:466]:   Accuracy Decimals: 3
[14:49:07][C][jk_bms:467]: Cell Voltage 3 'test cell voltage 3'
[14:49:07][C][jk_bms:467]:   Device Class: 'voltage'
[14:49:07][C][jk_bms:467]:   State Class: 'measurement'
[14:49:07][C][jk_bms:467]:   Unit of Measurement: 'V'
[14:49:07][C][jk_bms:467]:   Accuracy Decimals: 3
[14:49:07][C][jk_bms:468]: Cell Voltage 4 'test cell voltage 4'
[14:49:07][C][jk_bms:468]:   Device Class: 'voltage'
[14:49:07][C][jk_bms:468]:   State Class: 'measurement'
[14:49:07][C][jk_bms:468]:   Unit of Measurement: 'V'
[14:49:08][C][jk_bms:468]:   Accuracy Decimals: 3
[14:49:08][C][jk_bms:469]: Cell Voltage 5 'test cell voltage 5'
[14:49:08][C][jk_bms:469]:   Device Class: 'voltage'
[14:49:08][C][jk_bms:469]:   State Class: 'measurement'
[14:49:08][C][jk_bms:469]:   Unit of Measurement: 'V'
[14:49:08][C][jk_bms:469]:   Accuracy Decimals: 3
[14:49:08][C][jk_bms:470]: Cell Voltage 6 'test cell voltage 6'
[14:49:08][C][jk_bms:470]:   Device Class: 'voltage'
[14:49:08][C][jk_bms:470]:   State Class: 'measurement'
[14:49:08][C][jk_bms:470]:   Unit of Measurement: 'V'
[14:49:08][C][jk_bms:470]:   Accuracy Decimals: 3
[14:49:08][C][jk_bms:471]: Cell Voltage 7 'test cell voltage 7'
[14:49:08][C][jk_bms:471]:   Device Class: 'voltage'
[14:49:08][C][jk_bms:471]:   State Class: 'measurement'
[14:49:08][C][jk_bms:471]:   Unit of Measurement: 'V'
[14:49:08][C][jk_bms:471]:   Accuracy Decimals: 3
[14:49:08][C][jk_bms:472]: Cell Voltage 8 'test cell voltage 8'
[14:49:08][C][jk_bms:472]:   Device Class: 'voltage'
[14:49:08][C][jk_bms:472]:   State Class: 'measurement'
[14:49:08][C][jk_bms:472]:   Unit of Measurement: 'V'
[14:49:08][C][jk_bms:472]:   Accuracy Decimals: 3
[14:49:08][C][jk_bms:473]: Cell Voltage 9 'test cell voltage 9'
[14:49:08][C][jk_bms:473]:   Device Class: 'voltage'
[14:49:08][C][jk_bms:473]:   State Class: 'measurement'
[14:49:08][C][jk_bms:473]:   Unit of Measurement: 'V'
[14:49:08][C][jk_bms:473]:   Accuracy Decimals: 3
[14:49:08][C][jk_bms:474]: Cell Voltage 10 'test cell voltage 10'
[14:49:08][C][jk_bms:474]:   Device Class: 'voltage'
[14:49:08][C][jk_bms:474]:   State Class: 'measurement'
[14:49:08][C][jk_bms:474]:   Unit of Measurement: 'V'
[14:49:08][C][jk_bms:474]:   Accuracy Decimals: 3
[14:49:08][C][jk_bms:475]: Cell Voltage 11 'test cell voltage 11'
[14:49:08][C][jk_bms:475]:   Device Class: 'voltage'
[14:49:08][C][jk_bms:475]:   State Class: 'measurement'
[14:49:08][C][jk_bms:475]:   Unit of Measurement: 'V'
[14:49:08][C][jk_bms:475]:   Accuracy Decimals: 3
[14:49:08][C][jk_bms:476]: Cell Voltage 12 'test cell voltage 12'
[14:49:08][C][jk_bms:476]:   Device Class: 'voltage'
[14:49:08][C][jk_bms:476]:   State Class: 'measurement'
[14:49:08][C][jk_bms:476]:   Unit of Measurement: 'V'
[14:49:08][C][jk_bms:476]:   Accuracy Decimals: 3
[14:49:08][C][jk_bms:477]: Cell Voltage 13 'test cell voltage 13'
[14:49:08][C][jk_bms:477]:   Device Class: 'voltage'
[14:49:08][C][jk_bms:477]:   State Class: 'measurement'
[14:49:08][C][jk_bms:477]:   Unit of Measurement: 'V'
[14:49:08][C][jk_bms:477]:   Accuracy Decimals: 3
[14:49:08][C][jk_bms:478]: Cell Voltage 14 'test cell voltage 14'
[14:49:08][C][jk_bms:478]:   Device Class: 'voltage'
[14:49:08][C][jk_bms:478]:   State Class: 'measurement'
[14:49:08][C][jk_bms:478]:   Unit of Measurement: 'V'
[14:49:08][C][jk_bms:478]:   Accuracy Decimals: 3
[14:49:08][C][jk_bms:479]: Cell Voltage 15 'test cell voltage 15'
[14:49:08][C][jk_bms:479]:   Device Class: 'voltage'
[14:49:08][C][jk_bms:479]:   State Class: 'measurement'
[14:49:08][C][jk_bms:479]:   Unit of Measurement: 'V'
[14:49:08][C][jk_bms:479]:   Accuracy Decimals: 3
[14:49:08][C][jk_bms:480]: Cell Voltage 16 'test cell voltage 16'
[14:49:08][C][jk_bms:480]:   Device Class: 'voltage'
[14:49:08][C][jk_bms:480]:   State Class: 'measurement'
[14:49:08][C][jk_bms:480]:   Unit of Measurement: 'V'
[14:49:08][C][jk_bms:480]:   Accuracy Decimals: 3
[14:49:08][C][jk_bms:489]: Power Tube Temperature 'test power tube temperature'
[14:49:08][C][jk_bms:489]:   Device Class: 'temperature'
[14:49:08][C][jk_bms:489]:   State Class: 'measurement'
[14:49:08][C][jk_bms:489]:   Unit of Measurement: '°C'
[14:49:08][C][jk_bms:489]:   Accuracy Decimals: 0
[14:49:08][C][jk_bms:490]: Temperature Sensor 1 'test temperature sensor 1'
[14:49:08][C][jk_bms:490]:   Device Class: 'temperature'
[14:49:08][C][jk_bms:490]:   State Class: 'measurement'
[14:49:08][C][jk_bms:490]:   Unit of Measurement: '°C'
[14:49:08][C][jk_bms:490]:   Accuracy Decimals: 0
[14:49:08][C][jk_bms:491]: Temperature Sensor 2 'test temperature sensor 2'
[14:49:08][C][jk_bms:491]:   Device Class: 'temperature'
[14:49:08][C][jk_bms:491]:   State Class: 'measurement'
[14:49:08][C][jk_bms:491]:   Unit of Measurement: '°C'
[14:49:08][C][jk_bms:491]:   Accuracy Decimals: 0
[14:49:08][C][jk_bms:492]: Total Voltage 'test total voltage'
[14:49:08][C][jk_bms:492]:   Device Class: 'voltage'
[14:49:08][C][jk_bms:492]:   State Class: 'measurement'
[14:49:08][C][jk_bms:492]:   Unit of Measurement: 'V'
[14:49:08][C][jk_bms:492]:   Accuracy Decimals: 2
[14:49:08][C][jk_bms:493]: Current 'test current'
[14:49:08][C][jk_bms:493]:   Device Class: 'current'
[14:49:08][C][jk_bms:493]:   State Class: 'measurement'
[14:49:08][C][jk_bms:493]:   Unit of Measurement: 'A'
[14:49:08][C][jk_bms:493]:   Accuracy Decimals: 2
[14:49:08][C][jk_bms:494]: Capacity Remaining 'test capacity remaining'
[14:49:08][C][jk_bms:494]:   State Class: 'measurement'
[14:49:08][C][jk_bms:494]:   Unit of Measurement: '%'
[14:49:08][C][jk_bms:494]:   Accuracy Decimals: 0
[14:49:08][C][jk_bms:494]:   Icon: 'mdi:battery-50'
[14:49:08][V][api.connection:808]: Hello from client: 'Home Assistant 2022.2.6 (::FFFF:C0A8:102)'
[14:49:08][D][api.connection:826]: Home Assistant 2022.2.6 (::FFFF:C0A8:102): Connected successfully
[14:49:08][C][captive_portal:144]: Captive Portal:
[14:49:08][VV][time:024]: Got epoch<PHONE_NUMBER>
[14:49:08][D][time:039]: Synchronized time: 2022-02-15 14:49:08
[14:49:08][C][mdns:084]: mDNS:
[14:49:08][C][mdns:085]:   Hostname: test_clapet
[14:49:08][V][mdns:086]:   Services:
[14:49:08][V][mdns:088]:   - _esphomelib, _tcp, 6053
[14:49:08][V][mdns:090]:     TXT: version = 2022.3.0-dev
[14:49:08][V][mdns:090]:     TXT: mac = 3c71bfa1f080
[14:49:08][V][mdns:090]:     TXT: platform = ESP32
[14:49:08][V][mdns:090]:     TXT: board = esp32dev
[14:49:08][C][api:138]: API Server:
[14:49:08][C][api:139]:   Address: test_clapet.local:6053
[14:49:08][C][api:143]:   Using noise encryption: NO
[14:49:10][VV][scheduler:186]: Running interval 'update' with interval=5000 last_execution=4997 (now=9997)
[14:49:10][VV][uart.arduino_esp32:150]:     Flushing...
[14:49:10][D][uart_debug:114]: >>> 4E:57:00:13:00:00:00:00:06:03:00:00:00:00:00:00:68:00:00:01:29
[14:49:10][I][jk_bms:061]: Status frame received
[14:49:10][D][sensor:125]: 'test min cell voltage': Sending state 100.00000 V with 3 decimals of accuracy
[14:49:10][D][sensor:125]: 'test max cell voltage': Sending state -100.00000 V with 3 decimals of accuracy
[14:49:10][D][sensor:125]: 'test delta cell voltage': Sending state -200.00000 V with 3 decimals of accuracy
[14:49:10][D][sensor:125]: 'test power tube temperature': Sending state 0.00000 °C with 0 decimals of accuracy
[14:49:10][D][sensor:125]: 'test temperature sensor 1': Sending state -22089.00000 °C with 0 decimals of accuracy
[14:49:10][D][sensor:125]: 'test temperature sensor 2': Sending state -22089.00000 °C with 0 decimals of accuracy
[14:49:10][D][sensor:125]: 'test total voltage': Sending state 430.37000 V with 2 decimals of accuracy
[14:49:10][D][sensor:125]: 'test current': Sending state 0.00000 A with 2 decimals of accuracy
[14:49:10][D][sensor:125]: 'test capacity remaining': Sending state 186.00000 % with 0 decimals of accuracy
[14:49:10][V][component:199]: Component jk_modbus took a long time for an operation (0.15 s).
[14:49:10][V][component:200]: Components should block for at most 20-30ms.
[14:49:10][D][uart_debug:114]: <<< 4E:57:00:13:00:00:00:00:06:03:00:00:00:00:00:00:68:00:00:01:29
[14:49:15][VV][scheduler:186]: Running interval 'update' with interval=5000 last_execution=9997 (now=15000)
[14:49:15][VV][uart.arduino_esp32:150]:     Flushing...
[14:49:15][D][uart_debug:114]: >>> 4E:57:00:13:00:00:00:00:06:03:00:00:00:00:00:00:68:00:00:01:29
[14:49:15][I][jk_bms:061]: Status frame received
[14:49:15][D][sensor:125]: 'test min cell voltage': Sending state 100.00000 V with 3 decimals of accuracy
[14:49:15][D][sensor:125]: 'test max cell voltage': Sending state -100.00000 V with 3 decimals of accuracy
[14:49:15][D][sensor:125]: 'test delta cell voltage': Sending state -200.00000 V with 3 decimals of accuracy
[14:49:15][D][sensor:125]: 'test power tube temperature': Sending state 0.00000 °C with 0 decimals of accuracy
[14:49:15][D][sensor:125]: 'test temperature sensor 1': Sending state -22089.00000 °C with 0 decimals of accuracy
[14:49:15][D][sensor:125]: 'test temperature sensor 2': Sending state -22089.00000 °C with 0 decimals of accuracy
[14:49:15][D][sensor:125]: 'test total voltage': Sending state 430.37000 V with 2 decimals of accuracy
[14:49:15][D][sensor:125]: 'test current': Sending state 0.00000 A with 2 decimals of accuracy
[14:49:15][D][sensor:125]: 'test capacity remaining': Sending state 186.00000 % with 0 decimals of accuracy
[14:49:15][V][component:199]: Component jk_modbus took a long time for an operation (0.14 s).
[14:49:15][V][component:200]: Components should block for at most 20-30ms.
[14:49:15][D][uart_debug:114]: <<< 4E:57:00:13:00:00:00:00:06:03:00:00:00:00:00:00:68:00:00:01:29
[14:49:20][VV][scheduler:186]: Running interval 'update' with interval=5000 last_execution=14997 (now=20001)
[14:49:20][VV][uart.arduino_esp32:150]:     Flushing...
[14:49:20][D][uart_debug:114]: >>> 4E:57:00:13:00:00:00:00:06:03:00:00:00:00:00:00:68:00:00:01:29
[14:49:20][I][jk_bms:061]: Status frame received
[14:49:20][D][sensor:125]: 'test min cell voltage': Sending state 100.00000 V with 3 decimals of accuracy
[14:49:20][D][sensor:125]: 'test max cell voltage': Sending state -100.00000 V with 3 decimals of accuracy
[14:49:20][D][sensor:125]: 'test delta cell voltage': Sending state -200.00000 V with 3 decimals of accuracy
[14:49:20][D][sensor:125]: 'test power tube temperature': Sending state 0.00000 °C with 0 decimals of accuracy
[14:49:20][D][sensor:125]: 'test temperature sensor 1': Sending state -22089.00000 °C with 0 decimals of accuracy
[14:49:20][D][sensor:125]: 'test temperature sensor 2': Sending state -22089.00000 °C with 0 decimals of accuracy
[14:49:20][D][sensor:125]: 'test total voltage': Sending state 430.37000 V with 2 decimals of accuracy
[14:49:20][D][sensor:125]: 'test current': Sending state 0.00000 A with 2 decimals of accuracy
[14:49:20][D][sensor:125]: 'test capacity remaining': Sending state 186.00000 % with 0 decimals of accuracy
[14:49:20][V][component:199]: Component jk_modbus took a long time for an operation (0.14 s).
[14:49:20][V][component:200]: Components should block for at most 20-30ms.
[14:49:20][D][uart_debug:114]: <<< 4E:57:00:13:00:00:00:00:06:03:00:00:00:00:00:00:68:00:00:01:29
[14:49:25][VV][scheduler:186]: Running interval 'update' with interval=5000 last_execution=19997 (now=25001)
[14:49:25][VV][uart.arduino_esp32:150]:     Flushing...
[14:49:25][D][uart_debug:114]: >>> 4E:57:00:13:00:00:00:00:06:03:00:00:00:00:00:00:68:00:00:01:29
[14:49:25][I][jk_bms:061]: Status frame received
[14:49:25][D][sensor:125]: 'test min cell voltage': Sending state 100.00000 V with 3 decimals of accuracy
[14:49:25][D][sensor:125]: 'test max cell voltage': Sending state -100.00000 V with 3 decimals of accuracy
[14:49:25][D][sensor:125]: 'test delta cell voltage': Sending state -200.00000 V with 3 decimals of accuracy
[14:49:25][D][sensor:125]: 'test power tube temperature': Sending state 0.00000 °C with 0 decimals of accuracy
[14:49:25][D][sensor:125]: 'test temperature sensor 1': Sending state -22089.00000 °C with 0 decimals of accuracy
[14:49:25][D][sensor:125]: 'test temperature sensor 2': Sending state -22089.00000 °C with 0 decimals of accuracy
[14:49:25][D][sensor:125]: 'test total voltage': Sending state 430.37000 V with 2 decimals of accuracy
[14:49:25][D][sensor:125]: 'test current': Sending state 0.00000 A with 2 decimals of accuracy
[14:49:25][D][sensor:125]: 'test capacity remaining': Sending state 186.00000 % with 0 decimals of accuracy
[14:49:25][V][component:199]: Component jk_modbus took a long time for an operation (0.15 s).
[14:49:25][V][component:200]: Components should block for at most 20-30ms.
[14:49:25][D][uart_debug:114]: <<< 4E:57:00:13:00:00:00:00:06:03:00:00:00:00:00:00:68:00:00:01:29
[14:49:30][VV][scheduler:186]: Running interval 'update' with interval=5000 last_execution=24997 (now=30002)
[14:49:30][VV][uart.arduino_esp32:150]:     Flushing...
[14:49:30][D][uart_debug:114]: >>> 4E:57:00:13:00:00:00:00:06:03:00:00:00:00:00:00:68:00:00:01:29
[14:49:30][I][jk_bms:061]: Status frame received
[14:49:30][D][sensor:125]: 'test min cell voltage': Sending state 100.00000 V with 3 decimals of accuracy
[14:49:30][D][sensor:125]: 'test max cell voltage': Sending state -100.00000 V with 3 decimals of accuracy
[14:49:30][D][sensor:125]: 'test delta cell voltage': Sending state -200.00000 V with 3 decimals of accuracy
[14:49:30][D][sensor:125]: 'test power tube temperature': Sending state 0.00000 °C with 0 decimals of accuracy
[14:49:30][D][sensor:125]: 'test temperature sensor 1': Sending state -22089.00000 °C with 0 decimals of accuracy
[14:49:30][D][sensor:125]: 'test temperature sensor 2': Sending state -22089.00000 °C with 0 decimals of accuracy
[14:49:30][D][sensor:125]: 'test total voltage': Sending state 430.37000 V with 2 decimals of accuracy
[14:49:30][D][sensor:125]: 'test current': Sending state 0.00000 A with 2 decimals of accuracy
[14:49:30][D][sensor:125]: 'test capacity remaining': Sending state 186.00000 % with 0 decimals of accuracy
[14:49:30][V][component:199]: Component jk_modbus took a long time for an operation (0.14 s).
[14:49:30][V][component:200]: Components should block for at most 20-30ms.
[14:49:30][D][uart_debug:114]: <<< 4E:57:00:13:00:00:00:00:06:03:00:00:00:00:00:00:68:00:00:01:29
[14:49:35][VV][scheduler:186]: Running interval 'update' with interval=5000 last_execution=29997 (now=34997)
[14:49:35][VV][uart.arduino_esp32:150]:     Flushing...
[14:49:35][D][uart_debug:114]: >>> 4E:57:00:13:00:00:00:00:06:03:00:00:00:00:00:00:68:00:00:01:29
[14:49:35][I][jk_bms:061]: Status frame received
[14:49:35][D][sensor:125]: 'test min cell voltage': Sending state 100.00000 V with 3 decimals of accuracy
[14:49:35][D][sensor:125]: 'test max cell voltage': Sending state -100.00000 V with 3 decimals of accuracy
[14:49:35][D][sensor:125]: 'test delta cell voltage': Sending state -200.00000 V with 3 decimals of accuracy
[14:49:35][D][sensor:125]: 'test power tube temperature': Sending state 0.00000 °C with 0 decimals of accuracy
[14:49:35][D][sensor:125]: 'test temperature sensor 1': Sending state -22089.00000 °C with 0 decimals of accuracy
[14:49:35][D][sensor:125]: 'test temperature sensor 2': Sending state -22089.00000 °C with 0 decimals of accuracy
[14:49:35][D][sensor:125]: 'test total voltage': Sending state 430.37000 V with 2 decimals of accuracy
[14:49:35][D][sensor:125]: 'test current': Sending state 0.00000 A with 2 decimals of accuracy
[14:49:35][D][sensor:125]: 'test capacity remaining': Sending state 186.00000 % with 0 decimals of accuracy
[14:49:35][V][component:199]: Component jk_modbus took a long time for an operation (0.18 s).
[14:49:35][V][component:200]: Components should block for at most 20-30ms.
[14:49:35][D][uart_debug:114]: <<< 4E:57:00:13:00:00:00:00:06:03:00:00:00:00:00:00:68:00:00:01:29
[14:49:40][VV][scheduler:186]: Running interval 'update' with interval=5000 last_execution=34997 (now=39998)
[14:49:40][VV][uart.arduino_esp32:150]:     Flushing...
[14:49:40][D][uart_debug:114]: >>> 4E:57:00:13:00:00:00:00:06:03:00:00:00:00:00:00:68:00:00:01:29
[14:49:40][I][jk_bms:061]: Status frame received
[14:49:40][D][sensor:125]: 'test min cell voltage': Sending state 100.00000 V with 3 decimals of accuracy
[14:49:40][D][sensor:125]: 'test max cell voltage': Sending state -100.00000 V with 3 decimals of accuracy
[14:49:40][D][sensor:125]: 'test delta cell voltage': Sending state -200.00000 V with 3 decimals of accuracy
[14:49:40][D][sensor:125]: 'test power tube temperature': Sending state 0.00000 °C with 0 decimals of accuracy
[14:49:40][D][sensor:125]: 'test temperature sensor 1': Sending state -22089.00000 °C with 0 decimals of accuracy
[14:49:40][D][sensor:125]: 'test temperature sensor 2': Sending state -22089.00000 °C with 0 decimals of accuracy
[14:49:40][D][sensor:125]: 'test total voltage': Sending state 430.37000 V with 2 decimals of accuracy
[14:49:40][D][sensor:125]: 'test current': Sending state 0.00000 A with 2 decimals of accuracy
[14:49:40][D][sensor:125]: 'test capacity remaining': Sending state 186.00000 % with 0 decimals of accuracy
[14:49:40][V][component:199]: Component jk_modbus took a long time for an operation (0.15 s).
[14:49:40][V][component:200]: Components should block for at most 20-30ms.
[14:49:40][D][uart_debug:114]: <<< 4E:57:00:13:00:00:00:00:06:03:00:00:00:00:00:00:68:00:00:01:29
[14:49:45][VV][scheduler:186]: Running interval 'update' with interval=5000 last_execution=39997 (now=44997)
[14:49:45][VV][uart.arduino_esp32:150]:     Flushing...
[14:49:45][D][uart_debug:114]: >>> 4E:57:00:13:00:00:00:00:06:03:00:00:00:00:00:00:68:00:00:01:29
[14:49:45][I][jk_bms:061]: Status frame received
[14:49:45][D][sensor:125]: 'test min cell voltage': Sending state 100.00000 V with 3 decimals of accuracy
[14:49:45][D][sensor:125]: 'test max cell voltage': Sending state -100.00000 V with 3 decimals of accuracy
[14:49:45][D][sensor:125]: 'test delta cell voltage': Sending state -200.00000 V with 3 decimals of accuracy
[14:49:45][D][sensor:125]: 'test power tube temperature': Sending state 0.00000 °C with 0 decimals of accuracy
[14:49:45][D][sensor:125]: 'test temperature sensor 1': Sending state -22089.00000 °C with 0 decimals of accuracy
[14:49:45][D][sensor:125]: 'test temperature sensor 2': Sending state -22089.00000 °C with 0 decimals of accuracy
[14:49:45][D][sensor:125]: 'test total voltage': Sending state 430.37000 V with 2 decimals of accuracy
[14:49:45][D][sensor:125]: 'test current': Sending state 0.00000 A with 2 decimals of accuracy
[14:49:45][D][sensor:125]: 'test capacity remaining': Sending state 186.00000 % with 0 decimals of accuracy
[14:49:45][V][component:199]: Component jk_modbus took a long time for an operation (0.16 s).
[14:49:45][V][component:200]: Components should block for at most 20-30ms.
[14:49:45][D][uart_debug:114]: <<< 4E:57:00:13:00:00:00:00:06:03:00:00:00:00:00:00:68:00:00:01:29

This is the important part of the capture:
# Request
[14:49:45][D][uart_debug:114]: >>> 4E:57:00:13:00:00:00:00:06:03:00:00:00:00:00:00:68:00:00:01:29

# Response
[14:49:45][D][uart_debug:114]: <<< 4E:57:00:13:00:00:00:00:06:03:00:00:00:00:00:00:68:00:00:01:29

It looks like the response isn't a valid response from the BMS. It could be some echo / crosstalk / short circuit / missing GND issue because there is no difference in the Request (TX) and the Response (RX).

Ok ... I will check that point.... I just soldered a connector (JST XH 3p) from the provided cable. I will by able the check not before 2h. Anyway thanks for your Huge help ...

Here are some picts
https://ibb.co/nb2XqgH
So I wired a cable JST XH 3P, 15cm
RS485 <=> JST XH 3P
black  <=> black
yellow <=> yellow
white <=> red
Then from this femmal cable into the ESP
https://ibb.co/hCwwXy2
https://ibb.co/Ssj6D2Q
https://ibb.co/VLWf2HF

I had a very similar output to yours above but then I switched to:
uart:
  id: uart2
  baud_rate: 115200
  rx_buffer_size: 384
  tx_pin: GPIO16
  rx_pin: GPIO17

I have a slightly different BMS than yours but at least on my GPIO16 goes to the pin closest to ground and GPIO17 goes to the pin closest to V_Batt
It's been working well for days now.

I had a very similar output to yours above but then I switched to:
uart:
  id: uart2
  baud_rate: 115200
  rx_buffer_size: 384
  tx_pin: GPIO16
  rx_pin: GPIO17

I have a slightly different BMS than yours but at least on my GPIO16 goes to the pin closest to ground and GPIO17 goes to the pin closest to V_Batt
It's been working well for days now.

Can you confirm to me that triplet color from your RS485 module are (black, white, yellow) and black is the ground ?

I don't have the RS-485 module.  I made a custom cable that fits the RS-485 port on the BMS.
You can check which ports are +V_Batt and GND with a multi-meter, and that just leaves two other pins for TX&RX that you can just try one way and then another, but as I said above the pin closest to ground on mine is what goes into GPIO16 on the ESP.

I don't have the RS-485 module. I made a custom cable that fits the RS-485 port on the BMS. You can check which ports are +V_Batt and GND with a multi-meter, and that just leaves two other pins for TX&RX that you can just try one way and then another, but as I said above the pin closest to ground on mine is what goes into GPIO16 on the ESP.

You mean you attacked directly the RS-485 port from the JKBMS to the ESP32 without using the module ?

Correct,
Per the schematic in the instructions: https://github.com/syssi/esphome-jk-bms

Correct, Per the schematic in the instructions: https://github.com/syssi/esphome-jk-bms

OMG :) maybe it's the trick ..... Hope I have somewhere some JST picoblade 1.25mm 4P :) ..

Maybe ...
But I do have a different model BMS so I can't say for sure.
Mine at least is Molex PicoBlade 1.25mm 4P

Good news :) It's WORKING fine :)

And FYI, it's also working fine on my "PVbrain" ..... 3 UART used : JKBMS,PIPsolar and dual PZEM 004T :)

Do you use the official PZEM component? I'm aware of one bug report telling the component is unstable.

Do you use the official PZEM component? I'm aware of one bug report telling the component is unstable.

Yes ... I got some since 2 years ..... Super stable for me....

Cool! I will use one of these devices (PZEM-017 DC 0-300V 100A) as digital shunt in future.
https://esphome.io/components/sensor/pzemdc.html

Cool! I will use one of these devices (PZEM-017 DC 0-300V 100A) as digital shunt in future.
https://esphome.io/components/sensor/pzemdc.html

maybe ... I was not clear, the PZEM I installed are PZEM 004T V3 (modbus based). I don't plan to install the DC version with a shunt. The problem, the sens of current is not reported with PZEM ... it's big problem IMHO for solar application.
I bought such module.... : https://fr.aliexpress.com/item/4000762882822.html?gatewayAdapt=glo2fra&spm=a2g0o.90423<IP_ADDRESS>426c37To8Uh6
There are a UART port .... maybe a good excercice for hacking something.


Add support for splats in shapes

Is there a way to get all the attributes of an object, maybe on the first level.
these statements do not work, (not explained in the documentation).
SELECT User {};
SELECT User {*};

Currently, you have to specify the output shape explicitly. The main reason is that it is not obvious what is meant by *. Is it all properties, or all properties and links, or all singleton properties?  All three have different performance characteristics.
Generally speaking, * is mostly only useful in repl, where you need to run something quickly. We might think of something for repl specifically.

The proposed solution is to provide an autocomplete shortcut so that typing SELECT User{*<tab> would complete to a full list of type properties (but not links).

Just as a reminder, we also considered to use ...<tab> for that autocomplete shortcut. The benefit of that is largely that we don't have to disambiguate whether or not the * appears syntactically as an operator or not.

Most likely it will be *<TAB>

We're now considering adding support for splats in shapes:
SELECT User { ...User };
# or
SELECT User { ...UserFragmentView };

Using ... makes more sense than * since it's more readable to a non-Python programmer and is similar to the corresponding GraphQL syntax.

A few of nuances need to be addressed in regards to using views vs. types in splats.
1. What is included by a splat
The simple case:
# type is splatted, so all of its properties and links are included
SELECT User {...User};

# view is splatted, so only the explicitly defined shape elements are included?
WITH
    UserView := User {
        name,
        foo := 'bar'
    }
SELECT User {...UserView};

2. Ambiguous identifiers
Ambiguity arises when a view uses the same name as the underlying type, which is fairly common.
WITH
    User := User {
        name,
        foo := 'bar'
    }
SELECT User {...User};

# or worse, the view has no explicitly defined shape
WITH
    User := (SELECT User FILTER .name >= 'B')
SELECT User {...User};

We may want to disambiguate whether we're splatting a type or a view, the difference being that splatting types includes every property and link of that type, while splatting a view only includes the ones which are immediately defined on the view as a shape annotation.
Perhaps something like:
SELECT User {...TYPE User};
SELECT User {...VIEW UserView};

# or maybe

SELECT User {...User};  # the shortest version includes everything
SELECT User {...VIEW UserView};

3. Type expressions
Also, if an object type is what's allowed in a splat, then type expressions should be allowed there as well:
SELECT User {
    ...Named,
    ...Activatable  # has a property active -> bool
};

# should be nearly equivalent to the above,
# except for order of properties in serialization
SELECT User {
    ...Named & Activatable
};

4. Order of elements
What order do splatted elements appear in? Do we guarantee anything about order of shape elements at all? GraphQL, for example, does specify that the output should contain the fields in the same order as they appear in in the input document. It also specifies order for fields defined in fragments, but GraphQL has the advantage of always having fragments right in the input document, so the order is not terribly obscure.
Rather than relying on "definition order" (which may be non-trivial to infer for complex types extending other types and thus difficult for the end-user to actually predict and rely on), we can specify that a type splat always enforces alphabetical order of the splatted elements. At least this way, the order is always well defined and predictable. Incidentally this also works for splatting union and intersection types. Splatting a view might stick to the "definition order", though (although this may be an undesirable inconsistency).

I come from the multi-value no-sql world, my specif flavor is Rocket Softwares' D3 database system. I'm rather new here but in my world:
SELECT USER by itself would return all users and their fields per user.
In your example:
SELECT User {
...Named,
...Activatable  # has a property active -> bool
};
That would return a complete listing of users and their ...Named and ...Activatable fields only .
and the example:
SELECT User {...VIEW UserView};
could be used to create a procedural call to sort the users by a specific field or fields, by a non-existant key value, or what ever.
It would be nice to keep the specifc order of an item in tack, that way if you decide to create a specific language in edgeql to do more complex functions, (such as mvbasic in my world), it would be easier to read/write/edit a specific record.

Sorry misspoke above SELECT USERS by itself would only return all record IDs, from that point they could be edited/read/written to etc.
If we did a SELECT USERS RETURNING (OR CAPTURING) then we could return or capture result for a later operation.

Reviving the discussion here.

Ambiguous identifiers
Ambiguity arises when a view uses the same name as the underlying type, which is fairly common.

I don't think any of the listed examples warrant complication of the design and adding ...VIEW or ...TYPE splats. Just don't shadow your types with query aliases. And if you do, it's a trivial thing to fix. At least I'll be -1 on implementing this feature from the beginning -- this type of syntax should come from real world examples and user requests.

Type expressions

   ...Named & Activatable
};```

I don't see why not, but we don't necessarily need that in 1.0. If we need it at all, I'd use parens after ... to improve readability, as in:
SELECT User {
    ...(Named & Activatable)
};```

> What order do splatted elements appear in? Do we guarantee anything about order of shape elements at all?

Should be in the order the fields are described in the query or in the schema. We must preserve order to the best of our ability, and AFAIK we fully control the order.

> Rather than relying on "definition order" (which may be non-trivial to infer for complex types extending other types and thus difficult for the end-user to actually predict and rely on)

I don't fully agree with that. Predicting order in a complicated diamond inheretance is hard, but it's quite obvious for simple cases (and can be documented).

>  At least this way, the order is always well defined and predictable.

It's not predictable. Altering a parent type with a new property would screw things up in absolutely the same way.  And ordering would make output to look really weird in repl in simple cases. I'm -1 on that.

I come from the multi-value no-sql world, my specif flavor is Rocket Softwares' D3 database system. I'm rather new here but in my world:

Thanks for the pointer, I'll take a look at D3.

Sorry misspoke above SELECT USERS by itself would only return all record IDs

Almost the same in EdgeDB -- we'd return "User" object with only one field, its ID.

It would be nice to keep the specifc order of an item in tack,

Yes, I agree.

Maybe we could start iterating on the usage and API at the query builder level. We could add an API for selecting all attributes to the ts query builder.
let query = e.select(e.Movie, movie => ({
 "*": true
}}
let query = e.select(e.Movie, movie => ({
 "*": {
  properties: true,
  links: true // would compile to {id: true} for each link
  computed: true
}
}}

That sounds like a really good idea @haikyuu . I imagine introducing something like into the query builder would have lower development cost and lower misstep cost than introducing it into the core EdgeQL syntax. Good way to test out the concept.

That sounds like a really good idea @haikyuu . I imagine introducing something like into the query builder would have lower development cost and lower misstep cost than introducing it into the core EdgeQL syntax. Good way to test out the concept.

Just a suggestion from a new user, I was looking for a way to quickly inspect objects inside of the egdedb interactive REPL and found my way to this issue.
I find it useful during development to be able to poke around the database and play with objects, modify them, delete them, before the application is completely working. People who have tried Elixir and iex will understand how amazing solid introspection can be. At the moment it's a lot of typing to select properties, even if autocomplete is outstanding.
edgedb> select User filter .username = "Alice";
{default::User {id: d5ceabf2-c252-11ec-8820-9bb3eb36643f}}

This is not very useful when the cardinality is one, especially if a User has a lot of table properties to keep them localised in memory/on disk.
It would be a lot more ergonomic to either have a wildcard operator or just be a lot more verbose in the REPL, possibly run a count on links, ...
edgedb> select User filter .username = "Alice";
{default::User {
    id: d5ceabf2-c252-11ec-8820-9bb3eb36643f,
    username: 'Alice',
    sessions: <12 default::Session>
}}

I also understand the wish to keep EdgeQL as "unpolluted" as possible, perhaps this could be an extension of the REPL, or a GUI browser such as Prisma Studio (even if I find REPL more ergonomic)?

@MarcusCemes great idea. The studio (in alpha) has a REPL and this would be a great addition there as well

This has been added to the JavaScript query builder with the following API.
e.select(e.Movie, ()=>({
  ...e.Movie['*']
}))

This will fetch all properties of Movie; links must be specified separately. This API/behavior is subject to change if/when native splat functionality lands in EdgeQL.

There is also a syntax that seems nice in duckdb
SELECT * EXCLUDE (jar_jar_binks, midichlorians) FROM star_wars

And it would be nice to mark fields as excluded from * at schema level
required property password -> str { excluded := true };

Alright we are hoping to squeeze this into 3.0. Proposal is up here: https://github.com/edgedb/rfcs/pull/77

Implemented in #5080!


Add process.Manager

This change adds a process.Manager that uses type parameters for a specific Processor type and BigQuery result row type. A process.Manager wraps a specific Processor implementation. For example, a future PR will introduce an annotation.Processor for recreating annotation archives and files. In principle, the process.Manager could manage reprocessing of other types as well in the future, e.g. for test redaction.
The basic process.Manager usage follows this pattern:

Create a process.Manager with a specific BigQuery result row type (and input query).
Run the query for a specific date and collect all results.
Process every result row using the Processor implementation
Read the source archive, process each file in source archive, and add to an output archive
Finish the output archive, e.g. upload to GCS.

This change is

Pull Request Test Coverage Report for Build 158

89 of 105 (84.76%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-2.2%) to 94.139%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

archive/processor.go
89
91
97.8%

internal/jobs/client.go
0
3
0.0%

internal/jobs/handler.go
0
11
0.0%

Totals

Change from base Build 152:
-2.2%

Covered Lines:
514

Relevant Lines:
546

💛  - Coveralls

Thank you!

Part of:

https://github.com/m-lab/uuid-annotator/issues/48


OCPBUGS-38481: Update root image

we should update it to avoid errors in the pipeline as the current one is too old.

/jira refresh

/override ci/prow/okd-scos-images
broken test

/override ci/prow/e2e-metal-ipi-serial-ipv4
known unrelated issue

/test e2e-metal-ipi-virtualmedia

/lgtm

/label cherry-pick-approved


gollvm: golang.org/x/mod/semver package is not compiling on Ubuntu 20.04 (Github Actions)

Hi.
All jobs for https://github.com/advancedwebdeveloper/clang_test_cpu_features/runs/1446453097 failed.
Here is what I see here:

[1497/2668] Building Go package 'golang.org/x/mod/semver' (non-PIC)
FAILED: tools/gollvm/libgo/golang.org/x/mod/semver.o
cd /home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/build_release/tools/gollvm/libgo && /usr/local/bin/cmake -E make_directory ./golang.org/x/mod && /home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/build_release/./bin/llvm-goc -c -o /home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/build_release/tools/gollvm/libgo/golang.org/x/mod/semver.o -fgo-pkgpath=golang.org/x/mod/semver -I . /home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/golang.org/x/mod/semver/semver.go

Program arguments: /home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/build_release/./bin/llvm-goc -c -o /home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/build_release/tools/gollvm/libgo/golang.org/x/mod/semver.o -fgo-pkgpath=golang.org/x/mod/semver -I . /home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/golang.org/x/mod/semver/semver.go
Running pass 'Function Pass Manager' on module 'gomodule'.
Running pass 'Combine redundant instructions' on function<EMAIL_ADDRESS>Segmentation fault (core dumped)

That's coming from Clang 11.

I can build the package with gccgo using go build.
I'm not sure how to interpret that output but it looks like a middle-end bug.

CC @thanm @cherrymui

My workflow (Github Actions) could be modified, to trace anything that you would require.
Request anything you want - or try to modify the YAML file, within your own repo.
That could allow to reproduce/check some fault scenarios.
@ianlancetaylor , you didn't explain what should I trace/log.
Anything that I should check, ahead of @thanm's investigation?

I'm sorry, I don't know.

Is this a problem only with the Release cmake target? Or do you also see it with DCMAKE_BUILD_TYPE=RelWithDebInfo?

It might no more be reproducible/no issue present - some errors of another kind are observable, during https://github.com/advancedwebdeveloper/clang_test_cpu_features/actions/runs/395799034
As you can observe in the logs - I caught these errors, while using Clang 9:

[1197/2669] Building CXX object tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoSafeGetg.cpp.o
[1198/2669] Building CXX object tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/RemoveAddrSpace.cpp.o
[1199/2669] Building CXX object lib/ProfileData/CMakeFiles/LLVMProfileData.dir/SampleProfWriter.cpp.o
[1200/2669] Building CXX object lib/ProfileData/CMakeFiles/LLVMProfileData.dir/SampleProfReader.cpp.o
[1201/2669] Building CXX object tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GC.cpp.o
[1202/2669] Building CXX object tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoAnnotation.cpp.o
[1203/2669] Building CXX object tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoWrappers.cpp.o
[1204/2669] Building CXX object tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoNilChecks.cpp.o
FAILED: tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoNilChecks.cpp.o
2020-12-02T10:43:03.8272246Z /usr/bin/clang++  -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/gollvm/passes -I/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/passes -Iinclude -I/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/include -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -O2 -g -DNDEBUG    -fno-exceptions -fno-rtti -std=c++14 -MD -MT tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoNilChecks.cpp.o -MF tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoNilChecks.cpp.o.d -o tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoNilChecks.cpp.o -c /home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/passes/GoNilChecks.cpp /home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/passes/GoNilChecks.cpp:361:68: error: no member named 'unknown' in 'llvm::LocationSize'
AA->alias(MemoryLocation(MMO1->getValue(), LocationSize::unknown(),
~~~~~~~~~~~~~~^ /home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/passes/GoNilChecks.cpp:363:68: error: no member named 'unknown' in 'llvm::LocationSize'
MemoryLocation(MMO2->getValue(), LocationSize::unknown(),
~~~~~~~~~~~~~~^
2 errors generated.

.
There is a bug, with GCC:

FAILED: lib/CodeGen/AsmPrinter/CMakeFiles/LLVMAsmPrinter.dir/AsmPrinter.cpp.o
/usr/bin/c++  -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/CodeGen/AsmPrinter -I/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/lib/CodeGen/AsmPrinter -Iinclude -I/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/include -fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -O2 -g -DNDEBUG    -fno-exceptions -fno-rtti -std=c++14 -MD -MT lib/CodeGen/AsmPrinter/CMakeFiles/LLVMAsmPrinter.dir/AsmPrinter.cpp.o -MF lib/CodeGen/AsmPrinter/CMakeFiles/LLVMAsmPrinter.dir/AsmPrinter.cpp.o.d -o lib/CodeGen/AsmPrinter/CMakeFiles/LLVMAsmPrinter.dir/AsmPrinter.cpp.o -c /home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
c++: internal compiler error: Killed (program cc1plus)

. I got the very same bug, as I caught with Clang 9, while using Clang 10:

[1196/2669] Building CXX object tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoNilChecks.cpp.o
FAILED: tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoNilChecks.cpp.o
/usr/bin/clang++-10  -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/gollvm/passes -I/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/passes -Iinclude -I/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/include -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -O2 -g -DNDEBUG    -fno-exceptions -fno-rtti -std=c++14 -MD -MT tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoNilChecks.cpp.o -MF tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoNilChecks.cpp.o.d -o tools/gollvm/passes/CMakeFiles/LLVMCppGoPasses.dir/GoNilChecks.cpp.o -c /home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/passes/GoNilChecks.cpp
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/passes/GoNilChecks.cpp:361:68: error: no member named 'unknown' in 'llvm::LocationSize'
AA->alias(MemoryLocation(MMO1->getValue(), LocationSize::unknown(),
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/passes/GoNilChecks.cpp:363:68: error: no member named 'unknown' in 'llvm::LocationSize'
MemoryLocation(MMO2->getValue(), LocationSize::unknown(),
2 errors generated.
. And the same bug is present with Clang 11, too.

OK, that looks a bit more actionable. I'll send a patch later this morning for the build problem.
For the original issue (crash in Combine redundant instructions) I am able to reproduce that as well, will need to take a closer look.

Yes, your patch resolved the last issue.
I tried to re-run the workflow - and (as you can see) various packages are not compiled.
I am unsure what should be logged.

I just submitted 29d8ea6cf9e08a51f89d72dbeca6c0aed4c2016a, that should resolve the llvm-goc runtime error.

From https://github.com/advancedwebdeveloper/clang_test_cpu_features/commit/e8a830d4c248db0961e0f57f9d61e032efd1cb15/checks/1491324337/logs (Clang 9):

/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/build_relwdebinfo/tools/gollvm/libgo/sigtab.go
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:22:39: error: use of undefined type 'epollevent'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:52:3: error: reference to undefined name 'events'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:52:11: error: reference to undefined name '_EPOLLIN'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:22:39: error: use of undefined type 'epollevent'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:72:4: error: reference to field 'events' in object which has no fields or methods
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:72:14: error: reference to undefined name '_EPOLLIN'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:72:25: error: reference to undefined name '_EPOLLOUT'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:73:34: error: reference to field 'data' in object which has no fields or methods
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:22:39: error: use of undefined type 'epollevent'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:155:8: error: reference to field 'events' in object which has no fields or methods
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:159:37: error: reference to field 'data' in object which has no fields or methods
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:160:9: error: reference to field 'events' in object which has no fields or methods
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:160:20: error: reference to undefined name '_EPOLLIN'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:161:55: error: reference to field 'events' in object which has no fields or methods
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:176:8: error: reference to field 'events' in object which has no fields or methods
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:176:17: error: reference to undefined name '_EPOLLIN'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:176:38: error: reference to undefined name '_EPOLLHUP'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:176:48: error: reference to undefined name '_EPOLLERR'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:179:8: error: reference to field 'events' in object which has no fields or methods
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:179:17: error: reference to undefined name '_EPOLLOUT'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:179:27: error: reference to undefined name '_EPOLLHUP'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:179:37: error: reference to undefined name '_EPOLLERR'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:183:42: error: reference to field 'data' in object which has no fields or methods
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:185:9: error: reference to field 'events' in object which has no fields or methods
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:185:20: error: reference to undefined name '_EPOLLERR'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/signal_unix.go:316:13: error: reference to undefined name '_ITIMER_PROF'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/signal_unix.go:321:13: error: reference to undefined name '_ITIMER_PROF'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/signal_unix.go:498:20: error: reference to undefined name '_SI_USER'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/signal_unix.go:508:20: error: reference to undefined name '_SI_USER'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/signal_unix.go:528:20: error: reference to undefined name '_SI_USER'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/signal_unix.go:534:20: error: reference to undefined name '_SI_USER'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/signal_unix.go:654:20: error: reference to undefined name '_BUS_ADRERR'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/signal_unix.go:664:40: error: reference to undefined name '_SEGV_MAPERR'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/signal_unix.go:664:70: error: reference to undefined name '_SEGV_ACCERR'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/signal_unix.go:675:8: error: reference to undefined name '_FPE_INTDIV'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/signal_unix.go:677:8: error: reference to undefined name '_FPE_INTOVF'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/signal_unix.go:762:92: error: reference to undefined name '_SI_USER'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/signal_unix.go:939:21: error: reference to undefined name '_SI_USER'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/signal_unix.go:1029:17: error: reference to undefined name '_SS_DISABLE'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:22:39: error: use of undefined type 'epollevent'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:22:39: error: use of undefined type 'epollevent'
/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/netpoll_epoll.go:22:39: error: use of undefined type 'epollevent'

.

You can investigate the log for GCC oriented build https://github.com/advancedwebdeveloper/clang_test_cpu_features/commit/e8a830d4c248db0961e0f57f9d61e032efd1cb15/checks/1491324454/logs - it looks like the compilation process itself crashes:

FAILED: lib/CodeGen/AsmPrinter/CMakeFiles/LLVMAsmPrinter.dir/AsmPrinter.cpp.o
2020-12-03T09:00:19.1123741Z /usr/bin/c++  -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/CodeGen/AsmPrinter -I/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/lib/CodeGen/AsmPrinter -Iinclude -I/home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/include -fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -O2 -g -DNDEBUG    -fno-exceptions -fno-rtti -std=c++14 -MD -MT lib/CodeGen/AsmPrinter/CMakeFiles/LLVMAsmPrinter.dir/AsmPrinter.cpp.o -MF lib/CodeGen/AsmPrinter/CMakeFiles/LLVMAsmPrinter.dir/AsmPrinter.cpp.o.d -o lib/CodeGen/AsmPrinter/CMakeFiles/LLVMAsmPrinter.dir/AsmPrinter.cpp.o -c /home/runner/work/clang_test_cpu_features/clang_test_cpu_features/clang_test_cpu_features/llvm-project/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
c++: internal compiler error: Killed (program cc1plus)

@thanm, which verbosity options should be enabled?
I am not familiar with GCC, really.

I am confirming that go.googlesource.com/gollvm/+/29d8ea6cf9e08a51f89d72dbeca6c0aed4c2016a allowed to build gollvm with Clang 10:
https://github.com/advancedwebdeveloper/clang_test_cpu_features/runs/1491324386?check_suite_focus=true
. Same for Clang 11:
https://github.com/advancedwebdeveloper/clang_test_cpu_features/runs/1491324420?check_suite_focus=true
.
Everybody dance now :)

I just tried to build for "release" - and I didn't get that issue, with GCC, any more:
https://github.com/advancedwebdeveloper/clang_test_cpu_features/runs/1491760391?check_suite_focus=true
. All tests passed successfully.
Clang 10 and Clang 11 built gollvm successfully, as before.
Not sure if it makes sense to support Clang 9.
Thanks for assisting/patching.
Closing this.


How many scenes are there in your selected data for RealEstate10k?

Hi! Thanks for your great work.
I know there are 10k scenes(80k video subsets) in the original dataset. I wonder if you selected all the scenes in your download scripts(500GB)?

The versions of Real Estate 10k and ACID we used contain the following number of clips:
Real Estate 10k
Train: 66033 clips
Test: 7286 clips

ACID
Train: 11069 clips
Test: 1972 clips

The number of clips available to us was slightly smaller than the full number of clips because some of the YouTube videos in the original Real Estate 10k and ACID datasets were no longer available when we tried to download them.
It's worth noting that the 500 GB size is for compressed videos at 640x360 resolution.

Thanks


Add WikiCREM

Adding a Dataset

Name: WikiCREM
Description: A large unsupervised corpus for coreference resolution.
Paper: https://arxiv.org/abs/1905.06290
Github repo:: https://github.com/vid-koci/bert-commonsense
Data: https://ora.ox.ac.uk/objects/uuid:c83e94bb-7584-41a1-aef9-85b0e764d9e3
Motivation: Coreference resolution, common sense reasoning

Instructions to add a new dataset can be found here.

Hi @NielsRogge I would like to work on this dataset.
Thanks!

Hi @udapy, are you working on this?


[typespec-pr] Remove parameter "SourceBranch"

Parameter is unnecessary since pipeline has already checked out SourceBranch

I think keeping it for local testing might still be beneficial?

I think keeping it for local testing might still be beneficial?

I don't think it's necessary (just checkout the source branch first), but we could keep it as an optional parameter if you really want.  I also created this PR in preparation for another PR to allow manually specifying the target branch, but if we can somehow find the target branch automatically, it might not be necessary.

I think keeping it for local testing might still be beneficial?

I don't think it's necessary (just checkout the source branch first), but we could keep it as an optional parameter if you really want. I also created this PR in preparation for another PR to allow manually specifying the target branch, but if we can somehow find the target branch automatically, we might not need this PR either.

I think keeping source as optional is useful especially for us. if we're working on the tool itself in a branch, and want to do a test branch targeting main.
As to finding target branch automatically, I'm not sure if that's doable for local dev situations