Build ARM64 version of ddev

Describe the bug
I'm currently attempting to get ddev to run on my arm processor powered Pinebook Pro.  I was able to get both docker and docker-compose installed, but the binary for ddev is most likely built just for x86.
To Reproduce
Steps to reproduce the behavior:

Install docker/ docker-compose for arm
Install ddev via the https://ddev.readthedocs.io/en/latest/#installationupgrade-script-linux-and-macos command
Attempt to run ddev

Expected behavior
Basic help to display for ddev commands arguments
Actual behavior
$ ddev
bash: /usr/local/bin/ddev: cannot execute binary file: Exec format error
Version and configuration information (please complete the following information):

Host computer OS and Version: Ubuntu Mate, 18.04
Docker version information: Docker version 19.03.5, build 633a0ea
ddev version information: unable to run

Additional context
As mentioned above, I'm on the Pinebook Pro, an Arm powered machine, which I suspect is my main issue.  If someone could point me in the right direction for how to compile for arm, that would awesome for my (very small) use-case.

It looks like since Docker now supports Arm, it ought to be possible. Are you able to do ordinary things with Docker?
Doesn't the pinebook have pretty limited memory?

The specs look pretty limited, https://www.pine64.org/pinebook-pro/

Please try this out, https://www.dropbox.com/s/013wn7xyb5zzpss/ddev_arm_v1.12.0-rc1.tar.gz?dl=0

@rfay , this got me much closer!  DDev is running now, but fails on the ddev-ssh-agent build.  I disabled that via omit_containers key in my ./ddev/config.yaml, but then the build fails on the db container  build.

Specs are definitely limited (4GB of Ram, hexacore ~2GHz arm).
I'm not very familiar with docker, so if there's some sort of arm processor override or specific tag I should be using, please let me know.

Could you show the error output on trying to get the ddev-ssh-agent going? Thanks.

Note: I deleted all my docker images and started again with a brand new ddev project.
$ PATH_TO_CUSTOM_DDEV\ddev config
Creating a new ddev project config in the current directory (/home/rock64/projects/tmp)
Once completed, your configuration will be written to /home/rock64/projects/tmp/.ddev/config.yaml
Project name (tmp):
The docroot is the directory from which your site is served.
This is a relative path from your project root at /home/rock64/projects/tmp
You may leave this value blank if your site files are in the project root
Docroot Location (current directory):
Found a php codebase at /home/rock64/projects/tmp.
Project Type [drupal8, wordpress, typo3, backdrop, php, drupal6, drupal7] (php):
Project type has no settings paths configured, so not creating settings file.
Configuration complete. You may now run 'ddev start'.
Instrumentation is opted in, but SentryDSN is not available.
Instrumentation is opted in, but SegmentKey is not available.
$ PATH_TO_CUSTOM_DDEV\ddev start
[Process pulls a bunch of docker images]
.
.
.
Building ddev-ssh-agent
Service 'ddev-ssh-agent' failed to build: The command '/bin/sh -c (groupadd --gid $gid "$username" || groupadd "$username" || true) && (useradd  -l -m -s "/bin/bash" --gid "$username" --comment '' --uid $uid "$username" || useradd  -l -m -s "/bin/bash" --gid "$username" --comment '' "$username")' returned a non-zero code: 1
Failed to start tmp: failed to start ddev-ssh-agent: Failed to run docker-compose [-f /home/rock64/.ddev/ssh-auth-compose.yaml -p ddev-ssh-agent up --build --force-recreate -d], err='exit status 1', stdout='Step 1/6 : ARG BASE_IMAGE
Step 2/6 : FROM $BASE_IMAGE
---> 5780ca23a654
Step 3/6 : ARG username
---> Running in 6a49fa76627c
Removing intermediate container 6a49fa76627c
---> c866371ff094
Step 4/6 : ARG uid
---> Running in 65834d1fa611
Removing intermediate container 65834d1fa611
---> d52ced7f0ac5
Step 5/6 : ARG gid
---> Running in 0841557ce8f1
Removing intermediate container 0841557ce8f1
---> ffc6260f8f74
Step 6/6 : RUN (groupadd --gid $gid "$username" || groupadd "$username" || true) && (useradd  -l -m -s "/bin/bash" --gid "$username" --comment '' --uid $uid "$username" || useradd  -l -m -s "/bin/bash" --gid "$username" --comment '' "$username")
---> Running in 89457e7ceb8d
standard_init_linux.go:211: exec user process caused "exec format error"
', stderr='Building ddev-ssh-agent
Service 'ddev-ssh-agent' failed to build: The command '/bin/sh -c (groupadd --gid $gid "$username" || groupadd "$username" || true) && (useradd  -l -m -s "/bin/bash" --gid "$username" --comment '' --uid $uid "$username" || useradd  -l -m -s "/bin/bash" --gid "$username" --comment '' "$username")' returned a non-zero code: 1'

I wonder if it's possible that Docker on Arm expects to run arm-based images.
Could you try docker run -it --rm drud/ddev-ssh-agent:v1.12.0 bash
When you're in there, try running "groupadd someuser" and just "sh"
It does look like from https://engineering.docker.com/2019/06/getting-started-with-docker-for-arm-on-linux/ that you may have to take extra steps to run x86 images on Arm.

rock64@pinebookpro:~/projects$ docker run -it --rm drud/ddev-ssh-agent:v1.12.0 bash
Unable to find image 'drud/ddev-ssh-agent:v1.12.0' locally
v1.12.0: Pulling from drud/ddev-ssh-agent
be50d4e619fe: Already exists
e7529b48149b: Already exists
7a33dcda49ce: Already exists
53957f29cead: Already exists
e662ace2460c: Already exists
744a9ace49aa: Already exists
991a64fc324a: Already exists
Digest: sha256:e0617ddecb05f2ee8981cbc0a8b1f8595034fe1094d7e57bf16e962c67446d6a
Status: Downloaded newer image for drud/ddev-ssh-agent:v1.12.0
standard_init_linux.go:211: exec user process caused "exec format error"
Thanks, I'll take a look at the building portion and see if I can build the containers locally.  It's not something I'm super familiar with, but I have a hard head and I can bang it through most walls.
Thanks for the quick replies (and for the super helpfuly tool of ddev)

Yep, that's saying that the program "bash" inside the container is of the wrong architecture.
Besides building the containers yourself, the other option is to figure out how to run amd64 docker images on ARM.

Based on your discoveries I'm going to close this for now. Happy to support ongoing research here or elsewhere,.

I hope you'll be able to try out the current alphas on your pinebook, I'd love to hear your experience.

Sorry for the long delay,
I was able to pull the repo and make the master branch on my pinebook pro.  After moving the ddev executable, ddev functioned as it does on my x86 machine.  I was able to build out both a plain PHP site (GravCMS) as well as a MySQL based one (WP).
Congratulations!

I should also note that I had migrated from Ubuntu Mate on the PinebookPro to Manjaro, as it had better package support for some of my other requirements.  I did not try the arm build of ddev on Ubuntu Mate.

DDEV v1.16.0 is already released and can be used! Don't have to do any building. But since homebrew isn't out there, the best way to install is with the install_ddev.sh script, which pulls the right architecture.


Valid is true after syncErrors are set

Are you submitting a bug report or a feature request?
bug report
What is the current behavior?
When my component updates it runs validation; redux form dispatches UPDATE_SYNC_ERRORS and that triggers an update in my component. When I check nextProps.valid in componentWillReceiveProps it is true even though my form state has syncErrors.
What is the expected behavior?
nextProps.valid should be false when updating based on the dispatch to UPDATE_SYNC_ERRORS.
What's your environment?

redux-form version 6.4.3
Other informations

In troubleshooting I noticed that there are certain props that the redux-form connect component will not update for, including syncErrors. If I take syncErrors out of propsToNotUpdateFor then my component works as expected.

On further inspection, I realized that I am setting pure: false in my form, so the propsToNotUpdateFor is not an issue here.

So it seems that updating to the latest release has fixed this issue for me, surprisingly. Closing this.


Other Organizations: Link to Cases Broken

Click the "Cases Overdue" link.
Error: 404 page.
Should go to a link like: https://www.crisiscleanup.org/incident/254/work/new?showTable=true&work_type__claimed_by=426&work_type__status__in=open_unassigned,open_unresponsive,open_assigned,open_needs-follow-up,open_partially-completed&created_at__lte=2023-02-18T15%3A57%3A30.361Z
Note: I'm not sure if this functionality has been enabled on /work. It's currently going to /cases.

This issue is partially fixed by #119
The filters passed by /other_organizations page aren't loading on the worksite view page.

This still doesn't work on Staging...

This works, but creates a new issue: There is no way to turn it off :-). Closing this one and opening a new issue.


doc(styles): footer cuts off the sidebar

On a normal laptop screen (any viewport with a height less than 800px or so), the new documentation website has layout issues:

The position: fixed sidebar is overlapped by the sticky footer when you scroll to the bottom of the page.

Fixed in #494


多集群交付应用然后删除application PHASE一直处于deleting

vela veriosn  1.6.2
手动删除应用后application一直存在 且PHASE 是deleting
$ k get application.core.oam.dev  | grep deleting
multi-cluster-addon-fluxcd                    flux-system-namespace   raw           deleting         true               3h39m

应用定义：
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: multi-cluster-addon-fluxcd
  namespace: control-system
spec:
  components:
    - name: flux-system-namespace
      type: raw
      properties:
        ----
        ----
  policies:
  - name: topology-vela-clusters
    type: topology
    properties:
    - name: topology-clusters
      type: topology
      properties:
        clusterLabelSelector:
           xxx:xxx

事件错误信息：
Warning  FailedGC  5m38s               Application  failed to sweep resourcetrackers to be deleted: failed to get resource ....: dial tcp xxx.xxx.xxx: connect: connection timed out

Seems your application is unable to clean up the target resource because the remote cluster lost connection?

Seems your application is unable to clean up the target resource because the remote cluster lost connection?

也许是连接丢失了 ，我认为在丢失连接的时候应该不影响其他集群的操作，当前的现象是卡住不动了

For this application, you are trying to delete it. If one of the cluster (where the application has resources in) lost connection, it will block the deletion of this application. The other applications that do not use this broken cluster should not be affected.
The reason for the blocking of deletion is one of our design. Because there could be scenarios when cluster lost connection but join back later. In this case we do not want the application to skip the resource recycle in the temporarily lost cluster. But it does cause some inconvenience for the usage. We are planning to make some optimization to help improve the experiences but the blocking behaviour will remain the same.


(x-ui) user._id from guardian is a string, should be an ObjectId

We should automatically cast it like that from the response from me query. If someone wants to override this behavior they have their own Guardian and introduce their own retrieveUser.

