sql: add current_user, session_user, user builtins

PR: https://github.com/cockroachdb/cockroach/pull/17903

@knz, when you resolve https://github.com/cockroachdb/cockroach/issues/18647, can you also check that these new built-ins show up?

Yes they do - https://github.com/cockroachdb/cockroach/pull/19153


Fonz returns PASS when query fails

Using branch for PR #58
One some instances, the SQL errors don't get caught by Fonz.
The following run produces an error in Looker (screenshotted).
dylan@Dylans-MacBook-Pro:dbanalytics/Fonz ‹feature/misc›$ fonz sql --project receiptbank --branch fonz-tests --batch --explores "finance_kpis.*"
Authenticating Looker credentials...
Connected to https://receiptbank.eu.looker.com using API version 3.1
Checked out branch fonz-tests
Building LookML hierarchy for receiptbank...

=========================== Begin testing 1 explore ============================

15:24:50 | 1 of 1 CHECKING explore: finance_kpi_accounts................ [START]
15:24:53 | 1 of 1 PASSED explore: finance_kpi_accounts.................. [PASS]

============================= End testing session ==============================

====================== Found 0 SQL errors in receiptbank =======================

The error being returned looks like this:
[{'looker_error': "SQL Error: SQL Syntax Error: SQL compilation error: error line 35 at position 11\ninvalid identifier 'FINANCE_KPI_STRIPE.STATUS_CHARGE'"}]

We currently catch errors with the following logic:
if not result:
                return
            elif isinstance(result, dict) and result.get("errors"):
                first_error = result["errors"][0]
                error_message = first_error["message_details"]
                # Subtract one to account for the comment Looker appends to queries
                line_number = first_error["sql_error_loc"]["line"] - 1
                sql = result["sql"]

                explore.errored = True
                model.errored = True
                explore.error = SqlError(error_message, sql, line_number)

I think we need to change it to allow for different structures of error? (Really the errors should just be consistent...)

We are currently set up to handle errors of this format:
"errors": [
                {
                    "message": "The Google BigQuery Standard SQL database encountered an error while running this query.",
                    "message_details": "Failed to retrieve data - Name bad_sql_error not found inside order_items at [3:21]",
                    "params": "SELECT\n\torder_items.bad_sql_error  AS order_items_bad_sql_error\nFROM `publicdata.samples.shakespeare`  AS order_items\n\nGROUP BY 1\nORDER BY 1\nLIMIT 1000",
                    "edit_url": null,
                    "error_pos": null,
                    "level": "error",
                    "sql_error_loc": {
                        "line": 3,
                        "column": 21
                    }
                }
            ]

API callers should be checking the HTTP response status code before looking for error structure in the response text.

Closing this for now since we've moved to a different endpoint and seem to be handling the different error formats returned by the API.


Adding swiftlint validation to Mac.

Platforms Impacted

[x] iOS
[x] macOS

Description of changes
This changes enables swiftlint validation to the Mac Xcode project by adding the .swiftlint.yml file to the repo root folder and referencing it from the Xcode projects for iOS and Mac.
The path to lint is set through the LINTPATH environment variable set on the RunScript phase before the swiftlint is called.
Also updated all the files to resolve the warnings.
Verification
Rebuilt the Mac project/demo app and ensured all swiftlint warnings were solved.
Pull request checklist
This PR has considered:

[ ] Light and Dark appearances
[ ] VoiceOver and Keyboard Accessibility
[ ] Internationalization and Right to Left layouts
[ ] Different resolutions (1x, 2x, 3x)
[ ] Size classes and window sizes (iPhone vs iPad, notched devices, multitasking, different window sizes, etc)

Microsoft Reviewers: Open in CodeFlow

Wouldn't we prefer to use swift-format instead and use the first-party supported dependency?

Wouldn't we prefer to use swift-format instead and use the first-party supported dependency?

Wouldn't we prefer to use swift-format instead and use the first-party supported dependency?

I took a bit of time to research the potential benefits of swift-format over swiftlint for the linting purposes that we need.

It seems like swiftlint is more mature providing nearly 200 rules that can be applied and configured to the swift code while swift-format provides around 40.

The way they are integrated into XCode is the same (by using run script build phases):

SwiftLint:
if which swiftlint >/dev/null; then
    swiftlint
else
    echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"
fi

swift-format:
if which swift-format >/dev/null; then
    swift-format -m format -i -r ${PROJECT_DIR}
else
    echo "warning: swift-format not installed"
fi

Installing swiftlint is more convenient for developers/contributors with package managers while swift-format requires the developer to clone the repo and build the tool locally.

This may be a minor issue: Since we're already using swiftlint for the iOS projects, the current consumers of FluentUI would have a small disruption in their process to ensure their linting of swift files keeps working if we change it from swiftlint to swift-format.

I personally think it makes sense to remain with swiftlint for now (just adding support to cover the Mac files) and eventually entertain the possibility of a migration to swift-format when we have more time for a more thorough investigation on the benefits of adopting it.

Wouldn't we prefer to use swift-format instead and use the first-party supported dependency?

I took a bit of time to research the potential benefits of swift-format over swiftlint for the linting purposes that we need.

It seems like swiftlint is more mature providing nearly 200 rules that can be applied and configured to the swift code while swift-format provides around 40.

The way they are integrated into XCode is the same (by using run script build phases):

SwiftLint:
if which swiftlint >/dev/null; then
    swiftlint
else
    echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"
fi

swift-format:
if which swift-format >/dev/null; then
    swift-format -m format -i -r ${PROJECT_DIR}
else
    echo "warning: swift-format not installed"
fi

Installing swiftlint is more convenient for developers/contributors with package managers while swift-format requires the developer to clone the repo and build the tool locally.

This may be a minor issue: Since we're already using swiftlint for the iOS projects, the current consumers of FluentUI would have a small disruption in their process to ensure their linting of swift files keeps working if we change it from swiftlint to swift-format.

I personally think it makes sense to remain with swiftlint for now (just adding support to cover the Mac files) and eventually entertain the possibility of a migration to swift-format when we have more time for a more thorough investigation on the benefits of adopting it.

Wouldn't we prefer to use swift-format instead and use the first-party supported dependency?

I took a bit of time to research the potential benefits of swift-format over swiftlint for the linting purposes that we need.

It seems like swiftlint is more mature providing nearly 200 rules that can be applied and configured to the swift code while swift-format provides around 40.
The way they are integrated into XCode is the same (by using run script build phases):

SwiftLint:
if which swiftlint >/dev/null; then
    swiftlint
else
    echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"
fi

swift-format:
if which swift-format >/dev/null; then
    swift-format -m format -i -r ${PROJECT_DIR}
else
    echo "warning: swift-format not installed"
fi

Installing swiftlint is more convenient for developers/contributors with package managers while swift-format requires the developer to clone the repo and build the tool locally.
This may be a minor issue: Since we're already using swiftlint for the iOS projects, the current consumers of FluentUI would have a small disruption in their process to ensure their linting of swift files keeps working if we change it from swiftlint to swift-format.

I personally think it makes sense to remain with swiftlint for now (just adding support to cover the Mac files) and eventually entertain the possibility of a migration to swift-format when we have more time for a more thorough investigation on the benefits of adopting it.
Thoughts?

I guess the initial question I would have is, how has SwiftFormat been going inside devmain? I know that @cy255 added support for that in devmain and it seems to have been going well?
I think switching from SwiftLint to SwiftFormat is a different task than just making sure both iOS and macOS have the same linter (which is what this PR does). Perhaps just file an issue to track separately?

Wouldn't we prefer to use swift-format instead and use the first-party supported dependency?

I took a bit of time to research the potential benefits of swift-format over swiftlint for the linting purposes that we need.

It seems like swiftlint is more mature providing nearly 200 rules that can be applied and configured to the swift code while swift-format provides around 40.
The way they are integrated into XCode is the same (by using run script build phases):

SwiftLint:
if which swiftlint >/dev/null; then
    swiftlint
else
    echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"
fi

swift-format:
if which swift-format >/dev/null; then
    swift-format -m format -i -r ${PROJECT_DIR}
else
    echo "warning: swift-format not installed"
fi

Installing swiftlint is more convenient for developers/contributors with package managers while swift-format requires the developer to clone the repo and build the tool locally.
This may be a minor issue: Since we're already using swiftlint for the iOS projects, the current consumers of FluentUI would have a small disruption in their process to ensure their linting of swift files keeps working if we change it from swiftlint to swift-format.

I personally think it makes sense to remain with swiftlint for now (just adding support to cover the Mac files) and eventually entertain the possibility of a migration to swift-format when we have more time for a more thorough investigation on the benefits of adopting it.
Thoughts?

I guess the initial question I would have is, how has SwiftFormat been going inside devmain? I know that @cy255 added support for that in devmain and it seems to have been going well?
I think switching from SwiftLint to SwiftFormat is a different task than just making sure both iOS and macOS have the same linter (which is what this PR does). Perhaps just file an issue to track separately?

Wouldn't we prefer to use swift-format instead and use the first-party supported dependency?

I took a bit of time to research the potential benefits of swift-format over swiftlint for the linting purposes that we need.

It seems like swiftlint is more mature providing nearly 200 rules that can be applied and configured to the swift code while swift-format provides around 40.
The way they are integrated into XCode is the same (by using run script build phases):

SwiftLint:
if which swiftlint >/dev/null; then
    swiftlint
else
    echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"
fi

