Spline Runtime error

I am using Spine component in react Js with next Js and I get the following errors on my browser window,
Unhandled Runtime Error
Error: fetch for ["http://localhost:3000/_assets/_fonts/poppins_extralight_regular.json"](http://localhost:3000/%22http://localhost:3000/_assets/_fonts/poppins_extralight_regular.json%22) responded with 404: Not Found
Call Stack
eval
<EMAIL_ADDRESS>(2994:158346)

and also this similar error
Unhandled Runtime Error
Error: fetch for ["http://localhost:3000/_assets/_fonts/roboto_regular.json"](http://localhost:3000/%22http://localhost:3000/_assets/_fonts/roboto_regular.json%22) responded with 404: Not Found
Call Stack
eval
<EMAIL_ADDRESS>(2994:158346)

I am using
node version -v14.18.1
react version- 17.0.2
next -12.0.10

Hey! What are the packages that you currently have in your project?

The packages in my project.
"dependencies": {
    "@emotion/react": "^11.7.1",
    "@emotion/styled": "^11.6.0",
    "@fortawesome/fontawesome-free-solid": "^5.0.13",
    "@fortawesome/fontawesome-svg-core": "^1.3.0",
    "@fortawesome/free-solid-svg-icons": "^6.0.0",
    "@fortawesome/react-fontawesome": "^0.1.17",
    "@material-ui/core": "^4.12.3",
    "@material-ui/icons": "^4.11.2",
    "@material-ui/lab": "^4.0.0-alpha.60",
    "@mui/material": "^5.4.1",
    "@mui/x-data-grid": "^5.5.0",
    "@react-spring/parallax": "^9.4.4",
    "@splinetool/react-spline": "^2.0.0",
    "@splinetool/runtime": "^0.9.33",
    "bcrypt": "^5.0.1",
    "bootstrap": "^5.1.3",
    "cookie": "^0.4.2",
    "dotenv": "^16.0.0",
    "jose": "^4.6.0",
    "jquery": "^3.6.0",
    "jsonwebtoken": "^8.5.1",
    "material-ui-popup-state": "^2.0.0",
    "mongodb": "^4.3.1",
    "next": "^12.0.10",
    "next-connect": "^0.12.2",
    "react": "17.0.2",
    "react-dom": "17.0.2",
    "react-easy-crop": "^4.1.4",
    "react-hook-form": "^7.26.0",
    "react-icons": "^4.3.1",
    "react-spring": "^9.4.4",
    "react-ts-modal": "^1.4.0",
    "socket.io-client": "^4.4.1",
    "styled-components": "^5.3.3",
    "webcrypto": "^0.1.1"
  },
  "resolutions": {
    "@types/react": "^18.0.38"
  },
  "devDependencies": {
    "@types/bcrypt": "^5.0.0",
    "@types/cookie": "^0.4.1",
    "@types/jsonwebtoken": "^8.5.8",
    "@types/mongodb": "^4.0.7",
    "@types/node": "17.0.10",
    "@types/react": "18.0.1",
<EMAIL_ADDRESS>"^3.0.0",
    "@types/styled-components": "^5.1.22",
    "eslint": "8.7.0",
    "eslint-config-next": "12.0.8",
    "typescript": "4.5.5"
  }

I don't get the error, what's the relation between Poppins fonts and Spline's runtime?
Try to upgrade maybe your react version or remove the node_modules folder and then npm install.

Already done that, I was also confused about this error. But this error comes from spline and my spline animation has texts in it. Check it out here Spline

Oh okay, that makes sense. Try to optimize your scene on production, there's certainly a button somewhere in their application (the latest update related to compression spline's scenes in prod is  — 13/04/2022).
Also, make sure that you're using the exported production scene. :eyes:

I am using exported scene and the spline works good without texts in it. Can't find the optimize option.

Text is not currently supported in react-spline, it will be supported soon.
In the meantime you can hide the Text objects from your scene to make the example work.

Thanks to everyone for responding to this issue and waiting for the text-support feature to be release.

Leaving this issue open as a reminder!

Text now works correctly. Please re-export your scenes!


Table tool should be disabled when inside a table cell

Right now the tool is enabled, but it doesn't do anything when clicked.

Can you provide an example - using the sandbox the tool behaves as I'd expect and allows you to set the table properties.

Wow my mistake, I never realized that clicking the table tool inside a table opens up it's settings. I thought it was always used for adding tables.

np - glad it wasn't a bug :D


add support for spec v2

This PR supports object_id for ecom spec v2 in a nonbreaking way.
@f2prateek

LGTM


Only one SLS pictures per service stored when filename is the same

The function "Data storage" - "Overwrite existing files" does not work as expected.
I have lots of DAB services where the filename stays the same PAD1_SLS1.JPG for example.
But as soon a new picture is transmitted (with same file name), it's not saved.

When I tick that option, it will be saved, but I'll lose the old one.

Idea
Check the file size, and as soon as it differs from the previous one, it's a new picture, which shall be stored (maybe with an additional time stamp in the file name).

Well, it works as expected. If the file exist is is either overwritten (if set in settings) or dropped.
If you want to store everything as it is received, you should use transportId in the pattern, for example something like: {transportId}_{contentNameWithExt}
This shall be unique for a long time.

oh, what an interesting undocumented feature! That's exactly what I was looking for. :-)
You have explained me SPI and {directoryId} | transport ID of directory [only SPI] is only updated once a day, so I thought I could NOT use the transport ID here.
Maybe you can add this to the readme and add the transport ID to the popup in the tool tip?

Documentation is always painful task. I thought it was clear from the table that transportId applies to any MOT object and to both SLS and SPI application. I will try to improve the description.

As you can see, not even I have understood that :-)


NUR support

I noticed that this template used to have NUR support but it has since been removed.
I was wondering why that is?
I ask, because I'm using this wonderful template, and I had to spend a day or two figuring out how to add NUR support.
I feel like I managed to do it by blind luck, given how little I know of Nix. And I'd like to spare someone else from having to do the same in the future.
I could make a PR with the changes that worked for me. Turned out pretty elegant, I think :smile:
What do you think?

I've submitted a PR with the changes I made to get this to work on my setup.
I'm new to Nix, so if you feel any changes need to be made lmk


New package: lubomirkurcak.tend version 0.2.8

Checklist for Pull Requests

[ ] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Manifests