In the same breath I think we should also allow an option at XUIBundle castUserId , document it, and by default the castUserId uses @bluelibs/ejson to make it an ObjectId.

Fixed.


Problem in displaying columns properly in Outlook

Describe the bug
I'm having trouble showing an email template properly in Outlook 2016 desktop version.
I've read all the existing and closed issues regarding this.
I've added the owa="desktop" attribute to mjml tag
<mjml></mjml>
<mjml owa="desktop">
     ......
</mjml>

although it's only for the online version of Outlook.
I've checked my columns widths and they don't exceed 100% inside a section.
I still can't view my email template properly in Outlook.
I'm using Mailgun for sending emails.
To Reproduce
Open the email in Outlook
Expected behavior
The expected layout should look like this:

But it looks this way in Outlook:

MJML environment (please complete the following information):

OS: Windows
MJML Version 4.6.3
MJML tool used MJML via npm commands

Email sending environment(for rendering issues):

Mailgun

Affected email clients (for rendering issues):

Email Client: Outlook 2016
OS: Windows
Browser: IE

My mjml code is:
<mjml></mjml>
<mjml owa="desktop">
  <mj-head>
    <mj-include path="./theme.mjml" />
    <mj-style inline="inline">
      .image-contained img { width: auto !important; object-fit: scale-down !important; max-width:
      120px !important;}
    </mj-style>
  </mj-head>
  <mj-body background-color="#fff" width="90%">
    <mj-section background-color="#004b98" padding="25px">
      <mj-column width="100%">
        <mj-text color="#fff" mj-class="h3"> Order has been placed! </mj-text>
        <mj-text color="#fff" mj-class="body1">
          Your order has been successfully placed! You will receive an update when your order has
          been shipped.
        </mj-text>
      </mj-column>
    </mj-section>
    <mj-section> </mj-section>

    <mj-section padding="0px">
      <mj-group width="100%">
        <mj-column mj-class="box-bordered" width="48%">
          <mj-text mj-class="box-title">order details</mj-text>
          <mj-text mj-class="box-subtitle">ship to</mj-text>
          <mj-text mj-class="box-body"> {{shippingAddress.address.addressLine1}} </mj-text>
          <mj-raw> {{#if shippingAddress.address.addressLine2}} </mj-raw>
          <mj-text mj-class="box-body"> {{shippingAddress.address.addressLine2}} </mj-text>
          <mj-raw> {{/if}} </mj-raw>
          <mj-text mj-class="box-body">
            {{shippingAddress.address.city}}, {{shippingAddress.address.state}}
            {{shippingAddress.address.zipCode}}
          </mj-text>
          <mj-raw> {{#if shippingAddress.attention}} </mj-raw>
          <mj-text mj-class="box-body">ATTN: {{shippingAddress.attention}} </mj-text>
          <mj-raw>{{/if}}</mj-raw>
        </mj-column>
        <mj-column width="4%"></mj-column>
        <mj-column mj-class="box-bordered" width="48%">
          <mj-text mj-class="box-title">shipping details</mj-text>
          <mj-text mj-class="box-subtitle">shipping method</mj-text>
          <mj-text mj-class="box-body">{{shippingServiceOption.name}}</mj-text>
        </mj-column>
      </mj-group>
    </mj-section>

    <mj-section padding="20px 0px 0px 0px">
      <mj-group width="100%">
        <mj-column mj-class="box" width="48%">
          <mj-text mj-class="box-subtitle" padding-left="0px" padding-top="0px">notes</mj-text>
          <mj-text mj-class="box-body" container-background-color="lightgrey" font-size="13px">
            {{note}}
          </mj-text>
        </mj-column>
        <mj-column width="4%"></mj-column>
        <mj-column mj-class="box-bordered" padding-top="10px" width="48%">
          <mj-text mj-class="box-body-flex">

Shipping Cost

TBD

          </mj-text>
          <mj-text mj-class="box-body-flex">

Taxes

TBD

          </mj-text>
          <mj-divider />
          <mj-text mj-class="box-subtitle" padding-right="15px" font-size="12px">

ORDER TOTAL

                <mj-raw>${{#if orderTotal}} {{orderTotal}} {{else}} 0 {{/if}}</mj-raw>

          </mj-text>
        </mj-column>
      </mj-group>
    </mj-section>

    <mj-section> </mj-section>
    <mj-section border="solid 1px lightgrey" padding="0px">
      <mj-column width="100%">
        <mj-text mj-class="box-title">Order #{{orderNumber}}</mj-text>
        <mj-raw> {{#if erpOrderNumber}} </mj-raw>
        <mj-text mj-class="box-title">ERP order number: {{erpOrderNumber}}</mj-text>
        <mj-raw> {{/if}} </mj-raw>
      </mj-column>
    </mj-section>
    <mj-section border="solid 1px lightgrey" padding="5px">
      <mj-raw>{{#each items}}</mj-raw>
      <mj-group width="100%">
        <mj-column width="17%" padding="5px" vertical-align="middle">
          <mj-image
            src="https://{{../STORAGE_VTS}}/public/{{product._id}}/0-thumbnail?imgVersion={{product.imgVersion}}"
            height="80px"
            css-class="image-contained"
          >
          </mj-image>
        </mj-column>
        <mj-column width="55%" padding-left="5px">
          <mj-text mj-class="box-subtitle" text-transform="none"> {{product.name}} </mj-text>
          <mj-text mj-class="box-body" color="grey">SKU: {{product.sku}}</mj-text>
        </mj-column>
        <mj-column width="10%">
          <mj-text mj-class="box-subtitle" padding-left="0px">QTY</mj-text>
          <mj-text mj-class="box-body" padding-left="0px">{{quantity}}</mj-text>
        </mj-column>
        <mj-column width="18%">
          <mj-text mj-class="box-subtitle" align="right" padding-right="5px">Item Total</mj-text>
          <mj-text padding="5px" font-weight="bold" font-size="12px" align="right">
            ${{totalPrice}}
          </mj-text>
        </mj-column>
      </mj-group>
      <mj-raw>{{#unless @last}}</mj-raw>
      <mj-column width="100%">
        <mj-divider />
      </mj-column>
      <mj-raw>{{/unless}}</mj-raw>
      <mj-raw>{{/each}}</mj-raw>
    </mj-section>
  </mj-body>
</mjml>

theme.mjml file:
<mj-attributes>
  <mj-text align="center" />
  <mj-class name="h3" font-size="34px" line-height="43px" font-weight="700" />
  <mj-class name="h4" font-size="24px" line-height="30px" font-weight="400" />
  <mj-class name="h5" font-size="16px" line-height="18px" font-weight="600" />
  <mj-class name="body1" font-size="14px" line-height="17px" font-weight="300" />
  <mj-class name="ps" font-size="12px" line-height="14px" font-weight="300" color="grey" />
  <mj-class name="box-bordered" border="1px solid lightgrey" padding-bottom="10px" />
  <mj-class name="box" padding-bottom="10px" />
  <mj-class
    name="box-title"
    font-size="12px"
    font-weight="bold"
    padding="20px"
    padding-left="15px"
    align="left"
    container-background-color="lightgrey"
    text-transform="uppercase"
  />
  <mj-class
    name="box-subtitle"
    font-size="12px"
    font-weight="bold"
    padding="8px"
    padding-left="15px"
    padding-top="15px"
    align="left"
    text-transform="uppercase"
  />
  <mj-class name="box-body" font-size="12px" padding="5px" padding-left="15px" align="left" />
  <mj-class
    name="box-body-flex"
    font-size="12px"
    padding="5px"
    padding-left="15px"
    padding-right="15px"
    align="left"
  />
  <mj-class
    name="box-body-small"
    font-size="9px"
    padding="5px"
    padding-left="15px"
    align="left"
    font-color="lightgrey"
  />
  <mj-divider border-width="1px" border-color="lightgrey" padding="10px 10px" />
</mj-attributes>

I'd really appreciate it if you'd help me with this. I've already put a lot of time on it and couldn't fix it. Thanks

mj-body doesn't support width in % that's why it does break on outlook.
You should iterate over mj-section for your  <mj-raw>{{#each items}}</mj-raw> instead of mj-group because it will generate more than 100% of content inside a section ( if you have 4 items it goes 400%, browsers know how to handle it, but not Outlook it will put everything on the same line as it's wrapped into a table)

Thank you so much @iRyusa.
I removed the width attribute from mj-body , and changed the iteration like this:
<mj-raw>{{#each items}}</mj-raw>
    <mj-section border="solid 1px lightgrey" padding="5px">
      <mj-column width="17%" padding="5px" vertical-align="middle">
        <mj-image
          src="https://{{../STORAGE_VTSPROJECTS3PRODUCTIMAGES_CFDISTRIBUTIONDOMAINNAME}}/public/{{product._id}}/0-thumbnail?imgVersion={{product.imgVersion}}"
          height="80px"
          css-class="image-contained"
        >
        </mj-image>
      </mj-column>
      <mj-column width="55%" padding-left="5px">
        <mj-text mj-class="box-subtitle" text-transform="none"> {{product.name}} </mj-text>
        <mj-text mj-class="box-body" color="grey">SKU: {{product.sku}}</mj-text>
      </mj-column>
      <mj-column width="10%">
        <mj-text mj-class="box-subtitle" padding-left="0px">QTY</mj-text>
        <mj-text mj-class="box-body" padding-left="0px">{{quantity}}</mj-text>
      </mj-column>
      <mj-column width="18%">
        <mj-text mj-class="box-subtitle" align="right" padding-right="5px">Item Total</mj-text>
        <mj-text padding="5px" font-weight="bold" font-size="12px" align="right">
          ${{totalPrice}}
        </mj-text>
      </mj-column>
    </mj-section>
<mj-raw>{{/each}}</mj-raw>

It looks a little better in Outlook, but still the upper grouped columns and also the bottom columns inside the section for <mj-raw>{{#each items}}</mj-raw> break and don't stay side-to-side

Looks like you're forwarding your email too that can break a lot of stuff on Outlook.

@iRyusa I just tested it by sending the email directly to my Outlook account. It looks fine now. Thank you SOOO much for your help.


fix: store peer dependencies

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/ngneat/elf/blob/master/CONTRIBUTING.md#commit
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

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

What is the current behavior?

Currently this package causes typescript to be a production dependency.
Issue Number: N/A
What is the new behavior?
Now typescript wont be considered a production dependency which can be ignored when running npm ci --omit=dev. Also I added rxjs as a peer dependency as it is actually needed by the store.
Does this PR introduce a breaking change?
[ ] Yes
[ ] No

Other information

RxJS peer dependency is >=7.


[WIP][SPARK-35521][INFRA] List Python 3.8 installed libraries in build_and_test workflow

What changes were proposed in this pull request?

In the build_and_test workflow, tests are run against both Python 3.6 and Python 3.8. However, only libraries installed in Python 3.6 are listed. We should list Python 3.8's installed libraries as well.
Why are the changes needed?

Listing Python 3.8's installed libraries is helpful to debugging.
Does this PR introduce any user-facing change?

No.
How was this patch tested?

Manual check.

Test build #138937 has started for PR 32663 at commit effe01a.

CC @HyukjinKwon

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43458/

Test build #138939 has started for PR 32663 at commit 3717bde.

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43458/

There is another PR to upgrade Python to 3.9 in which the library list will be shown. #32657

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43460/

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

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43460/

Test build #138937 has finished for PR 32663 at commit effe01a.

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

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

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

Test build #138939 has finished for PR 32663 at commit 3717bde.

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

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

Let's drop this for now since now we upgraded it to Python 3.9, and don't run the tests with Python 3.8 now.


Slow response for OpenSourceApp() [cpu]

It takes a very long time to get the response with OpenSourceApp from embedchain==0.0.17, around 100 secs, is this normal?

Closing this issue as OpenSourceApp is no longer available.


Fixed PR template

What do these changes do?
Fixed typo in PR template

Current coverage is 98.77% (diff: 100%)

Merging #1328 into master will not change coverage

@@             master      #1328   diff @@
==========================================
  Files            29         29
  Lines          6521       6521
  Methods           0          0
  Messages          0          0
  Branches       1092       1092
==========================================
  Hits           6441       6441
  Misses           36         36
  Partials         44         44

Powered by Codecov. Last update 4294067...385da5b

Thanks


Multiple Duplicate Notifications

Summary of Issue
When an Event has multiple set Reminders, the notification gets pushed n-Reminder times, where n=Number of Reminders.
How to Repeat
Not too sure, at this time, it seems that when the notification gets pushed and then the event gets moved till later, the notification gets pushed n-Reminder times.

Set an Event with 2 Reminders
Wait till one Reminder Goes off
Move event till later and add another Reminder
When Reminder gets triggered, n-Reminders Pop-up

Issue fixed in Commit 995e345


Indiescripter/upgrade husky

The only real commits in this husky upgrade were
build: update husky v7.0.2, lint-staged v11.1.2
build: husky v7.0.2 did not install git hooks; try v4.3.5

However I did do a rebase against Indiescripter/upgrade webpack (#2409) which makes merging into master without conflicts.
It's a new approach I've been thinking about with serialising PRs and linearising into master. This approach has pros and cons, the main downside being that you might end up with duplicate commit messages. Hmm, I am not sure.
Anyway please deal with this PR in order which means after dealing with the previous one #2409.
Note:
husky started getting broken after v4.3.5. It's not at v7.x.x because of an install problem which I reported ages ago and is still not fixed. I noticed that after v4.3.5 it started failing to install git hooks during package manager install lifecycle.

husky started getting broken after v4.3.5. It's not at v7.x.x

I've migrated few projects to v7 and is quite different, we might need to run several test locally before moving to such version.


Handle event exceptions in caledar

This ensures that we backup and restore and exceptions in the recurring events. One thing pending here is fixing up the attachments. I hope to create that as a separate PR. This can probably go in separately as well.

Does this PR need a docs update or release note?

[x] :white_check_mark: Yes, it's included
[ ] :clock1: Yes, but in a later PR
[ ] :no_entry: No

Type of change

[x] :sunflower: Feature
[ ] :bug: Bugfix
[ ] :world_map: Documentation
[ ] :robot: Supportability/Tests
[ ] :computer: CI/Deployment
[ ] :broom: Tech Debt/Cleanup

Issue(s)

https://github.com/alcionai/corso/issues/2835

Test Plan

[ ] :muscle: Manual
[x] :zap: Unit test
[x] :green_heart: E2E

Hmm, I was going by the precedent that we set for permissions where we did not bump the version and letting it only update the data when there is a change. 🤔

Thanks a good point, I sort of forgot about that. I guess since there's no guarantee we'd pick up the new data it's fine to skip it. Sort of a bummer overall though since it will make debugging a bit more difficult

I guess since there's no guarantee we'd pick up the new data it's fine to skip it.
Not sure what you meant by this. 🤔

PS: @ryanfkeepers this should now be good to go!

Not sure what you meant by this. 🤔

oops sorry, it's fine to skip the version bump since we'll end up with mixed data anyway


update djinni, support lib and projects

Codecov Report
Patch and project coverage have no change.

Comparison is base (5f9e301) 100.00% compared to head (9725339) 100.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff            @@
##              main       #34   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            3         3
  Lines           13        13
=========================================
  Hits            13        13

Impacted Files
Coverage Δ

...enerated-src/cpp/nativium/core/ApplicationCore.hpp
100.00% <ø> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


iconv not found

When I have tried to build WavPack under development environment which is separated from os system libraries, wav pack's configure "--with-iconv=$DEV_HOME" can not find libiconv that actually exists in $DEV_HOME/lib
I could fix this problem by adding a line into configure.ac like below...
    diff configure.ac configure.ac.org
    85d84
    < 			CFLAGS="${ICONV_CFLAGS} ${CFLAGS}"

Thanks for reporting this! I have to admit that I really don't understand this configure stuff very well, but your change seems to make sense.
However, in that same section there seems to be some stuff to save the old LDFLAGS and LIBS (in old_ldflags, etc). Should I add that for CFLAGS also then? Sorry I'm so clueless about this!  :)

It seems CFLAGS only problem that I have mentioned.

I have committed a fix for this, including your patch line and what I talked about saving CFLAGS. If convenient, please let me know if this works okay. Thanks again for reporting and the patch!

Thanks, the problem has gone.

Thanks. I'll close the issue.


Failed passing 686. Repeated String Match

Hi, @aQuaYi. Your solution doesn't pass all the latest test cases(51/55).
Input:
"abc"
"cabcabca"
Output:
-1
Expected:
4

Mind me to pull a request?

@zhongqin0820 thanks for pull request


我发现了一个bug

我尝试使用c++示例库中的程序，但是连接设备这个一部分总是不行，无法连接上设备，是不是代码有错误，我已尝试了许多次，好像python也有相同的情况。

can you please provide more specific information.  what exactly is not working?
do you have a way for me to try to reproduce the problem?

主要的问题是，如果整个程序中有连接设备的代码，那么这个程序就无法执行，或者是闪一下就没有了（在模拟器中执行），我觉得可能是变量的类型有问题，也可鞥能是示例代码有错误，我是直接使用示例代码的。

@AstroAir I see that you closed this issue. What was the resolution?

@agalasso I open this issue again .I am thinking about how to write a API to recive message from PHD2 instead of using telnet (This is too slow,and work not very well).
I found this code in https://github.com/agalasso/phd2client/blob/master/cxx/guider.cpp:
else if (e == "GuideStep")     {         GuideStats stats;         if (accum_active)         {             accum_ra.Add(ev["RADistanceRaw"].asDouble());             accum_dec.Add(ev["DECDistanceRaw"].asDouble());             accum_get_stats(&stats, accum_ra, accum_dec);         }         std::unique_lock<decltype(m_mutex)> _lock(m_mutex);         AppState = "Guiding";         AvgDist = ev["AvgDist"].asDouble();         if (accum_active)             Stats = stats;     }
but this did not write in https://github.com/agalasso/phd2client/blob/master/cxx/guider.h,so I could not use it.And I also found a bug in guider.h."#include <jsoncpp/json/json.h>" did not exit.It should change into "#include <json/json.h>".


format limits safely check data references

When using {... $data: true } options in ajv, the checks for "format" and format...Exclusive schemas being data references results in exceptions since the schema is treated as an object when it could be a string.

Coverage remained the same at 100.0% when pulling a9ba005a27387b8c41a716f0ad5170da63a4247e on lochiego:master into f8acbecff0fcc3105822219749b011f291c203e4 on epoberezkin:master.

There are tests for both string and object in these keywords - they pass.
Could you please post the example that throws exception, ideally into runkit.com?

format limits are now in ajv-formats


Chris/parser.ts

Creates a base, functional parser. Still needs work in regards to pulling oneway data bound variables.

Good stuff!!!


Release/tf melhorias

Terraform Format and Style 🖌success
Terraform Initialization ⚙success
Terraform Validation 🤖success
Terraform Plan 📖success
Show Plan
```terraform
aws_db_instance.mssql-techlanches-instance: Refreshing state... [id=db-TOHX7Z2X2BNXEE35RQT2TNZHPI]
Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
~ update in-place
Terraform will perform the following actions:
aws_db_instance.mssql-techlanches-instance will be updated in-place
~ resource "aws_db_instance" "mssql-techlanches-instance" {
id                                    = "db-TOHX7Z2X2BNXEE35RQT2TNZHPI"
~ tags                                  = {
~ "Environment" = "Dev" -> "Prod"
"ManagedBy"   = "Terraform"
"Name"        = "TechLanches MSSQL Server Database"
"Repository"  = "https://github.com/g12-4soat/techlanches-infra-db"
}
~ tags_all                              = {
~ "Environment" = "Dev" -> "Prod"
# (3 unchanged elements hidden)
}
# (51 unchanged attributes hidden)
    # (1 unchanged block hidden)
}

Plan: 0 to add, 1 to change, 0 to destroy.
─────────────────────────────────────────────────────────────────────────────
Note: You didn't use the -out option to save this plan, so Terraform can't
guarantee to take exactly these actions if you run "terraform apply" now.
</details>
*Pushed by: @gabriellima09, Action: `pull_request`*

Terraform Format and Style 🖌success
Terraform Initialization ⚙success
Terraform Validation 🤖success
Terraform Plan 📖success
Show Plan
```terraform
aws_db_instance.mssql-techlanches-instance: Refreshing state... [id=db-TOHX7Z2X2BNXEE35RQT2TNZHPI]
Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
~ update in-place
Terraform will perform the following actions:
aws_db_instance.mssql-techlanches-instance will be updated in-place
~ resource "aws_db_instance" "mssql-techlanches-instance" {
id                                    = "db-TOHX7Z2X2BNXEE35RQT2TNZHPI"
~ tags                                  = {
~ "Environment" = "Dev" -> "Prod"
"ManagedBy"   = "Terraform"
"Name"        = "TechLanches MSSQL Server Database"
"Repository"  = "https://github.com/g12-4soat/techlanches-infra-db"
}
~ tags_all                              = {
~ "Environment" = "Dev" -> "Prod"
# (3 unchanged elements hidden)
}
# (51 unchanged attributes hidden)
    # (1 unchanged block hidden)
}

Plan: 0 to add, 1 to change, 0 to destroy.
─────────────────────────────────────────────────────────────────────────────
Note: You didn't use the -out option to save this plan, so Terraform can't
guarantee to take exactly these actions if you run "terraform apply" now.
</details>
*Pushed by: @gabriellima09, Action: `pull_request`*


Issue starting ACS Commons bulk workflow with smart tag workflow

Required Information

[x] AEM Version, including Service Packs, Cumulative Fix Packs, etc: 6.4 L21
[x] ACS AEM Commons Version: 3.11+
[x] Reproducible on Latest? yes

Expected Behavior
I would really like to run bulk workflow for smart tags.
Actual Behavior
It acts like it's starting, creates an action manager (using multi-threaded mode with Query Builder) and it just dies.  Found this error in the log:
javax.jcr.RepositoryException: Invalid name or path: /var/workflow/models//var/workflow/models/dam/dam-autotag-assets
	at org.apache.jackrabbit.oak.jcr.session.SessionContext.getOakPathOrThrow(SessionContext.java:375) ```

is that the full stack trace?
On Wed, Mar 7, 2018 at 6:55 PM Gary<EMAIL_ADDRESS>wrote:

Here is the settings we used.
[image: 2018-03-07_14-50-03]
https://user-images.githubusercontent.com/33269737/37125100-e706bed2-221f-11e8-9e9f-add7886b3248.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/1276#issuecomment-371328255,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEBcsy-UFTvI6iuHpHBHEEvzbad21o-ks5tcHOEgaJpZM4Shuyk
.

+1 to adding the full stack trace - took a look at the synth code and not clear where that would be happening (thought there are static references to the pre-6.4 /etc/workflow/models that needs adjusting; but are not this issue)

I'm pretty sure it's whatever converts that numeric value into a workflow path.  The UI doesn't have the workflow paths as selection values, so it's whatever happens on the other side of the POST of the setup part, I think.  Probably affects synthetic and plain workflow the same way because neither of them worked.


Live Share appears to be scanning my Keybase directories

Describe what happened:
After joining a Live Share session, my local Keybase folders are scanned, triggering notifications.
Keybase is an encryption tool which creates some virtual mounts for encrypted folders:
$ ls -al /keybase
total 0
lr-xr-xr-x 1 root root 0 Apr  7 18:40 private -> /run/user/1000/keybase/kbfs/private
lr-xr-xr-x 1 root root 0 Apr  7 18:40 public -> /run/user/1000/keybase/kbfs/public
lr-xr-xr-x 1 root root 0 Apr  7 18:40 team -> /run/user/1000/keybase/kbfs/team

I am receiving notifications that /keybase/public/bin, /keybase/private/bin and /keybase/private/scripts are being accessed, even though I am not accessing them myself. I have reason to believe that Live Share is the culprit. (Keybase reports "access denied" errors because /keybase/private/scripts refers to the private directory of a Keybase user named scripts.)
I am concerned that Live Share is accessing folders that it should not. I wonder if maybe they are being monitored because they are inside of /run/user/$UID/ where I also see lots of VS Code related sockets?
What was your system configuration?
Product and Version [VS/VSCode]: VSCode 1.66.2
OS Version[macOS/Windows]: Ubuntu 20.04
Live Share Extension Version: v1.0.5527
Target Platform or Language [e.g. Node.js]: Python
Steps to Reproduce / Scenario:

Join a Live Share session
Do general activities (I have not been able to correlate it with any particular action)
Observe notifications from Keybase that my folders are being accessed.

Please attach logs to this issue:
Unfortunately I'm not connected with my colleague, so I can't deliver any logs at the moment.
Screenshots
If applicable, add screenshots to help explain your problem.

Apologies for the delay here. We've made several major updates to the extension since this was filed and the Live Share extension does not have logic to scan for such directories. As is, this issue doesn’t have enough information to be reproduced. Please reopen if the issue persists with any additional details. Thank you.


Settings: bold selected element should not jump

Refs: #67304

click into settings TOC
each selected element jumps up a bit because it gets bold

=> I would prefer if the element stays visually on the same line and not jump upon clicking

Did this involve zoom or something? Haven't been able to repro.


Bound and Unbound Symbols; bound, partially bound, and pure expressions

I'm making the case to rename InteractiveSymbol to BoundSymbol, and to remove the whole interactive nomenclature throughout the codebase.  blaze.expr.expressions.Symbol could stay as it is, or it could be renamed to UnboundSymbol for parallelism.
Our reasoning is as follows: we've witnessed new users tripping up with InteractiveSymbols frequently, thinking wrongly that they can only be used in a REPL due to their name.  Also, new users expect Data to be the one-stop-shop for all data-related things, when in fact, Data is currently made only for specific interactive usages.  For instance, you can't use a Data object when setting up a Blaze Server--blaze server expects a resource instead.  I see no reason why a BoundSymbol can't be used where a resource is expected -- it's just a resource plus a symbol.
This improvement will make Data return a BoundSymbol object, that simply associates a symbol with some resource.  Data's API will remain the same.
Since end-users rarely if ever create InteractiveSymbols directly, we expect this to not affect existing code in a significant way.
We could keep InteractiveSymbol callable around, and re-implement it to raise a deprecation warning and return a BoundSymbol instead.
Similarly for Symbol: it can return an UnboundSymbol object.  Since users do use Symbol, this one we'd want to keep, IMO.
This paves the way conceptually towards talking about bound, partially bound, and unbound (or pure) expressions down the line.
The downside is that "bound" and "unbound" are a little jargony -- I'm open to other suggestions.
Thoughts?

In zipline and other code that consumes blaze expressions I have used the phrase 'bound expression' to refer to an expression whose leaves are interactive symbols. I think this name better expresses the concept of binding a name to data.
I would prefer to rename Data to data to go along with this; however, I feel less strongly about that.
I am heavily in favor of this change.

+1 on renaming Data to data.  I'll make a separate issue out of that.
@llllllllll  thoughts on renaming the Symbol type to UnboundSymbol?

I think that 'unbound' is the default state for a symbol. I think that Symbol and BoundSymbol pair nicely but I wouldn't mind having an UnboundSymbol. I guess +0.

I see no reason why a BoundSymbol can't be used where a resource is expected -- it's just a resource plus a symbol

Symbols and resources are not the same and in general one can't use a blaze expression where a resource is expected. resource returns many different kinds of things, ranging from your garden variety ndarray to more exotic structures like Spark DataFrames.

Symbols and resources are not the same and in general one can't use a blaze expression where a resource is expected. resource returns many different kinds of things, ranging from your garden variety ndarray to more exotic structures like Spark DataFrames.

InteractiveSymbols are atomic expressions that evaluate to their underlying resource, correct?  Why is there an issue with Blaze extracting the underlying resource associated with an InteractiveSymbol object when it expects a resource?  There's no ambiguity here.  You can't call Data on an expression that requires computation -- you get a NotImplementedError.  I would expect an error if I pass in a non-atomic expression where Blaze is expecting a resource.
If we can't do this, then we have a significant usability issue.  From observation, I've seen new users expect to be able to use the result of data when they need data somewhere.  The subtle distinction we're expecting them to make between data and resource is just another source of cognitive overhead.  I've had to explain this distinction several times to frustrated users -- to me, that's an indication that there might be something wrong with our design.  This bit me when I first tried to use Blaze, and I've helped three separate people debug this issue (using a data() call where they should use resource()) on various occasions.

How about just calling data something else?

Why is there an issue with Blaze extracting the underlying resource associated with an InteractiveSymbol object when it expects a resource

Because it doesn't make sense to use an expression as a piece of data, to be computed on against some other expression. For example, this doesn't make sense:
d = Data(...)
t  = symbol('t', d.dshape)
expr = by(t.name, avg=t.amount.mean())
result = compute(expr, d)

especially when you can just do this:
d = Data(...)
expr = by(d.name, avg=d.amount.mean())
result = compute(expr)

InteractiveSymbols are atomic expressions that evaluate to their underlying resource

No, they are Symbols whose _resources() method returns a non-empty dictionary

You can't call Data on an expression that requires computation -- you get a NotImplementedError. I would expect an error if I pass in a non-atomic expression where Blaze is expecting a resource.

I don't understand what you're saying here, Data takes as its main argument a piece of data (DataFrame, sa.Table, etc.) or a string to be passed on to the resource function. Why would it take an expression?

The subtle distinction we're expecting them to make between data and resource is just another source of cognitive overhead.

I guess I don't see the subtlety here. data returns a blaze expression, and resource returns something from the PyData ecosystem.
One thing is very much a blaze thing and the other can be basically whatever.

I've had to explain this distinction several times to frustrated users -- to me, that's an indication that there might be something wrong with our design.

I think the fact that its called data is probably a large part of the problem, as well as that resource is actually a function from odo.

At the risk of stepping into a pile of something, I will throw in my thoughts. (from the perspective of an end-user)
In learning Blaze, it was confusing trying to understand when I should use Data and when I should use resource.  At times, I even found myself asking why I had to deal with resource at all.
Like Joe, I started to think of and label my expressions as bound or unbound.  (I even have started to use a third category, which is partially bound)  I endorse a Blaze naming convention change that moves in the direction of being more explicit as to whether an expression is bound to data or not.
It seems very "unpythonic" to me that at times Blaze will not accept Data when it wants a resource since by definition a Data always has a resource.
I also think there is an instance when the following make sense, albeit, in a slightly more expanded example.
d = Data(...)
t  = symbol('t', d.dshape)
expr = by(t.name, avg=t.amount.mean())
result = compute(expr, d)

If I a want to create an unbound expression to compute against multiple datasets that have the same data shape.

I would like to amend my previous proposal to rename Data to bound_symbol which should return an instance of BoundSymbol (rename of InteractiveSymbol). This would be the same pattern as our other expression objects that have a paired function to do input normalization.
I think most of this confusion around resource and Data comes from the name. I think that a lot of this ambiguity goes away if we rename data to bound_symbol or something to mark that you are getting back a blaze expression, I think that we want to get away from duck typing bound expressions as concrete or materialized data so we would not want to allow this as a resource to compute. With a name change to bound_symbol there should be a more clear distinction between these two concepts.

+1 @ltransom

To distill the conversation thus far, there seems to be argreement on the following:

Rename InteractiveSymbol to BoundSymbol.
If a "data" callable still exists, it should be named data(), not Data().

On the remaining points, I see two proposals:

Proposal 1: Everywhere a resource is expected, allow the result of data() to be used as well.  BoundSymbols are equal parts symbols to be used in expressions and resources, and can be used where either a symbol or a resource is expected.  data() would be the only callable required to access resources, and resource() would be removed from the public API of Blaze.  Concretely, this change would allow the following code to work:

t = symbol('t', '<datashape for t>')
s = symbol('s', '<datashape for s>')
compute(t.foo * s.bar, {t: data('/path/to/csv'),
                                   s: data('postgresql://...')})

The semantics being that the t symbol is mapped to the underlying resource named by data('/path/to/csv') and analogously for s.  No ambiguity arises since there is only one resource named by data().  The automatically generated symbol generated by data() is effectively ignored, and the resources are re-bound at compute time to the t and s symbols.

Proposal 2: Maintain the data() and resource() separation.  Remove the data / Data callable, and replace with bound_symbol().  BoundSymbols can only be used in expressions, and are not allowed to be implicitly re-bound to other symbols, as in compute() calls and when setting up a blaze.server.Server() instance.

Is this accurate?

@ltransom The blaze way to do this:
d = Data(...)
t  = symbol('t', d.dshape)
expr = by(t.name, avg=t.amount.mean())
result = compute(expr, d)

is
d = resource(...)
t  = symbol('t', discover(d))
expr = by(t.name, avg=t.amount.mean())
result = compute(expr, d)

InteractiveSymbols (what Data returns) are just that--Symbol instances.
@kwmsmith @ltransom It seems like you guys might be thinking of InteractiveSymbols as being a resource whereas what is actually the case is that they have a resource. They are Symbols and have resources.
I propose that data/Data be renamed to bound_symbol so that the API looks like like this:

resource: actual pieces of data
symbol: the thing that builds expressions
bound_symbol: symbol + resource

The automatically generated symbol generated by data() is effectively ignored, and the resources are re-bound at compute time to the t and s symbols.

I think the behavior of data sometimes behaving like a symbol and sometimes like a resource is a bda idea. To me, it indicates some coupled features that should be decoupled. The current system doesn't have this problem. I think renaming data to bound_symbol will solve most of the confusion.

I think the behavior of data sometimes behaving like a symbol and sometimes like a resource is a bda idea. To me, it indicates some coupled features that should be decoupled.

But a BoundSymbol is coupling symbols with resources -- if we were to decouple them as you say, then we'd nix BoundSymbols altogether, and have only pure symbols and resources, and never the twain shall meet, except when we need to compute something.  So as long as BoundSymbol exists, we do have this concept.  And I think it is a useful concept, for the record.
Whether we name it InteractiveSymbol, BoundSymbol, or something else, this thing will always be, semantically, the combination of a symbol with some resource.  The symbol part of it is used in expressions and, at times, ignores the resource; the resource part of is used during computation and may discard, rename, or ignore the symbol.  Renaming data to bound_symbol doesn't change any of that: it's still a symbol bound to a resource.  It's both, and it can take on the role of either in different situations.

Resources never manipulate symbols. Resources can be nearly any object from the Python ecosystem. How could they know anything about blaze symbols?
A bound symbol literally is a Symbol: it subclasses. It is a very strong guarantee on the interface. Resources attached to symbols are always a dictionary mapping Symbols to some arbitrary object whose interface has zero knowledge of how blaze will use it.

Resources never manipulate symbols. Resources can be nearly any object from the Python ecosystem. How could they know anything about blaze symbols?

This was not my intended meaning -- I'm aware that resources don't manipulate symbols; I meant that, during compute, the symbol part of a BoundSymbol may be manipulated by the compute infrastructure.

A bound symbol literally is a Symbol: it subclasses. It is a very strong guarantee on the interface.

Yes, and a BoundSymbol is guaranteed to have a public .data attribute, which is a resource.  This is also guaranteed by the BoundSymbol interface.  What's the issue with accessing the .data public attribute on a BoundSymbol, as we're proposing with compute(expr, {t: data('...')})?  BoundSymbols are a place where the expression part of Blaze overlaps with the data part of Blaze -- why not allow BoundSymbols be usable in both situations?

I meant that, during compute, the symbol part of a BoundSymbol may be manipulated by the compute infrastructure.

This happens with every blaze expression regardless of whether it is bound to a resource.

why not allow BoundSymbols be usable in both situations?

Because they aren't resources, they are symbols. If you want to compute an expression against a resource, you provide the resource at compute time or you execute against a bound symbol, you don't mix modes.
Think about how you would define compute for an expression against an BoundSymbol:
@dispatch(Symbol, InteractiveSymbol)
def compute(expr, data, **kwargs):
    # ...

To me this doesn't make any sense, since symbols describe computation, they aren't things that provide data to compute against. What does it mean to execute a symbol against another symbol?
Please correct me if I'm wrong, but I think what you're proposing is this API:

symbol: compute(<expr derived from symbol>, resource)
resource: resource from above
bound_symbol:

compute(<expr derived from other symbol>, bound_symbol)
or compute(<expr dervied from bound_symbol>)

The last bullet is redundant. Why create a symbol if you don't need to?
I'm proposing this:

symbol: same as above
`resource: same as above
bound_symbol: only compute(<expr derived from bound_symbol>)

I think the main point is to educate users about the two modes of blaze usage and to have names for things that indicate that they are separate.
It makes no sense to create a symbol + data and then only operate on the data, why wouldn't you just create only the data and run against that? It is literally the exact same amount of code.
I'm +1000 on renaming and -1000 on allowing bound_symbol to be a resource.

Please correct me if I'm wrong, but I think what you're proposing is this API:

This is good; the API we're proposing is the following:

symbol: compute(<expr derived from symbol or bound symbols>, <mapping from symbols to calls to data()>)
resource: unnecessary in blaze public API -- anything that needed a resource previously would just use the result of data() instead.
data(): returns a BoundSymbol which semantically is both a symbol for use by expressions and a resource, depending on need or context.
expressions: can be classified as fully unbound, fully bound, or partially bound, depending on whether it is built from symbol()s, calls to data(), or a combination of the two.

The last bullet point starts to pave the way for other interaction modes with expressions that we think are interesting and worth discussing, and that we'll put in a separate GH issue to not distract from the current thread.

I think the main point is to educate users about the two modes of blaze usage and to have names for things that indicate that they are separate.

This is also something that end users find confusing -- why the strict separation between the two modes in Blaze?  By shifting to "bound" and "unbound" symbol terminology, and by allowing a mixture of bound and unbound symbols in one expression, my hope is to remove the need to have these two modes in Blaze.
An analogy can be made between Blaze expressions and regular Python functions.  Blaze Symbols take the role of (unbound) function arguments that have to be provided at compute() time to actually compute anything.  Blaze BoundSymbols take the role of either arguments with default values, or closed over variables in a function closure.  Taking this analogy further, it would be interesting and useful to allow a user to pass in a blaze expression to another blaze expression, yielding yet another blaze expression, just as you can pass in a function to another function in pure Python.
Again, I don't want to derail our current thread, and I'll be summarizing our thoughts around this in a separate issue soon.  But it's all related to our desire to allow compute(expr, {s: data(...)}) and compute(expr, {e: other_expr}) other similar things to work, which opens up blaze expressions to be able to be applied to other blaze expressions.

why the strict separation between the two modes in Blaze?

The whole idea of blaze is based on separating data from computation. Systems like numpy and pandas are the result of coupling these two things. While both of these are great libraries for their intended use cases, it's difficult to scale them is because they are so tightly bound to a specific way of thinking about data. Dask, Spark and many other "big data" systems take a very similar approach. This is especially apparent in the Apache Drill project, where you can run a SQL query over a huge number of different systems. SQL is to Drill what Python is to Blaze.

it would be interesting and useful to allow a user to pass in a blaze expression to another blaze expression, yielding yet another blaze expression, just as you can pass in a function to another function in pure Python.

Expressions already work this way where it makes sense. The BinOp expression takes two blaze expressions lhs and rhs as its arguments. There are quite a few failure modes here for certain backends, but that isn't a result of not allowing expressions to be resources.

compute(expr, {e: other_expr})

How would this be different from expr._subs({e: other_expr})? (Wherever e occurs in expr replace it with other_expr)

Again, I don't want to derail our current thread

I don't think you're derailing. This all seems like very relevant stuff from both our ends. If you think I'm derailing please say so.

it would be interesting and useful to allow a user to pass in a blaze expression to another blaze expression

I don't see how this is particularly useful for users.


Hide Dashboard During Intro Sequence

Dashboard is visible during a map's intro sequence. It would be nice if it was hidden since it wont be showing any information during that time.

Can we detect if the intro mediatracker is playing? I know there are some instances of the mediatracker player around, perhaps those can be queried to see if the intro is being played.

I think there are some state variables in the UIMgr that might indicate if we are in an intro. As you say, it would take some investigating to find whether it works consistently in all cases.

The EUISequence enum in CGamePlaygroundUIConfig looks promising.


prisma migrate. Oops, an unexpected error occured!

Hello,
I am trying to use the experimental feature: migrate
I am having this warning after prisma migrate save --experimental:
 You are about to alter the column `plaidDataId` on the `PlaidBalanceHistorical` table, which still contains 629 non-null values. The data in that column could be lost.

and then. an error  after prisma migrate up --experimental
Oops, an unexpected error occured!
Failure during a migration command: Connector error. (error: Error querying the database: Error querying the database: Server error: `ERROR HY000 (3780): Referencing column 'plaidDataId' and referenced column 'id' in foreign key constraint 'PlaidBalanceHistorical_ibfk_1' are incompatible.'
   0: migration_core::api::ApplyMigration
           with migration_id="20200831191340-test-1"
             at migration-engine/core/src/api.rs:79)

the report id is :  10913.
My schema:
model PlaidBalanceHistorical {
  id                String     @default(cuid()) @id
  plaidDataId       String?
  plaidData         PlaidData? @relation(fields: [plaidDataId], references: [id])
  @@index([plaidDataId], name: "plaidDataId")
}

model PlaidData {
  id                        String                   @default(cuid()) @id
  plaidBalanceHistoricals   PlaidBalanceHistorical[]
}

You will now get datamodel errors from introspection for this schema, so the nature of the problem changed. The new issue to follow is https://github.com/prisma/prisma/issues/5289


chore(tests,virtctl): Add virtctl label and VirtctlDescribe

What this PR does
Add a label to allow filtering for virtctl tests and add Describes that
allow to use this label easily. Then make use of the new VirtctlDescribe.
Before this PR:
virtctl functests cannot be filtered with a label.
After this PR:
There is a label that allows to filter functests so only virtctl tests run.

Fixes #
Why we need it and why it was done in this way
The following tradeoffs were made:
The following alternatives were considered:
Links to places where the discussion took place:
Special notes for your reviewer
Merge after #13415
Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[ ] PR: The PR description is expressive enough and will help future contributors
[ ] Code: Write code that humans can understand and Keep it simple
[ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note

None

/test pull-kubevirt-generate

Thank you! Looks great!
/lgtm

/lgtm

/hold cancel


Jenkins build improvements

Bugfixes für fehlschlagende Unit-Tests

sorry this PR was not mentioned for this repo.


[full-ci] update web to v5.7.0-rc.10

bump ownCloud Web to v5.7.0-rc.10

I don't really get the CI errors... :confused:
When I run oCIS locally it works fine but I'm not yet running the UI test suite so maybe I'm missing some crucial setup option or so.

Ok, even with the test suite it's working locally... :confused:

@C0rby, i see a lot of fishy errors... https://drone.owncloud.com/owncloud/ocis/14829/54/9

@C0rby, i see a lot of fishy errors... https://drone.owncloud.com/owncloud/ocis/14829/54/9

Do you mean the events errors or something else?

@individual-it, can you please have a look, we do not find why the tests are failing...

a little more context for that:

web CI on the linked commit id was successful
ocis commit id in web is not up to date (5 days old)
all web scenarios in this PR are failing
test middleware is up to date

I'd suspect that this is some kind of config issue, but I don't see anything that has changed in that regard. Maybe you have an idea...

Just now I realized that the e2e tests are passing. So the issue is only with the nightwatch acceptance tests apparently.

Create a PR in web with screenshots from CI enabled. maybe that gives us a clue...

Created a PR in web with screenshots from CI enabled. maybe that gives us a clue...

aaand acceptance tests for this PR here seem to pass in the web CI.

I'll take a look at what's happening

Note: This branch is 3 commits ahead, 3 commits behind master.
This branch does not have #4444 "update reva". It would be good to also know/test that this web update works with the really latest reva.

Note: This branch is 3 commits ahead, 3 commits behind master.
This branch does not have #4444 "update reva". It would be good to also know/test that this web update works with the really latest reva.

Yes, true. Feel free to rebase :-)

Locally while running the tests there's this popup

And the test fail in the similar way as in CI
Scenario: Delete multiple files at once on a public share # features/webUIDeleteFilesFolders/deleteFilesFolders.feature:204
   ✔ Before # setup.js:38
   ✔ Before # setup.js:42
   ✔ Before # setup.js:53
   ✔ Before # setup.js:60
   ✔ Before # setup.js:71
   ✔ Before # stepDefinitions/filesContext.js:17
   ✔ Before # stepDefinitions/generalContext.js:206
   ✔ Before # stepDefinitions/generalContext.js:244
   ✔ Before # stepDefinitions/middlewareContext.js:46
   ✔ Given user "Alice" has been created with default attributes and without skeleton files in the server # stepDefinitions/middlewareContext.js:66
   ✔ Given user "Alice" has created folder "simple-folder" in the server # stepDefinitions/middlewareContext.js:66
   ✔ And user "Alice" has created file "simple-folder/data.zip" in the server # stepDefinitions/middlewareContext.js:66
   ✔ And user "Alice" has created file "simple-folder/lorem.txt" in the server # stepDefinitions/middlewareContext.js:66
   ✔ And user "Alice" has created file "simple-folder/simple-empty-folder" in the server # stepDefinitions/middlewareContext.js:66
   ✔ And user "Alice" has shared folder "simple-folder" with link with "read, update, create, delete" permissions in the server # stepDefinitions/middlewareContext.js:66
   ✔ When the public uses the webUI to access the last public link created by user "Alice" in a new session # stepDefinitions/publicLinkContext.js:51
   ✖ And the user batch deletes these files using the webUI # stepDefinitions/filesContext.js:487
       | name                |
       | data.zip            |
       | lorem.txt           |
       | simple-empty-folder |
       Timed out while waiting for element <//button[contains(@class, "oc-files-actions-delete-")]> to be present for 10000 milliseconds. - expected "visible" but got: "not found" (10025ms)
           at Proxy.deleteAllCheckedFiles (/home/swikriti/www/web/tests/acceptance/pageObjects/personalPage.js:232:19)
           at World.<anonymous> (/home/swikriti/www/web/tests/acceptance/stepDefinitions/filesContext.js:493:37)
           at runMicrotasks (<anonymous>)
           at processTicksAndRejections (node:internal/process/task_queues:96:5)
   - Then as "Alice" file "simple-folder/data.zip" should not exist in the server # stepDefinitions/middlewareContext.js:66
   - And as "Alice" file "simple-folder/lorem.txt" should not exist in the server # stepDefinitions/middlewareContext.js:66
   - And as "Alice" folder "simple-folder/simple-empty-folder" should not exist in the server # stepDefinitions/middlewareContext.js:66
   - And the deleted elements should not be listed on the webUI # stepDefinitions/filesContext.js:402
   - And the deleted elements should not be listed on the webUI after a page reload # stepDefinitions/filesContext.js:406
   ✔ After # stepDefinitions/middlewareContext.js:60
   ✔ After # stepDefinitions/generalContext.js:262
   ✔ After # stepDefinitions/generalContext.js:231
   ✔ After # stepDefinitions/generalContext.js:172
   ✔ After # setup.js:104
   ✔ After # setup.js:100
   ✔ After # setup.js:96
   ✔ After # setup.js:89
   ✔ After # setup.js:80

I'll rebase and push and look more into it

golangci-lint keeps on failing in one pipeline or another in every run 😢

@SwikritiT could you tell me which requests are failing with a 401 (see network tab in browser dev tools) if you cancel the basic auth popup?

@kulmann This is failing with 401
Request URL: https://host.docker.internal:9200/accounts.js
Request Method: GET
Status Code: 401 Unauthorized
Remote Address: <IP_ADDRESS>:9200
Referrer Policy: strict-origin-when-cross-origin

OCIS LOG
2022/08/24 12:50:35 http: TLS handshake error from <IP_ADDRESS>:60008: remote error: tls: unknown certificate
2022/08/24 12:50:35 http: TLS handshake error from <IP_ADDRESS>:60012: remote error: tls: unknown certificate
2022/08/24 12:50:35 http: TLS handshake error from <IP_ADDRESS>:60014: remote error: tls: unknown certificate
2022/08/24 12:50:35 http: TLS handshake error from <IP_ADDRESS>:60016: remote error: tls: unknown certificate
2022/08/24 12:50:35 http: TLS handshake error from <IP_ADDRESS>:60020: remote error: tls: unknown certificate
2022/08/24 12:50:35 http: TLS handshake error from <IP_ADDRESS>:60018: remote error: tls: unknown certificate
2022/08/24 12:50:35 http: TLS handshake error from <IP_ADDRESS>:60024: remote error: tls: unknown certificate

The Ci has already failed in generate-go and golint. I'll restart the build

@C0rby When I open the settings app via the user menu (top right) and do a page reload I also get a 401 + basic auth popup.

The CI failed again at https://drone.owncloud.com/owncloud/ocis/14883/35/3 go-generate and golangci-lint has become really annoying lately. Is there nothing we do about it?

@C0rby When I open the settings app via the user menu (top right) and do a page reload I also get a 401 + basic auth popup.

Ah interesting. That means another path is missing. I'll add it.

@C0rby this brings up another issue: can we have a wildcard allowance for certain file types, like .js, .css, .html? Because any external app that gets added to the config.json would fail with a 401 at the moment, right?

I wouldn't really implement a wildcard for security reasons but yeah we need to refactor the proxy quite a bit to make this easier.

@C0rby this brings up another issue: can we have a wildcard allowance for certain file types, like .js, .css, .html? Because any external app that gets added to the config.json would fail with a 401 at the moment, right?

I wouldn't really implement a wildcard for security reasons but yeah we need to refactor the proxy quite a bit to make this easier.

Then we probably need to be able to register unprotected routes...

Then we probably need to be able to register unprotected routes

Yeah, that is the plan. To use the proxy routes and mark certain routes as "unprotected".

@SwikritiT @C0rby nice, settings ui tests are passing now. All the other pipelines were green in the run before. Should be good now. Thanks for your efforts!


listening port on interface (maybe)

I am trying to connect my HA to a fritzbox in another city with wireguard. I am quite sure the problem is the listening port. The fritzbox has a wireguard server and it works (I connected to it with both my laptop and android mobile), but it wants ListenPort = 51336 while wireguard client uses a random number for the interface.
It doesn't receive anything
transfer: 0 B received, 2.89 KiB sent
persistent keepalive: every 25 seconds
I am not really able to make it works. Any help will be much appreciated!

I made some wrong config, sorry! No issue here


Indexer: investigate duplicate transactions

Block 14895180 on the mainnet-9 spork seems to have duplicate transactions. We should investigate if this is from the execution node database, or whether the bug is somehow on our side.
See also: https://github.com/dapperlabs/flow-go/issues/3556

The issue is clearly somewhere in the DPS code. We have no duplicate transactions in the protocol state database of the execution node. However, the duplicate transactions show up as part of the transaction index at certain heights in the state index database.
 This means that the fix in #356 is actually valid, as the duplicate transaction IDs don't replace any other transactions. It also helps narrow down the root cause further.
{"level":"info","time":"2021-08-12T10:22:54Z","message":"comparing duplicates between databases"}
{"level":"info","height":15036642,"duplicates":1,"height":15036642,"block":"f03ef4100b8ab01bf915ad8603ae70dac96a655d4220ade04c2fa138f9a8db97","first_count":2,"second_count":3,"first_found":1,"second_found":2,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15459613,"duplicates":25,"height":15459613,"block":"ea83e4c8a6b159c2558d4c9a3e072cddca6059eec47d8776d3c002d6126ef421","first_count":27,"second_count":52,"first_found":25,"second_found":50,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15529210,"duplicates":4,"height":15529210,"block":"f6d5af8f0675b542de79d5e84707d58ba97b37485e233691ea2cc4434cff498f","first_count":7,"second_count":11,"first_found":4,"second_found":8,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15675460,"duplicates":4,"height":15675460,"block":"ca9b30f8a7b28bd81c62a0f99ccfdd97185f56bdaeaedcae2327db5f08cc0995","first_count":5,"second_count":9,"first_found":4,"second_found":8,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15772990,"duplicates":6,"height":15772990,"block":"81ac248c2901ce18e6d4da4433298bcdadf4c3d8728d00f5c4775eeb38bb9988","first_count":12,"second_count":18,"first_found":6,"second_found":12,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15348298,"duplicates":4,"height":15348298,"block":"2ef05450bf3c6312c43b4ea9150085a518953ea2c8899e7ae897059f5e1a5985","first_count":6,"second_count":10,"first_found":4,"second_found":8,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15416504,"duplicates":9,"height":15416504,"block":"0b942d82181a33a19e72badf6ae5d61d73c317ab6c82615a88bda40e4394835f","first_count":21,"second_count":30,"first_found":9,"second_found":18,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15522036,"duplicates":30,"height":15522036,"block":"7d7a0de57ad1b4e711d71e5f666f9a65c51e724f019252b5f8ee4d30bf0d7367","first_count":42,"second_count":72,"first_found":30,"second_found":60,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15605398,"duplicates":6,"height":15605398,"block":"f6e4dfeeaa7d9c89d3cdc249bcced825a1628649752b0e547356d452e0070f46","first_count":7,"second_count":13,"first_found":6,"second_found":12,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":14989460,"duplicates":21,"height":14989460,"block":"964c93b94bc6288cff2c44bb2a9a4652527582ac1cd31018000c94e272e045e5","first_count":32,"second_count":53,"first_found":21,"second_found":42,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":14993514,"duplicates":2,"height":14993514,"block":"14fb26da3264e950d2722d8d477c19f903c428f44e65c00e24b02a21561077ae","first_count":5,"second_count":7,"first_found":2,"second_found":4,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15447240,"duplicates":15,"height":15447240,"block":"9441034c300581535443fe660998a9697b725f2ad298bed0de3a41fbd32b5932","first_count":17,"second_count":32,"first_found":15,"second_found":30,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15649116,"duplicates":1,"height":15649116,"block":"a53206dc2415b3876c7d3d646a62a7c29c3e3be23adbb40c4d0eb8f024c4d5d8","first_count":5,"second_count":6,"first_found":1,"second_found":2,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15615078,"duplicates":4,"height":15615078,"block":"5922fddf16a41b8efb7966fc47a82906001b42935b010aca7f58189fcbe4b2a2","first_count":5,"second_count":9,"first_found":4,"second_found":8,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15725777,"duplicates":2,"height":15725777,"block":"022a4996055e3cf07320210d477f86d56781cab9da5b0c1376704e12e1d6c050","first_count":3,"second_count":5,"first_found":2,"second_found":4,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":14919096,"duplicates":1,"height":14919096,"block":"a9f7e5663a4773a2e14f74456f3a3bb54e657f2b19e9dd27a11b1e4591aa9c99","first_count":4,"second_count":5,"first_found":1,"second_found":2,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15102855,"duplicates":5,"height":15102855,"block":"277dd6ca615f580f0ea9e5a6401125ec33b7540150aa513dfcc261f6edc4ab6b","first_count":6,"second_count":11,"first_found":5,"second_found":10,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15410750,"duplicates":15,"height":15410750,"block":"310e420e913e3a3d66dddbc41435e9007307b9a8d68490ca39bd483584795ce5","first_count":31,"second_count":46,"first_found":15,"second_found":30,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15458130,"duplicates":5,"height":15458130,"block":"af3014f1cbb5000d6f544a5ef6a7b85560ce82a4b541ae61c8cdef38b65aa43f","first_count":69,"second_count":74,"first_found":5,"second_found":10,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15438733,"duplicates":87,"height":15438733,"block":"f4bb9c6d59ca2527ece3f2f1dfd2a39f6832ea753543fca3cf178a0a4165aa77","first_count":97,"second_count":184,"first_found":87,"second_found":174,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15449078,"duplicates":5,"height":15449078,"block":"ead8e94687d1b7654c9968e075a61a5b39d59f95643b509e9a4254d4cbed1eea","first_count":9,"second_count":14,"first_found":5,"second_found":10,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15500116,"duplicates":8,"height":15500116,"block":"9e21a898c600962b6b16f157a6c382259100f7e17b6d4e9c24d2c481d10d75b8","first_count":38,"second_count":46,"first_found":8,"second_found":16,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15639466,"duplicates":3,"height":15639466,"block":"62fe1f1ae5edf79ff53adad9a05fda1571e3744d406c8e0c5340397bb340f8e4","first_count":24,"second_count":27,"first_found":3,"second_found":6,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15532280,"duplicates":6,"height":15532280,"block":"2d8e75a25247f48ea6cee1342529d543c6c04989ebbd1460c7485dfcc1e7e522","first_count":8,"second_count":14,"first_found":6,"second_found":12,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15579069,"duplicates":10,"height":15579069,"block":"e9ac4bd61759fa7299cda6a3240d5e0c07c9ca6a8943c259e8963b0c578ecbdc","first_count":27,"second_count":37,"first_found":10,"second_found":20,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15617008,"duplicates":3,"height":15617008,"block":"0593eb071fd616710a369467a906e0cd942189cdbc8f7a32aaff143dd48c10ed","first_count":3,"second_count":6,"first_found":3,"second_found":6,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15123681,"duplicates":3,"height":15123681,"block":"03617109dd567adc43e8eeab30953a1fc7dbc850561ddb4000ff1e4bef7d8119","first_count":3,"second_count":6,"first_found":3,"second_found":6,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15176802,"duplicates":6,"height":15176802,"block":"e7643e2fb9b9b9f13d6db31396c77dcebdb255a04c13db7b33a86e4eaed552f9","first_count":16,"second_count":22,"first_found":6,"second_found":12,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15486148,"duplicates":25,"height":15486148,"block":"ff3258331d8912326b7a126cebaf7f68b2fbb85b00202d252d418a7f6ebeaa6f","first_count":30,"second_count":55,"first_found":25,"second_found":50,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15518162,"duplicates":41,"height":15518162,"block":"7777d118d72066cbf9051a2ce62d82ffb8d3b9b362ee6ba78d26354996eff196","first_count":106,"second_count":147,"first_found":41,"second_found":82,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15713481,"duplicates":1,"height":15713481,"block":"898a98d22887940b15ff4dae0854aac20fa8b6e0e5e9a194ac44680e55ffe3c3","first_count":1,"second_count":2,"first_found":1,"second_found":2,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":14895180,"duplicates":4,"height":14895180,"block":"025c36c1d8daa36a2d494bca9b711a271a7caa255a2847a5d5a71393ab5a874a","first_count":5,"second_count":9,"first_found":4,"second_found":8,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15061321,"duplicates":1,"height":15061321,"block":"8af5f25def90b32855a7c4e93b88c07211cedd0cd9c553b80a0a1d202c934d4a","first_count":2,"second_count":3,"first_found":1,"second_found":2,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15522631,"duplicates":10,"height":15522631,"block":"06f8da5b8e25755a942ecb659a5c512bdac986401d982f5e00994d658f738555","first_count":42,"second_count":52,"first_found":10,"second_found":20,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15696405,"duplicates":1,"height":15696405,"block":"81777ce4433811c4fc2085ae1a8f19d508a07ec34f5efd3b2b1dcb9de7e75f90","first_count":2,"second_count":3,"first_found":1,"second_found":2,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15342842,"duplicates":1,"height":15342842,"block":"6f082cbb8374c4590e6041517a27d62dc25581c03b1215c5f715bfd3360cb55d","first_count":6,"second_count":7,"first_found":1,"second_found":2,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15461631,"duplicates":15,"height":15461631,"block":"b7a192b2e9f70efc66b710fb32623d64fcea1d9c61ad6ef39e0534370ec85093","first_count":25,"second_count":40,"first_found":15,"second_found":30,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15577227,"duplicates":13,"height":15577227,"block":"d691bb7a2d8ab637603de27e882306d0f1e8c254d504dceb902ace54f4ea194b","first_count":16,"second_count":29,"first_found":13,"second_found":26,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15778959,"duplicates":5,"height":15778959,"block":"47cecd1c6ee38841f1d1e9dc22b532c852f4edeccc0c1457fe305e4f14268a62","first_count":13,"second_count":18,"first_found":5,"second_found":10,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":14935737,"duplicates":1,"height":14935737,"block":"707bbdf763d06a1d6db01108dceb1dfe186f5aafbbecd41b5b3fcdae459a29f9","first_count":1,"second_count":2,"first_found":1,"second_found":2,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15114897,"duplicates":1,"height":15114897,"block":"d9742950a1345220c8786013d5a323a3bb73329ca794bccc0263b5165e0712f8","first_count":2,"second_count":3,"first_found":1,"second_found":2,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15283911,"duplicates":1,"height":15283911,"block":"caf47c0b317957a3049073da868698147b77ffdc621175b9f6b2c8070b9f16ad","first_count":4,"second_count":5,"first_found":1,"second_found":2,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15308782,"duplicates":1,"height":15308782,"block":"d26f733df3be0e9334328e7de4ae027fc1da9ccdc7024c4ca6ec27b96b339a4d","first_count":21,"second_count":22,"first_found":1,"second_found":2,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15439139,"duplicates":47,"height":15439139,"block":"4aa77c6132cf1edae4ed898ae9e3f09fec7d5855e040c0bb31ec761cf89782cc","first_count":209,"second_count":256,"first_found":47,"second_found":94,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":14927251,"duplicates":19,"height":14927251,"block":"7f48f8f2d26be453dbbc748b4da40cdd81b85186ca10c94e7d5b682ac25d7479","first_count":23,"second_count":42,"first_found":19,"second_found":38,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":14958421,"duplicates":1,"height":14958421,"block":"d468152febd1d4011997f5760599e210dae25de3035a390ead9b4dbeeba7836b","first_count":5,"second_count":6,"first_found":1,"second_found":2,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15099237,"duplicates":18,"height":15099237,"block":"c33562cf069ae04f236b35bf443cc1e2ccc4261ac542dea12e5d73fb52404a89","first_count":30,"second_count":48,"first_found":18,"second_found":36,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15281149,"duplicates":7,"height":15281149,"block":"9464f88b5b6b99761ee79111f6a63fa2907c73c34218cd8be32108df9acfc05c","first_count":9,"second_count":16,"first_found":7,"second_found":14,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15546745,"duplicates":1,"height":15546745,"block":"3d69235ec996e371cbdd37e1590e14303fa989dec983585f833265186ba1731c","first_count":12,"second_count":13,"first_found":1,"second_found":2,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":14960542,"duplicates":55,"height":14960542,"block":"1cc8625f9eec00191b844437ee4c649e4720ffbd3e82f6bd9189eb5d15cfb0da","first_count":83,"second_count":138,"first_found":55,"second_found":110,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15231374,"duplicates":16,"height":15231374,"block":"c4f21fc629b410f87dd2e7ddc04291205d7842e0a2f6810f262d92dda0e480a7","first_count":19,"second_count":35,"first_found":16,"second_found":32,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15490188,"duplicates":13,"height":15490188,"block":"ee9dfc2977061ce5f157d27751050a92f3cb7e39b3dc59a129d797b37bfbd80e","first_count":21,"second_count":34,"first_found":13,"second_found":26,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15498645,"duplicates":59,"height":15498645,"block":"8d6f8de09a0b302e8f01b68302820c49039269bba3bab0bef7e74381cfc245ef","first_count":79,"second_count":138,"first_found":59,"second_found":118,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15432399,"duplicates":97,"height":15432399,"block":"185a4250e48411f24a243fc69465c8ce4f60ee7fa18cd1b62efd68584941587e","first_count":102,"second_count":199,"first_found":97,"second_found":194,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15454557,"duplicates":7,"height":15454557,"block":"3700e4b83ef03593a5d0c3df0efb423a2ea5599c61c377bb42722c9b4593094c","first_count":23,"second_count":30,"first_found":7,"second_found":14,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15643365,"duplicates":4,"height":15643365,"block":"be09fc4abd2c849a62958638958cb187083462ef05a77e9b95eb86f5c98f226a","first_count":14,"second_count":18,"first_found":4,"second_found":8,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15653659,"duplicates":11,"height":15653659,"block":"1455b8cd30b274950b4e29201f10d636ffbb6bcd51562fd88b5af6ce907f9bf4","first_count":24,"second_count":35,"first_found":11,"second_found":22,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15309957,"duplicates":16,"height":15309957,"block":"bb81721a36acf691ef4b8b946a23c368f75c65950b444c0d78bd45237da15382","first_count":18,"second_count":34,"first_found":16,"second_found":32,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15433831,"duplicates":70,"height":15433831,"block":"0aa9a24e53ee2bf05e15cf3438b2f1e8db29eae64efcaac163629bbc740f0ad6","first_count":89,"second_count":159,"first_found":70,"second_found":140,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15524938,"duplicates":11,"height":15524938,"block":"06f523708b5bbf584a703513aa50863709ff16d7a304c9d4f0222c19da7f852a","first_count":11,"second_count":22,"first_found":11,"second_found":22,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15580737,"duplicates":3,"height":15580737,"block":"b6db1b377b4e3cc1c5111665c99bd1cd9e3225d104375b59073888c682078a6e","first_count":6,"second_count":9,"first_found":3,"second_found":6,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15549535,"duplicates":10,"height":15549535,"block":"76aa840a984d78bb08337a0e0d858b4cbd52e3b1d17b1e4fb1e31eddb17490a8","first_count":16,"second_count":26,"first_found":10,"second_found":20,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15584000,"duplicates":6,"height":15584000,"block":"48fda6e3db73dda42d69b2d495c91d22e9cb1ac6c7a79630ebc339c66f93e333","first_count":10,"second_count":16,"first_found":6,"second_found":12,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15587766,"duplicates":8,"height":15587766,"block":"02859f22030bdd657f9f969f1819f2bff8532f38ff640e3b3d54a84b4e89da2f","first_count":46,"second_count":54,"first_found":8,"second_found":16,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15642115,"duplicates":26,"height":15642115,"block":"c73f0bc004fb1bf8f1fc90b0544739ca24c041b7e670ebed36a0c45cc1662ae1","first_count":37,"second_count":63,"first_found":26,"second_found":52,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15178293,"duplicates":5,"height":15178293,"block":"c01101309c49ec8a313ecd607383b23bc4acbc5f7996fcd1e619689d9d122b15","first_count":9,"second_count":14,"first_found":5,"second_found":10,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15456402,"duplicates":8,"height":15456402,"block":"0741bfdafc5adb936add80fe1e6114474ca1c7be7ec1c4c891da3b6b41a40d8d","first_count":29,"second_count":37,"first_found":8,"second_found":16,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15468446,"duplicates":7,"height":15468446,"block":"df5d0835e3955123a1ac1d0b5387ed56da71ac4d142a06cdfad7646b1285f052","first_count":15,"second_count":22,"first_found":7,"second_found":14,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15484609,"duplicates":12,"height":15484609,"block":"bb569ef47c5b8ea4567d2b61b4f627fc4071139cc5c3b971285ce56ce9613673","first_count":22,"second_count":34,"first_found":12,"second_found":24,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15242815,"duplicates":2,"height":15242815,"block":"d469eaf6f966f9188132c14e98261c3226d72b581911b4584844e33cf84d66a1","first_count":5,"second_count":7,"first_found":2,"second_found":4,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15491520,"duplicates":3,"height":15491520,"block":"04ea5e3eee1f939767ce60bc85bb9be6b67a9a6b7225df4bed82fb543e28fa16","first_count":10,"second_count":13,"first_found":3,"second_found":6,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15595553,"duplicates":3,"height":15595553,"block":"57143dd9f4cc118a5e0a5a0e69506f85087b09712e350f487e0f4aa6fab58430","first_count":6,"second_count":9,"first_found":3,"second_found":6,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15357137,"duplicates":3,"height":15357137,"block":"11db1962db99b01e2c5f858bcdac704fdb493906c5c2e4bac9be8f03d10d0634","first_count":5,"second_count":8,"first_found":3,"second_found":6,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15434884,"duplicates":71,"height":15434884,"block":"97dbd92112794cbc1e3feee1db75f08c7ca6bf3eb7da6463c7c76b9d455028d2","first_count":206,"second_count":277,"first_found":71,"second_found":142,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15203497,"duplicates":41,"height":15203497,"block":"e3106fd408c7e0422ceabf34a1cb872c8353d53b1f0e58d7ac07677eadf1fe7e","first_count":44,"second_count":85,"first_found":41,"second_found":82,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15435204,"duplicates":15,"height":15435204,"block":"2ba8035abede35cae052405f5832b591e2d4286ab3d124ebe1f8941e4ca56c6f","first_count":128,"second_count":143,"first_found":15,"second_found":30,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15534911,"duplicates":10,"height":15534911,"block":"9175045682e8994bb9e76b0e796ef8b36cb23366ed77c42f3e763898931b6be0","first_count":10,"second_count":20,"first_found":10,"second_found":20,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","height":15562648,"duplicates":2,"height":15562648,"block":"c6f7c99afd31c16383f779afe977483e4d79bf6b04b20fa1df483c0bb46c8c76","first_count":3,"second_count":5,"first_found":2,"second_found":4,"time":"2021-08-12T10:22:56Z","message":"compared duplicates for block"}
{"level":"info","time":"2021-08-12T10:22:56Z","message":"duplicate comparison completed"}

Unfortunately #362 still did not really fix the issue, even though it seemed exactly like what would cause it.


unbound: fix no-cache feature

Years ago I submitted the no-cache feature to unbound which over time broke. I debugged it down to the point that pre-seeding no_cache_store will fix this with minimal changes and make no-cache work again which remains highly valuable in a lot of environments this got deployed.
Obtained from:	https://reviews.freebsd.org/D38057

I suspect that this could be broken because of specific module configuration i.e., the module-config: option.
Do you have a specific configuration where this fails?
By default (module-config: 'validator iterator') it works, as there is a testcase for that already.

I believe last time I checked was with:
module-config: "dns64 validator iterator


Added version

added version in init.py

Coverage decreased (-0.1%) to 79.718% when pulling b7db601eda001b917b691b1bf87f6ac3b2627bd6 on lubon:add_version into 7720187df43c44a4f3a8fb98ee346618b06b75fb on napalm-automation:develop.


Merging swift-DEVELOPMENT-SNAPSHOT-2019-06-17-a into tensorflow

For apple/swift: merge e4e009f74f (from 2019-06-17).
For all other repositories: merge swift-DEVELOPMENT-SNAPSHOT-2019-06-17-a .

@swift-ci Please clean test tensorflow


docs: add deployment instructions for Heroku

This method uses Express to serve the dist directory to Heroku's load balancer.

Will commit again following the naming conventions


API Listproviders endpoint needs a ROLE!

Describe the bug
The API list providers now work fine also with API version attached to the request. However, by passing an Authorization header to that call the response ends up in 401 Forbidden, which means there need to be a listprovider specific ROLE (like ROLE_API_LISTPROVIDERS_VIEW) for the API user to add.
To Reproduce
Steps to reproduce the behavior:

In a clear—not-logged-in session, try to make the HTTP request to the /api/listproviders/*
Add the Authorization header, just like with default API username and password
Make a GET call to one of the listproviders endpoint (i.e. /api/listproviders/providers.json or /api/listproviders/LANGUAGES.json)
See the response, which is always 401 Forbidden!

Expected behavior
Either:

Having a separated ROLE like ROLE_API_LISTPROVIDERS_VIEW to set for the API user.
(Recommended) Make it accessible when the API user has ROLE_API

The first approach, although it seems to be more practical, is not of the favour from LMS side. Because it forces the admins to edit their API user in opencast and if they don't pay attention to the manual or helper docs (Who reads them 😅). They always end up with forbidden error!
Previous Work of this topic
Issue (https://github.com/opencast/opencast/issues/5308) => PR (https://github.com/opencast/opencast/pull/5344)

Having a separated ROLE like ROLE_API_LISTPROVIDERS_VIEW to set for the API user.
(Recommended) Make it accessible when the API user has ROLE_API

Going with 1., as that is common practice. ROLE_API is only used for a few top level paths. And if you don't want to bother with fine grained access control, you can always slap ROLE_ADMIN on your LMS user anyway.

@ferishili this should be fixed in 13.x now, but not forward merged and obviously also not released, yet. However, the fix is just configuration, so you can just apply it locally on your site as well. See #5404.

Great, thanks a lot


Pattern hint

Current dependencies on/for this PR:

main

PR #3744

PR #3745

PR #3746   👈

This comment was auto-generated by Graphite.


[TypeChecker] Fix a problem with rethrows classification.

We failed to properly classify arguments that are of optional function
type, in this case leading to a verification failure due to the throws
attribute on the apply expression not being set to some value.
Fixes: SR-9102 / rdar://problem/45615204

@swift-ci Please smoke test

@rjmccall It's to avoid inferring throwing-function types for nil-literal operands. In decl/func/rethrows.swift there are a couple tests where we start emitting diagnostics about missing try without that change. I suppose it could be pattern-matched as a special-case in the error type checking code as well.


Create a Chat Demo App

This will create a an example app demonstrating the Medplum chat functionality and how to use the Communication resource. This includes creating threads and individual messages, creating linked encounters, and editing threads.

@SocketSecurity ignore<EMAIL_ADDRESS>

This is almost there!
Missing pieces:

Chat input not disabled when thread is closed
No patient profile on left 1/3 of the screen (should be based of the Communication.subject of the thread header)
Errors when trying to create an encounter (specifically when I try to set the Encounter.subject, which should have been autopopulated)
Make the Create Encounter Modal a bit wider
After closing the thread "Blood Test for Peanut Allergy", I get an error (3rd screenshot) whenever I click on the thread

This is looking really great! I just ran on my machine and have a couple fit-and-finish requests

Only show the Create Encounter button if one of the thread participants is a Patient
After creating the Encounter, navigate to the page /Encounter/:id for the newly created encounter
On the encouter page, display the Patient Profile on the left 1/3 of the screen

Appshell.showNotifications = true


EBSI : Drawer / choose issuer registry

This registry is the one we call to get data about the issuers and verifiers (DID document , etc). It changes the API endpoints. For polygon it will change the setup of the PolygondID sdk as the Polygon identity uses the polygon blockchain to write/read data
remove Compelio
remove None
remove Talao
Add Polygon and Polygon testnet with default on Polygon
EBSI is always "on" as there is no EBSI testnet

Rename this registry as "Verifialble Data Registry"