swift-format:
if which swift-format >/dev/null; then
    swift-format -m format -i -r ${PROJECT_DIR}
else
    echo "warning: swift-format not installed"
fi

Installing swiftlint is more convenient for developers/contributors with package managers while swift-format requires the developer to clone the repo and build the tool locally.
This may be a minor issue: Since we're already using swiftlint for the iOS projects, the current consumers of FluentUI would have a small disruption in their process to ensure their linting of swift files keeps working if we change it from swiftlint to swift-format.

I personally think it makes sense to remain with swiftlint for now (just adding support to cover the Mac files) and eventually entertain the possibility of a migration to swift-format when we have more time for a more thorough investigation on the benefits of adopting it.
Thoughts?

I guess the initial question I would have is, how has SwiftFormat been going inside devmain? I know that @cy255 added support for that in devmain and it seems to have been going well?
I think switching from SwiftLint to SwiftFormat is a different task than just making sure both iOS and macOS have the same linter (which is what this PR does). Perhaps just file an issue to track separately?

I have synced offline with @cy255  before posting my findings and it learned that swift-format in devmain is being used for formatting (not linting swift code integrated to Xcode). From what I heard from her, it seems swift-format is doing well to format code as an automated process.
And I agree with your point of eventually creating a separate issue to investigate the migration as I pointed out before.

Wouldn't we prefer to use swift-format instead and use the first-party supported dependency?

I took a bit of time to research the potential benefits of swift-format over swiftlint for the linting purposes that we need.

It seems like swiftlint is more mature providing nearly 200 rules that can be applied and configured to the swift code while swift-format provides around 40.
The way they are integrated into XCode is the same (by using run script build phases):

SwiftLint:
if which swiftlint >/dev/null; then
    swiftlint
else
    echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"
fi

swift-format:
if which swift-format >/dev/null; then
    swift-format -m format -i -r ${PROJECT_DIR}
else
    echo "warning: swift-format not installed"
fi

Installing swiftlint is more convenient for developers/contributors with package managers while swift-format requires the developer to clone the repo and build the tool locally.
This may be a minor issue: Since we're already using swiftlint for the iOS projects, the current consumers of FluentUI would have a small disruption in their process to ensure their linting of swift files keeps working if we change it from swiftlint to swift-format.

I personally think it makes sense to remain with swiftlint for now (just adding support to cover the Mac files) and eventually entertain the possibility of a migration to swift-format when we have more time for a more thorough investigation on the benefits of adopting it.
Thoughts?

I guess the initial question I would have is, how has SwiftFormat been going inside devmain? I know that @cy255 added support for that in devmain and it seems to have been going well?
I think switching from SwiftLint to SwiftFormat is a different task than just making sure both iOS and macOS have the same linter (which is what this PR does). Perhaps just file an issue to track separately?

I have synced offline with @cy255  before posting my findings and it learned that swift-format in devmain is being used for formatting (not linting swift code integrated to Xcode). From what I heard from her, it seems swift-format is doing well to format code as an automated process.
And I agree with your point of eventually creating a separate issue to investigate the migration as I pointed out before.

In the specific case of Fluent UI Mac, I think SwiftLint is a better option because it provides consistency within the repo. However, I do think we should migrate to swift-format eventually when swift-format becomes more mature.

In the specific case of Fluent UI Mac, I think SwiftLint is a better option because it provides consistency within the repo. However, I do think we should migrate to swift-format eventually when swift-format becomes more mature.


Ability to detach an agent from a running process

When monitoring an application via a standalone agent as follows:
java -javaagent:PATH_TO_APM_AGENT.jar -Delastic.apm.service_name=NEW_NAME -Delastic.apm.server_url=http://HOSTNAME:8200 -jar PATH_TO_APPLICATION_JAR.jar
it will be beneficial to be able to detach the agent without stopping the application itself.
Use case examples: - Update the agent to a later version. - Agent errors and needs restarting - No further need for monitoring.

Thanks for opening this issue. We have this goal on our long term roadmap and we started working on an infrastructural change that will enable that.
For the short term, the recording and instrument flags should be useful for most cases of "No further need for monitoring" (as overhead would be mostly eliminated) and "Agent errors" (most are likely related to instrumentation and tracing activities).

Thank you for your prompt response and glad to hear that the lack of detach has already been recognised.
Is there any example of how the recording and instrument flags can be used and switched on/off at runtime, please?

Checkout the relevant documentation - see the options marked as Dynamic


chore: Make all the response bodies in predictable format

Task linked: DEV-3494 Make response bodies in predictable format


[semver:patch] fix(scripts): build url regex for pipeline ids < 10

The current regex matched against the build url fails when the pipeline id is < 10. Fixed in this PR! I'm assuming the . isn't needed, but if it is we can adjust to d+..

Thank you @jksaunders, that was a good catch.
That error sneaked in with the last PR where it went from d* to d. 😞


Undecided Movies

Hi,
This is the first time I used Flexget.
I saw many tutorials online and It was simple to me to make RPI2 to download series that I want.
The problem is, when I try to download movies from a trakt_list, I only got undecided ones. I tried everything I can, and cannot solve it.
I let you see my config.yml simplified to show you whats wrong it the movies
Config.yml:
tasks:
get_movies:
discover:
what:
- trakt_list:
username: xxxx
list: Filmes
type: movies
strip_dates: yes
from:
- rarbg:
category: x264 1080p
content_size:
max: 10000
min: 50
transmission:
host: localhost
port: 9091
username: transmission
password: transmission
path: /media/Movies/
Result:
2016-01-03 20:34 WARNING  manager                       Your locale declares ascii as the filesystem encoding. Any plugins reading filenames from disk will not work properly for filenames containing non-ascii characters. Make sure your locale env variables are set up correctly for the environment which is launching FlexGet.
2016-01-03 20:34 VERBOSE  task_queue                    There are 1 tasks to execute. Shutdown will commence when they have completed.
2016-01-03 20:34 VERBOSE  input_cache   get_movies_1080p Restored 5 entries from db cache
2016-01-03 20:34 VERBOSE  discover      get_movies_1080p Discovering 5 titles ...
2016-01-03 20:34 VERBOSE  discover      get_movies_1080p Discover interval of 5 hours not met for 4 entries. Use --discover-now to override.
2016-01-03 20:34 VERBOSE  discover      get_movies_1080p Searching for Sicario with plugin rarbg (1 of 1)
2016-01-03 20:34 VERBOSE  details       get_movies_1080p Produced 4 entries.
2016-01-03 20:34 VERBOSE  content_size  get_movies_1080p Entry Sicario.2015.1080p.BluRay.x264.TrueHD.7.1.Atmos-RARBG too big, rejecting
2016-01-03 20:34 VERBOSE  task          get_movies_1080p REJECTED: Sicario.2015.1080p.BluRay.x264.TrueHD.7.1.Atmos-RARBG by content_size plugin because maximum size 10000 MB, got 11171.0946655 MB
2016-01-03 20:34 VERBOSE  content_size  get_movies_1080p Entry Sicario.2015.1080p.BluRay.x264.DTS-HD.MA.7.1-RARBG too big, rejecting
2016-01-03 20:34 VERBOSE  task          get_movies_1080p REJECTED: Sicario.2015.1080p.BluRay.x264.DTS-HD.MA.7.1-RARBG by content_size plugin because maximum size 10000 MB, got 10594.3325071 MB
2016-01-03 20:34 VERBOSE  details       get_movies_1080p Summary - Accepted: 0 (Rejected: 2 Undecided: 2 Failed: 0)

Well everything seemed to work fine. The item that was matched according to your setup was rejected based on the content_size plugin settings.
In any case please open an issue on the forums or join irc for further assistance, git issues is for bugs.

I understand why I get those rejected. I do not understand why do I get 2 Undecided. Tht's my problem

Undecided are entries that did not match any filters.

Yes, but one of the movies that I have in my trakt list is the intern, and I get undecided for that entry:
title            : The.Intern.2015.1080p.WEB-DL.DD5.1.H264-RARBG
url              : magnet:?xt=urn:btih:7bc238fd69f5a43c1cd5566870420d63f074bad8&dn=The.Intern.2015.1080p.WEB-DL.DD5.1.H264-RARBG&tr=http%3A%2F%2Ftracker.trackerfix.com%3A80%2Fannounce&tr=udp%3A%2F%2F9.rarbg.me%3A2710&tr=udp%3A%2F%2F9.rarbg.to%3A2710&tr=udp%3A%2F%2Fopen.demonii.com%3A1337%2Fannounce
original_url     : magnet:?xt=urn:btih:7bc238fd69f5a43c1cd5566870420d63f074bad8&dn=The.Intern.2015.1080p.WEB-DL.DD5.1.H264-RARBG&tr=http%3A%2F%2Ftracker.trackerfix.com%3A80%2Fannounce&tr=udp%3A%2F%2F9.rarbg.me%3A2710&tr=udp%3A%2F%2F9.rarbg.to%3A2710&tr=udp%3A%2F%2Fopen.demonii.com%3A1337%2Fannounce
content_filename : <LazyField - value will be determined when it is accessed>
content_size     : 4744.29681778
discovered_from  : The Intern 2015
discovered_with  : rarbg
imdb_id          : tt2361509
quality          : 1080p webdl h264 dd5.1
task             : get_movies
torrent_info_hash: 7BC238FD69F5A43C1CD5566870420D63F074BAD8
torrent_leeches  : 481
torrent_seeds    : 1696
tvdb_id          : None
tvrage_id        : None