[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.6 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

@microsoft-github-policy-service agree

Automatic Validation ended with:

Executable C:\Users\validator\AppData\Local\Microsoft\WinGet\Links\tend.exe returned exit code: -1073741515

Automated error analysis suggests -1073741515 may mean STATUS_DLL_NOT_FOUND - possibly due to a dependency on Microsoft.VCRedist.2015+.x64 (or .x86).
(Automated response - build 880.)

This version indeed relies on dynamically linking CRT.
Will close the PR and create new one for newer version.
Thanks


we need error messages in the parser

Something happened between the old parser and the new parser with error messages that has supressed most of the messages.  Now I get lots of cases with no message at all where there used to be expectation failure messages indicating both the right location of the error and at least giving some hint as to what the compiler was thinking.  Now I'm getting the wrong location and no hint at all.  For example, with this functions block
functions {
  real[] ode(real t, real[] y, real[] theta, real[] x, int[] x_int) {
    real dydt[0];
    return dydt;
  }
foo
}

I get an error in the wrong location with no message:
--- Translating Stan model to C++ code ---
bin/stanc /Users/carp/temp2/ois.stan --o=/Users/carp/temp2/ois.cpp --no_main
Model name=ois_model
Input file=/Users/carp/temp2/ois.stan
Output file=/Users/carp/temp2/ois.cpp

SYNTAX ERROR, MESSAGE(S) FROM PARSER:

ERROR at line 1
  1:    functions {
       ^
  2:      real[] ode(real t, real[] y, real[] theta, real[] x, int[] x_int) {

Execute "stanc --help" for more information

The function is well defined here, but the foo is extraneous.  The location of the error should be before the foo, where the parser is expecting either a new function definition or a right curly brace to close the function block.
Options:

sloppy:  put the expectation errors back, with the plan of gradually upgrading them;  this only makes sense if it produces the correct location of the error (maybe a day or less, but with testing).

strict:  do this right and try to catalogue where things can go wrong and design what the parser should do and fix everything (big project).

Closing this.  It's part of #1244 and I've already taken approach (2) in the branch.


Made test_change_list_sorting_model_admin_reverse's assertions more specific.

The test could fail on databases like CockroachDB that use non-serial
primary keys if the numbers (2000, etc.) appeared in the pk values.

Thanks Tim :+1:


Update LllbinParseInfo.cs

Data length error for IsoType: LLLBIN. When value as LLLBIN is being parsed, value is parsed with the wrong length.

Closing this PR since there is no unit test. You can reopen it whenever you properly add a unit test


Running as non-root user who is not permitted to run sysctl as root by doas(1) results in "Operation not permitted" errors

I generally run recordctl with doas(1), as I also suggest in the README, so that it can modify kern.audio.record & kern.video.record sysctl(8) variables: doas recordctl. Unfortunately, if the user doesn't have a permit entry in doas.conf for sysctl(8), they'll get "Operation not permitted" error(s) from sysctl(8) when it is executed. For example:
$ doas recordctl
sysctl: kern.audio.record: Operation not permitted
sysctl: kern.video.record: Operation not permitted

One will receive the same errors if running recordctl directly from a non-root user. At a minimum, if recordctl is executed by a non-root user, it would fail and return a non-zero EXIT code without even trying to execute sysctl(8).
Better, I recently discovered that the doas(1) -C config option can be used, if the command arguments are also passed in, to test whether the user is permitted to run the command (it will output either deny, permit nopass, or permit). So, we could determine in advance whether the user is permitted to execute the required sysctl(8) command to set the variable values. For example:
$ doas -C /etc/doas.conf sysctl kern.audio.record=1
permit

So, I propose the following implementation:

Add a new -n option to function like the doas(1) -n option (fail if the user is not permitted to run the sysctl(8) commands non-interactively; e.g. missing nopass in doas.conf(5))
Upon execution (unless using the not-yet-implemented -m monitoring option):

Print an error about not having permission and EXIT > 1 if the user is not root or if doas(1) doesn't permit the user to execute all of the following as root (e.g. neither permit nor permit nopass):

sysctl kern.audio.record=0
sysctl kern.audio.record=1
sysctl kern.video.record=0
sysctl kern.video.record=1

If the -n option is provided, the above logic should be tightened to be either root or doas(1) permitting executing as root with no password (e.g. not permit nopass)

Okay, I have this implemented and seems to work correctly in my latest testing. I'll be updating the manual page next.

Manual page updated. Next up: the README.

Okay, I discovered that ability to use doas -C to test whether commands are permitted by doas(1) was based on incorrect local permissions, so I have thrown away the previous implementation, updated this issue's description, and implemented just the basic check for root privilege in recordctl. That implementation is now ready to go.


Can't process folders

I can optimize individual files but if I do something like: svgo -f ./svg it just says C:\current\path\svg:.
If I do svgo -f ./svg -o min it runs through all the files and says it has optimized each one, but there is no output folder and no output files.
I have also tried variations on input and output folder like svg, /svg, /svg/, ./svg/, and svg/. And I have tried back slashes as well. I am using Windows 7 64-bit.

v0.5.1 with the fix has been just published.


[Feature]: Improved console.* usability when focusing a test

🚀 Feature Proposal
Make console.* more useful when focusing on a single test by either:

Allowing to not print the test names of skipped tests (and related information such as obsolete snapshots)
Moving console.* calls below the test summary

Motivation
Especially in large test suites I usually focus on a single test when working on a bug/feature. In some cases (e.g. new codebase, simple debugging instructions) I prefer to use console.* methods.
However, Jest currently displays them before the test summary which means I have to constantly scroll back up or, even worse, in the case of test failures I have to scroll between bottom (for the failure) and top (for the log).
Example
In the React codebase (51947a14bb24bd151f76f6fc0acdbbc404de13f7) with
diff --git a/packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js b/packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js
index 435e90d9b1..cce594175c 100644
--- a/packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js
+++ b/packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js
@@ -126,6 +126,8 @@ describe('ReactDOMServerSelectiveHydration', () => {
   });

   it('hydrates the target boundary synchronously during a click', async () => {
+    console.log(1)
+    throw new Error()
     function Child({text}) {
       Scheduler.unstable_yieldValue(text);
       return (

$ yarn test ReactDOMServerSelectiveHydration --watch --testNamePattern 'hydrates the target boundary synchronously during a click'
console.log
    1

      at Object.<anonymous> (packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js:129:13)

 FAIL  packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js
  ReactDOMServerSelectiveHydration
    ✕ hydrates the target boundary synchronously during a click (99 ms)
    ✓ hydrates the target boundary synchronously during a click (createEventHandle) (50 ms)
    ○ skipped hydrates at higher pri if sync did not work first time
    ○ skipped hydrates at higher pri for secondary discrete events
    ○ skipped hydrates at higher pri if sync did not work first time (createEventHandle)
    ○ skipped hydrates at higher pri for secondary discrete events (createEventHandle)
    ○ skipped hydrates the hovered targets as higher priority for continuous events
    ○ skipped replays capture phase for continuous events and respects stopPropagation
    ○ skipped replays event with null target when tree is dismounted
    ○ skipped hydrates the last target path first for continuous events
    ○ skipped hydrates the last explicitly hydrated target at higher priority
    ○ skipped hydrates before an update even if hydration moves away from it
    ○ skipped fires capture event handlers and native events if content is hydratable during discrete event
    ○ skipped does not propagate discrete event if it cannot be synchronously hydrated
    can handle replaying events as part of multiple instances of React
      ○ skipped Inner hydrates first then Outer
      ○ skipped Outer hydrates first then Inner

  ● ReactDOMServerSelectiveHydration › hydrates the target boundary synchronously during a click

      128 |   it('hydrates the target boundary synchronously during a click', async () => {
      129 |     console.log(1)
    > 130 |     throw new Error()
          |           ^
      131 |     function Child({text}) {
      132 |       Scheduler.unstable_yieldValue(text);
      133 |       return (

      at Object.<anonymous> (packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js:130:11)
      at asyncGeneratorStep (packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js:12:310)
      at _next (packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js:12:648)
      at packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js:12:813
      at Object.<anonymous> (packages/react-dom/src/__tests__/ReactDOMServerSelectiveHydration-test.internal.js:12:554)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 14 skipped, 1 passed, 16 total
Snapshots:   0 total
Time:        0.844 s

Notice the, in my opinion, wasted space by the list of skipped tests.
Related issues: https://github.com/facebook/jest/issues/2169
Pitch
The current behavior encourages small test files or straight up not focusing on a single test. However, iteration speed for debugging is very important so people may be hesitant to add more tests due to Jest becoming harder to read when focusing on a single test.

Comment

Comment

bump

bump

Comment

This sounds like it can just be a custom reporter. Or possibly configuration for the built in reporters?


Why React-based

Can someone explain why base is currently React-based?
Questions:

What i will gain using react instead of only meteor?
React is an external framework and the meteorchef is the biggest reference about meteor. Using react in base maybe can make peoples think react is a requirement for meteor?
Maybe is possible create a base without react?

This choice was made due to the Meteor Development Group's decision to stop work on its own UI framework Blaze. Additionally, I realized that the React community/resource pool is far larger than Blaze and it made sense to leverage that as opposed to limit folks. Finally? I'm a personal fan of React and have found it keeps code organized and easy to understand. React is not a requirement for Meteor, just one of a few options for handling your UI.
Re: a version of Base without React, this has been discussed but I have no concrete plans for when I'd do it. If you'd like to see an early approach without React, check out any of the tags on this repo before 4.0.0.


Closes #31 #32

Closes #31 #32
This PR adds minor changes to use cylon oauth2 client with other oauth2 providers (like Google)

so easy? no discussion?
wow!
:)

haha!
On 5 February 2015 at 17:01, tangrammer<EMAIL_ADDRESS>wrote:

so easy? no discussion?
wow!
:)
—
Reply to this email directly or view it on GitHub
https://github.com/juxt/cylon/pull/33#issuecomment-73083480.


Verify and document Ubuntu versions for Beckn ONIX

Description
The goal of this ticket is to verify and document the versions of Ubuntu on which Beckn ONIX has been tested and confirmed to work. Specifically, the verified versions 22.04 and 20.04 need to be mentioned in the guide as pre-requisites. Additionally, it should be checked if Beckn ONIX works with Ubuntu version 24.04.
Goals

[x] Document Ubuntu versions 22.04 and 20.04 as verified pre-requisites for Beckn ONIX in the guide.
[ ] Verify if Beckn ONIX works with Ubuntu version 24.04.
[x] Update the guide with findings from the verification process for Ubuntu 24.04.

Expected Outcome
The guide for Beckn ONIX will be updated to include Ubuntu versions 22.04 and 20.04 as pre-requisites. Verification results for Ubuntu version 24.04 will be documented, and the guide will be updated accordingly.
Acceptance Criteria

[ ] Ubuntu versions 22.04 and 20.04 are documented as pre-requisites in the guide.
[x] Verification process for Ubuntu version 24.04 is completed.
[ ] Guide is updated with the findings from the verification of Ubuntu 24.04.

Mockups / Wireframes
Not applicable
Product Name
Beckn
Domain
Beckn ONIX
Tech Skills Needed

Beckn ONIX
Ubuntu Administration
Documentation

Complexity
Low
Category
Infrastructure
Sub Category
Documentation and Verification

We have updated the Document with supported OS details.
PR: https://github.com/beckn/beckn-onix/pull/190

Review Completed
@prasad-takale-eminds  please merge the PR as @vbabuEM  has already approved it

@emmayank - As we discussed in today sync up call, if the PR is merged please update the card and take it closure.
@viraj89 @faizmagic


fix: always pop current element in readStringOpt and readBufferOpt

In the case of null elements, the current stack element wasn't popped which caused incorrect processing of the subsequent tuple elements.
Here is the issue in Tact https://github.com/tact-lang/tact/issues/918 where this bug manifests itself.

@dvlkv Thanks a lot!


basic mixpanel tracking

Hi!
Thanks so much for creating this repo. I'm having trouble doing basic mixpanel tracking.
I've set up my template html file to look like this:
{% load analytical %}
{% load mixpanel %}
<!DOCTYPE ... >
<html>
    <head>
        {% analytical_head_top %}

        ...

        {% analytical_head_bottom %}
    {% mixpanel %}
    </head>
    <body>
        {% analytical_body_top %}

        ...

        {% analytical_body_bottom %}
    </body>
</html>

and my settings.py file looks like:
INSTALLED_APPS = [
    ...
    'analytical',
    ...
]

I also added my MIXPANEL_API_TOKEN to settings.py as well, and I have django-analytical==3.1.0 in my requirements.txt file.
I deployed these changes to a test website, so it's in prod, not dev.
I think I must be missing something -- should I be making any other code changes to enable tracking?
Thanks!

I think you're mixing up the generic setup for Analytical and the specific setup for Mixpanel.
Try to remove the {% mixpanel %} from your code. It should only be necessary if you don't (want to) use the generic setup.
Also, take a look at the generated code in your web browser. You should be able to see the JavaScript code snippet included in the HTML once.
Let us know if that works or if there is actually some issue with the integration!

I can't answer this question for sure. Usually, our documentation walks you through the complete setup steps, at least on the Django side.
Note that Analytical is really just a template tag library that injects a JavaScript code snippet into your Django templates. All the rest depends on the provider of the analytics service.
It could be that Mixpanel have changed their setup, and that the one that was contributed to Analytical is legacy. But really that's just guessing on my side, based on the fact that I can't find the code snippet we have in their documentation.
If you find out more please post your findings here for everyone to benefit. Thanks!

I know this seems like an extremely simple question so thank you for helping me -- I don't see any events showing up in my Mixpanel dashboard. Should I be making any other code changes to enable tracking? Does django-analytical automatically track all clicks on the website? (I suspect the answer is "no", but I'm asking this as an example).

I can answer that. Because it's not obvious what events are "interesting", django-analytical will not send any events itself. There is some hints about sending events yourself in the documentation, and a very old issue (#10) on doing something generic.


Can't view my Next.js app when running mightymeld studio

Describe the bug
My application does not show up when I run npx mightymeld  and launch the MightyMeld studio. All is see are the side panels and a blank grey page where my application UI should be displayed. This is a recent behavior I am experiencing.
I initially suspected it may be due to a slow internet connection at the time, but it persisted since.
To Reproduce
Steps to reproduce the behavior:

Run your setup Next.js app with npx mightymeld
Navigate to the launched mightymeld studio in your browser
Attempt to view your application UI
See error

Expected behavior
I expect to see my running application's UI and select elements from the window view area
Screenshots

Environment

OS: MacOS Sonomo 14.5
Browser: Arc Browser
MightyMeld Version: v0.2.10

App

Framework: Next.js
Link to repo: https://github.com/theadultnoble/weather42.git

Hey @theadultnoble thanks for sharing the repo.
I took these steps on my Mac:

cloned the repo
npm i
npx mightymeld

It launched for me on Arc (see screenshot below). I'm on Ventura 13.3 but otherwise the setup is the same.
Here are my thoughts for next things to try:

try doing a hard reset of your browser cache
look in the console and network tab - do you see anything unexpected?
as a sanity check, try running MightyMeld in Chrome.
open you app (which should be at http://localhost:3001/) in its own tab. does it look OK?

Please let me know what you find when you try these steps.

Also worked for me. What version of node / npm are you on?

@tim-dev @schkolne I'm on npm version 9.8.0 and node v20.5.0.
I tried clearing and resetting my browser cache on Arc. I also inspected the console. Nothing unusual.
However, I installed Chrome and ran it there. it worked fine.
I'll do some further research and see what I find as to why it stopped working on my Arc browser.

@theadultnoble thanks for the additional detail and glad to hear you got it working in Chrome! yes please do let us know if you figure out why it wasn't working in Arc.


Fix typo

https://github.com/tsukasaoishi/word_scoop/blob/master/ext/word_scoop/word_scoop.c#L216
t_filter_hrml is t_filter_html

Fixed e46f32e7ed6a4


anyOf() throws ClassCastException when used with pattern match.

Hi,
@danieldietrich i'm getting the below exception when i match against using  anyOf predicate i'm not sure whether this is the actual behaviour or it needs a fix. Thanks..
java.lang.ClassCastException: class io.vavr.collection.List$Cons cannot be cast to class java.lang.Number (io.vavr.collection.List$Cons is in unnamed module of loader 'app'; java.lang.Number is in module java.base of loader 'bootstrap')
public void shouldPatternMatchForGivenPredicate() {

     List<Integer> list = List(1, 2, 3);
     Predicate<Number> p = n -> n.intValue() > 0;
     Match(list).of(
            Case($(anyOf(p)), true),
            Case($(), false)
    );

}

Thx! Interesting - this should not happen. In fact there should be a compile error if you do it this way because the List is matched, not the contained elements. Will check that!

I will close this because it can't be reproduced. Maybe you used an outdated version of VAVR?
I implemented the test case you provided. The CI build passed for jdk8, jdk9, jdk10, jdk11 and jdk12.
PR: https://github.com/vavr-io/vavr/pull/2428
CI: https://travis-ci.org/vavr-io/vavr/builds/554424019

Now it hit me in #2452.

It isn't a VAVR bug. It is a wrong application of pattern matching.
This is the way it works:
public void shouldPatternMatchForGivenPredicate() {

     List<Integer> list = List(1, 2, 3);
     Predicate<Number> p = n -> n.intValue() > 0;
     Match(list).of(
            Case($(l -> l.exists(anyOf(p))), true),
            Case($(), false)
    );

}


Feature/2135/script between tests

https://github.com/ga4gh/dockstore/issues/2135
--script is now NOT carried between tests.
Edit:
Within the Client, --script is only set if you specify it and call Client.main or Client.run directly. For these tests we simply add --script to the args. Some tests call functions downstream of main/run, which means that script is not being set. So you have to manually do Client.SCRIPT.set(true/false) for these tests.

Coverage decreased (-2.3%) to 73.016% when pulling 452083bc6b99a85b3d32a8238e9cfa0b33b06416 on feature/2135/script-between-tests into 96a36302904a759973f928135fdc1d3a3f6774fb on develop.

Coverage decreased (-2.3%) to 73.016% when pulling 452083bc6b99a85b3d32a8238e9cfa0b33b06416 on feature/2135/script-between-tests into 96a36302904a759973f928135fdc1d3a3f6774fb on develop.


Allow Bandcamp to parse and download all albums

Hello,
First of all, thanks in advance for this great tool. :smile:
I'm really happy with all the work you and others have put into this and I hope my commits may be helpful.
Before going any further, it is worth mentioning how some special Bandcamp pages seem to work:
....bandcamp.com/releases    ==>    mirrors the page of the artist's latest album
....bandcamp.com/music       ==>    shows a grid with all albums of the band
....bandcamp.com/merch       ==>    shows a bunch of merchandise

The main URL (....bandcamp.com) usually mirrors one of those.
Here's an example where /releases is mirrored: https://mothermooch.bandcamp.com/
Here's an example where /music is mirrored: https://mississippibones.bandcamp.com/
(examples checked as of 2015/October/31 - may differ in the future)
(I can't find any examples right now, but I'm 100% sure some bands choose to mirror /merch)
While testing SoundScraper, I couldn't download all albums from a certain band.
This band's main URL was mirroring /music, so it couldn't be parsed correctly.
SoundScraper would also fail for any artists mirroring /merch, for obvious reasons.
So, these are my main proposed additions with this Pull Request:
[1] The /music page is now accessed when only the artist's username is provided
[2] The /music page is now parsed, recursively calling the relevant method for each album URL
This only introduces a small bug: the limit of tracks is applied for each album separately.
It's like "num_tracks" actually means "num_tracks_per_album".
(if num_tracks=2 and the band has 5 albums, you're going to download 10 tracks)
I'm sure it's an easy fix, but I didn't have time to give it a closer look. :neutral_face:
I'm kinda busy and had to use the browser editor to commit my changes, so I may have messed up the indentation. Sorry. :expressionless:
Best regards,
Antonio

Hey MasterFocus!
Thanks for the PR! I'm happy to accept this update, although it seems like you have introduced some formatting errors which cause the tests to fail.
Can you please run your changes through PEP8ify and make sure that the tests pass? It'd also be great if you could write a test for the specific case you are adding support for.
Thanks!

This is indeed my first PR ever on GitHub, so I just noticed the indentation problem. I'll try to fix that ASAP. I'll also try to add tests as you mentioned in the near future. Once again, thanks for your work (and your patience :sweat_smile:)!

Merged, and published as version 0.20.0
Thank you for your contribution! :D

This has already been useful for me today!! Thanks!


feat(libreoffice): add macOS *.pages support

Closes #635.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 93.31%.  Consider uploading reports for the commit 53dbfba to get more accurate results

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #812   +/-   ##
=======================================
  Coverage   93.31%   93.31%
=======================================
  Files          42       42
  Lines        3468     3469    +1
=======================================
+ Hits         3236     3237    +1
  Misses        147      147
  Partials       85       85

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Hey 👋
saw this, and it seems interesting, but I noticed it doesn't support "key"(notes) files is there a reason or a plan about that?

Hello @eMerzh 👋 what’s a « key »?

keynotes (apple's powerpoint)

It’s mostly a file extension to add, plus some testing to check if LibreOffice is able to handle such files.


allow info.version: null

the api client breaks if the document has info.version: null, let's be easy with that, it’s totally okay and actually AFAIK completely irrelevant for the client if this value is null. :)

{
"openapi": "3.1.0",
"info": {
"title": "Nitro Server Routes",
"version": null
}
}

according to the spec it is mandatory, should we just default to 0.0.1?

also that nitro package can pull all this info from the package.json like we do in that next POC 😉

I’ve seen other OpenAPI documents without a version, too! ✌


Newsletters: add #38 (2019-03-19)

Added a commit that should address all the feedback I didn't comment on directly.
This currently includes a link to an email by Rusty Russell about the mailing list move on lightning-dev.  A more detailed post that also covers bitcoin-dev has been sent to that list by Warren Togami, but it hasn't made it through moderation yet.  It would be a good idea to check the archive to see if it's available before we publish and, if so, update the link to point to it.  Otherwise, I think the current link is acceptable.

It would be a good idea to check the archive to see if it's available before we publish and, if so, update the link to point to it.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016785.html is there now but could link to both?

Updated mailing list sections with both links, as suggested by @ajtowns, and squashed.

ACK b1614c9863ef48d0cd6b8232efcc308d4d84c732. Thanks @harding and all reviewers! :1st_place_medal:


Add examples of common category nodes

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)

Proposed changes

This PR add examples of common category nodes.
Checklist

[x] I have read the contribution guidelines
[x] For non-bugfix PRs, I have discussed this change on the forum/slack team.
[x] I have run grunt to verify the unit tests pass
[ ] I have added suitable unit tests to cover the new/changed functionality

Coverage remained the same at 77.466% when pulling 62ec7f4d3756c6a214e1a21a5569cf47e9916dd3 on node-red-hitachi:common-category-examples into efb9dce92fca61238dabf5c15b4467075b76318e on node-red:dev.

The Debug example contains 5 different example flows - we should try not to do that. Each example should be demonstrating one thing and allow the user to get the example they need without having to import one example and then search through it.

updated example flow to make each example individual one

added missing examples of inject node referring related Node-RED cookbook items.


Contributing : Questions about the developpement environment

I am trying to understand the build and test process of the repo.
After a fresh clone I run
> yarn install
> npm run buil
> npm run int-test

at the root and all the tests fail.
Below is a sample of the errors
--snip--
FAIL int-test/OperationFunctionality.test.ts (8.935 s)
  ● CAP V4 Integration Testing: Operation Capabilities › string returning function with param
    connect ECONNREFUSED <IP_ADDRESS>:4004
  ● CAP V4 Integration Testing: Operation Capabilities › string collection returning function
    connect ECONNREFUSED <IP_ADDRESS>:4004
  ● CAP V4 Integration Testing: Operation Capabilities › entity type returning function
    connect ECONNREFUSED <IP_ADDRESS>:4004
  ● CAP V4 Integration Testing: Operation Capabilities › entity collection returning function
    connect ECONNREFUSED <IP_ADDRESS>:4004
FAIL int-test/QueryFunctionality.test.ts (8.973 s)
  ● CAP V4 Integration Testing: Query Capabilities › list books with count
    connect ECONNREFUSED <IP_ADDRESS>:4004
  ● CAP V4 Integration Testing: Query Capabilities › get book zero
    connect ECONNREFUSED <IP_ADDRESS>:4004
--snip--

If I run examples/bookshop > npm run start they all pass.
Maybe thats why the script is lifted in the global package.json under the name start-cap ?
Is the complete build/test process supposed to be :
> yarn install
> npm run build
> npm run test
> npm run start-cap
> npm run int-test

?

Hey,
sorry, that you've had that hassle. You're right.
But usually I would only run the unit tests when developing.
The integration tests are a last line of defense => does it really work the way as the library assumes?

Of course!
Oh man, I've got bad conscience now... the two packages without tests....

Hi @Involture,
I've added now the contribution guidelines.
They try to capture what you needed to do. Can you please take a look? Is anything missing? Any suggestions?
Additionally, each README also got a section about "support, feedback and contributing" referencing these guidelines.


Add quiet mode for backup and restore

Add quiet mode in command-line options to not display rsync verbose mode

Done in commit c8e35f06faef35ec791563e5130c97afcde21b5a.


Cannot use @relation(id) to specify the side of the relation

The examples for lift shows the following:
// The @relation attribute can be used to specify the side of the foreign key.
// Here, it's explicitly stored on the `User` model.
model User {
  id        Int           @id
  customer  Customer?     @relation(id) // stores a foreign key
  name      String
}

model Customer {
  id       Int     @id
  user     User?
  address  String
}

However, when trying it with the following schema:
datasource db {
  provider = "sqlite"
  url      = "file:dev.db"
  default  = true
}

generator photon {
  provider = "photonjs"
}

model B {
  id String @default(cuid()) @id
  a  A?     @relation(id, name: "BtoA")
  c  C?     @relation(id, name: "BtoC")
}

model A {
  id String @default(cuid()) @id
  b  B?
}

model C {
  id String @default(cuid()) @id
  b  B?
}

And then opening the generated dev.db file and exporting its schema, we get the following:
CREATE TABLE "A"("id" TEXT NOT NULL  ,PRIMARY KEY ("id"));
CREATE TABLE "B"("id" TEXT NOT NULL  ,"a" TEXT   REFERENCES A(id),PRIMARY KEY ("id"));
CREATE TABLE "C"("id" TEXT NOT NULL  ,"b" TEXT   REFERENCES B(id),PRIMARY KEY ("id"));
...

This shows that B has the foreign key of A, but it does not have the foreign key of C. In the contrary, it's C that has the foreign key of B.

You will need to do the following:
datasource db {
  provider = "sqlite"
  url      = "file:dev.db"
  default  = true
}

generator photon {
  provider = "photonjs"
}

model B {
  id String @default(cuid()) @id
  a  A?     @relation(references: [id], name: "BtoA")
  c  C?     @relation(references: [id], name: "BtoC")
}

model A {
  id String @default(cuid()) @id
  b  B?
}

model C {
  id String @default(cuid()) @id
  b  B?
}

Can you please share the link the to example?

Ah, thanks for the answer, so that means it's just an inconsistency between the documentation and the example.
The example can be found directly on the https://lift.prisma.io/ website, when clicking on the "One to One" button

Thanks a lot for opening this issue @Errorname 🙌 I've just updated the example code on the Lift website and also clarified this in the actual documentation.


1.3.275.0: missing checking VulkanHeaders and volk.c installation

Instead hardcoding pulling vulkan heders better would just add checking dependencies
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -61,31 +61,7 @@
 # -----------------------------------------------------
 # Vulkan transitive dependency

-if(VOLK_PULL_IN_VULKAN)
-  # If CMake has the FindVulkan module and it works, use it.
-  find_package(Vulkan QUIET)
-
-  # Try an explicit CMake variable first, then any Vulkan paths
-  # discovered by FindVulkan.cmake, then the $VULKAN_SDK environment
-  # variable if nothing else works.
-  if(VULKAN_HEADERS_INSTALL_DIR)
-    message("volk: using VULKAN_HEADERS_INSTALL_DIR option")
-    set(VOLK_INCLUDES "${VULKAN_HEADERS_INSTALL_DIR}/include")
-  elseif(Vulkan_INCLUDE_DIRS)
-    message("volk: using Vulkan_INCLUDE_DIRS from FindVulkan module")
-    set(VOLK_INCLUDES "${Vulkan_INCLUDE_DIRS}")
-  elseif(DEFINED ENV{VULKAN_SDK})
-    message("volk: using VULKAN_SDK environment variable")
-    set(VOLK_INCLUDES "$ENV{VULKAN_SDK}/include")
-  endif()
-
-  if(VOLK_INCLUDES)
-    if(TARGET volk)
-      target_include_directories(volk PUBLIC "${VOLK_INCLUDES}")
-    endif()
-    target_include_directories(volk_headers INTERFACE "${VOLK_INCLUDES}")
-  endif()
-endif()
+find_package(VulkanHeaders)

 # -----------------------------------------------------
 # Installation

Please let me know if you want above as PR.
Other thing is installation of both files volk.h and volk.c.
https://github.com/zeux/volk/blob/f2a16e3e19c2349b873343b2dc38a1d4c25af23a/CMakeLists.txt#L99

Yet another issue: looks like tests/ content is n`ot integrated with ctest
+ /usr/bin/ctest --test-dir x86_64-redhat-linux-gnu --output-on-failure --force-new-ctest-process -j48
Internal ctest changing into directory: /home/tkloczko/rpmbuild/BUILD/volk-vulkan-sdk-1.3.275.0/x86_64-redhat-linux-gnu
Test project /home/tkloczko/rpmbuild/BUILD/volk-vulkan-sdk-1.3.275.0/x86_64-redhat-linux-gnu
No tests were found!!!

Please let me know if you want above as PR.

What if VulkanHeaders is not available as a CMake module? volk is explicitly designed to work without it.

Other thing is installation of both files volk.h and volk.c.

Intended to make header-only mode work I believe.

What if VulkanHeaders is not available as a CMake module? volk is explicitly designed to work without it.

As usually cmake will exit with exit code and error message that this dependency is missing in build env.
Really please do not hardcode any network interactions because most of the distributions build envs are INTENTIONALLY cut off from access to public network.

What network interactions do you mean?

As usually cmake will exit with exit code and error message that this dependency is missing in build env.

The support for VULKAN_SDK env var in particular is valuable for Windows installations where CMake doesn't always have access to the modules I believe, or didn't in the past. It might make sense to replace the use of Vulkan module with VulkanHeaders but it still must be conditional and configurable externally. Additionally some of the "complexity" is due to Vulkan SDK build process where I think it wants to be able to supply VULKAN_HEADERS_INSTALL_DIR variable externally to override the default choice. So there are three conditions in the snippet, and all three serve a specific purpose.

Above patch is incorrect. Please ignore it.

Intended to make header-only mode work I believe. See 51f8af5.

Q: why by default cmake do not build and install, cmake module, static library and volk.h? 🤔

Yeah, it would probably make more sense for installation of volk.c to be conditional on VOLK_HEADERS_ONLY. cc @jeweg for opinion on this as the author of the original change.

The support for VULKAN_SDK env var in particular is valuable for Windows installations where CMake doesn't always have access to the modules I believe

Vulkan-Headers installs Vulkan headers and VulkanHeaders cmake module which is possible to require in other projects like here
https://github.com/KhronosGroup/Vulkan-Utility-Libraries/blob/4cfc176e3242b4dbdfd3f6c5680c5d8f2cb7db45/CMakeLists.txt#L28

For FindVulkan specifically, I believe VULKAN_SDK env var will be considered from CMake 3.18 - but earlier versions will probably be safer doing the env check that volk is doing. This might not be very important for the project you linked and/or it might have been made after CMake 3.18. For that project the min. version is 3.17 but for volk it's 3.5.

For example with below patch:
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -61,31 +61,7 @@
 # -----------------------------------------------------
 # Vulkan transitive dependency

-if(VOLK_PULL_IN_VULKAN)
-  # If CMake has the FindVulkan module and it works, use it.
-  find_package(Vulkan QUIET)
-
-  # Try an explicit CMake variable first, then any Vulkan paths
-  # discovered by FindVulkan.cmake, then the $VULKAN_SDK environment
-  # variable if nothing else works.
-  if(VULKAN_HEADERS_INSTALL_DIR)
-    message("volk: using VULKAN_HEADERS_INSTALL_DIR option")
-    set(VOLK_INCLUDES "${VULKAN_HEADERS_INSTALL_DIR}/include")
-  elseif(Vulkan_INCLUDE_DIRS)
-    message("volk: using Vulkan_INCLUDE_DIRS from FindVulkan module")
-    set(VOLK_INCLUDES "${Vulkan_INCLUDE_DIRS}")
-  elseif(DEFINED ENV{VULKAN_SDK})
-    message("volk: using VULKAN_SDK environment variable")
-    set(VOLK_INCLUDES "$ENV{VULKAN_SDK}/include")
-  endif()
-
-  if(VOLK_INCLUDES)
-    if(TARGET volk)
-      target_include_directories(volk PUBLIC "${VOLK_INCLUDES}")
-    endif()
-    target_include_directories(volk_headers INTERFACE "${VOLK_INCLUDES}")
-  endif()
-endif()
+find_package(VulkanHeaders ${VERSION} REQUIRED)

 # -----------------------------------------------------
 # Installation

if headers are not isntalled
+ /usr/bin/cmake -B x86_64-redhat-linux-gnu -D BUILD_SHARED_LIBS=ON -D CMAKE_AR=/usr/bin/gcc-ar -D CMAKE_BUILD_TYPE=RelWithDebInfo -D CMAKE_C_FLAGS_RELEASE=-DNDEBUG -D CMAKE_CXX_FLAGS_RELEASE=-DNDEBUG -D CMAKE_Fortran_FLAGS_RELEASE=-DNDEBUG -D CMAKE_INSTALL_PREFIX=/usr -D CMAKE_NM=/usr/bin/gcc-nm -D CMAKE_RANLIB=/usr/bin/gcc-ranlib -D CMAKE_VERBOSE_MAKEFILE=ON -D INCLUDE_INSTALL_DIR=/usr/include -D LIB_INSTALL_DIR=/usr/lib64 -D LIB_SUFFIX=64 -D SHARE_INSTALL_PREFIX=/usr/share -D SYSCONF_INSTALL_DIR=/etc -S .
-- The C compiler identification is GNU 14.0.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
CMake Error at CMakeLists.txt:64 (find_package):
  By not providing "FindVulkanHeaders.cmake" in CMAKE_MODULE_PATH this
  project has asked CMake to find a package configuration file provided by
  "VulkanHeaders", but CMake did not find one.

  Could not find a package configuration file provided by "VulkanHeaders"
  with any of the following names:

    VulkanHeadersConfig.cmake
    vulkanheaders-config.cmake

  Add the installation prefix of "VulkanHeaders" to CMAKE_PREFIX_PATH or set
  "VulkanHeaders_DIR" to a directory containing one of the above files.  If
  "VulkanHeaders" provides a separate development package or SDK, be sure it
  has been installed.

-- Configuring incomplete, errors occurred!

For FindVulkan specifically, I believe VULKAN_SDK env var will be considered from CMake 3.18 - but earlier versions will probably be safer doing the env check that volk is doing.

Please do not use that cmake module.
https://github.com/KhronosGroup/Vulkan-Headers/ installs always headers and cmake VulkanHeaders module. That module i VERSIONED. What is in cmake FindVulkan has no version checking. I think that cmake should stop provide that module.

Yeah, it would probably make more sense for installation of volk.c to be conditional on VOLK_HEADERS_ONLY. cc @jeweg for opinion on this as the author of the original change.

But again .. what is the sense install volkc.c if that installed static library has been generated out of that file? 🤔

What is in cmake FindVulkan has no version checking

What version checking are you talking about? In other words, can you explain the issues that existing header discovery logic in volk is causing?
Let’s discuss the volk.c installation in a separate issue, feel free to open one.

Here is proposition of the patch which I've added to my rpm build procedure:
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -2,47 +2,35 @@
 cmake_policy(PUSH)
 cmake_policy(SET CMP0048 NEW) # project(... VERSION ...) support

-project(volk VERSION
-# VOLK_GENERATE_VERSION
-275
-# VOLK_GENERATE_VERSION
-  LANGUAGES C
+project(volk
+  VERSION      1.3.275.0
+  DESCRIPTION  "volk - meta-loader for Vulkan"
+  HOMEPAGE_URL https://github.com/zeux/volk/
+  LANGUAGES    C
 )

+include(GNUInstallDirs)
+
 # CMake 3.12 changes the default behaviour of option() to leave local variables
 # unchanged if they exist (which we want), but we must work with older CMake versions.
 if(NOT DEFINED VOLK_STATIC_DEFINES)
   option(VOLK_STATIC_DEFINES "Additional defines for building the volk static library, e.g. Vulkan platform defines" "")
 endif()
-if(NOT DEFINED VOLK_PULL_IN_VULKAN)
-  option(VOLK_PULL_IN_VULKAN "Vulkan as a transitive dependency" ON)
-endif()
-if(NOT DEFINED VOLK_INSTALL)
-  option(VOLK_INSTALL "Create installation targets" OFF)
-endif()
-if(NOT DEFINED VOLK_HEADERS_ONLY)
-  option(VOLK_HEADERS_ONLY "Add interface library only" OFF)
-endif()
-if(NOT DEFINED VULKAN_HEADERS_INSTALL_DIR)
-  option(VULKAN_HEADERS_INSTALL_DIR "Where to get the Vulkan headers" "")
-endif()

 # -----------------------------------------------------
 # Static library

-if(NOT VOLK_HEADERS_ONLY OR VOLK_INSTALL)
-  add_library(volk STATIC volk.h volk.c)
-  add_library(volk::volk ALIAS volk)
-  target_include_directories(volk PUBLIC
-    $<BUILD_INTERFACE:${CMAKE_CURRENT_LIST_DIR}>
-    $<INSTALL_INTERFACE:include>
-  )
-  if(VOLK_STATIC_DEFINES)
-    target_compile_definitions(volk PUBLIC ${VOLK_STATIC_DEFINES})
-  endif()
-  if (NOT WIN32)
-    target_link_libraries(volk PUBLIC dl)
-  endif()
+add_library(volk STATIC volk.h volk.c)
+add_library(volk::volk ALIAS volk)
+target_include_directories(volk PUBLIC
+  $<BUILD_INTERFACE:${CMAKE_CURRENT_LIST_DIR}>
+  $<INSTALL_INTERFACE:include>
+)
+if(VOLK_STATIC_DEFINES)
+  target_compile_definitions(volk PUBLIC ${VOLK_STATIC_DEFINES})
+endif()
+if (NOT WIN32)
+  target_link_libraries(volk PUBLIC dl)
 endif()

 # -----------------------------------------------------
@@ -61,77 +49,49 @@
 # -----------------------------------------------------
 # Vulkan transitive dependency

-if(VOLK_PULL_IN_VULKAN)
-  # If CMake has the FindVulkan module and it works, use it.
-  find_package(Vulkan QUIET)
-
-  # Try an explicit CMake variable first, then any Vulkan paths
-  # discovered by FindVulkan.cmake, then the $VULKAN_SDK environment
-  # variable if nothing else works.
-  if(VULKAN_HEADERS_INSTALL_DIR)
-    message("volk: using VULKAN_HEADERS_INSTALL_DIR option")
-    set(VOLK_INCLUDES "${VULKAN_HEADERS_INSTALL_DIR}/include")
-  elseif(Vulkan_INCLUDE_DIRS)
-    message("volk: using Vulkan_INCLUDE_DIRS from FindVulkan module")
-    set(VOLK_INCLUDES "${Vulkan_INCLUDE_DIRS}")
-  elseif(DEFINED ENV{VULKAN_SDK})
-    message("volk: using VULKAN_SDK environment variable")
-    set(VOLK_INCLUDES "$ENV{VULKAN_SDK}/include")
-  endif()
-
-  if(VOLK_INCLUDES)
-    if(TARGET volk)
-      target_include_directories(volk PUBLIC "${VOLK_INCLUDES}")
-    endif()
-    target_include_directories(volk_headers INTERFACE "${VOLK_INCLUDES}")
-  endif()
-endif()
+find_package(VulkanHeaders ${VERSION} REQUIRED)

 # -----------------------------------------------------
 # Installation

-if(VOLK_INSTALL)
+set(INSTALL_CONFIGDIR ${CMAKE_INSTALL_LIBDIR}/cmake/volk)

-  include(GNUInstallDirs)
-  set(INSTALL_CONFIGDIR ${CMAKE_INSTALL_LIBDIR}/cmake/volk)
+# Install files
+install(FILES volk.h DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})

-  # Install files
-  install(FILES volk.h volk.c DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})
+# Install library target and add it and any dependencies to export set.
+install(TARGETS volk volk_headers
+  EXPORT volk-targets
+  LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
+  ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
+  RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
+)

-  # Install library target and add it and any dependencies to export set.
-  install(TARGETS volk volk_headers
-    EXPORT volk-targets
-    LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
-    ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
-    RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
-  )
-
-  # Actually write exported config w/ imported targets
-  install(EXPORT volk-targets
-    FILE volkTargets.cmake
-    NAMESPACE volk::
-    DESTINATION ${INSTALL_CONFIGDIR}
-  )
-
-  # Create a ConfigVersion.cmake file:
-  include(CMakePackageConfigHelpers)
-  write_basic_package_version_file(
-    ${CMAKE_CURRENT_BINARY_DIR}/volkConfigVersion.cmake
-    COMPATIBILITY AnyNewerVersion
-  )
-
-  # Configure config file
-  configure_package_config_file(${CMAKE_CURRENT_LIST_DIR}/cmake/volkConfig.cmake.in
-    ${CMAKE_CURRENT_BINARY_DIR}/volkConfig.cmake
-    INSTALL_DESTINATION ${INSTALL_CONFIGDIR}
-  )
-
-  # Install the fully generated config and configVersion files
-  install(FILES
-    ${CMAKE_CURRENT_BINARY_DIR}/volkConfig.cmake
-    ${CMAKE_CURRENT_BINARY_DIR}/volkConfigVersion.cmake
-    DESTINATION ${INSTALL_CONFIGDIR}
-  )
+# Actually write exported config w/ imported targets
+install(EXPORT volk-targets
+  FILE volkTargets.cmake
+  NAMESPACE volk::
+  DESTINATION ${INSTALL_CONFIGDIR}
+)
+
+# Create a ConfigVersion.cmake file:
+include(CMakePackageConfigHelpers)
+write_basic_package_version_file(
+  ${CMAKE_CURRENT_BINARY_DIR}/volkConfigVersion.cmake
+  COMPATIBILITY AnyNewerVersion
+)
+
+# Configure config file
+configure_package_config_file(${CMAKE_CURRENT_LIST_DIR}/cmake/volkConfig.cmake.in
+  ${CMAKE_CURRENT_BINARY_DIR}/volkConfig.cmake
+  INSTALL_DESTINATION ${INSTALL_CONFIGDIR}
+)
+
+# Install the fully generated config and configVersion files
+install(FILES
+  ${CMAKE_CURRENT_BINARY_DIR}/volkConfig.cmake
+  ${CMAKE_CURRENT_BINARY_DIR}/volkConfigVersion.cmake
+  DESTINATION ${INSTALL_CONFIGDIR}
+)

-endif()
 cmake_policy(POP)

That patch

removes all IMO useless stuff
adds checking for VulkanHeaders cmake module
fixes project version
adds more  project() entries

I'm going now test is it will be possible to build  vulkan-tools 1.3.275.0 which looks like unconditionally requires volk cmake module.

What version checking are you talking about? In other words, can you explain the issues that existing header discovery logic in volk is causing?

Probably you don't want to build volk against to old VulkanHeaders 😋

I think this is going nowhere... Let's take this step by step.

I can not accept the proposed patch. It removes a lot of variables that other people have added over the years without consulting these people. It breaks automatic version update by removing the annotations. It's probably changing other things, I'm not sure, I just won't take a change that cleans things up in CMake without a reason for the changes.
The patch does not set up the include folder. It happens to work - as best as I can tell it only works if VulkanHeaders is installed into a globally visible location. In that case I'm not sure what the point of even checking the package is.
Relying on VulkanHeaders unconditionally is simply a no-go. I just checked on my macOS installation where I had Vulkan SDK installed, and volk currently compiles perfectly fine out of the box - it's using FindVulkan CMake module. If I replace it with find_package(VulkanHeaders REQUIRED), the build fails because VulkanHeaders CMake module is not actually globally visible. I'm sure this can be "fixed" with adjusting env variable that CMake uses to discover modules or something of the sort - but that is exactly the point behind what volk is doing, to require no additional CMake configuration on user's behalf unless they so choose. That's why all this "useless stuff" is in the file.
I do actually want to build volk against old, or new, VulkanHeaders. volk is designed to not care about the version of the vulkan.h that it's linking to - this makes sure that maximum compatibility is achieved. For Linux distributions that pre-package all carefully configured libraries this may seem redundant, but it's absolutely critical when volk that's bundled into a project, which is how it most often is used, is used against Android NDK or Vulkan SDK installed manually. Now, when volk is pre-built as a static library as part of Linux distribution, maybe you want to check some sort of compatibility, but it can not be there by default.

I do actually want to build volk against old, or new, VulkanHeaders. volk is designed to not care about the version of the vulkan.h that it's linking to

Please check since when is provided VulkanHeaders. You can always remove check version.
To be honest I do not understand completely this project. It installs .c files on side with header file. That .c file is included in provided header. Literally NONE of other projects has such things in its public API interface.
I have more and more impression that volk still is not ready for production and it was kind of mistake to include use it in last Vulcan stack SDK release.
Looks like volk provides only statically linked bits used only by vulkan-tools.
Why in this case what is in volk is not part of the vulkan-tools especially that seems like it is not possible to build vulkan-tools without volk it is for me kind of mystery. 🤔
I have impression that this separation is artificial/has no real propose.

I think you don't understand what volk is, how it's used, and this ecosystem in general. I don't know what vulkan-tools uses volk for but that's not what the purpose here is. Your suggestion about volk not being production ready is outrageous, frankly, as it's been used by games in production for years.
I will close this issue because it has no real substance, and it just wasted hours of my time yesterday following up on commit history and testing suggestions to use CMake replacements that do not work reliably without extra configuration.
If your issue is the presence of volk.c in the install target, I agree it's questionable, but that needs separate followup as I think Vulkan SDK distributes volk.c in a similar fashion and I'm not sure if they use the INSTALL flow for packaging.

I think you don't understand what volk is, how it's used, and this ecosystem in general.

That is what I've LITERALLY wrote so you don't need to suppose about that part.

I don't know what vulkan-tools uses volk for but that's not what the purpose here is.

You can see that in the code https://github.com/KhronosGroup/Vulkan-Tools/
https://github.com/KhronosGroup/Vulkan-Tools/commit/e156996c478a8e5d040ccf199437bcdbdbab63ed

I will close this issue because it has no real substance, and it just wasted hours of my time yesterday following up on commit history and testing suggestions to use CMake replacements that do not work reliably without extra configuration.

IMO this issue still is unresolved because:

by default volk install target do not install any files
IMO it should be just generated .h file without .c one.

If your issue is the presence of volk.c in the install target, I agree it's questionable, but that needs separate followup as I think Vulkan SDK distributes volk.c in a similar fashion and I'm not sure if they use the INSTALL flow for packaging.

Just checked all vulcan repos and only vulcan project which uses volk is Vulkan-Tools and it started using it only with last SDK release.

Hey @zeux, thanks for the heads-up.
I don't have a strong opinion about FindVulkanHeaders.cmake. Requiring it would be silly since it doesn't come with CMake or the Vulkan SDK. I myself have it on my system exactly once, because I built the validation layers at one point. That is a rather obscure thing to do. We could still add it to the chain of conditions, but note that in the file itself it states "Vulkan applications should instead use the FindVulkan (or similar) find module". This part of volk seems fine and robust the way it is.
Regarding volk.c in the include path: I wanted a volk install to be usable in all supported ways: linking to the static lib or header-only, with the latter case requiring the .c file (rather than giving the generator a special case of stuffing everything into a header file). That impl file might look weird there, but what's the harm? Currently, VOLK_HEADERS_ONLY is a setting for project build-time, useful for when one adds volk to a project build tree. The proposed change would make it also a setting for volk build/install-time. That volk install would then only support the static lib way. I don't see an upside to limiting it like this.
In my view, volk has always made its decisions erring on the side of usage flexibility, and its CMake side tries to do the same. That's why it instead of being very opinionated supports all of: just adding the source files to a project, adding volk as a subdir and using its targets, or installing it and importing target configs.
Specifically, that's why the install targets are not just always created -- those would be added to the user project's installs if it includes volk with add_subdirectory, and that's usually not desired. It's debatable whether the default should be switched around, but at this point that'd probably break/inconvenience existing projects for close to no reason.

I don't have a strong opinion about FindVulkanHeaders.cmake. Requiring it would be silly since it doesn't come with CMake or the Vulkan SDK.

 FindVulkanHeaders cmake modle is OOTB interface to interact using cmake.
So again .. why volk cmake by default do not install any files? 🤔
FYI: in volk git tree there is no any comments about how it should be used.

So again .. why volk cmake by default do not install any files? 🤔
I addressed that in the last paragraph above.

FYI: in volk git tree there is no any comments about how it should be used.
There is this section and the test directory that shows four different ways of using it with CMake. What do you feel is missing?


Annotations for indicating a parameter is modified by the function

Let me start by saying, the name you've come up with for this library is awesome, I'm very tempted to steal it to make my own variation.
That being said, I figured I'd run my proposal by you before performing grand theft (please understand this is meant as a compliment, not a threat).
I'd like to be able to annotate the parameters on methods if the parameters get side effected.
For example:
/**
 * Allow us to annotate that collection passed has elements added/removed/sorted/ect...
 * within the method.
 */
int doActions(@SideEffectModifies(type = COLLECTION) final Set<Something> somethings) {
    somethings.add(anotherSomething());
    return somethings.size();
}

/**
 * Allow us to annotate that collection elements get modified when passed to the method.
 */
int doActions(@SideEffectModifies(type = ELEMENTS) final Set<Something> somethings) {
    something.forEach(something -> something.setIt("it"));
    return somethings.size();
}

/**
 * Allow us to annotate that both kinds of side effecting happens.
 */
int doActions(@SideEffectModifies(type = BOTH) final Set<Something> somethings) {
    somethings.add(anotherSomething());
    something.forEach(something -> something.setIt("it"));
    return somethings.size();
}

My particular use case is that I'm refactoring a large swath of code. I'd like myself and other developers to leave hints to each other that we have discovered this kind of side effecting behaviour. The goal is, while you might not be able to do the refactor to fix the problem at the time, you've figured out this is what is going on.

Nice idea. Instead of @SideEffectModifies with different types, why not just allow users to annotate a param with @HereBeDragons to hint that a particular parameter is going to be mutated.
example:
int doActions(@HereBeDragons final Set<Something> somethings) {
    somethings.add(anotherSomething());
    something.forEach(something -> something.setIt("it"));
    return somethings.size();
}

Personally, I'd rather be able to flag the two different kinds independently because each has different characteristics and fixes. For example, if the collection is side effected, you can't pass an immutable collection into the method (like guava's ImmutableSet) but if the elements are side effected you can still pass an immutable collection without having the code not work correctly. Would two different annotations be better instead?

For example, if the collection is side effected, you can't pass an immutable collection into the method (like guava's ImmutableSet) but if the elements are side effected you can still pass an immutable collection without having the code not work correctly

I think you're talking about Unmodifiable collections which means you can't add or remove elements but the underlying collection can change. It's like a read only wrapper.
Immutable means that no additions, deletions or modifications are allowed.
As someone reading code, if I see an annotation that says the collection I'm passing in is going to change in some way, I'm gonna be careful with it. A single annotation to hint this should suffice I think.

Immutable means that no additions, deletions or modifications are allowed.

Guava's ImmutableX Collections don't work that way, though - there is simply no way they could enforce immutability on the contained items as well.

There is a difference between immutable data types and deeply immutability data types.


pulumitest: edit python dependency

Upsert a dependency in the requirements.txt of the current program under test to a specific version and ensure pip install is up to date.

Closing as dupe of https://github.com/pulumi/providertest/issues/40


Is there any limitation on calling the API in order to remove messages?

Like Telegram Docs says, there is a limitation when sending messages. I wanted to know there is a limitation on removing them. I didn't found that answer on Telegram Docs.
I want to remove all chat history by iterating from one message (the last message) to the initial message by subtracting 1 to current message id. Breaking iteration when Bad Request: message can\'t be deleted for everyone response received.
So I want to know if I have to put time limitations on this iteration.
Thanks
UPDATE: It seems that it is working okay without time limitation but I want to be sure of that.

You must never do any arithmetic operations on message identifiers. Also, bots can't delete messages older than 48 hours.

I know when I have to stop deleting when I receive this Bad Request: message can't be deleted for everyone. This indicates that this message is 48+ hours ago.

No, this only indicates that the bot sent a wrong request.

It's the only way because there is not an API way to clear history efficiently.

No, you must store identifiers of messages, which you want to delete. Otherwise, you will exceed limits were quickly.

No, this only indicates that the bot sent a wrong request.

It is not true, 400 HTTP status code indicates a wrong request. But also there is more info if you dig into... There is a more detailed info that you can get (you must know) if you read the different messages that Telegram sends together with the status code. Since I dind't found any offical documentation about these different erros (reasons), I digged into. These are the different "wrong request" message I studied:
switch (error.description) {
      case 'Bad Request: message can\'t be edited':
        return TelegramResponseError.messageCantBeEdited;
      case 'Bad Request: message is not modified: specified new message content and reply markup are exactly the same as a current content and reply markup of the message':
        return TelegramResponseError.messageContentNotChanged;
      case 'Bad Request: message to edit not found':
        return TelegramResponseError.messageNotFound;
      case 'Bad Request: query is too old and response timeout expired or query ID is invalid':
        return TelegramResponseError.invalidCallbackQuery;
      case 'Bad Request: message to delete not found':
        return TelegramResponseError.messageToDeleteNotFound;
      case 'Bad Request: message can\'t be deleted for everyone':
        return TelegramResponseError.messageCantBeDeletedForEveryone;
      case 'Bad Request: failed to get HTTP URL content':
        return TelegramResponseError.failedToGetHttpUrlContent;
      case 'Bad Request: wrong file identifier/HTTP URL specified':
        return TelegramResponseError.wrongFileIdentifierOrHttpUrlSpecified;
      default:
        return TelegramResponseError.other;
    }

I can tell you this:

When you try to delete a non existent (or yet deleted) message, the error description is Bad Request: message to delete not found.
When you try to delete and old message (48+ hours), the error description is Bad Request: message can't be deleted for everyone.

Conclusion: No, it doesn't indicate only that the bot sent a wrong request.

No, you must store identifiers of messages, which you want to delete. Otherwise, you will exceed limits were quickly.

I do store message identifiers. But also I want to remove all "prehistory" messages (48- hours). So repeat my question. Is it possible to know the limits for removing messages the same way we do know the limits for sending messages.
Have a good logic day

No, it doesn't indicate only that the bot sent a wrong request.

This is absolutely wrong. The error tells nothing about message send date and can be returned because of dozens other errors in the request.
You must not use guessed message identifiers in requests.

I tested it and it operates like I described, even without knowing the code (black box) using induction. If it is round and bounce, it is a ball.
Thank you very much

I tested it and it operates like I described

This only means that the code is incorrect by design.

Not round, squared then


HSTNS-PL18 compatibility

Could a similar approach be applied for a HSTNS-PL18?

Yes, it is possible that a similar approach to modifying the HSTNS-PL18 could work as with the HSTNS-PL11. However, it would be best if you could upload some images of the power supply, including close-ups of the control board or any labels, so we can analyze the specifics.


Missing git tag for 4.1.0 release?

There was a commit seemingly pumping out a 4.1.0 release: https://github.com/SOCI/soci/commit/db89eb26e191c244f761655ccb8f06977d250b60
However, a matching git tag seems to be missing. Was this a simple oversight?

No, 4.1.0 simply hasn't been released yet.

Reasonable!
Any roadmap/guesstimated ETA on the next release?

Sorry, I can't commit to anything right now. Hopefully before the end of the year.
Of course, using the current master is always possible too and is not really different from using a release if you're using it as Git submodule, CMake external or equivalent.


Fix third party signed definitions for join APIs

Fixes https://github.com/matrix-org/matrix-doc/issues/1978

For reference: the third_party_signed object is passed down through Synapse here and here which then jets passed straight through here. Finally, the sender property is read here - an indicator it does not expect it to be under signed.


Some navdata frames do not include demo data

Ignore them to prevent crashes due to undefined value.

Thanks for contributing !!


get_timestamp should use the cache, not query the database

Opening and reloading a stage applies these steps with database calls:

resolve asset: check asset existence in db
fetch asset: download asset from db if NEEDS_CACHING
get timestamp: check asset existence again in db

Fetch asset always does an extra get_raw_timestamp check when the cache says that fetching is not necessary...
Because of this, I think that the get_timestamp call should just return the cached timestamp value without making yet another database query.
I think this line should be dropped: https://github.com/LumaPictures/usd-uri-resolver/blob/master/URIResolver/sql.cpp#L525
This reduces the database queries per unique asset from 3 to 2.

Hey! Querying the timestamp is meant to support updating the asset in case the time stamp has been updated. Using the timestamp from the cache does not give us this feature.
However, we can add an option that disables updating the timestamp from the database and always uses the cache.

@elrond79 @nrusch what do you think?

I think that get_timestamp is (ab)used to check if a reload of the assets will be required on the next reload... while most of the code in SDFLayer seems to use get_timestamp to keep track of the timestamp of the current layer.
The SDFLayer._reload call seems to prefer to make use of UpdateAssetInfo.

The timestamp recorded during the resolver.FetchToLocalResolvedPath is the correct asset timestamp to be reported in layer::_OpenLayerAndUnlockRegistry.
But for layer::_Reload you'd want the latest timestamp from the original asset, not from the localPath.
So if you won't need to reload assets in the usd runtime (usdcat, usdzip, ...), you can save a lot of database calls.

The confusion all starts with this dubious function
AssetResolver::GetModificationTimestamp(
    const std::string& path,
    const std::string& resolvedPath)

It would be ideal if an extra 'fetch' boolean would be passed along to indicate that you want either the timestamp from the path (from database) or from the resolvedPath (local file).
It requires some changes in sdf stage... but then both the initial stage load and reloads would run optimally without extra configuration options such as 'NO_CACHED_TIMESTAMP'.
Something for AR2.0 @spiffmon?

I'm getting my expected result by using UpdateAssetInfo to fetch the latest date modified from the db when the cache indicates that the asset is already fetched. When the cache indicates 'NEEDS_CACHING', UpdateAssetInfo does nothing.
Stage.Open
- resolve: set entry in cache with NEEDS_CACHING
- update asset info: do nothing as asset is not cached yet
- fetch: fetch asset and save timestamp in cache
- timestamp: get timestamp from cache

Stage.Reload (no changes)
- resolve: uses cache
- update asset info: update info in cache
- timestamp: get timestamp from cache

Stage.Reload (with changes)
- resolve: uses cache
- update asset info: update info in cache, set NEEDS_CACHING
- timestamp: get timestamp from cache, is newer than layer.info
- fetch: fetch and save timestamp in cache

I ended up with an implementation where Resolve only determines the localPath (without doing any calls), UpdateAssetInfo does a HEAD request (similar to get_raw_timestamp) only if a local cache is present (to refresh the metadata) and Fetch does the heavy lifting with less pre-conditions.
On top of that, I'm adding the "IfModifiedSince" header in the Fetch call, catching the 304 Not Modified error.
In MySQL, a similar feature could be added to the query, allowing the server to decide that no data needs to be send.
So ideally, the URI resolver does a single DB call max for each time the scene is loaded. Only when the server doesn't support the 'IfModifiedSince' header (even not via a query), you may need up to 2 DB calls: one to resolve/update and one to fetch.
An option should exist to prevent checking/fetching if a local cached copy exists.

Thanks for the detailed information, I'll dig through the details. If you have it working on your side, a PR would be useful.

I've been working in a separate repo: https://github.com/westerndigitalcorporation/usd-s3-resolver
Primary focus was a performant S3 resolver, I bothered a bit less about 'plugability' with the URI resolver at this stage... I kept the history of this project though, so it shouldn't be too hard to merge them.
I need to add a few more performance tests and sort out the fact that reloads are slower than initial loads on S3. Once that is done, I could apply the same logic to the MySQL resolver. It looks like stage.reload is single threaded while the initial load is multithreaded... more on that later.
Unfortunately I have to move on to my next project so I can't make promises on the timeline here.

resolver.RefreshContext(context) seems the ideal place to reset the caches. You're even able to flush only a subset of the cache.
You may need to expose the python bindings here.


Roll engine 8dc3a4cde207..64a4a0eaa314 (23 commits)

https://github.com/flutter/engine/compare/8dc3a4cde207...64a4a0eaa314
git log 8dc3a4cde2075a4f5458fd0eb199627f5124508d..64a4a0eaa314fca5a5ec9415e62ec34c6c90fbe3 --no-merges --oneline
64a4a0eaa Roll src/third_party/skia f06b6d5469a5..de7e074e8190 (1 commits) (flutter/engine#9094)
fdee6256a Roll src/third_party/skia 7e5a64f517e4..f06b6d5469a5 (2 commits) (flutter/engine#9093)
daf47f0b4 Roll src/third_party/skia dc01a84ae098..7e5a64f517e4 (1 commits) (flutter/engine#9092)
41e10f07f Fix internal break since listing contents can return null (flutter/engine#9078)
cf1b20318 Roll src/third_party/skia f33c95cd6f55..dc01a84ae098 (3 commits) (flutter/engine#9091)
2404cdc90 Rename macOS FLEPlugin* to FlutterPlugin* (flutter/engine#9074)
509a43fe2 Apply minor cleanups to Android embedding (flutter/engine#9088)
0a0f3305b Removed outdated deprecation comments (flutter/engine#9087)
a44cbbf49 Delete BSDiff sources (flutter/engine#9086)
0f1ff3bdb Correct typos, adopt US spellings (flutter/engine#9081)
651c90409 Use track-widget-creation transformer included in the sdk. (flutter/engine#9085)
cfa524fcd New Plugin API PR4: Adds Lifecycle support to the new plugin system. (flutter/engine#9049)
6b8ac18b8 Roll src/third_party/skia d9430297e74a..f33c95cd6f55 (5 commits) (flutter/engine#9082)
11408effd Update macOS podspec version requirement (flutter/engine#9077)
66c6ae48e Roll src/third_party/skia a4b837971c4b..d9430297e74a (30 commits) (flutter/engine#9080)
9151b377e Roll src/third_party/skia 9339a8a61af0..a4b837971c4b (34 commits) (flutter/engine#9076)
ee6a9c404 Fix unchecked operation warnings in FlutterMain (flutter/engine#9073)
333042cf3 Roll third_party/dart/tools/sdks to 2.3.0 (flutter/engine#9072)
01b8c078c Roll src/third_party/skia f77dbd04b926..9339a8a61af0 (12 commits) (flutter/engine#9065)
26b4fb57f Roll src/third_party/dart e3edfd36b2..ec4d48e241 (7 commits)
9d2d58a3c Add mouse button support to the macOS shell (flutter/engine#9054)
b17c0c6e6 Add a podspec for FlutterMacOS.framework (flutter/engine#9062)
82ccba303 libtxt: have GetRectsForRange(strut) fall back to tight bounds if layout isn't forcing use of the strut (flutter/engine#9058)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff (garyq@google.com), and stop
the roller if necessary.

Trybots failed. These were the failed builds: https://cirrus-ci.com/task/6658547081805824 , https://cirrus-ci.com/task/5743753407496192 , https://cirrus-ci.com/task/5391909686607872 , https://cirrus-ci.com/task/4617853500653568 , https://cirrus-ci.com/task/6306703360917504 , https://cirrus-ci.com/task/5180803454074880 , https://cirrus-ci.com/task/5954859640029184

Commit queue failed; closing this roll.


[baxter_sim_hardware] Depends on baxter_sim_controllers

run_depend baxter_sim_controllers is missing

@IanTheEngineer can you review and merge this?

@IanTheEngineer can you review and merge this?

Sorry for the delay @knorth55. You're absolutely correct. Despite not being present in the launch files directly, baxter_sim_controllers is required for the yaml files to load specific controllers. Thank you for the fix. I'll cherry-pick this into the kinetic-devel branch


Fix the auto include

move the auto include statement to writeVars

Signed-off-by: renfeiw<EMAIL_ADDRESS>

internal grinder: Grinder_TKG/1509


Method to annotate __get_pydantic_core_schema__ on arbitrary classes/types

Initial Checks

[X] I have searched Google & GitHub for similar requests and couldn't find anything
[X] I have read and followed the docs and still think this feature is missing

Description
Libraries such as NumPy, Pandas, Trimesh, Open3D, etc offer many functionalities; however, they come with their own arbitrary types. Having the will to work with them on Pydantic, and doing it right, my goal was to add Pyndatic support so that I wouldn't have to set allow_arbitrary_types to True.
I couldn't find a way to annotate my way to having Pydantic full support. A numpy array annotation looks like this, work in progress from pydantic-numpy for V2:
def array_origin_and_data_type_validation_typing(target_datatype: DataType, dimensions: Optional[int] = None):
    return Annotated[
        Union[
            Annotated[
                np.ndarray[int_to_dim_type[dimensions] if dimensions else Any, np.dtype[target_datatype]],
                BeforeValidator(ensure_array_likeness),
            ],
            Annotated[FilePath, Strict(), AfterValidator(read_and_verify_numpy_file)],
        ],
        AfterValidator(validate_array_data_type(target_data_type=target_datatype)),
        numpy_array_serializer,
    ]

According to Pydantic, the output is still an arbitrary type, in my eyes, it isn't. Maybe I am missing something :)
Affected Components

[ ] Compatibility between releases
[X] Data validation/parsing
[ ] Data serialization - .model_dump() and .model_dump_json()
[ ] JSON Schema
[ ] Dataclasses
[ ] Model Config
[ ] Field Types - adding or changing a particular data type
[ ] Function validation decorator
[ ] Generic Models
[ ] Other Model behaviour - model_construct(), pickling, private attributes, ORM mode
[ ] Plugins and integration with other tools - mypy, FastAPI, python-devtools, Hypothesis, VS Code, PyCharm, etc.

You'll want either https://docs.pydantic.dev/latest/usage/types/custom/#handling-third-party-types or #6737

Sorry missed the details. What do you mean by “the output is still an arbitrary type”? That it requires the arbitrary types flag?

Your example looks like it should work but since you posted the issue I'm guessing it doesn't. Can you give me the rest of the details in a MRE so I can test it? It would also help if you can remove any of the unions or complexity that are not causing the issue.

I got it working, thanks! Will send the repo soon! :)

Done! https://github.com/caniko/pydantic-numpy


source_url on supermarket is not up-to-date

See on https://supermarket.chef.io/cookbooks/seven_zip
the source_url is not pointing to this repo (and points to the deprecated one).
Could you fix it?
thanks

This impacts us because we use source_url to generate changelog on all cookbooks that we could upgrade.
Tag 2.0.1 does not exist on the old repo which makes this process crash.

Supermarket source_url has been updated.

Great thanks you!
Le mar. 4 oct. 2016 19:45, Heath Snow<EMAIL_ADDRESS>a écrit :

Closed #1 https://github.com/windowschefcookbooks/seven_zip/issues/1.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/windowschefcookbooks/seven_zip/issues/1#event-812135011,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAeu8Sb21oZ-ufiEfvuleI_tsVEP-tIhks5qwpDHgaJpZM4KHnFz
.


Feature Request: Auto Clustering

I am using the feature ranking within MCT for automated Root Cause Analysis of incidents for our Rest API (e.g. increase in InternalServerError responses from our service).  Our dataset is our IncomingRequests (uri, datacenter, responsecode, latency, requestId, etc.), merged with OutgoingRequests (target, responsecode, latency, requestId, etc.). If, for example, we are returning InternalServerError because we received 429 in our first call to DocDB, then our metric column, ResponseCode will equal InternalServerError and a feature column DocDB_GetThead_ResponseCode will equal 429 and we expect our automated Root Cause Analysis tool to tell us that the reason for InternalServerError increase is DocDB_GetThead_ResponseCode == 429.
Ours is a situation of multicollinearity.  If the first call to DocDB fails, then all subsequent calls will not happen so for all of the failures, another column, say DocDB_UpdateThead_ResponseCode will be empty.  We would like auto clustering, so that instead of producing some 200 "Features Explaining Metric Difference" with the actual root cause buried beneath the noise, we instead produce a handful of combinations of features that are correlated to our metric.
Thank you for your awesome work with this tool!

Thanks for your feedback, and thanks for using our tool. We are working on a multivariate version that does consider combinations of metrics to better find out the root cause of the issue. Will add it as soon as we have the extension ready.
Thanks,
Ashkan


Syntax error in deployment script

This CL fixes an extra '"' in the deploy script.
Issue #10

TBRing to fix deploy.


Prevent big page offset

Our current pagination is translated into offset-limit pagination by Postgres.
The more P=page*pageSize increase, the longer Postgres takes to process the request.
In particular, P could lead to a full scan.
To prevent this, P should be bounded.
Eg: P_MAX=1_000 ensures that a query will never scan more than P_MAX+MAX_PAGE_SIZE.
P_MAX=1_000 is large enough to cover all the use cases of the API.
* We don't expect consumers to dump the whole database
* Consumers are only expected to find users by weak comparison on
* ref
* firstname
* name

Use the BoundedPageSize for pagination.


3.11.3 Constantly repeating sentinel WARN

Expected behavior
I should not see any warnings in my logs.
Actual behavior
after I had updated Redisson from 3.3.1 to 3.11.3, it started constantly repeating logs, never ending:
[2019-09-05 14:13:20,402] INFO  [redisson-netty-8-12] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 added
[2019-09-05 14:13:20,982] WARN  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 has down
[2019-09-05 14:13:25,410] INFO  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 added
[2019-09-05 14:13:25,998] WARN  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 has down
[2019-09-05 14:13:30,422] INFO  [redisson-netty-8-7] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 added
[2019-09-05 14:13:32,022] WARN  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 has down
[2019-09-05 14:13:35,429] INFO  [redisson-netty-8-31] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 added
[2019-09-05 14:13:41,063] WARN  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 has down
[2019-09-05 14:13:45,443] INFO  [redisson-netty-8-25] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 added
[2019-09-05 14:13:46,082] WARN  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 has down
[2019-09-05 14:13:50,451] INFO  [redisson-netty-8-22] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 added
[2019-09-05 14:13:53,109] WARN  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 has down
[2019-09-05 14:13:55,459] INFO  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 added
[2019-09-05 14:13:58,130] WARN  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 has down
[2019-09-05 14:14:00,463] INFO  [redisson-netty-8-5] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 added
[2019-09-05 14:14:01,143] WARN  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 has down
[2019-09-05 14:14:05,470] INFO  [redisson-netty-8-31] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 added
[2019-09-05 14:14:07,172] WARN  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 has down
[2019-09-05 14:14:10,476] INFO  [redisson-netty-8-19] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 added
[2019-09-05 14:14:11,188] WARN  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 has down
[2019-09-05 14:14:15,486] INFO  [redisson-netty-8-16] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 added
[2019-09-05 14:14:18,216] WARN  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 has down
[2019-09-05 14:14:20,495] INFO  [redisson-netty-8-26] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 added
[2019-09-05 14:14:21,233] WARN  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 has down
[2019-09-05 14:14:25,503] INFO  [redisson-netty-8-23] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 added
[2019-09-05 14:14:26,250] WARN  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 has down
[2019-09-05 14:14:30,511] INFO  [redisson-netty-8-21] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 added
[2019-09-05 14:14:32,280] WARN  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 has down
[2019-09-05 14:14:35,514] INFO  [redisson-netty-8-4] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 added
[2019-09-05 14:14:36,306] WARN  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 has down
[2019-09-05 14:14:40,524] INFO  [redisson-netty-8-20] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 added
[2019-09-05 14:14:41,329] WARN  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 has down
[2019-09-05 14:14:45,528] INFO  [redisson-netty-8-17] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 added
[2019-09-05 14:14:47,354] WARN  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 has down
[2019-09-05 14:14:50,532] INFO  [redisson-netty-8-32] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 added
[2019-09-05 14:14:53,376] WARN  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 has down
[2019-09-05 14:14:55,537] INFO  [redisson-netty-8-14] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 added
[2019-09-05 14:14:57,397] WARN  [redisson-netty-8-8] o.redisson.connection.SentinelConnectionManager - sentinel: redis://<IP_ADDRESS>:26379 has down

Steps to reproduce or test case
we have 9 sentinels. One of these sentinels, the special one, redis://<IP_ADDRESS>:26379  is deployed on the same machine as the application itself. I think this is the key to understand the problem. We use docker for redis, sentinels and application.
Redis version
5.0.3
Redisson version
3.11.3
Redisson configuration
JsonJacksonCodec codec = new JsonJacksonCodec();
codec.getObjectMapper()
        .registerModule(new JavaTimeModule())
        .registerModule(new Jdk8Module());
config.setCodec(codec);

if (StringUtil.isNotNullOrEmpty(sentinelHosts) && StringUtil.isNotNullOrEmpty(sentinelMaster)) {
    String[] sentinelAddress = Arrays.stream(sentinelHosts.split(",")).map(h -> {
        if (!h.startsWith("redis")) {
            return "redis://" + h;
        } else {
            return h;
        }
    }).toArray(String[]::new);
    config.useSentinelServers()
            .addSentinelAddress(sentinelAddress)
            .setMasterName(sentinelMaster)
            .setDatabase(db);
} else {
    config.useSingleServer()
            .setAddress(host + ":" + port)
            .setDatabase(db);
}

Could you set TRACE logging level for org.redisson package and share output?

here https://pastebin.com/MvxPWfqj

The problem is that <IP_ADDRESS> is not appeared in SENTINEL SENTINELS command response

Looks like my docker deployment is misconfigured. Docker should use hosts network (--net=host) for sentinel containers. Without this flag, all sentinels have IPs from container network.

thank you for your time!


The mv strikes back (windows symlinks)

Windows build number:  10.0.16299.125

Repro:

Store-installed Ubuntu.
Windows symlink: C:\utemp to C:\Users\[user]\Desktop\temp\
Commands:

root@GLaDOS:~# ls /mnt/c/utemp
[files in 'C:\Users\[user]\Desktop\temp\']

root@GLaDOS:~# touch testfile
root@GLaDOS:~# mv testfile /mnt/c/utemp/

[WSL hangs]

Expected behaviour:
mv copies testfile to /mnt/c/utemp (C:\utemp to C:\Users\[user]\Desktop\temp\)

Strace:
No trace, but I was able to extract the stack: https://gist.github.com/0x5c/84144b4a8e8dad0860726b526a0aec4f

Call it 17093 or 17101 for the sake of argument.


release: 0.2.17

Codecov Report

Merging #68 (197efbf) into main (9acb897) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main      #68   +/-   ##
=======================================
  Coverage   68.44%   68.44%
=======================================
  Files          10       10
  Lines        1122     1122
=======================================
  Hits          768      768
  Misses        354      354

Impacted Files
Coverage Δ

clippy-sarif/src/bin.rs
93.75% <100.00%> (ø)

hadolint-sarif/src/bin.rs
93.75% <100.00%> (ø)

sarif-fmt/src/bin.rs
50.64% <100.00%> (ø)

serde-sarif/src/lib.rs
100.00% <100.00%> (ø)

shellcheck-sarif/src/bin.rs
93.75% <100.00%> (ø)

Continue to review full report at Codecov.

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


[stdlib] remove duplicated code

call UnsafeMutablePointer.allocate(capacity:) from
UnsafeMutableBufferPointer.allocate(capacity:).
This was a straight code duplication until the return statement. Since both functions are inlinable, having only one copy in source code is probably better.

@swift-ci please smoke test

@swift-ci please smoke test


AKCORE-7: Defined request/response for ShareFetch and ShareAcknowledge APIs

PR contains the json schema for ShareFetch and ShareAcknowledge APIs for KIP-932.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

This PR is against confluentinc/master' rather than confluentinc/kip-932`.

My bad, corrected it.


[Podspec] Fix issue with latest CocoaPods 1.0 betas

Attempts to fix #3052.

I could reproduce the CI failure locally. It works with CocoaPods 1.0, but it breaks backwards-compatibility to 0.39.0. The podspec itself still lints on 0.39.0, but the Clang module can't be included. It fails because of the inclusion of "non-modular headers". This supposedly happens because the headers in the sandbox, where CocoaPods links headers according to the header_mapping_dir overlap now with the framework headers. A not so recent Xcode version started to reject such configurations, from my understanding because framework module headers may only be included and found in the framework's header directory itself and not in any other search path. CocoaPods 1.0 ships a fix for exactly this problem, which broke our podspec in the first place.
One possible workaround to continue working with an older CocoaPods version is to delete the Pods/Headers/Private/Realm directory from a post installation Podfile hook.

@tgoyne: As you made some modifications recently to our podspec to address this as well, you may have some thoughts to this?

I'm not a fan of requiring that people add extra stuff to their Podfile since there's no reasonable way to tell them that they need to do so. I'd sort of prefer to just outright drop support for 0.39 and require 1.0 over that.
With 1.0 I think we can skip coping the public headers to the include directory, since that was just a convoluted way of getting them out of the header search path for things using the dynamic framework.

I'm not a fan of requiring that people add extra stuff to their Podfile since there's no reasonable way to tell them that they need to do so. I'd sort of prefer to just outright drop support for 0.39 and require 1.0 over that.

I'd prefer that as well and would be fine with just setting the minimum required version in the podspec to 1.0 once the final release is out. So the workaround was more thought as a reference, what users could do in the mean time, once we adopt these changes in our official podspec.

With 1.0 I think we can skip coping the public headers to the include directory, since that was just a convoluted way of getting them out of the header search path for things using the dynamic framework.

Good to know, I wasn't aware that this was the original motivation. I thought that it was done so that the binding library headers work alongside the core headers with the way how CocoaPods places files. If there is now no strong reason to keep it like that, we should definitively get rid of it.

So, with https://github.com/CocoaPods/CocoaPods/pull/4933 shipped in the latest prerelease, I could implement the solution as discussed in our meeting, which I could successfully test with CocoaPods 0.39 and 1.0.0.beta.4.

The CI failure was because of job ios-device-objc, which seems unrelated.

What happens when pod install is first run with 0.39.0 and then again with 1.0.0.beta.4? I imagine that'd be a fairly common scenario, so it'd be nice to support it.
If this change handles that scenario, I'm all for this. We should really have a changelog entry for this, since many users have been trying to use CocoaPods 1.0 with Realm already.

What happens when pod install is first run with 0.39.0 and then again with 1.0.0.beta.4?

CocoaPods would detect that a newer version runs and automatically nukes the cache, loads a fresh copy of Realm and integrates just like it would be installed the first time with 1.0.

Would appreciate a :+1: on the added CHANGELOG entry before merging.

:+1:


problem with polymorphic 'this' type in bound generics

I've defined two interfaces: (this is synthetic example)
interface BaseNode { next?: this; }
interface SomeNode extends BaseNode { a: number; }

then if i write something like
var node: SomeNode = {a: 1, next: {a: 2, next: {a: 3}}};
var arr = [], i = 0;
while (node) {
	arr[i] = node;
	i++;
	node = node.next; // As expected (no errors)
}
console.log(arr)

then all compiles like a charm. On the other side when I'm trying to write a function that does the same and has the correct signature, I'm getting an error:
function toArray<T extends BaseNode>(node: T): Array<T> {
	var arr = [], i = 0;
	while (node) {
		arr[i] = node;
		i++;
		node = node.next; // Error: Type 'BaseNode' is not assignable to type 'T'
	}
	return arr;
}

Should it compile without any errors?

It may not depend polymorphic this type.
function f<T extends number>(n: T) {
	n = 0; // base to derived, error
	var m: number = n; // derived to base, ok
}

Duplicate of #5525. It was fixed in #5552 and your example works with current compiler in master.


2020-10-21 GUARD-845 Add-Timeouts

Summary
All REST services now support cancellation tokens and it's possible now to set specific timeout for any operation. As before the default timeout value equals 10 minutes.

These changes were moved to combined release: https://github.com/skuvault/channelAdvisorAccess/pull/27