docs: Update the Deploy Applications section of the OSM Manual Demo document

This PR updates the Installing OSM on Kubernetes section of the "OSM Manual Demo" document.
In this PR:

add clarity and simplify verbiage
be explicit about the version of OSM (v0.8.2) this document is written for
swap kubectl apply -f http://... with kubectl apply <<EOF heredoc EOF -- this inlines the YAML in the document. I believe this allows us to look at what we are about to apply and understand in small chunks, without having to click through to another page (or copy paste the link, read etc).

This is one of a few steps to update the entire doc as part of #2845
Related PRs:

#3010
#3011
#3012

Once the entire doc is rewritten - all changes will be applied to the release-v0.8 branch.

@michelleN Could you PTAL?


Alignment of Dashboard Icons and Heading Typeface

Overrides Sufia with the 7.2 migration code because cherry picking newish Sufia code creates to many conflicts. Needed partial to update the Bootstrap columns. Overrides default Bootstrap type with Lato.


Move Inline SVG Code to Separate Files

Context
The application contains several components with inline SVG code, which clutters the codebase and makes it harder to maintain. To improve the code structure and maintainability, all inline SVG code should be moved to dedicated SVG files in the public folder.
Description
We need to refactor the codebase to move all inline SVG code into separate SVG files located in the public folder. This will involve creating a logical folder structure under public/icons to organize the icons and updating the code to reference these SVG files.
Requirements

Move Inline SVG Code to public Folder:

Identify all occurrences of inline SVG code within the codebase.
Move each inline SVG to a dedicated SVG file in the public/icons folder.
Create logical subfolders under public/icons to organize the icons. For example, hosting/src/components/Sidebar/icons/ArrowLeftIcon.tsx should be moved to public/icons/sidebar/arrow-left-icon.svg.

Update Code References:

Update all code references to use the new SVG files from the public folder instead of the inline SVG code.

Steps to Accomplish

Global Search for Inline SVG Code:

Perform a global search for the word "svg" (case insensitive, whole word match) to identify all occurrences of inline SVG code in the codebase.

Move SVG Code to Files:

For each identified inline SVG, create a corresponding SVG file in the public/icons folder.
Create logical subfolders under public/icons to categorize the icons based on their usage or location in the codebase.

Update Code References:

Replace the inline SVG code in the components with references to the new SVG files in the public folder.
Use the Image component from Next.js or standard <img> tags to include the SVG files in the components.

Example
Before:
// hosting/src/components/Sidebar/ArrowLeftIcon.tsx
const ArrowLeftIcon = () => (
  <svg width="20" height="18" viewBox="0 0 20 18" fill="none" xmlns="http://www.w3.org/2000/svg">
    <path d="M19 8.175H2.98748L9.36248 1.6875C9.69998 1.35 9.69998 0.825 9.36248 0.4875C9.02498 0.15 8.49998 0.15 8.16248 0.4875L0.399976 8.3625C0.0624756 8.7 0.0624756 9.225 0.399976 9.5625L8.16248 17.4375C8.31248 17.5875 8.53748 17.7 8.76248 17.7C8.98748 17.7 9.17498 17.625 9.36248 17.475C9.69998 17.1375 9.69998 16.6125 9.36248 16.275L3.02498 9.8625H19C19.45 9.8625 19.825 9.4875 19.825 9.0375C19.825 8.55 19.45 8.175 19 8.175Z" fill="" />
  </svg>
);

After:
1. Move the SVG code to public/icons/sidebar/arrow-left-icon.svg:
<!-- public/icons/sidebar/arrow-left-icon.svg -->
<svg width="20" height="18" viewBox="0 0 20 18" fill="none" xmlns="http://www.w3.org/2000/svg">
  <path d="M19 8.175H2.98748L9.36248 1.6875C9.69998 1.35 9.69998 0.825 9.36248 0.4875C9.02498 0.15 8.49998 0.15 8.16248 0.4875L0.399976 8.3625C0.0624756 8.7 0.0624756 9.225 0.399976 9.5625L8.16248 17.4375C8.31248 17.5875 8.53748 17.7 8.76248 17.7C8.98748 17.7 9.17498 17.625 9.36248 17.475C9.69998 17.1375 9.69998 16.6125 9.36248 16.275L3.02498 9.8625H19C19.45 9.8625 19.825 9.4875 19.825 9.0375C19.825 8.55 19.45 8.175 19 8.175Z" fill="" />
</svg>

2. Update the component to reference the SVG file:
// hosting/src/components/Sidebar/ArrowLeftIcon.tsx
import Image from 'next/image';

const ArrowLeftIcon = () => (
  <Image src="/icons/sidebar/arrow-left-icon.svg" alt="Arrow Left" width={20} height={18} />
);

Acceptance Criteria

All inline SVG code has been moved to separate SVG files in the public/icons folder.
Logical subfolders are created under public/icons to categorize the icons.
All components are updated to reference the new SVG files.
The application works as expected without any broken icons.

Hallo @DennisAlund , I've partiality done to move inline svg to a separate file, but along the way, I encountered a couple of issues which is related to customizing svg itself, so here are the issues:
Issues

It is hard to make the svg reusable because when we have different colors, we need to make a new file for each color
Still related to 1st point, I see a lot of our implementation that we put a className on svg itself,  for example: changing the color on the hover or changing the color on the dark theme, we couldn’t do it on an image tag
Changing the size is also quite tricky sometimes
We need to make sure that svg is optimized

Proposed Solutions
Based on these problems, I propose a solution where we use a class-based icon with this library. Here are the benefits:

It is natively built for Tailwind so it's easier for us to use it
We can choose from a lot of icon options. Not just a lot of icon options, but we can combine more than one icon set, for example, we can combine icons from MDI icons, Lucide icons, and many more. You can see the icon set options here: https://icon-sets.iconify.design/
It's easier for us to customize the color, size, etc, since it uses Tailwind
Well-optimized library, because in the build process, it will automatically compile only the icon that we use
If we even need a custom icon that doesn’t exist on the icon sets, then we can easily add it
We can remove all of the icon files from our source code

if you agree, I will implement all of the icons with this solution :)
If you not , I will continue moving the rest of the svg file ✌

Perfect suggestion @WidaSuryani  go for that solution and exchange what you find with Google Material icons 🙏


404 at /develop/develop-images/dockerfile_best-practices/%E2%80%A2

I found a broken link : https://docs.docker.com/develop/develop-images/dockerfile_best-practices/•

Thanks for reporting; do you remember where you found that broken link? I checked the source code in this repository, and couldn't find it, but perhaps it was fixed already

closing, as this looks to have gone stale


[Bug][UI-Next][V1.0.0-Alpha] click timing error in process definition page

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened

What you expected to happen
click successfully.
How to reproduce
above.
Anything else
No response
Version
dev
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Thank you for your feedback. Will be processed later.

I'll work out this issue.


Issue With Ubuntu 14.04... Install guide

mkdir /MusicBot-develop
git clone https://github.com/SexualRhinoceros/MusicBot.git /MusicBot-develop
cd MusicBot-develop
This tells the computer (on ubuntu 14.04) to create the directory /MusicBot-develop INSTEAD of /root/MusicBot-develop
Seems all good right? But now you're telling them to cd to /root/MusicBot-develop but it doesn't exist, they need to go to /MusicBot-develop
Just a minor issue but confusing for noobs like me :)

Yeah the person that wrote the install wiki for Ubuntu made a few blunders

Actually you were the one who changed it from unzipping to git clone @abalabahaha.

I forgot you can edit the wiki :P xD


CSS

CSS
User  Story
As a  bootcamp student,
I want the prework notes to be structured on a webpage
so that I can easily find and read information.
Acceptance Critera
GIVEN a prework Study Guide website,
WHEN I view the study guide,
THEN I see a dark blue header and footer and four boxes with a shadow.

CSS file added.


Custom arguments on tables

Relates to #16. How about if you could define custom arguments on tables which worked something like this:
trees(radius: {"lat": 37.78, "lng": -122.43, "km": 10}) {
  nodes {
    id
    name
  }
}

The radius here would be a custom argument defined in the plugin configuration.
Maybe it can be defined in terms of the where SQL clauses it adds?

Syntax something like:
plugins:
  datasette-graph-ql:
    databases:
      sf-trees:
        tables:
          arguments:
            radius:
              inputs:
                lat: float
                lng: float
                km: float
              where_sql: |-
                PtDistWithin(geometry, MakePoint(:lat ,:lng, 4326), :km * 1000)=TRUE

I think this is too similar to #16 - I'm going to solve this with custom queries instead, by making it so custom queries can state "I return the equivalent of an Entry" so nested GraphQL for foreign keys can work correctly.


Error Installing

Context
I'm getting an error trying to install the plugin:

[Error] :release-asset-not-found "null"]

Image:

Logseq version 0.10.9, Windows 10.

Sorry please try again.

That works, thanks 👍


Deploying Synapse Workspace with Managed Vnet Enabled (Bicep), but cannot assign private endpoints in UI

Situation:
I am deploying a Synapse workspace instance in Bicep with Managed Virtual Network Enabled.
I can see the Managed Vnet Is enabled from the UI:

However, when I enter the workspace my integration runtimes are not enabled for virtual network access and I cannot create managed private endpoints.
I'm writing the following code for the bicep deployment:
resource synapse_workspace 'Microsoft.Synapse/workspaces@2021-06-01' = {
  name: synapse_workspace_name
  location: location
  tags: {
    Workload: '####'
    Environment: envName
    Classification: 'Confidential'
    Criticality: 'Low'
  }
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    // Git Repo
    workspaceRepositoryConfiguration: {
      accountName: '#####'
      collaborationBranch: 'main'
      projectName: '####'
      repositoryName: '#############'
      rootFolder: '/synapse/syn-data-${envName}'
      tenantId: '####################'
      type: 'WorkspaceVSTSConfiguration'
    }
    defaultDataLakeStorage: {
      resourceId: storage_account_id
      createManagedPrivateEndpoint: true
      accountUrl: ###################
      filesystem: ################
    }
    encryption: {
      cmk: {
        kekIdentity: {
          useSystemAssignedIdentity: true
        }
        key: {
          name: 'default'
          keyVaultUrl: '#########################'
        }
      }
    }
    managedVirtualNetwork: 'default'
    connectivityEndpoints: {
      web: 'https://web.azuresynapse.net?workspace=%2fsubscriptions%######################
      dev: 'https://##############.dev.azuresynapse.net'
      sqlOnDemand: '################-ondemand.sql.azuresynapse.net'
      sql: '################.sql.azuresynapse.net'
    }
    managedResourceGroupName: guid('synapseworkspace-managed-resource-group-${envName}')
    sqlAdministratorLogin: 'sqladminuser'
    privateEndpointConnections: []
    managedVirtualNetworkSettings: {
      preventDataExfiltration: true
      allowedAadTenantIdsForLinking: []
    }
    publicNetworkAccess: 'Disabled'
    cspWorkspaceAdminProperties: {
      initialWorkspaceAdminObjectId: '#########################'
    }
    trustedServiceBypassEnabled: false
  }
}

I get no errors in the deployment regarding the virtual network or any associated settings, but I still get the default integration runtime set to "Public" and not "Managed Virtual Network".
Is this a limitation in Bicep or am I missing some parameter?
Any help would be great
Joao

This might be something you are misunderstanding of what the synapse/workspaces API is expecting. I will convert this to a discussion since it doesn't look like a bicep-specific issue. You may also want to open a support ticket to get more immediate traction on the issue.


Fixed several object-literal-type-assertion

Related to #313
Proposed Changes
Redundant typing were removed from the following files:

BotConfig.ts
azureBotService.ts
connectedService.ts
dispatchService.ts
fileService.ts
luisService.ts
qnaMakerService.ts
msbot-list.ts

Testing
Travis will no longer report this issue

@johnataylor I'm not sure the semantic differences here. Can someone who knows JS better than me chime in? These changes seem a simple no-op for clarity, but JS can be subtle and I'm not certain.

@cleemullins we'll review and recreate TSLint PRs after outdated by #338.


Remove runtime program and quantum instance

Summary
This PR removes runtime clients, which have been already removed at IBM Quantum Platform, and QuantumInstance-based algorithms.

[x] remove QuantumInstance-based legacy algorithms
[x] remove VQEClient and QAOAClient
[x] update tutorials
[x] reno

Details and comments
It still uses opflow-based PauliSumOp somewhere for the compatibility. E.g., to_ising function to return PauliSumOp with the default option (option opflow=False returns SparsePauliOp). Should I remove them all as well?

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

15 of 19 (78.95%)  changed or added relevant lines in 3 files are covered.
8 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.6%) to 92.981%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit_optimization/algorithms/grover_optimizer.py
10
14
71.43%

Files with Coverage Reduction
New Missed Lines
%

qiskit_optimization/algorithms/optimization_algorithm.py
8
89.42%

Totals

Change from base Build<PHONE_NUMBER>:
0.6%

Covered Lines:
4173

Relevant Lines:
4488

💛  - Coveralls

It still uses opflow-based PauliSumOp somewhere for the compatibility. E.g., to_ising function to return PauliSumOp with the default option (option opflow=False returns SparsePauliOp). Should I remove them all as well?

Yes, the intent is to cease use of deprecated function like that so supporting just SparsePauliOp is all that should be done.
In terms of other deprecated code in Opt, I did a quick search and this was all that came up for me. We should remove this too - in this case its time is up anyway (could have been removed last release)
https://github.com/qiskit-community/qiskit-optimization/blob/e2855f2b6337a76da41fcab15b188d9904642f0f/qiskit_optimization/applications/graph_optimization_application.py#L83-L89

I removed opflow and updated tutorials and reno following Steve's feedback.


Is this work associated to a research paper?

Can you please share the name of the research paper explaining this tracking methodology?

It applies a standard EKF to lidar and radar data, so no research paper linked.


Module initialization will not run if the cast API is available at startup

Module initialization will not run if the cast API is available at startup.
In practice I assume there's always a delay so the initialization does run but it would be make it more robust (e.g. using similar technique to CastVideos example).
if (!chrome.cast || !chrome.cast.isAvailable) {
  setTimeout(initializeCastApi, CAST_API_INITIALIZATION_DELAY);
}

Please use the latest Cast Chrome sender SDK and use this initialization:


Mounting camera statically

I need to mount camera on a pole at a traffic intersection. (The reason is to get a pseudo data collection pipeline ready, and I could test my downstream algorithms like object detection and tracking.)
How can I mount a sensor to any static point in the scene ? (I know there are APIs available for mounting on a vehicle.)

p0 = traffic_light.get_transform()
blueprint_library = self.__world.get_blueprint_library()
camera_bp = blueprint_library.find('sensor.camera.rgb')
camera = self.__world.spawn_actor(camera_bp, p0, attach_to=traffic_light)

client = carla.Client('<IP_ADDRESS>', 2000)
client.set_timeout(20.0)
world = client.get_world()
traffic_light=world.get_actors().filter('traffic.traffic_light')[0]  #world.get_actors() will show all actors in the world, find the actor's type, then filter this type, the information will be shown.
p0 = traffic_light.get_transform()
blueprint_library = self.__world.get_blueprint_library()
camera_bp = blueprint_library.find('sensor.camera.rgb')
camera = self.__world.spawn_actor(camera_bp, p0, attach_to=traffic_light)

the completed code is above, thank you


Fix bug when handling errors from call_ext_last

Typically when using throw, the stack base that is affected by call_ext_last is incorrect when restoring it to the catch label
Add test that current crashes on master without this change
These changes are made under both the "Apache 2.0" and the "GNU Lesser General
Public License 2.1 or later" license terms (dual license).
SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later

We actually may need to adopt OTP23+ stack model introduced in https://github.com/erlang/otp/pull/2351 to fix this crash.
I am not totally sure of the semantics of call_ext_last, let's put on hold until we hear back from OTP team.
https://github.com/erlang/otp/issues/7152


Update CODEOWNERS to DG team

@jonjanego Can we update the codeowners to the DG team alias? We missed this one during the changeover. Thanks!


successful download-file returns false in bash

As you can see below, a successful download has a return code of 1, which means false in a Linux shell. Unfortunately this is breaking the use of lgogdownloader as a registered downloader for Arch linux packages, because the scripts rely on a return value of 0 to signal success. There are probably other Linux scripting issues in other distributions that arise from this. Can this please be fixed? Thanks for your hard work on this very useful tool.
-> % lgogdownloader --download-file heroes_of_might_and_magic_3_complete_edition/en1installer0
Getting game names (1/1) 17 / 17
Downloading: ./setup_heroes_of_might_and_magic_3_complete_4.0_(28740).exe
100% ▕██████████████████████████▏ 0.78/0.78MB @ 803.24kB/s ETA: 0s
-> % echo $?
1
-> % false
-> % echo $?
1

Apparently when I rewrote Downloader::downloadFileWithId to use Galaxy API in a884e8c I accidentally reversed the return code meaning.
This is now fixed in aa29adf

Thanks very much!!


xpdf: added long description

The added description will help folks who are looking for a specific tool to be directed here.
When looking for texttopdf it was a mild hassle to need to turn to google rather than nixpkgs to find the proper package.
When someone else had the same hassle just now in the IRC I thought I'd add this to help remedy others who are searching.
Motivation for this change
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

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

Thanks, explicit documentation is always nice.
In future, please include the package names into commit messages. (see CONTRIBUTING.md link in the template)

Thanks, explicit documentation is always nice.
In future, please include the package names into commit messages. (see CONTRIBUTING.md link in the template)

Thanks for the tip, I will start looking at CONTRIBUTING for better commit messages from now on.


make install error

make install
time mi compile coreppl/src/[cppl.mc](https://cppl.mc/) --output /tmp/tmp.D0Z0yefWz1
ERROR <./miking-dppl/coreppl/src/coreppl-to-mexpr/[compile.mc](https://compile.mc/) 440:15-440:42>: Unknown variable 'eliminateDuplicateExternals'

Command exited with non-zero status 1
2.02user 0.17system 0:02.22elapsed 99%CPU (0avgtext+0avgdata 432488maxresident)k
16inputs+104outputs (0major+113470minor)pagefaults 0swaps
make: *** [Makefile:29: build/cppl] Error 1

Version mismatch with the latest Miking. I have update Miking and the installation went fine.


Selection of autocomplete doesn't work on mobile (iOS Safari)

due to this part here, only mouse events are valid for selection
onMouseOver={() => this.setActiveItemAtIndex(p.index)}
onMouseDown={() => this.selectAddress(p.suggestion, p.placeId)}

changing onMouseDown to onClick or adding onTouchEnd and onTouchStart events should fix this.

I added a pull request for this:
https://github.com/kenny-hibino/react-places-autocomplete/pull/93

Closed via #93


Somehow deal with the fact that meaningful variables don't necessarily have normal forms.

Take into consideration the "divide" operator:
(λn.((λf.(λx.x x) (λx.f (x x)))   (λc.λn.λm.λf.λx.(λd.(λn.n (λx.(λa.λb.b))   (λa.λb.a)) d ((λf.λx.x) f x) (f (c d m f x)))   ((λm.λn.n(λn.λf.λx.n(λg.λh.h(gf))(λu.x)(λu.u))m)nm)))   ((λn.λf.λx.f(nfx))n))
You can't currently assign that to a variable (because I think it doesn't have a normal form), but it looks like it works if you do the application inline.
Maybe we don't compute normal forms of definitions?

Maybe we don't compute normal forms of definitions?

Sure, that's the way to go. Definitions are entities of the metalanguage, so reductions should not be performed in the bodies of definitions.

Fixed in https://github.com/evinism/lambda-explorer/pull/45


vs code log

Product and Version [VS/VSCode]:
OS Version [macOS/Windows]:
Live Share Extension Version:
Target Platform or Language [e.g. Node.js]:
Steps to Reproduce / Scenario:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Screenshots
If applicable, add screenshots to help explain your problem.
20190604_150115_15596604754760_VSCode.log
20190604_150455_15596606951290_VSLSAudio.log
20190604_160505_15596643055420_VSCode.log
20190604_160507_15596643077780_VSLSAudio.log
20190604_160950_15596645903460_VSCode.log
20190604_160953_15596645931660_VSLSAudio.log
20190604_161633_15596649933890_VSCode.log
20190604_161643_15596650030230_VSCode.log
20190604_161645_15596650055330_VSLSAudio.log
20190604_165859_15596675393140_VSCode.log
20190604_165902_15596675428020_VSLSAudio.log
20190604_170853_15596681332310_VSCode.log
20190604_170855_15596681358270_VSLSAudio.log
20190604_171040_15596682409180_VSCode.log
20190604_171043_15596682434830_VSLSAudio.log
20190604_171054_15596682540830_VSCode.log
20190604_171056_15596682565860_VSLSAudio.log
20190604_174431_15596702715680_VSCode.log
20190604_174434_15596702740980_VSLSAudio.log
20190604_175420_15596708606770_VSCode.log
20190604_175721_15596710415140_VSLSAudio.log
20190604_182534_15596727345080_VSCode.log
20190604_182537_15596727374310_VSLSAudio.log
20190604_182543_15596727431010_VSCode.log
20190604_182545_15596727453400_VSLSAudio.log
20190604_192408_15596762480010_VSCode.log
20190604_192412_15596762523670_VSLSAudio.log
20190605_014553_15596991531600_VSCode.log
20190605_014628_15596991889000_VSCode.log
20190605_014653_15596992132370_VSLSAudio.log
20190605_015050_15596994509740_VSCode.log
20190605_015055_15596994555760_VSLSAudio.log
20190605_015242_15596995624790_VSCode.log
20190605_015600_15596997607840_VSLSAudio.log
20190605_015633_15596997935700_VSCode.log
20190605_015641_15596998017820_VSLSAudio.log
20190605_015728_15596998482990_VSCode.log
20190605_015731_15596998514040_VSLSAudio.log
20190605_015746_15596998666590_VSCode.log
20190605_015750_15596998704200_VSLSAudio.log
20190605_022201_15597013217960_VSCode.log
20190605_022203_15597013238190_VSLSAudio.log
20190606_183338_15598460185000_VSCode.log
20190606_183406_15598460467020_VSLSAudio.log
20190606_183413_15598460531000_VSCode.log
20190606_183420_15598460607980_VSLSAudio.log
20190606_190728_15598480480270_VSCode.log
20190606_190731_15598480515160_VSLSAudio.log
20190606_193520_15598497208310_VSCode.log
20190606_193532_15598497321750_VSLSAudio.log
20190606_194321_15598502017290_VSCode.log
20190606_194326_15598502061980_VSLSAudio.log
20190606_194524_15598503243150_VSCode.log
20190606_194537_15598503370950_VSLSAudio.log
20190606_200728_15598516482010_VSCode.log
20190606_200732_15598516522640_VSLSAudio.log
20190606_200809_15598516894490_VSCode.log
20190606_200813_15598516931480_VSLSAudio.log
20190606_203240_15598531601610_VSCode.log
20190606_203250_15598531703990_VSLSAudio.log
20190606_204710_15598540308240_VSCode.log
20190606_204719_15598540391840_VSCode.log
20190606_204725_15598540454900_VSLSAudio.log
20190612_014321_15603038010160_VSCode.log
20190612_014411_15603038519440_VSLSAudio.log

Hi @EdManDev ,is the issue your are having related to Live Share extension ? If so, would you give some more details about the problem , what was the error ? if it is related to VS Code please use the following address : https://github.com/Microsoft/vscode/issues

It looks like this is a follow-up to #2203.
The error in the log is "Agent terminated with exit code: -4058", which is the same as some other reports we've had. So I'm closing this as a duplicate of #2270.


Leap

Contains
Brief description of what the PR does like "Fixes #12345"
How to test
Brief description of how to test / confirm this PR before merging
Outstanding before merging
If anything. You can use neat checkboxes! Feel free to delete if not needed

[ ] Need to consider use case x
[ ] Still have to adjust the wiki doc
[ ] Will need translation work

Can one of the admins please verify this patch?

Hi @tinafanson - if you are trying to test out how Pull Requests work or something, please be sure to target your own personal test repo instead of an upstream / live repo like this one :-)
https://help.github.com/articles/about-pull-requests


Hashicorp Vault - accept root token as string instead of file

I'm trying to setup Hashicorp Vault as secret store and have an issue on how to pass the token file to the component while running in the sidecar in the Kubernetes cluster.
My proposal is to introduce another configuration parameter (vaultToken?) which is required if vaultTokenMountPath is not supplied. This way I would be able to pass the token using standard kubernetes secretRef syntax.
Thanks!

I am willing to update the component if everyone agrees to this change. I think we support the current file-based method as well as a vaultToken that can be read from a K8s secret.


[future] Add "enableAuditLog" option to master and volume server

The default value of "enableAuditLog" option is false. when it set to true, it will produce the audit log files.
Because  some critical operations,  such as: '/delete', PUT/POST actions,  need be record in same format for audit use case.
There are the import fields should be record:
time(ms);clientIP;ACTION;FID
Any other suggestions?

If fronted by nginx, this log can be generated with nginx logs?


Papyrus] IDL import

Issue and tracking information
Developer's time Estimated effort to fix (hours):
Developer's Actual time spent on fix (hours)
Issue reporter to provide a detailed description of the issue in the space below
Support IDL import in Papyrus

Implemented.
Right click on the model and select "Import -> IDL Import" to import IDL.


Support getters for already set members

Hi, Bon is my favorite crate and I'm using it as the backbone for a complex pipeline internal framework.
In essence, my pipeline works like this:
        pipeline
            .pass(the_first_step)
            .pass(another_step)
            .pass(some_other_step)
            .pass(the_last_step)

Each step of the pipeline is (simplified) implemented like this:
pub async fn the_first_step<S>(
    Payload(id): Payload,
    PgConn(pg_conn): PgConn,
    State(builder): State<NewDbRowBuilder<S>>,
) -> Result<NewDbRowBuilder<SetTheFirstStepValue<S>>, crate::Error>
where
    S: new_db_row_builder::State,
    S::TheFirstStepValue: IsUnset,
{
   // some work that connects to api, db, etc, and produces a value

    Ok(builder.the_first_step_value(my_awesome_value_i_fetched))
}

The types of the pipeline enforce that the state produced by a prior pass must be fed into the pass under it, so you can't accidentally order anything wrong. I love using Bon to back this pipeline system and allow me to make each pass specify what the conditions of its state should be.
Where I am struggling is that sometimes I run into a weird, limiting situation.
I have one step in my pipeline that scrapes some information off of a user in my DB, processes it, then sets it in the builder (because this value must go in the row that's being built). Then, in another pass of the pipeline, I must read processed data out and use it to compute another value that also goes on my row. Given the current implementation of Bon (while following the rules and not directly implementing unsafe methods on generated code), I have three solutions:

Take this processed value, clone it and set it into the state, then return a tuple of the state and the cloned value. This is bad to me because the passes of my pipeline become much less generic as they now must take a tuple of the built state and any previously obtained values and drill them through the entire way
Do what I'm doing currently, and maintain a cache that passes can use to set values and retrieve them later. This works (and is fairly generic), but I lose the ability to safely do the guards like IsSet because this cache has to be completely detached from bon
Use builder(field) on these fields I want to cache. This also works, but it has the same problem as before where I lose the ability to do guards on the passes which is what I love so much about bon.

I noticed in 3.1.1 you removed the non-determinism of generated privates. After seeing this, being able to add methods that take in &self and return a reference to a value in the builder state would be incredible and make my pipeline work exactly how I want it to. This long winded context finally leads to my question (the one in the title)...
How fundamentally unsafe is this? Taking a look at the expanded macro from builder everything I can see indicates that adding read only accessor methods that do not move out of the tuple or clone the data would be completely safe, but I figured it would be well worth opening an issue for this because this will be running in production code where a mistake like this will not be acceptable.
Thank you!

A note for the community from the maintainers
Please vote on this issue by adding a 👍 reaction to help the maintainers with prioritizing it. You may add a comment describing your real use case related to this issue for us to better understand the problem domain.

Hi, thank you for creating the issue! Accessing the private fields of the builder (except for #[builder(field)]) is definitely wrong, since those internals may change between patch versions. The only unsafe code generated by builder macros is unwrap_unchecked for required members in the finishing function. So the only way this may break is if you set the required field inside the builder to None by directly accessing its internals. Vending a readonly reference to the internal field is completely, fine, however, there isn't an official API to do that in the current version of bon (3.1.1).
But.. I was actually planning to add an ability to generate getters for already set members as the next feature after #[builder(field)]. I imagine it like this. There will be a #[builder(getter)] annotation that will generate a simple getter with no magic, that has the name get_{member}. It will be possible to override its visibility, docs and name with the usual attributes #[builder(getter(name = ..., vis = ..., doc { ... })]. The default visibility will be the same as it would be for setters.
In future increments, I plan to provide the ability to generate getters for mutable references, the ability to do AsRef and Deref coercions, and custom conversions similar to #[builder(with)], but it'll be #[builder(getter(with))].

Fantastic to hear! Thank you. I am fairly familiar with bon's internals, and if you haven't started I'd be happy to take on and implement this.

Yeah, I've been procrastinating on this a bit given the Stalker 2 release 😳. I haven't started with this feature yet, so feel free to take a stab at this 👍

Haha, have fun. Feel free to assign me this. Will get started now.

At a high level, how do you feel about having the getters return an impl Borrow<T> instead of just &T? The main reason I'm suggesting this is because the ergonomics could be a bit better for Strings and Vecs which would then return &str and &[T] accordingly.

Honestly, I have mixed feelings about automatic magic conversions.
If you suggest the getter to return literally impl Borrow<T>, then it will be inconvenient for the caller, because the caller will then need to both specify the generic parameter T explicitly, and invoke borrow() on the returned value.
In general, even if we use Deref instead of Borrow in this case, I'm against complex type projections like <Vec<T> as Deref>::Target, because that would appear in type hints and in docs in this complex form.
Here are some ideas I have for this API here:
#[builder(
      // For optional members automatically does `Option::as_ref` (reference
    // is moved under the Option).
    //
    // &T | Option<&T>
    getter,

    // For optional members does no conversion, because `&mut Option<_>` makes
    // sense if the caller wants to reset the `Option` to `None`.
    //
    // &mut T | &mut Option<T>
    getter(mut),

    // Deref is only supported for readonly getters. One probably doesn't
    // need deref for mutable getters, because returning e.g. `&mut String`
    // or `&mut Vec<T>` makes perfect sense.
    //
    // The argument to `deref` specifies the return type of the getter
    // (i.e. the target of the deref coercion). However, it can be omitted
    // (i.e. just `getter(deref)`) for some well-known types such as:
    // - String
    // - Vec<T>
    // - Box<T>
    // - Rc<T>
    // - Arc<T>
    // - Cow<T>
    // - PathBuf
    // - OsString
    // - CString
    // - Utf8PathBuf
    // - ...
    // Just look up the `Deref` impls in `std` here: https://doc.rust-lang.org/stable/std/ops/trait.Deref.html,
    // and in `camino` crate, we may extend this list in the future.
    //
    // &str | Option<&str>
    getter(deref(&str)),

    // Getter by `Copy` -> T | Option<T>
    getter(copy),

    // Getter by `Clone` -> T | Option<T>
    getter(clone),

    // Some other standard additional attributes
    getter(
        name = getter_name,
        vis = "",
        docs {
            /// Docs for getter_name
        }
    )

    // Multiple getters need to have name specified explicitly
    getter(name = getter_name_1),
    getter(name = getter_name_2, clone),

    // Custom readonly getter. Accepts a readonly reference and transforms it.
    // Only `&_` type is accepted (_ is replaced with member's type)
    getter = |value: &_| -> Ty { expr }

    // Custom mutable getter. Accepts a mutable reference and transforms it.
    // Only `&mut _` type is accepted (_ is replaced with member's type)
    getter = |value: &mut _| -> Ty { expr }

    // Give a name to the getter if there are several getters
    getter(name = foo, with = |value: &mut _| -> Ty { expr }),
)]

So users would manually need to write #[builder(getter(deref))] for String or Vec<T>.

Just a remark. I expect implementing those will be a PITA, because mut is a keyword and can't be easily parsed by darling (https://github.com/dtolnay/syn/issues/1458). So I'd definitely postpone that part.

Got it. How do you feel about this then?
I'll finish up the PR and polish it and get it to support the following:

Standard #[builder(getter)] with default name
name, docs, and vis since most of the code to do that is already there and quite easy

That could probably go in as an experimental / unstable API like overwritable, because I think that those two would cover most people's use cases. And then the rest of the features can be implemented in afterwards for stability?

As another aside (this will likely be pretty complex to implement correctly too and would break the API), it would be very cool if we could add another state like IsSetSome for option types that gets set when calling the non-maybe version of an Option's builder. That way, we can automatically return &T from an Option<T> builder from a getter if we know that it was set to Some.

Got it. How do you feel about this then?

Makes sense to me.

That could probably go in as an experimental

By "that" do you mean the getter attribute as a whole in its initial implementation proposed by you (i.e. builder(getter) / builder(getter(name, vis, doc))? If so, makes sense, maybe the API will change according to more feedback.

could add another state like IsSetSome

Yeah, I've had such thing in mind as well even before releasing v3 where the new typestate design landed. However, I wouldn't like to have that state generated by default, because that would complicate things and also probably increase compile times. I was thinking of adding something like that in the future, and make that enabled with some explicit attribute.

Sweet, just put up the PR: https://github.com/elastio/bon/pull/222
This supports those mentioned configurations.

One more thing. We should also probably support generating a getter for the receiver (self) of associated methods. Today any #[builder(...)] attributes on the receiver are explicitly prohibited:
https://github.com/elastio/bon/blob/00d9a3ee614f76f477b9f0f8a4f3e1210cbadc57/bon-macros/src/builder/builder_gen/input_fn.rs#L148-L153
.. and I guess this is the first precedent when we need to support #[builder(getter)] on self. Luckily this doesn't conflict with the current design and can also be added as a future extension just like other getter configs that I proposed above (https://github.com/elastio/bon/issues/221#issuecomment-2506766749)

Tbh in this case, I would probably just do get_{name_of_struct_method_is_on}
But at the same time, I don't actually think get_selfis all that bad.

Another interesting design, I'm wondering how we should support getter with start_fn or finish_fn. IMO it should be supported, but you have to manually specify a name.


Identify Infrastructure as Code (Terraform, Chef, Puppet,Ansible)

Is your feature request related to a problem? Please describe.
When assessing content in a repo it would be a nice feature to also identify infrastructure as code in use.
Describe the solution you'd like
Possibly a new category for IAC identifiers That include Azure ARM templates, Terraform, Packer, Ansible
Describe alternatives you've considered
Instead of new category add to an existing category related to DevOps or build.
Additional context
Thinking at the concept of unified pipelines it would help to Also identify infrastructure as code and other infrastructure configurations.

I like it.

Support is added for ARM, Hashicorp Terraform and Packer.  No required/common distinguishable features in script code could be identified for Ansible, Chef or Puppet from other types of files.

The fix will be in the next release.


[Physics Interpolation] Interpolated triggered from outside physics process when using multi-threaded rendering.

Tested versions

Reproducible in: 3.6.stable, 3.5.3.stable.

Cannot reproduce in earlier versions, as in-built 3D physics interpolation was introduced in 3.5.
System information
Linux Mint 22
Issue description
Specifically when using the multi-threaded rendering model while physics interpolation is enabled, every so often this warning is generated while rigid bodies are in motion:
W 0:00:15.011   instance_set_transform: [Physics interpolation] Interpolated triggered from outside physics process: "/root/Scene/@Cube@2/CollisionShape/MeshInstance" (possibly benign).
  <C++ Source>  servers/visual/visual_server_scene.cpp:892 @ instance_set_transform()

The rigid body that generates the warning is random, and I'm pretty sure the warnings are actually rate-limited in 3.6, since in 3.5, the warnings are essentially spammed out.
I would like to keep using the multi-threaded rendering model for my project, as I need to instance meshes in a separate thread, but this warning is somewhat annoying. Is there a nice way to solve this issue, or is my only option to hide the warnings?
Steps to reproduce

Open the reproduction project.
Run the scene, and let physics do its thing for about 30 seconds. Since by default Godot uses single-threaded rendering, there should be no warnings generated.
Stop running the scene, enter the project settings, and under Rendering > Threads > Thread Model, change to "Multi-Threaded".
Run the scene again, and wait about 30 seconds again. This time, the warning should appear at regular-ish intervals.

Minimal reproduction project (MRP)
InterpolationWarning.zip

Have you been able to get better performance using multithread rendering?

I don't have it enabled necessarily for the performance gain (for my project, it barely makes a difference because of how few objects there are), but from what I remember reading in the documentation, instancing anything that renders something (like a Sprite or MeshInstance, iirc) outside of the main thread was not thread-safe, unless multi-threaded rendering was enabled. The problem is, instancing MeshInstance in a separate thread is now a necessity for my project.
If this requirement no longer applies, and I am safe to use single-threaded rendering, then I will probably do so to avoid this issue altogether, as disabling the warnings feels wrong to me :P

Had a look at the MRP, and it does appear like the physics / rendering is running out of sync in multithread render mode, hence the interpolation warnings.
Essentially physics interpolation relies on things being called in a specific order:

1 or more physics ticks
render frame
repeat

If during multithread-render mode it is attempting to update physics objects within the render frame, then things will go wrong, best case you'd get subtle glitches in rendered transforms, as the previous and current transforms changed in and out of sync, as well as getting the warnings.
What may be worth adding on my side is a warning at startup to this effect when the combination of physics interpolation and multithread rendering is used, that the combination is not recommended and not guaranteed to work correctly. I'm not sure that adjusting multithread render syncing is worth it at this stage in 3.x lifetime.
The docs do say:

Instancing nodes that render anything in 2D or 3D (such as Sprite) is not thread-safe by default. To make rendering thread-safe, set the Rendering > Threads > Thread Model project setting to Multi-Threaded.

Note that the Multi-Threaded thread model has several known bugs, so it may not be usable in all scenarios.

I'm not aware that we've changed anything recently to make instancing these nodes thread-safe, so this advice still stands.

Thank you for digging into this! That makes sense, but that essentially means I've boxed myself into a corner without realising, as I need the multi-threaded model, as well as physics interpolcation so that rigid bodies move smoothly on monitors that are faster than 60Hz.
I think it's definitely worth adding this to the documentation, and potentially to the tooltip for the thread model in the settings as well.
As an aside, I did notice as I was experimenting with the project settings in the MRP, that there are actually two modes for the single-thread model: safe and unsafe. I still have some hopium left in the tank, so I'd like to ask for clarification on what it means exactly by being safe vs. unsafe: what I assume is that the safe version has locks and mutexes in place in the rendering code, whereas the unsafe version does not (for performance gains), however I'm not sure at all, since I can't find anything about these modes in the documentation.
So does the "single-safe" thread model mean what I think it means, in that I can instance visual nodes outside of the main thread without the engine crashing? If so, that is 100% my course of action. Otherwise, I don't think I have any choice but to hide the warnings, unfortunately.

I have never looked into this before, but it looks to me as if:

Single thread unsafe - creates regular visual server
Multithread - creates VisualServerMT, creates separate thread for render
Single thread safe - creates VisualServerMT, but runs on main thread

VisualServerMT has a command queue, whereas I assume regular visual server (unsafe) just runs commands as they come in.
Whether "single safe" means it is ok to create visual nodes from another thread, I really have no idea and can't confidently answer, you would probably need info from one of the ye olde maintainers like reduz (if it isn't in the docs). Whether that documentation was written before a split into single-safe and single-unsafe I don't know, and agree it is rather vague.

That sounds promising! But yeah, I'll see if I can get extra confirmation first before committing to using it :+1:

Just as an update, I've tried using single-safe with my project multiple times to see if it crashes, and thankfully it hasn't crashed once. That, plus the fact that when I tried to use single-unsafe it immediately crashed the game, means I'm very confident I can use the single-safe model as a workaround for this issue. :+1:


i need video

Problem encountered on https://dotnet.microsoft.com/en-us/learn/aspnet/hello-world-tutorial/modify
Operating System: windows
Provide details about the problem you're experiencing. Include your operating system version, exact error message, code sample, and anything else that is relevant.

This tutorial no longer exists but the idea of having end-to-end tutorials for these is still in the backlog.


HTTP2 should coalesce contiguous received DATA frames

For larger payloads they are often split into 16k chunks based on the max allowed frame size setting. Even if these chunks are contiguous for a stream we report them individually to Http2FrameListener which can cause sub-optimal interactions with the flow-controller if the application returns bytes based on each chunk individually.
Given a flow-control window of 64k, a caller could immediately issue 4x 16k frames on the wire. If a  recipient proccesses each one separately and returns bytes to the flow controller for each frame received the current implementation will send a WINDOW_UPDATE returning 32k to the remote side after processing the first two frames. If the other side needs to send another 64k it cannot, it sends two 16k frames and receives another 32k back which allows the final two frames to be sent.
I suggest that if we read a contiguous sequence of frames of the wire for the same stream we treat it as a single DATA frame when reporting up to the application layer which can then release flow-control window in a more efficient fashion. This would also help if the DATA is shipped across a thread boundary.
@nmittler @Scottmitch @ejona86

@louiscryan, in your example, did you intend to say the sender initially sends 3x 16k + 16k-1 ? In your current example as soon as the initial 64k is processed locally WINDOW_UPDATES return the entire 64k, albeit in two 32k WINDOW_UPDATES.
From my current understanding, the request seems misguided and maybe even a mis-feature. You don't want WINDOW_UPDATES to be batchy, as that means you are under-utilizing the network link (you are only using it half the time). Instead, you hope for half the window size to be in transit and the other half to be ACKs going the other direction. Looking at that a different way, if you are able to "receive" 64k all in one read, then either 1) your window size is too small for the network link or 2) you can't keep up with the flow of traffic. Neither problem should be solved by coalescing DATA frames.
Thread boundary optimizations need other solutions, as this solution does not handle merging HEADERS and DATA.

I think there is still significant benefit here.
If returning bytes to the flow-controller is being done on the network thread then with the current behavior we will delay the flush of the window update until channelReadComplete so that is already batched. Not only that but consumption of the data frames following the trigger to window update which has now occurred is not acknowledged back to the remote side until another read occurs.
If returning bytes to the flow-controller is done on a separate thread in a naive / simplistic way (i.e separate call backs per DATA frame read) then we incur separate flushes. In this case I agree timeliness matters with returning bytes as they are processed but the cost of the N context switches and flushes may outweigh any potential end-to-end latency benefit. Benchmarking would be useful to see impact in this case. This would matter for single-payload responses where parsing it as a unit on end-of-stream is the preferred choice.
Largely the proposal here is to address issues where max frame size < window size, Optimization of window size itself is an entirely separate issue.

It seems you are conflating a problem we have in gRPC with a problem in Netty. That seems like it should be solved by our code, and I see nothing that would prevent us from doing so (buffer until channelReadComplete(), then send frames to other thread).

@louiscryan and I discussed offline. He is interested in combining DATA frames when 1) they are contiguous in the same ByteBuf, 2) for the same stream, and 3) later frames are complete. The primary goal is to promote smaller frames into larger frames to gain the lower overhead advantages of larger frames without actually negotiating them. This sounds fine to me, with the above restrictions.
I was mainly concerned this was for multithreading and WINDOW_UPDATE optimization, which would be inappropriate rationale in my mind.

1 - I was looking at implementing something like a sliced buffer except
that it could represent more than one subsection of the underlying buffer
as CompositeBuffer is a little heavyweight and has different retention
behavior to slice which we are currently using. The alternative as you say
is to broaden the listener interface to receive more than one slice. If
we're open to that API change I could take a look at doing that
2 - Agreed. I think we'll just end up adjusting the connection window size
to compensate
On Thu, May 7, 2015 at 11:24 AM, Scott Mitchell<EMAIL_ADDRESS>wrote:

@ejona86 https://github.com/ejona86 @louiscryan
https://github.com/louiscryan - Sounds like you have hashed this out?
I'm still not exactly sure what changes are being suggested or what the
associated overhead is to track what it seems like are additional
metrics....but looking forward to a PR :) However I have a few questions:

If the concern is a Http2FrameListener is returning bytes in chunks
as they are received couldn't we make this Http2FrameListener
"smarter" to delay how/when it returns bytes? Of course if this can be done
relatively cheaply and has good "general" characteristics it may make sense
to put it in the flow controller itself...
Optimization of window size itself is an entirely separate issue.
agreed there are a lot of variables involved. However it seems related to
the issue you describe. Have you explored this option, in combination with
adjusting the window update ratio
https://github.com/netty/netty/blob/master/codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2LocalFlowController.java#L180
?

—
Reply to this email directly or view it on GitHub
https://github.com/netty/netty/issues/3737#issuecomment-99968173.

@louiscryan - Can you pseudo code the API change(s) you are proposing?

Instead of coalescing the DATA frames how would folks feel about coalescing the window-updates on flush? i.e. returning bytes to the flow-controller doesn't trigger a write of a window update immediately, instead the controller is marked stale, if more bytes are returned then it just accumulates until its told to flush a window update.
In the typical case where we process all reads (and return of their associated bytes) in the event loop this would work pretty well.

@louiscryan - Sounds reasonable.  So are you suggesting adding another method onto the flow controller which does something like writeAndFlushAccumulatedWindowUpdates?  Then we will allow users to call this, and we will call it by default when we are flushing?

Yup, something along those lines. I want to run some benchmarks first to
see if that kind of change has any meaningful benefit vs varying the window
update ratio.
On Mon, May 18, 2015 at 10:56 AM, Scott Mitchell<EMAIL_ADDRESS>wrote:

@louiscryan https://github.com/louiscryan - Sounds reasonable. So are
you suggesting adding another method onto the flow controller which does
something like writeAndFlushAccumulatedWindowUpdates? Then we will allow
users to call this, and we will call it by default when we are flushing?
—
Reply to this email directly or view it on GitHub
https://github.com/netty/netty/issues/3737#issuecomment-103148691.

I think this is done... @louiscryan please reopen if this is not the case.


fix(prometheus): regexp handling should comply with PromQL

Closes #19831

@davidby-influx could you take a look?


Suggestions for future versions?

After the latests commits I'm running out of ideas of what to improve and would like to hear if anyone has any suggestions for future versions. For further speed improvements, I can see the possibility of adding functionalities for uploading images that are not necessarily in floats, using half precision floats for storage and matching of SIFT vectors, as well as projecting vectors to a lower dimension, similar to PCA-SIFT. In most practical scenarios though, gaining a fraction of a millisecond doesn't help much, since there is much more around it that is more important. Thus the nature of the end application becomes more important than the actual feature extraction code.

Maybe cuda affine sift?

You mean [Yu & Morel, 2011], not [Mikolajczyk & Schmid, 2002], right? Do you have a feeling for how many angles you need to test in practice?

First question: yes.
Second question:
int ml = 6; //max, 3 works fine for most pictures.
for(int tl = 1; tl < ml; tl++)
{
double t = pow(2, 0.5*tl);
for(int phi = 0; phi < 180; phi += 72.0/t)
{
// extract sift points...
}
}
41 angles if ml=6.
I restrict total sift point number to 16000, other wise matching costs too much time.

It's really a brute force method and I'm not sure it's the most effective one. The DoG responses might be more invariant to rotations than the descriptors, which means that just to detect points, you could use a sparser sampling of angles. Once you have detected a DoG point, you then do some further sampling of angles for the descriptor. How much overlap do you have of points from different angles, but at exactly the same location in the original image? Do you prune these points or do you keep them all through the matching and then possibly prune afterwards? On the other hand, even with the current version, a brute force method might be sufficient in most cases, in particular if some optimisations are done for image rotation and buffering of feature data. Getting fast enough matching should become a greater concern and for that some kind of pruning might become important.

Cuda Stream support?

What about OpenCV interoperability?


Search for pending aggergate alerts before starting new one

Fixes a bug where if an aggregation has been started, restarting elastalert would always start a new aggregation.
Now, before when a new aggregation starts, we will query for a future alert event that hasn't been set. If we find one, use it's alert_time and _id for the aggregation.
Updated existing tests but did not add any tests for this case specifically. I've tested this manually by starting an aggregation then restarting elastalert and verifying subsequent alerts were added to the original.

lgtm, after conversation off-thread


clean HTML to reduce size, fix text summary

the only reason that the HTML is included in the responses is because it contains semantic/structural information that the text summary doesn't. Something like lynx or any HTML reader applies the default meaning of the HTML tags, which gives the page structure
Also, the text summary breaks anything that is ascii-art like, i.e. it strips each line of any whitespace so that breaks a lot of info

Remove unnecessary tag/attributes from the HTML (e.g. class names), after readability has done its thing, remove any items which are paragraph/div like, but have no content
Figure out how to handle the parsing from HTML -> text better than iterating through all text nodes. is some other tool/library/pandoc useful here?

Instead of trying to parse the cleaned HTML into text here, that should either be a separate library written by me, or someone else
Currently, replaced the example in the README to use lynx, which is a possibility

Yeah, I think it'd be best to have this just provide the interface to cache things, instead of trying to add every feature/html minifying things -- better to sweep over the directory with something that can do that nicer instead of trying to do it all at request time


Fix NuGet fallback folder packages

Creates a Godot.Offline.Config file to configurate NuGet with Godot's fallback folder. This is easier because now we can assume we can override the entire file since user config will likely be in the default NuGet.Config file or an additional *.config file.

See https://docs.microsoft.com/en-us/nuget/consume-packages/configuring-nuget-behavior#additional-user-wide-configuration

Ensure the NuGet fallback folder is created at the same time it is added to the NuGet configuration so future builds don't fail.

Fixes https://github.com/godotengine/godot/issues/44532

Add GodotSharp and GodotSharpEditor packages to the fallback folder.
Add .nupkg.metadata file to packages in fallback folder.

This file seems to be necessary, without it building projects offline was failing to resolve the packages for me with error NU1100. I could not find version 2 of the metadata file spec but I copied what nuget add -Expand creates.

:warning: I'm still unable to resolve the Godot.SourceGenerators package using the fallback folder and it seems to be related to using a floating version because using the exact package version works:
https://github.com/godotengine/godot/blob/5803a1ddc5024bcea6fa5482bee206ccac94d62e/modules/mono/editor/Godot.NET.Sdk/Godot.NET.Sdk/Sdk/Sdk.targets#L20
Here's the full error I get:
Build FAILED.

       "/media/raulsntos/Data/GodotProjects/TestProject/TestProject.sln" (Restore target) (1) ->
       (Restore target) ->
         /media/raulsntos/Data/GodotProjects/TestProject/TestProject.csproj : error NU1100: Unable to resolve 'Godot.SourceGenerators (>= 4.0.0-0)' for 'net6.0'. [/media/raulsntos/Data/GodotProjects/TestProject/TestProject.sln]

    0 Warning(s)
    1 Error(s)

:warning: I'm still unable to resolve the Godot.SourceGenerators package using the fallback folder and it seems to be related to using a floating version because using the exact package version works:

But AFAIK this worked for you with the local NuGet source that's needed during development, right? I think we should probably create a local source instead of a fallback folder.

But AFAIK this worked for you with the local NuGet source that's needed during development, right?

Yeah, it works with a local source but not when it's a fallback folder. No idea why. This issue is the reason I'm keeping this as a draft.

I think we should probably create a local source instead of a fallback folder.

I don't really know what that implies, other than the difference in precedence. As described in the nuget.config documentation a source would be used after the fallback folder and in the order they are specified (but file sources before http sources). Since our local source would be a file source it would still be used before the nuget.org source which is an http source so I guess nothing would change.

I meant that if it doesn't work with a fallback folder, but it does with a local source, then this class should be creating a local source instead and adding that to the config file.

The Godot.SourceGenerators is referenced using a floating version to avoid having to update Godot.NET.Sdk for every update of the source generators (see https://github.com/godotengine/godot/pull/55597#issuecomment-986199953), but since we'll be removing the fallback folder in the future we could undo it and use the specific version number as a temporary solution for the few alphas/betas until we publish the packages to nuget.org.

Thanks!


Fixed tile modifier issue for NV12 format

If we are using I915_FORMAT_MOD_Y_TILED which is needed for
NV12 format then modifiers need to be enabled which can be passed
as flags argument to ioctl.
Issue: None
Test: Manually
Signed-off-by: Sodhi, Vunny<EMAIL_ADDRESS>

Thanks @dmitryermilov for merge.

Thanks @dmitryermilov for merge.

I shall thank you:)


Improper casing for gradients.

When converting an SVG from it's normal to React the casing for Gradient's break.
EX.
<linearGradient id="a">
      <stop offset="0" stop-color="#fff"/>
      <stop offset="1" stop-color="#f15770"/>
    </linearGradient>

becomes

<lineargradient id="a">
      <stop offset="0" stopColor="#fff" />
      <stop offset="1" stopColor="#f15770" />
</lineargradient>

and gradienttransform => gradientTransform

Thanks, will take a look this week.

@ryanlittle - still maintained, I completely rewrite the transformer, will be released in the following days.


feat/dependencies

This PR includes:

The initial set of dependencies the project will need were added to the pubspec.yaml file.

LGTM!


[tests] Test that Picker selection is updated correctly

Don't merge this yet. The tests catch a new bug and will only pass once the bug is fixed.
A React pull request broke the Picker: https://github.com/facebook/react/pull/6572
This pull request adds a test so that we prevent breakages like this in the future.
PickerAndroidExample in the UIExplorer before the breakage (video): https://vid.me/h5Rg
PickerAndroidExample in the UIExplorer after the breakage (video): https://vid.me/atFc
Test plan
./scripts/run-android-local-integration-test.sh
The test is failing, we can only merge this once React is fixed.

By analyzing the blame information on this pull request, we identified @bestander and @satya164 to be potential reviewers.

@mkonicek updated the pull request.

@mkonicek updated the pull request.

Tests passed: https://circleci.com/gh/facebook/react-native/6636

@bestander It looks like those tests run quite slowly - one minute per the simple picker test case, all integration tests took 13 minutes. Could this be because of the HW acceleration disabled?
@facebook-github-bot shipit

Thanks for importing. If you are an FB employee go to Phabricator to review.

@mkonicek HW acceleration is indeed disabled.
That is the sad truth of virtualized CI environments, I don't think we can enable it unless we run tests on a non VM test environment.
I am planning to enable parallelization and have all instrumentation tests run in parallel with the other tests and am open to suggestions.

@bestander 👍 Ah I didn't realize that, good to know. Parallelization sounds good.


Fix not priority

Not should have priority over || and &&.
Consider the contract regression/not-priority.sol:
contract NotPriority {
    function pay() {
      msg.sender!1
    }
}

and consider the following property:
property p1_live {
    Forall xa
    [
      not false || true
        ->
      Exists tx [1, xa]
      [
        ((app_tx_st.balance[xa] == st.balance[xa] + 1000))
      ]
    ]
}

The correct parenthesization of not false || true should be (not false) || true, which is true. Therefore, the property should be false since the contract could not have enough balance to pay xa.
Instead, the tool returns:
PROPERTY: out/smt2/p1_live
LIVE

This is only possible is not false || true is paranthesized as not (false || true) = false: in this way, the property is trivially true since the antecedent of the implication is false.
Note that by manually parenthesizing the expression, the verifier's outputs is correct:
property p2_live {
    Forall xa
    [
      (not false) || true
        ->
      Exists tx [1, xa]
      [
        ((app_tx_st.balance[xa] == st.balance[xa] + 1000))
      ]
    ]
}

PROPERTY: out/smt2/p2_live
NOT LIVE (COUNTEREXAMPLE FOUND AND STORED IN out/smt2/p2_live/counterexample.txt)

Commit 41f357d fix this issue