Create Mappings Extension

Currently, the ServiceBinding type contains a mappings element that allows the creation of mappings from the contents of a ProvisionedService’s Secret to a new Secret projected into an Application.  The inclusion of this element, while reducing the number of resources that a user might need to create, had some significant downsides.

The ServiceBinding reconciler needed to have permissions to read existing Secrets.
A single fixed set of mapping syntaxes had to be defined
If a platform wanted additional or alternate mapping syntaxes they had to create their own ServiceBinding reconciler and ensure that only a single implementation was installed.

Proposal
The mapping element should be removed from the ServiceBinding resource and its functionality should be moved into a set of discrete resource types devoted to this mapping.  For example, instead of defining
apiVersion: service.binding/v1alpha2
kind: ServiceBinding
metadata:
  name: account-service
spec:
  application:
    apiVersion: apps/v1
    kind:       Deployment
    name:       online-banking
  service:
    apiVersion: com.example/v1alpha1
    kind:       AccountService
    name:       prod-account-service
  mappings:
  - name:  accountServiceUri
    value: https://{{ urlquery .username }}:{{ urlquery .password }}@{{ .host }}:{{ .port }}/{{ .path }}

a user would define multiple resource types
apiVersion: service.binding/v1alpha2
kind: ServiceBinding
metadata:
  name: account-service
spec:
  application:
    apiVersion: apps/v1
    kind:       Deployment
    name:       online-banking
  service:
    apiVersion: mapping.service.binding/v1alpha2
    kind:       GoV1Template
    name:       mapped-prod-account-service

---
apiVersion: mapping.service.binding/v1alpha2
kind: GoV1Template
metadata:
  name: mapped-prod-account-service
spec:
  service:
    apiVersion: com.example/v1alpha1
    kind:       AccountService
    name:       prod-account-service
  mappings:
  - name:  accountServiceUri
    value: https://{{ urlquery .username }}:{{ urlquery .password }}@{{ .host }}:{{ .port }}/{{ .path }}

Benefits
This change would immediately improve the permissions situation removing the need for the ServiceBinding reconciler to have permissions to read Secrets.  Instead a user could elect whether to add mapping behavior or not based on whether they felt the value/risk of having a third-party controller with access to Secrets was worth it.
If the user wanted mappings, but didn’t trust our implementation this change also provides a point of extensibility allowing a user to install another implementation that they trust more or even implement a mapping reconciler themselves.
That extensibility isn’t just beneficial to users concerned with security either.  This same point of extensibility also allows the introduction of an arbitrary number of mapping syntaxes.  While we might have implementations for OLM, Go V1 Templates, and more, the project wouldn’t be gatekeepers for platform-specific or user-specific templating syntaxes.  Each user could implement or install a mapping controller that suited their needs.
A design that moves mappings out so that they are just another implementation of the ProvisionedService duck type also results in architectural benefits.  It improves the separation of concerns (ServiceBinding only cares about performing the binding, not also doing an inline mapping), it simplifies the mapping of the most critical controller, and it enables composability of mappings.
apiVersion: service.binding/v1alpha2
kind: ServiceBinding
metadata:
  name: account-service
spec:
  application:
    apiVersion: apps/v1
    kind:       Deployment
    name:       online-banking
  service:
    apiVersion: mapping.service.binding/v1alpha2
    kind:       TypeProvider
    name:       typed-prod-account-service

---
apiVersion: mapping.service.binding/v1alpha2
kind: TypeProvider
metadata:
  name: typed-prod-account-service
spec:
  service:
    apiVersion: mapping.service.binding/v1alpha2
    kind:       GoV1Template
    name:       mapped-prod-account-service
  type: my-account-service-type
  provider: my-company

---
apiVersion: mapping.service.binding/v1alpha2
kind: GoV1Template
metadata:
  name: mapped-prod-account-service
spec:
  service:
    apiVersion: mapping.service.binding/v1alpha2
    kind:       JSONPath
    name:       extracted-prod-account-service
  mappings:
  - name:  accountServiceUri
    template: https://{{ urlquery .username }}:{{ urlquery .password }}@{{ .host }}:{{ .port }}/{{ .path }}

---
apiVersion: mapping.service.binding/v1alpha2
kind: JSONPath
metadata:
  name: extracted-prod-account-service
spec:
  service:
    apiVersion: com.example/v1alpha1
    kind:       AccountService
    name:       prod-account-service
  mappings:
  - name:  username
    path: .status.credentials.username
  - name:  password
    path: .status.credentials.password
  - name:  host
    path: .status.endpoint.host
  - name:  port
    path: .status.endpoint.port
  - name:  path
    path: .status.endpoint.path

Finally by moving this feature, for which each platform has diverging needs, out of the reference implementation it reduces the need to have multiple implementations of the specification which reduces the possibility of collisions within a given cluster.
Outcomes
There are a couple of options for what happens to the mapping functionality after it is extracted.
First, it could become a purely community concern.  Each platform vendor would be free to implement their own controllers for their own mapping styles.  This option provides ultimate flexibility at the expense of interoperability.
Second, a set of mapping types could be included in the project implementation, but not as part of the specification.  This would not preclude vendors from adding their own mapping styles in their platforms.  This option maintains much of the flexibility of the previous option while adding some level of interoperability for commonly used mapping needs.
Third, a set of mappings could be included in the specification as well as in the implementation of the specification.  This would not preclude vendors from adding their own mapping styles in their platforms.  This option creates the highest level of interoperability at the expense of flexibility.

My opinion is that mappings as currently defined in the spec does not add very much value, given that the scope of input is limited to the currently exposed Secret - so it's just combining and transforming data that is already available to the application.  So +1 in doing something about this. 😄
A new resource similar to the JSONPath sample that @nebhale proposed above would be interesting as it allows the scope to be anything in the source service:  .spec, .status, .data, etc, so you can truly add extra value beyond the currently exposed Secret - or in some cases where a Secret is not exposed this feature would create a new one.
In some ways this is the reverse of the binding secret generation strategies, which may be good for cases where the source service's community has no interest in updating their CR.
I think it would be helpful to have, as an extension, at least one of such synthetic mappers (CRD for JSONPath makes sense), so that there's some level of interoperability between opted-in implementations.  For example:  if we have a JSONPathCR for Strimzi we could re-use that between environments - as long as the implementation supports this extension.

I think it would be helpful to have, as an extension, at least one of such synthetic mappers (CRD for JSONPath makes sense), so that there's some level of interoperability between opted-in implementations.

Do you see value in having different implementations of spec'd mappers? If there are semantic differences in the mapper that would justify distinct implementations, then the value (portability) of them being spec'd is lessened.

I think the implementations would be the same - or at least yield the exact same result.

@arthurdm What's your preference of three possible outcomes?  For reference, in the meeting I like #2, but almost everyone else voted for #1 😆

I think I would like option 2.5 😄
Have a single CRD for mapping in the extension part of the spec - so it's not required, but if supported by a vendor it will be consistent.
An example (morphed from @nebhale 's examples) of a CR:
apiVersion: mapping.service.binding/v1alpha2
kind: CustomProvisionedService
metadata:
  name: extracted-prod-account-service
spec:
  type:  jsonpath
  service:
    apiVersion: com.example/v1alpha1
    kind:       AccountService
    name:       prod-account-service
  mappings:
  - name:  username
    value: .status.credentials.username

So the type of supported template is push into .spec.type so that a single CRD can cover multiple scenarios, and .spec.mappings consistently has {name, value} pairs.

I believe the "single resource type, multiple type: values" leads us down to needing multiple implementations of the project again.  If your platform wants another mapping style, you have to provide a new reconciler for mapping.service.binding/v1alpha2:CustomProvisionedService that will collide with the SIG-provided implementation.  Alternatively, having different resources for each mapping style allows disjoint contribution.

good point @nebhale - I haven't thought about the reconciler implications.
My preference is for a spec extension to define a set of popular CRDs (JSONPath and Go templates may be good ones to start with).

Hi @nebhale, thanks for including me in this discussion!
#151 proposes to be able to define static values in the Provisioned Service's CRD by adding:
 “service.binding/key”: "value"
This seems be a requirement for almost all Provisioned Service adopters that will specify a type and provider.  Kafka is one example. There are current workarounds already provided by the specification but #151 proposes a simple solution to a simple problem. I think this is important when considering specification adopters.
In this proposal, as you mentioned, this would be addressed in the following way:
apiVersion: service.binding/v1alpha2
kind: ServiceBinding
metadata:
  name: account-service
spec:
  application:
    apiVersion: apps/v1
    kind:       Deployment
    name:       online-banking
  service:
    apiVersion: mapping.service.binding/v1alpha2
    kind:       TypeProvider
    name:       typed-prod-account-service

---
apiVersion: mapping.service.binding/v1alpha2
kind: TypeProvider
metadata:
  name: typed-prod-account-service
spec:
  service:
    apiVersion: com.example/v1alpha1
    kind:       AccountService
    name:       prod-account-service
  type: my-account-service-type
  provider: my-company

---

In this solution, the knowledge required to bind a Provisioned Service to an Application is greater:

Knowledge of TypeProvider and variants
Knowledge  that the type and provider fields not exposed by the Provisioned Service
Knowledge that application needs the type and provider fields

Whereas with #151, the problem would be addressed by creating a regular ServiceBinding:
apiVersion: service.binding/v1alpha2
kind: ServiceBinding
metadata:
  name: simple-binding
spec:
  application:
    apiVersion: apps/v1
    kind:       Deployment
    name:       online-banking
  service:
    apiVersion: com.example/v1alpha1
    kind:       AccountService
    name:       prod-account-service

Therefore, when considering this use case, as a developer,  I would rather use the approach described in #151 than the one described here.
To circle back to the original issue of moving mappings: I agree with the problem but I might not agree with the solution. The mapping problem is a vaste issue and can quickly become a rabbit hole especially if one chooses to solve it in yaml. The current state of the specification proposes a "lightweight" solution to the mapping problem which leverages Go templates.
Beyond "Go templates" use cases, I think the mapping problem should be the responsibility of the application itself. For example, in Java, frameworks, such as Quarkus or Spring, will already read binding properties for you and create Database connections or Kakfa connections with the specification as it is today. This is where the  "mapping" between binding properties to service connections is done.
You also added concerns about interoperability (which I share). That and the added complexity this adds to create a ServiceBinding are important concerns when considering adoption from a Provisioned Service/ Application developer perspective. Hence the benefit of such approach isn't so clear compared to the application/framework itself doing the more advanced mapping.
At the very least, I think #151 and #145 should be treated separately?
Let me know what you think,
Thanks !
ps: sorry for the long post...

The first half of this move (the removal from the core spec) has been completed.  The issue is open to track the creation of one or more extension specifications that contain the removed functionality.

I proposed a mapping extension: #221


Master

The current do-notation was more like applicative-do-notation rather
than monadic-do-notation. Adding bind(..) lets you do something that
depends on the result of something else.

Damn, I tried to resolve a conflict locally, and pushed it. So your changes are actually already in the repo, but GitHub still won't allow me to merge here. Would it be okay if you pull the changes, and I close the request?  Should I push it and do another pull request?


[cluster-test] Add a teardown method for ClusterTestRunner

Summary
Add a teardown method for ClusterTestRunner which scales down the cluster to size 0.
Depends upon https://github.com/calibra/libra-ops/pull/527
Motivation
Now that cluster-test also performs autoscaling, it can conflict with the cluster-autoscaler running on the cluster. This has led to a couple of failures in cluster-test. There is no way to coordinate these two processes, so its easier that cluster-test does both the scaling-up and scaling-down.
One downside of this is that subsequent runs on the cluster-test will have to scale-down and scale up everytime, but the average scale-up overhead is only 40-50 seconds, so that should be fine
Test Plan
Ran single experiment and ci suite

@bors-libra delegate+
What is the implication if process just terminates without going into tear_down?
Will it just leave resource hangin, or will subsequent run fail too?

:v: @ankushagarwal can now approve this pull request

It will leave just the autoscaling group sized up. Subsequent run will not fail, it will correctly set the asg group size during scale up and scale down

@bors-libra r=andll

:pushpin: Commit 0a9a89f has been approved by andll

:hourglass: Testing commit 0a9a89f83f24c6fe7c2055ab101f968132a3b40d with merge fe282088ade2bfcde757d1b85b37be1fb7cf4892...

:sunny: Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow
Approved by: andll
Pushing fe282088ade2bfcde757d1b85b37be1fb7cf4892 to master...


Add exponential backoff

This PR as a stage for https://github.com/einaregilsson/beanstalk-deploy/pull/74

LGTM. Could consider converting promise chaining to async/await in deployNewVersion for thread blocking if you needed that at some point and for consistency, but looks like it doesn't matter now. If you ran a linter there would likely be a lot of things to fix, but again, not sure if that matters here.

Thanks for the feedback!
I'm new to most of this so I took tips from the net.
We'll see what https://github.com/einaregilsson/beanstalk-deploy has to say about consistency and - yeah - for the linting, same deal. I'm trying to minimize the diff a little.

I need to replace the date logic for DescribeEvents to stop repeating events, but otherwise we have a pass here: https://github.com/rewindio/foghorn/runs/4526803270?check_suite_focus=true
I don't see any rate limits, which concerns me, so I'll be test driving it a bit more.


Moved to Gridcoin-Community Org!

Hey,
We're moving the 'gridcoin-site' repo to the gridcoin-community org repo: https://github.com/gridcoin-community/Gridcoin-Site/
So don't submit issues nor pull requests to here, but rather towards the gridcoin-site repo now.
Thanks

@grctest is it possible to transfer ownership of this repo? That way everybody would get redirected and only 1 repo would exist.
You would have to first merge back all changes from the fork, then delete the fork.


Features/integrate unity py

Purpose
Integration of unity-py for jobs tutorial notebook.
Proposed Changes

Updated imports
Removed ad-hoc login and relying on login functionality that is now a part of unity-py
Updated notebook cells that educate users about fetching all process, executing a job, checking the status of a job, getting the results of a job, getting a list of jobs for a process, and dismissing jobs.

@rtapella When reviewing these notebook changes, target the develop branch of the unity-py repo to install the package in your jupyterlab workspace.


fix(qwik-city): do not write into a destroyed stream

Overview

What is it?

[ ] Feature / enhancement
[x] Bug
[ ] Docs / tests / types / typos

Description
Check if the response is already destroyed similar to checking if the response is closed.
PR https://github.com/BuilderIO/qwik/pull/5074 fixed some of the Error [ERR_STREAM_DESTROYED]: Cannot call write after a stream was destroyed errors but sometimes closed is undefined and destroyed is true.
If checking for destroyed, I don't know if that makes checking for closed redundant so I kept the closed check.
Use cases and why

One use case

Another use case

Checklist:

[x] My code follows the developer guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] Added new tests to cover the fix / functionality

Not sure if this fix is enough. I've been testing this PR in production and now i'm seeing error


How to configure sorting order?

With the way you handle RegEx, I was able to:

Sort xml files.
Also be able to sort class AND classes.

I achieved this using the following configuration:
"tailwind-raw-reorder.classRegex": {
  "xml": [
    [
      "[class|classes]=(([\"'`])(?:(?:[^{}<>](?!\\2))|\\\\\\2)+[^{}<>])\\2",
      "[\"'`]([^]+)"
    ]
  ]
}

One thing I noticed is the sorting order difference between your extension and Headwind:
// Tailwind Raw Reorder
class="rounded-16 mx-auto h-16 w-16"
// with FontAwesome classes
class="fas fa-phone-alt mr-1 flex-1 text-xs text-gray-600"

// Headwind
class="w-16 h-16 mx-auto rounded-16"
// with FontAwesome classes
class="flex-1 mr-1 text-xs text-gray-600 fas fa-phone-alt"

Did you notice how the spacing and sizing classes come first in the list in Headwind?
How can I configure Tailwind Raw Reorder to sort them in the same way?
Thank you!

@macCesar This repo uses the approach that the prettier plugin does. That is it hooks into your local copy of tailwind (or the included dependency if the local tailwind can't be found) and uses it to assign orders. This gets around the issue with the Headwind where you had to constantly maintain your list of selectors and headwind had no support for computed selectors "w-[5px]" for example. You would always have to add these to your list of selectors. The benefit of the tailwind established order is that later selectors override earlier ones if there is any overlap in properties assigned.
Custom class names are sorted first so they don't get lost at the tail end of a long list of classes.

Thanks @Trapfether ... 👍🏼
I got used to the new sorting order!! 😀


Add network metadata support for vmware metadata service

Added parsing of vmware  metadata as NetworkDetailsV2
Using NoCloudNetworkConfigV1Parser for parsing the data

Functionality is analog to cloud-init as per https://cloudinit.readthedocs.io/en/latest/reference/datasources/vmware.html#instance-data-and-lazy-networks and https://github.com/canonical/cloud-init/blob/4f60ff099eb0a6f57595706f4d34cf713d3c02b1/cloudinit/sources/DataSourceVMware.py#L275

Hello,
We are currently using opendev for patches:
https://review.opendev.org/q/project:x/cloudbase-init
How to create an account and contribute to:
https://docs.openstack.org/contributors/common/setup-gerrit.html
Thank you,
Adrian Vladu.

Hi @Eifoen . This feature is already followed in #107

Hi @ader1990
Could you please close this PR ? This feature was finally brought by f0fe66b in release 1.1.5.


New ?codes= option to simulate HTTP errors from echo server

This is a re-write of the ?codes= injection feature from last week.
The echo server output includes its hostname
If a request to the echo server HTTP includes ?codes=code[:chances],... the server might send a response other than HTTP 200.  This is for testing code that retries, but where we don't need to track the exact number of retries.
For example, ?codes=500:90,200:10 returns 500 90% of times and 200 10% of times
For example, ?codes=500:1,200:1 returns 500 50% of times and 200 50% of times
For example, ?codes=501:999,401:1 returns 500 99.9% of times and 401 0.1% of times.
For example, ?codes=500,200 returns 500 50% of times and 200 50% of times

Jenkins job manager/presubmit passed

Jenkins job manager/presubmit passed

Jenkins job manager/e2e-smoketest passed

Jenkins job manager/presubmit passed

Jenkins job manager/e2e-smoketest passed

Jenkins job manager/presubmit passed

Jenkins job manager/e2e-smoketest passed


python3Packages.aiohomekit: 0.2.67 -> 0.3.0

Motivation for this change
Update to latest upstream release 0.3.0
Change log: https://github.com/Jc2k/aiohomekit/releases/tag/0.3.0
Things done

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

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

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 128284 run on x86_64-linux 1

3 packages built:

home-assistant
python38Packages.aiohomekit
python39Packages.aiohomekit

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
Result of nixpkgs-review pr 128284 run on x86_64-linux 1

3 packages built:

home-assistant
python38Packages.aiohomekit
python39Packages.aiohomekit


LibWebView: Add Startpage as a search engine

Added Startpage to the list of search engines.

Hello, to pass the check you have to change your commit message using git commit --amend or the Git GUI in your editor, rather than the PR title


Extend library to include the remaining OSCAL Models

There is a known hard-coded value for component-definitions currently. We should be able to generate Golang structs for the OSCAL models such as SSP, etc.
go-oscal should be able to account for each model independently. Also considerations for generating structs for all models (foreach schema in this directory) and the possibility of de-duplicating structs across models if present.

Need to consider the de-duplication of types and extending the current implementation to handle both generating all of the models (deduplicated) and single models without requiring the generation of all models.

One solution for evaluation:
Following extending oscal one solution is to link the implemented-requirement.link to an item in the backmatter.
In the implemented requirement, we can reference to the backmatter via UUID and a text identifier for Lula validation.
This would allow a single validation to be re-used across the document.

[ ] Catalogs
[ ] Profiles


Allow LOS-Manager to see poll progress

Adjust poll progress bar to be visible for LOS-Manager.
Cleans up redundant permission asking
Adds push CD to progress bar to react better on permission changs

@FinnStutzenstein @jsangmeister there is an open requirement in this PR
Backend / Autoupdate are only sending poll-voting updates which are required to see the poll progress to users who have their corresponding poll.can_manage. We would now need to also include LOS-Manager to also receive updates to poll votes, so they can see when the voting is over.

users with agenda.can_manage_list_of_speakers now receive votescast in the autoupdate even if the user cannot manage the motion/assignment poll: https://github.com/OpenSlides/openslides3-autoupdate-service/pull/166


pubsub.snssqs: Support regions in other AWS partitions

Fixes #1907
Signed-off-by: Clare Liguori<EMAIL_ADDRESS>Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[x] Code compiles correctly
[x] Created/updated tests
[ ] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

Will only merge once a docs PR has been created.

@mukundansundar @berndverst I don't think a docs update is needed here. This doesn't change the component format, it just determines the partition ID based on the current metadata.

@clareliguori is correct, this PR doesn't introduce any changes to metadata or the existing format.

Sounds good. I was going off of @mukundansundar 's review. Agreed and understood that no docs are required.


Some UI elements on iPad with Smart Keyboard disappear

See video for example.
https://user-images.githubusercontent.com/10354268/117677209-2813b600-b1a6-11eb-9df7-b6e490eb3e73.MP4

Fixed in latest build.


Is there a cli to query for consumed artifacts used by a yaml (deployment job) pipeline?

If the issue is to do with Azure CLI 2.0 in-particular, create an issue here at Azure/azure-cli

Extension name (the extension in question)
{
"azure-cli": "2.25.0",
"azure-cli-core": "2.25.0",
"azure-cli-telemetry": "1.0.6",
"extensions": {
"application-insights": "0.1.13",
"automation": "0.1.0",
"azure-devops": "0.18.0",
"front-door": "1.0.14",
"storage-preview": "0.7.4"
}
}
Description of issue (in as much detail as possible)
requirements:

Find out what version of an app service (azure app service) deployed to Azure.  This information should include the build number of the CI build that was deployed to the app service.

Problem:

Querying 'deployment center' in the log using 'az webapp deployment log' returns information of the yaml pipeline (deployment job yaml) which contains the build number of the deployment pipeline.

However, when querying Azure Devops using 'az pipelines build list' command and filtering it based on a build definition id, the list of build results returned showed some has triggerInfo populated and some don't.

Expectation:

The command should always return the triggerInfo or somehow return the information of the consumed artifacts used by the yaml deployment job.

route to CXP team

@hb66772-home Apologies for the late reply. Thanks for sharing this feedback. We will look into this ask and provide an update here once we have more details on this.


Auto nesting sub-queries on $and clauses on joined tables

Is your feature request related to a problem? Please describe.
I'm always frustrated when I need an ordinary query for an entity with two linked entities (m:n relation), but need to switch to query builder and construct nested queries.
Usual cases when usual em.find is not suitable:

Find user with two friends (on a user's profile page I want to see mutual friends for me and the user)
Find a transport company which works in two countries (when I want to find a supplier which can deliver from one country to another, I need a company which works in both countries)
Any filter which allows multiple selection (tags, labels, etc. with m:n relation, and has to find entities having all selected items)

Describe the solution you'd like
I would like to make such queries with usual em.find syntax, e.g.:
const companies = await em.find(Company, {
  $and: [
    { country: { name: 'Canada' } },
    { country: { name: 'Argentina' } },
  ],
});

Describe alternatives you've considered
The current available alternative in mikro-orm is to construct a nested query with QueryBuilder, which is verbose and poorly readable. Also this disallows us to construct more complex queries, each time we need to focus on constructing SQL instead of being focusing on the application logic.
const subquery = em.createQueryBuilder(Company, 'c1')
  .select('id')
  .leftJoin('c1.country', 'c2')
  .where({
    'c2.name': 'Canada',
  });

const companies = await em.createQueryBuilder(Company, 'c1')
  .select()
  .leftJoin('c1.country', 'c2')
  .where({
    id: { $in: subquery.getKnexQuery() },
    'c2.name': 'Argentina',
  })
  .groupBy('c1.id')
  .execute();

I suggest to extend the where parser to detect $and clauses on connected relations and automatically make sub-queries.

I've started working on it, here is my progress:
https://github.com/CareerLunch/mikro-orm/commit/b9ad9b1242ef5e26aa10a1baeb2ad3f1a36e04dd
Please, take a look, maybe you know better place for this change in code.
Also added some functions to Utils, but most likely it won't be used anywhere else, so maybe it's better to place it as local functions? Just wanted to have them tested.

Instead of subqueries, I would rather see multiple joins as discussed on slack. And I believe the place is wrong (maybe not if we want subqueries, but I dont think we want them), this needs to happen in CriteriaNode and its child classes (that is where the mapping happens), definitly not in driver - that layer has nothing to do with this.
Instead of trying to fix the query in driver, you need to "not break it" earlier. CriteriaNode is what handles auto joining and mapping of joins between each other.

One hint for testing, this needs to be resolved also for QB usage - QB itself is handling this via CriteriaNode here:
https://github.com/mikro-orm/mikro-orm/blob/master/packages/knex/src/query/QueryBuilder.ts#L200-L207
In other words, this needs to do the same too:
const companies = await em.createQueryBuilder(Company).where({
  $and: [
    { country: { name: 'Canada' } },
    { country: { name: 'Argentina' } },
  ],
}).getResult();

One more hint: qb.getAliasForJoinPath() is what we use to map those conditions to existing joins. If this method return undefined, it will create new join branch. If we temporarily make this method always return undefined, this test will be passing:
  test('GH issue 2677', async () => {
    const qb1 = orm.em.createQueryBuilder(Book2);
    qb1.select('*').where({
      $and: [
        { tags: { name: 'tag1' } },
        { tags: { name: 'tag2' } },
      ],
    });
    expect(qb1.getQuery()).toEqual('select `e0`.*, `e0`.price * 1.19 as `price_taxed` ' +
      'from `book2` as `e0` ' +
      'left join `book2_tags` as `e2` on `e0`.`uuid_pk` = `e2`.`book2_uuid_pk` ' +
      'left join `book_tag2` as `e1` on `e2`.`book_tag2_id` = `e1`.`id` ' +
      'left join `book2_tags` as `e4` on `e0`.`uuid_pk` = `e4`.`book2_uuid_pk` ' +
      'left join `book_tag2` as `e3` on `e4`.`book_tag2_id` = `e3`.`id` ' +
      'where `e1`.`name` = ? and `e3`.`name` = ?');
  });

I've been playing with this and got it working for the top level $and, trying out more complex cases now. Do I get it right that you would expect this behaviour:
const qb = orm.em.createQueryBuilder(Book2);
qb.select('*').where({
  $and: [
    {
      author: {
        $and: [
          { favouriteBook: { title: 'a1' } },
          { favouriteBook: { title: 'a2' } },
        ],
      },
    },
    {
      author: {
        $and: [
          { favouriteBook: { title: 'a3' } },
          { favouriteBook: { title: 'a4' } },
        ],
      },
    },
  ],
});
expect(qb.getQuery()).toEqual('select `e0`.*, `e0`.price * 1.19 as `price_taxed` ' +
  'from `book2` as `e0` ' +
  'left join `author2` as `e1` on `e0`.`author_id` = `e1`.`id` ' +
  'left join `book2` as `e2` on `e1`.`favourite_book_uuid_pk` = `e2`.`uuid_pk` ' +
  'left join `book2` as `e3` on `e1`.`favourite_book_uuid_pk` = `e3`.`uuid_pk` ' +
  'left join `author2` as `e4` on `e0`.`author_id` = `e4`.`id` ' +
  'left join `book2` as `e5` on `e4`.`favourite_book_uuid_pk` = `e5`.`uuid_pk` ' +
  'left join `book2` as `e6` on `e4`.`favourite_book_uuid_pk` = `e6`.`uuid_pk` ' +
  'where `e2`.`title` = ? and `e3`.`title` = ? and `e5`.`title` = ? and `e6`.`title` = ?');

Hi, that's great!
Yes, it only makes sense for m:n and 1:m and not to m:1, so favouriteBook's clauses should merge.

I've also been playing with this for a while. I updated the code of ObjectCriteriaNode.shouldAutoJoin:
  private shouldAutoJoin(nestedAlias: string | undefined): boolean {
    if (!this.prop || !this.parent) {
      return false;
    }

    const embeddable = this.prop.reference === ReferenceType.EMBEDDED;
    const knownKey = [ReferenceType.SCALAR, ReferenceType.MANY_TO_ONE, ReferenceType.EMBEDDED].includes(this.prop.reference) || (this.prop.reference === ReferenceType.ONE_TO_ONE && this.prop.owner);
    const operatorKeys = knownKey && Object.keys(this.payload).every(key => Utils.isOperator(key, false));
    const primaryKeys = knownKey && Object.keys(this.payload).every(key => {
      const meta = this.metadata.find(this.entityName)!;
      if (!meta.primaryKeys.includes(key)) {
        return false;
      }
      if (!Utils.isPlainObject(this.payload[key].payload) || ![ReferenceType.ONE_TO_ONE, ReferenceType.MANY_TO_ONE].includes(meta.properties[key].reference)) {
        return true;
      }
      return Object.keys(this.payload[key].payload).every(k => meta.properties[key].targetMeta!.primaryKeys.includes(k));
    });

    // here are the added lines
    const relationToMany = [ReferenceType.MANY_TO_MANY, ReferenceType.ONE_TO_MANY].includes(this.prop.reference);
    const isArrayItem = !this.parent.key && Utils.isGroupOperator(this.parent.parent?.key ?? '');

    // return !primaryKeys && !nestedAlias && !operatorKeys && !embeddable;
    return !primaryKeys && (!nestedAlias || relationToMany && isArrayItem) && !operatorKeys && !embeddable;
  }

And this makes the trick but adds extra joins:
// searching authors that have both cheap and expensive books
const qb = orm.em.createQueryBuilder(Author2).where({
  $and: [
    { books2: { price: { $lt: 100 } } },
    { books2: { price: { $gt: 1000 } } },
  ],
});
console.log(qb.getQuery());

select `e0`.* from `author2` as `e0`
    left join `book2` as `e1` on `e0`.`id` = `e1`.`author_id`
    left join `book2` as `e2` on `e0`.`id` = `e2`.`author_id`
    left join `book2` as `e3` on `e0`.`id` = `e3`.`author_id`
    left join `book2` as `e4` on `e0`.`id` = `e4`.`author_id`
where `e1`.`price` < ? and `e2`.`price` > ?

There is something I missed. I'm going to proceed my tests on Monday.

I think I already found the right way to do it, without any side effects. All that's needed is to adjust the getPath method of CriteriaNode to respect indexes in $and clauses (and save such indexes when we create the node structure via factory).
So I don't really need you to work on this more, but I would very much welcome some additional tests.

Yes, it only makes sense for m:n and 1:m and not to m:1, so favouriteBook's clauses should merge.

Both Book.author and Author.favouriteBook are m:1, so in that example there should be no branching, right? But if they would be both m:n/1:m, it would work the way I proposed.

The left joins are not created on nested entities. I'm trying to do something along the lines of:
const qb = orm.em.createQueryBuilder(Author2).where({
  $and: [
    { books2: { genre: { name: { $in: ['Fantasy', 'Murder/Mystery'] } } } },
    { books2: { tags: { name: { $in: ['tag1', 'tag2'] } } } },
  ]
});
console.log(qb.getQuery());

I need a left join on both tags and genre. Any help is appreciated!


Header and button

Added some breathing room for main CTAs, intent is to allow more time/chance for users to linger on them
I think the button without border is still highlighted enough and looks is a bit more modern + in line with the buttons in the Pricing section
Hover state goes brighter instead of darker now so the action is more associated with energy/excitement. The original darker yellow was imported from Tailwind 1 though, so the TW2 darker yellow might not look as dull
Added active state for some depth/interactivity
The email signup form is in the Pricing section, so technically the Samples button/link is a bit redundant

appreciate the great notes!


Peer to Peer Code Review

This issue is created to provide feedback and code reviews on this project

##Good Job @rebaz36
I think your app is OK 👌
No more to add.
Keep working hard 💪 🎉

There is nothing that I can add for the moment to improve your project. You did a great job!


SFS | Expose the date that the status changed in the UI |1|

https://trello.com/c/hP0W5CLX/1229-sfs-expose-the-date-that-the-status-changed-in-the-ui-1
Story:
As a TFRS user, I want to see the date that the status changed for a SFS so that I can keep track of its progress.
Task:
For both BCeID and IDIR users, make the date that the status changed visible within the View page of a SFS (see attached screenshot). This change is only for within the view page of a particular SFS; not within the main table on the main SFS page that shows all of the SFS.

 SFS | Expose the date that the status changed in the UI |1|


Add tox support for testing redshift, bigquery and snowflake

Resolves #316
Description & motivation
This PR make a slight update to the current testing layout to allow dbt Labs to start testing this package as part of our own
release process.
This only adds support for testing with snowflake and redshift.
Adding support for Bigquery will involve updating the secrets and can be done in the next round of changes.
To add additional adapter testing support in the future, you will just need to modify

.github/workflows/ci_dbt_test_package.yml to pass through the env vars
modify profiles.yml to meet the desire var format (example in [dbt-package-testing](https://github.com/dbt-labs/dbt-- package-testing/blob/main/integration_tests/profiles.yml))
supported_adapters.env to list the adapters you want to test
tox.ini to add the commands for the associated adapter tests

I've left your current testing as is to allow you to decide what to do with it.
Why Do We Need These Changes
As explained in #316, by setting up tox as a standard entry-point, the Core development team at dbt Labs can include this package's integration tests (along with other popular dbt packages) as part of our continuous development & delivery of dbt.
Checklist

[ ] I have verified that these changes work locally
[ ] I have updated the README.md (if applicable)
[ ] I have added an integration test for my fix/feature (if applicable)

To get this working I will need the following added as variables instead of secrets:

REDSHIFT_HOST
REDSHIFT_USER
REDSHIFT_PORT
REDSHIFT_DATABASE
SNOWFLAKE_USER
SNOWFLAKE_WAREHOUSE
SNOWFLAKE_ROLE
SNOWFLAKE_DATABASE
BIGQUERY_PROJECT

The following need to be added as secrets

DBT_ENV_SECRET_REDSHIFT_PASS
SNOWFLAKE_ACCOUNT
DBT_ENV_SECRET_SNOWFLAKE_PASS
BIGQUERY_KEYFILE_JSON


Untangle webpack bundles in docs

These files are unnecessarily-optimized, and make automating builds require extra tooling:

docs/js/benchmark-bundle.min.js
docs/js/peg-bundle.min.js
docs/js/test-bundle.min.js

Figure out what's in each of them and do something less complicated.

While we're at it, figure out why there's a copy of mocha vendor'd into docs.

[expletive removed]
he's using bundler, whose docs are in Russian.


PopupMenu.always_on_top error on gui_embed_subwindows = false

Godot version
4.0.1.rc1
System information
Windows10
Issue description
	get_viewport().gui_embed_subwindows = false
	$PopupMenu.always_on_top = true

and
	$PopupMenu.popup(Rect2(pos,Vector2.ZERO))

E 0:00:01:0997   test.gd:18 @ _on_button_pressed(): Windows with the 'on top' can't become transient.
E 0:00:03:0264   window_set_transient: Condition "wd_window.transient_parent == p_parent" is true.
If it's just this, there's actually no problem, but when I add a submenu, there's a real problem.
if PopupSubMenu.always_on_top = false
Hide under "always ontop window"
else PopupSubMenu.always_on_top = true
The popup menu itself disappears before the submenu is displayed
Steps to reproduce
When you press the center button, a pop-up menu will appear on the upper left across the border of the window, so please mouse over it
Minimal reproduction project
embed_popup_menu.zip

Popups are always transient so they can't be set to always on top, and from the documentation it sounds like transient means on top of the parent window

In fact, when displaying a popup menu in an always_on_top parent window, if the popup menu is not set to always_on_top, it will be hidden behind the parent window and will not work.
In the case of a single popup menu, it works as expected (although I get an error message).
There is no problem if the child window of the always_on_top window is displayed in front without any flags.(but it isn't)

Close this and open a new issue with just the functional defect.


Fix time window in SlidingTimeWindowReservoir

The time window given to the constructor of SlidingTimeWindowReservoir is converted to nanoseconds. However, the keys used in the field measurements are in milliseconds. This results in incorrect behavior when invoking the trim method. Less measurements are removed than required.

Looks good to me @jvanderkallen! Would you mind signing the CLA prior to me merging the fix?

Would you mind signing the CLA prior to me merging the fix?

Not at all. I have signed it.

@jvanderkallen, a test is failing as well I see. Would you mind fixing that too?


feat: math preview

Added math preview for block equations. This PR fixes #130, #100 and maybe https://github.com/artisticat1/obsidian-latex-suite/issues/49#issuecomment-1242495278
Now the preview only gets displayed when the cursor is inside an equation. Just didn't want/couldn't implement the preview when the cursor is between the $$ in a block equation. isTouchingInlineEquation would just say that it's inside an inline equation. To make it consistent I removed it for now and don't use the function at all. In my opinion it's really no big deal and can be dealed with at some other point if necessary. I didn't remove the function.

It looks like this will cause the popup preview to be shown for block math in Live Preview mode. However, Live Preview already previews block math by displaying the rendered equation beneath the source. Therefore, the popup is unnecessary.
Can you modify this to only show the popup for block math in Source mode?

Oh yeah I forgot about that. Thanks! I don't really know how to implement that though. I don't know how to pass that information to the tool tip function. I don't know how codemirror and their StateFields work. Can you help me?

this.app.workspace.getActiveViewOfType(MarkdownView)?.currentMode.sourceMode should return:

true on source mode
false on live preview
undefined on reading mode or if the current active view is not a markdown view
(It uses a bit of private API, however.)

If there is a state field that stores whether the editor is in Source/LP mode (would have to investigate whether one exists), I think you could access it via state.field(...). Then you could modify the boolean shouldShowTooltip based on this value.

Okay tell me when you found a way how to implement it or just go ahead and do it yourself :)

@artisticat1 any updates?

At the moment, I don't have much time to look into it.

It looks like you can use this StateField to check whether or not the editor is in Live Preview mode!

Thanks! Should be good to go now :)

@artisticat1 just wanted to check in. It's been nearly two weeks since I added the fix. Have you had a chance to look at it? It's really a simple change.

Apologies for the delay. Looks fine to me! Thanks for your contribution.


[Bug]: Compress PDF bug

Installation Method
None
The Problem
Compressed files cannot be obtained by the input size, and the output file size is the same when compression 1 2 3 4 is selected, without any change at all,
Version of Stirling-PDF
0.26.1
Last Working Version of Stirling-PDF
No response
Page Where the Problem Occurred
No response
Docker Configuration
No response
Relevant Log Output
No response
Additional Information
No response
Browsers Affected
No response
No Duplicate of the Issue

[X] I have verified that there are no existing issues raised related to my problem.

This isn't a bug, it just means your PDF is as compressed as it can be

it just means your PDF is as compressed as it can be , but Assume that my PDF file is 20M, but no matter how I set the parameters, the output files of the software are all the same size. Can this prove that the parameter settings are invalid, because the default output document image quality is very low, I hope it can be optimized Thx!

I am having the same bug, no matter what compression setting I pick (1-4) it outputs the same exact sized PDF. However, when I select "Auto" mode and type in 1MB (on a 2MB file) it compresses it down to 506kb. So the file can be compressed.


Key event handler with Input types

keyHandler:function(e) {
    if(disabled===true) {
        return true;
    }
    if(locked===true || document.activeElement.readOnly===false) {
        return false;
    }

The document.activeElement.readOnly===false function return always false when your active element is a Input, Select or Textarea. If you have a form in the site it does not work with the plugin!
How can I disable the keyHandler for the form?

If the currently focused element is editable then the arrow keys won't trigger Scrollify.
This is so that users can edit an input without being unexpectedly scrolled away from it.

I get that! The problem I'm having is that if you return false in the function that it is attached to the keydown event the key won't be trigger (You can check it in this link).
This can be solved this way!
if(disabled===true || document.activeElement.readOnly===false) {     return true; } if(locked===true) {     return false; }

Ah, I see what you mean now. That's a pretty major bug. Thanks for spotting it.


Uploaded files with dashes in their name cause a routing error

With the latest master, if I upload an image with dashes ("-") in the filename, refinery 404s when I try to view it. Here's the log output:
Started GET "/system/images/BAhbB1sHOgZmSSIwMjAxMi8wMS8yNC8yMl8xMl8yNl80MjBfeWVzX3RoaXNfaXNfZG9nLnBuZwY6BkVUWwg6BnA6CnRodW1iSSINMjI1eDI1NT4GOwZU/yes-this-is-dog.png" for <IP_ADDRESS> at 2012-01-24 22:14:15 -0800

ActionController::RoutingError (No route matches [GET] "/system/images/BAhbB1sHOgZmSSIwMjAxMi8wMS8yNC8yMl8xMl8yNl80MjBfeWVzX3RoaXNfaXNfZG9nLnBuZwY6BkVUWwg6BnA6CnRodW1iSSINMjI1eDI1NT4GOwZU/yes-this-is-dog.png"):

Rendered<EMAIL_ADDRESS>within rescues/layout (0.5ms)

Confirmed.

I added a spec that fails on master:
[16:48:14 refinerycms (master u+1)]$ git diff HEAD^
diff --git a/images/spec/fixtures/image-with-dashes.jpeg b/images/spec/fixtures/image-with-dashes.jpeg
new file mode 100644
index 0000000..ced2ee6
Binary files /dev/null and b/images/spec/fixtures/image-with-dashes.jpeg differ
diff --git a/images/spec/requests/refinery/admin/images_spec.rb b/images/spec/requests/refinery/admin/images_spec.rb
index b0fdf29..0e36f38 100644
--- a/images/spec/requests/refinery/admin/images_spec.rb
+++ b/images/spec/requests/refinery/admin/images_spec.rb
@@ -33,6 +33,22 @@ module Refinery
         page.should have_content("'Beach' was successfully added.")
         Refinery::Image.count.should == 1
       end
+
+      it "uploads image with dashes in the filename", :js => true do
+        visit refinery_admin_images_path
+
+        click_link "Add new image"
+
+        page.within_frame "dialog_iframe" do
+          attach_file "image_image", Refinery.roots(:'refinery/images').join("spec/fixtures/image-with-dashes.jpeg")
+          click_button "Save"
+        end
+
+        page.should have_content("'Image With Dashes' was successfully added.")
+
+        get Refinery::Image.last.url
+        response.should be_success
+      end
     end

     context "edit/update" do

(image-with-dashes.jpeg is just a copy of beach.jpeg)
96d87bc79779ee344e6b68494351b040393ae1f1 is the commit that breaks this, the previous one passes.

It's definitely a mystery...

@parndt Would it be an acceptable fix to change Dragonfly's url_format based on whether or not trust_file_extensions is enabled/disabled?

Or should a fix be pushed upstream into dragonfly?

Both, maybe? cc @markevans

@phiggins it has nothing to do with trust_file_extensions but with our use of :name.. see the issue I referenced above markevans/dragonfly#165

@parndt Not directly, no. I thought the idea was that with trust_file_extensions on, :name.:ext will be "foo.jpg.jpg", with it turned off it would be "foo.jpg", and that all this trouble was to make sure it was always 'foo.jpg'.


jonasmaziero/LibForQ appears to have been renamed LibForQ-v1

README.md:3120 references github.com/jonasmaziero/LibForQ which appears to have a new name: LibForQ-v1
[LibForQ](https://github.com/jonasmaziero/LibForQ): performs several numerical tasks one frequently needs when working in quantum information science, such as trace, partial trace, and partial transpose; entanglement, discord, and coherence quantifiers; Pauli group (PG), Generalized Gell Mann Matrices (GGMM), and Bloch vector and correlation matrix with GGMM, by Jonas Maziero

renamed


Password not changeable

Updating password is not possible, only the other things.

Not true anymore since Auth0 was chosen as authentication provider.


Checkpoints frequency

I couldn't find an option that specifies how often current model evaluation is conducted. (I'm interested in BLEU scores).
I supposed that option '-save_interval' should do it, but apparently it doesn't.
Could anyone please point me in the right direction?

Yes, you would have to change the code to do this. -save_interval just
specifies how often the model is serialized to disk.
On 26 June 2017 at 08:58, Alexander Chebykin<EMAIL_ADDRESS>wrote:

I couldn't find an option that specifies how often current model
evaluation is conducted. (I'm interested in BLEU scores).
I supposed that option '-save_interval' should do it, but apparently it
doesn't.
Could anyone please point me in the right direction?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/facebookresearch/fairseq/issues/71, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ADGSfvJLUugHR-MefbxsxT6WXxoghzHBks5sH9U8gaJpZM4OFg3R
.

Hmmm, and could you tell where can I do that?
Also, I wonder what word 'epoch' means in this framework? I've alway thought that it means 'the model saw all samples 1 time', but if it's so, I can't understand why in my case the next epoch started after 69.000 iterations with batch size == 32 (meaning that model saw 69000 * 32 = 2 208 000 samples), and I have training dataset of 1 800 000 samples. The only explanation I see is that model keeps track of which samples it saw and since they're picked at random it takes more steps to see all samples. Is this the case?

Regarding the difference between updates and samples: If you use -maxbatch or -bptt, a mini-batch may yield more than one sample for the model because the batch might be split into several smaller batches. Hence, the number of updates may differ from the number of sentences in your training set.
For more frequent checkpointing, you can try calling onCheckpoint (defined in train.lua:318) in regular intervals from the onUpdate hook (see a few lines below). Please let me know if you run into issues with this.

Thanks for the information. You've answered my questions, so I'm closing the issue.
@jgehring if I try it and have any problems, I'll report them here.


[NetworkX-compatibility] algorithm: simple paths

implement the four algorithms in simple paths

Hi, I am a final year undergraduate student in math and I am interested in the simple paths question, particularly in all_simple_paths. I think that we could firstly decomposed the graph by clique separators.
(Results: V1, V2, V3,...,Vn, the source vertex s is in V1 and the target vertex t is in Vn). Then calculate the connectivity between cliques (V2,V3, ... V(n-1)). ...
Do you think the ideal is workable? Could I apply for joining the Plan?
Thanks a lot!

I think clique decompostion may be too low for a such large graph.
For some special type graph, e.g. planar graphs, there is a O(n^0.5) algorithm. For a simple graph, the
best known algorithm runs in  O(mn)-time,  and every graph can be clique-decomposed in O(n^2.3729)-time.May a distributed decomposed algorithm exist? And could we achieve a approximate algorithm?
Thanks a lot.

I think clique decompostion may be too low for a such large graph.
For some special type graph, e.g. planar graphs, there is a O(n^0.5) algorithm. For a simple graph, the
best known algorithm runs in O(mn)-time, and every graph can be clique-decomposed in O(n^2.3729)-time.May a distributed decomposed algorithm exist? And could we achieve a approximate algorithm?
Thanks a lot.

GraphScope has not implemented clique decomposed algorithm yet. I think use a bfs traversal is better to solve the simple path problem than clique decomposed in GraphScope distributed programming  model.

Ok, I will browse the algorithms carefully.
I do hope to join in the plan and try to make progress in the problem.
Thank you.

I have been studying graph calculation acceleration by multi-GPU. I wonder whether the project is similar with the kernel implement of benchmark algo. SSSP.

hi, @LDA111222 @jiangxiaobin96 the project application has begin, if you interesting this project, welcome to apply the project with a [materi  als] (https://summer.iscas.ac.cn/help/assets/项目申请模板.pdf).
the application deadline is June 13.


Discussion: Finer details

@pandafy @awalvie @grimmmyshini
Backend: Golang (using SocketIO)
Frontend: React + P5.js/physics/any other + SocketIO
Socket Messages:
Client -> Server

move (while in lobby - global)
message (while in room)
reaction (while in room)

Server -> Client

movement - 30 per second (send locations of everyone on the map, i.e. Dictionary) - emit
join-lobby - Send details of person who has joined the global township - broadcast
leave-lobby - Send ID of person left the global township- broadcast
join-room - Joined the room - broadcast in room
leave-room - Left the room - broadcast in room
message - (in a room) - emit
reaction - (in a room) - emit
peoplesync - Send data of all the people in the lobby once per second to keep everything in sync

User model:

username - sent by username
socketid - obtained from the connectionid
location - [x, y]
color - ["r", "g", "b"]


Change FileUtils.cpp

Better to move away from using the old deprecated styles and use the C++ standards file system.

First of all, the FILE API is not Windows only.
Secondly, this has already been discussed, see #18.

Whoops that was my bad then, I was not meant to say windows only API.
Still the fact using old and deprecated functions isn't really innovative or a good way to teach newcomers.
Secondly, I just did about 200 or so tests for each of them and std api is only about 2000 nanoseconds slower, which really isn't gonna be noticable.
Tests was ran on a 3kb test file.

He said he benchmarked it though and it was faster for smaller files and slower for really big files(that he wasn't planning on having).
Also, why you do an if and then ASSERT(false,...)? Why not putting the if contents in the place you have the false?

To be fair, that is an actual issue with the original code.
if (file == nullptr) SP_ASSERT(file, "Could not open file '", filepath, "'!");
should become
SP_ASSERT(file, "Could not open file '", filepath, "'!");

This will be eventually re-written in a platform specific FileSystem class; we won't be using FILE anyway, so don't think too much into this. As for C-style FILE vs C++ streams, FILE does perform better than file streams, based on real-world experience.


Allowed non-readable textures to be read without reimporting!

This is totally a hack to read unreadable textures at edit time.  Basically blit them onto a rendertexture and then read the data back off of that rendertexture into a readable texture.  Unity is very silly.
To test:

[ ] Verify you can use any texture (that is not compressed) in a texture field!  Also verify that this does not change the import settings of the texture.

Non-readable textures are in a compressed format.  They wouldn't want to do this for free because it would silently eat draw calls.

Yeah that's true, but it would be nice if they provided some sort of api at edit time, where all the information is available anyway.


Automated Package Upgrade

:tada: This PR is included in version 2.2.129 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Implement checksums properly in dataplane

Problem Statement
We currently don't handle checksums properly or at all in several places. The purpose of this task is to get that sorted out.
Acceptance Criteria

[ ] find all the places we are currently handling, or NOT handling L3 and L4 checksums and get them consistent
[ ] use helpers like bpf_l3_cksum_replace to properly recalculate checksums

Opening this up as a good issue for newcomers interested in getting involved in the ebpf dataplane bits :)

Would like to work on this one o/

Yup, the nice folks over there already gave me a hand on the other issue I'm working on to improve the build process, thanks for the heads up @astoycos

@LCaparelli as I understand it you may not have time for this one going forward so I'm opening it back up, however if you still want to take this one on please just let us know! :vulcan_salute:

Not stale, we still intend this for the v0.7.0 milestone:
/remove-lifecycle stale
However, I suspect @LCaparelli is no longer working on this (do correct me if you still wanted this)? So I think we're back to help wanted.
/help

I have some questions about this issue, I found some functions implemented with bpf_l4_cksum_replace and bpf_l3_cksum_replace like set_ipv4_dest_port and set_ipv4_ip_dst in tc_ingress module, so you mean that we should keep consistent in other module like tc_egress?

Consistency for sure, but I also think we just have a lot of hacks in place. I removed the good-first-issue on this one some time ago because basically what we need is someone to deep dive in and suss it all out first and actually figure out exactly what is needed, and then make the patch. So just know that we're happy to support you in this one but it's a bit of a deeper dive!

Hey guys,i am happy to work on this task

@jokestax mentioned wanting to have a go at this one:
/assign @jokestax
Please do note it's kinda old, and maybe a bit crunchy, so take your time and do reach out here or on Slack if you need any support. Also when in doubt, I would highly recommend looking at what Cilium does as they are usually a good model to follow.

Hey guys,
I've made some progress! The ingress implements the checksum properly. However, I noticed it wasn’t being handled correctly in egress for ICMP and TCP. I’ve made the necessary changes for TCP and raised a draft PR for review: link.
I’d really appreciate it if someone could review the PR and provide guidance so I can proceed with making similar changes for ICMP as well.


Updating LBFGS buffer

Regarding function update_hessian, the LBFGS buffer should be updated only if (s,y) satisfies the condition in the paper of Li and Fukushima, otherwise, the pair should be discarded. This means that old_state and old_gradient shouldn't be updated.
That said, I think that the following should be moved below inside the if block
// TODO: Check if these should be inside the if statement
self.old_state.copy_from_slice(state);
self.old_gradient.copy_from_slice(gradient);

Additionally, since LBFGS can be used in applications other than gradient-based optimisation, we could rename gradient to something else. We could adopt the notation:

s_k = x_{k+1} - x_k
y_k = g_{k+1} - g_k, where g_k = g(x_k) and g is some function

Often, g is the gradient of a cost function.

Another related question: I see that in the following function:
fn new_s_and_y_valid(&self, gradient: &[f64]) -> bool {
    // TODO: Check if EPSILON should be changed
    const EPSILON: f64 = 1e-12;
    let sy = vec_ops::inner_product(&self.s.last().unwrap(), &self.y.last().unwrap())
            / vec_ops::inner_product(&self.y.last().unwrap(), &self.y.last().unwrap());

    // TODO: Check the alpha power to be used
    let ep = EPSILON * vec_ops::norm2(gradient);

    // Condition: (y^T * s) / ||s||^2 > epsilon * ||grad(x)||^alpha
    sy > ep && sy.is_finite() && ep.is_finite()
}

I see that the inner products are calculated on self.s.last() and self.y.last(), that is, on s and y variables which are already in the buffer. However, if the condition of Li and Fukushima is not satisfied, then these s and y should not be included in the buffer -- the buffer should, instead, not be updated.

Thanks for the comments, here are the answers:
active_size should be 3, when there are 3 active buffers (which there are), so this is fine.
If you look at line 72-73, active_size is used non-inclusive.
s and y are storing the s and y under test  by the C-BFGS criteria in the last element, and must be there if it is rejected, else we would overwrite old good gradients with the temporary, sadly it is necessary when having the C-BFGS criteria.

I think we resolved all related issues, so I'll close it.


Adding remaining Virtual Guest CRUD operations

In reference to the work we've been doing to complete the Terraform SoftLayer Provider work that @eirslett started.
We've been working on getting all CRUD operations for Virtual Guests implemented as referenced here https://github.com/TheWeatherCompany/softlayer-go/issues/4 and here https://github.com/TheWeatherCompany/terraform/issues/5. This PR includes quite a few additions that fully round out Virtual Guest abilities.
We have also been working on getting all CRUD operations for DNS Domains and Resource Records implemented as referenced here https://github.com/TheWeatherCompany/softlayer-go/issues/5  here https://github.com/TheWeatherCompany/terraform/issues/8 and here https://github.com/TheWeatherCompany/terraform/issues/7.
DCO 1.1 Signed-off-by: Daniel Bright<EMAIL_ADDRESS>

Thanks @maximilien, this is the new PR into develop, all issues should be resolved now as of my last check, please let me know if anything else needs to be done.
-Daniel

Nice @danielcbright. Doing final review now. Unless I find something major, I'll merge. You can always address anything subsequently.
@jianqiu and @mattcui are setting up a CI for develop so we can test and vet. Once that's done then we will bump to master.

Great work @danielcbright and team. Please address the comments into subsequent PRs when ready. Merging to develop. Cheers :beers:

Thanks @maximilien - I'll get a PR ready to address those comments where needed, the guidance from your end has been excellent, thanks for the help!


Using field transformer breaks integration with hypothesis

Adding field transformer according to documentation (i.e. as a function of type Callable[[type, list[attr.Attribute[Any]]], list[attr.Attribute[Any]]])
breaks attrs integration with hypothesis, because attributes transformed with such function are not casted to generated AttrsClass, but remains just an list of attributes (here)
This causes error in hypothesis here, because fields is an list, not an AttrsClass instance, and therefore getattr(fields, name) raises an AttributeError.
Easy workaround for that is just to create an AttrsClass again inside field transformer, like so:
def transformer(cls: type, fields: list[attr.Attribute[Any]]) -> list[attr.Attribute[Any]]:
    attr_names = [f.name for f in fields]
    AttrsClass = _make_attr_tuple_class(cls.__name__, attr_names)

    ... do something with fields ...

    return AttrsClass(fields)

...but it's not very handy nor pretty, and messes with typing. So, I would very thankful if it could be resolved within attrs (it would be quite easy, I guess).
BTW. I love your package, awesome job! Cheers!

@sscherfke? 😇


Visualize hex-to-bytecode mapping

Feature
Allow users to see a display similar to this:

Ideally for the entire class file, rather than just the method bytecode. But the method code would be good for now and could be expanded later. This is handy for things such as writing YARA rules where knowing the hex is necessary.
Process
This will likely be implemented using CAFEDOOD once it is fleshed out more, specifically once this issue is completed: https://github.com/Col-E/CAFED00D/issues/1

This would be a great feature!

Some thoughts on this, if its ok that the index pointers are not included then just showing the bytecode of instructions' opcodes + argument wildcards could be done.
For instance:
START:
 ALOAD this
 INVOKEVIRTUAL com/example/MyApp.doLog()Z
 IFEQ END
LOGGING:
 GETSTATIC com/example/MyApp.logger Lorg/slf4j/api/Logger;
 LDC "Logging message"
 INVOKEVIRTUAL org/slf4j/api/Logger.info(Ljava/lang/String;)V
END:
 RETURN

Would show up as (comments included for clarity):
2A     // aload_0
B6 ??  // invokevirtual <method-ref>
99 ??  // ifeq <branch-offset>
B2 ??  // getstatic <field-ref>
12 ??  // ldc <cp-utf8-index>
B6 ??  // invokevirtual <method-ref>
B1     // return

Working on a new hex editor in 3X
https://user-images.githubusercontent.com/21371686/136320417-4ad66da2-45b2-4e44-b7c7-c1a6febd2cc6.mp4
The plan is to make it so you can correlate regions of the class file to the displayed hex. This will still require a bit of extra work, but the design now fully accommodates for this use case :)
The next step is to flesh out CAFED00D so that it will optionally let you get back the hex offsets from the data representation. My rough idea for this is to make it so that there is a common class representation over interfaces, but implementations can be provided via an optional factory. One could implement a factory that tacks on the offset information to data that gets parsed.


Normalize shared library file names in datasets

For fast lookups and determining what package a file came from, we'll want to transform the file name used as a key and do some fuzzier matching for the file names.
e.g. libcrypto.so.4.2 should be normalized to just libcrypto.so; for identifying the package a file came from we don't really care about the ABI version, since the odds of it being the exact same version as what was in our dataset is slim (or if it is, then the ABI version probably gives hardly any useful information on the actual library version).
There may also be some library names with version numbers in them (e.g. libsomething-2.so) -- it would be nice to remove version number from our normalized file names for package identification. We'll have to look at our file name to package datasets, but that version number might actually be useful to determine a more exact library version.

Duplicate of this issue, in a note I had (slightly different wording):
Shared library names tend to be in the form libxyz.so.6.0.2, and maybe there is a libxyz.so.6 symlink, and potentially a libxyz.so symlink in the same package. That last is the best case, since it is a version agnostic file name that should always be present. In our dataset, we probably want to do something like drop any numbers after the .so for fast lookups, then when matching a .so library file, make the check ignore any ABI SO version number.
A harder issue is when the file name is something like libxyz-2.0.so; do we try to recognize the part that is a version number and take it out?

so-name-normalization branch has some code added to try different .so file name normalization strategies.

So far, here's what I've found from looking at identifying files in the Ubuntu package repository based on file names in the Contents-amd64 file:

Filtering for files ending with .so seems to be a good indication that the file is a shared library
Filtering for files containing .so. that don't end with .gz, .patch, .diff, .hmac, or .qm appears to be reliable for identifying libraries that end in a SOABI version number, including some corner cases like libpsmile.MPI1.so.0d and *.so.0.* (messed up file name in happycodeslibsocket-dev)
After the above filters are applied (leaving us with ~39k unique file names):

Filter out Python related platform tags if the shared library name contains -cpython or -pypy
If the file name (case-sensitive) starts with libHS it was compiled by the GHC haskell compiler and the name matches a pretty standard format of libHS<package_name>-<version>-<api_hash>-ghc<ghc_version>.so
Matching files ending with a -<version> suffix using the regex -\d+(\.\d+)+.*\.so is reliable for detection multi-component version numbers (applies to 1076 files)

Additional filters for normalizing file names with version numbers that were considered but not implemented include:

v\d+(\.\d+)*.*\.so -- 478/39k names have something looking like a v-prefixed version... around half are pv, and the remainder has questionable accuracy: libvtkCommonSystem-pv5.11.so
-\d+(\.\d+)+.*\.so -- 1166/39k names that have a -<version> in them somewhere (this pattern is a combination of what is found by the -<version> suffix pattern that is implemented, and the next pattern name, with 1-2 exceptions: libdsdp-5.8gf.so and libsingular-omalloc-4.3.2+0.9.6.so)
-\d+(\.\d+)+-.*\.so -- 89/39k have "skewered" version numbers in the middle, often followed by a CPU arch (quite a few false positives)
\d+(\.\d+)+-.*\.so -- in addition to previous, mostly catches liblua5.*- names with false positives for other names matched
\d+(_\d+)+.*\.so -- 139/39k, underscore separated version numbers aren't popular and lots of false positives (such as x86_64)
\d+(-\d+)+.*\.so -- 1012/39k numbers separated by a "-", of which 888 are amd64-64, amd64-32, and amd64-linux
\d+(\.\d+)*\+.*\.so -- 17/39k version number-ish things followed by a "+" (not very common, not sure if worth adding something to normalize these names and try to extract version number)

In particular, some names have numbers like 802.11 that appear to be version numbers, but aren't (actually identifying a standard such as for WiFi protocol). Appending a number like 64 or 32 to denote 64 or 32 bit is common, so matching a single component version number would have many false positives. Numbers such as 512 are also common for amd64 (e.g. avx512).

With normalization removing -<version> suffixes, there are a small number of shared libraries that multiple packages install due to some "vendoring" others, usually in a plugins subfolder. This case can be handled by adding functions for recognizing /usr/lib/x86_64-linux-gnu/... names to discern which shared library is directly under a standard location for shared libraries vs one that is vendored.
There are a number corner cases where the normalized name without a version suffix was installed by a package with a different name (often there's a <package_name>-dev variant and then a <package_name>- variant. A handful are less clear what is going on:

libodin vs mitools?
libmjpegtools and libmplex (or liblavjpeg)?
libgstreamer vs libgupnp-dlna?
lib++dfb vs libdirectfb?
libp4est-sc vs libp4est?

It may be useful to have functions to normalize package names (e.g. remove -dev and -3.4.2 version suffixes), but converting to the source package names might eliminate most of the issues here with getting the most human-recognizable/common package name.
libpipewire, libgrilo, and libruby may be exceptions to these -- for the /usr/lib path name matching, it may be necessary to remove the version suffix from the libblah-.so in order to identify a correct "match".

Need to decide if files containing .so_ installed by Ubuntu/Debian packages are shared libraries. Applies to basically two files, like lib_postgresqludf_sys.so_
Also need to decide if files containing .so- are shared libraries... basically download one of the Kernel files ending in .hsaco and see if it is a shared library. If not, then this entire category of file names can be ignored.

The .so_ (and .dll_) file extension in the Ubuntu/Debian package repositories are just from pre-compiled payloads for sqlmap, to use various UDFs (user defined functions) on remote hosts.

Source code: https://github.com/sqlmapproject/udfhack/tree/master
Binaries: https://github.com/sqlmapproject/sqlmap/tree/master/data/udf

The .so- file extension is either a false positive (not an so file, just part of a different file name such as ...ld.so-.... that is really an svg or other file type, or better matched by another file installed by the same package:

libapache2-mod-wsgi-py3 installs both "mod_wsgi.so-3.12" and "mod_wsgi.so"
librocblas0 installs multiple "Kernels.so-000-gfx900.hsaco" and "Kernels.so-000-gfx906-xnack-.hsaco" files, but also "librocblas.so.0" which is a better indicator of the package being present

Decided that no special name normalization is needed at the moment for either case.


TriggerRepository should ensure required indexes are created

On large collections (e.g. tens of thousands of triggers), queries which use sort  SortBuilder.Ascending(trigger => trigger.NextFireTime),                     SortBuilder.Descending(trigger => trigger.Priority) will fail unless an index is created.
I can create a PR with the required change.

released with 4.0.0-preview.2


slice expression

The following program sample.go triggers an unexpected result
package main

import (
    "crypto/sha1"
    "encoding/hex"
)

func main() {
    script := "hello"
    sumRaw := sha1.Sum([]byte(script))
    sum := hex.EncodeToString(sumRaw[:])
    println(sum)
}

Expected result
$ go run ./sample.go
aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d

Got
yaegi ./sample.go
run: ./sample.go:11:28: cannot use type [20]uint8 as type []uint8

Yaegi Version
v0.11.1
Additional Notes
No response

Issue found when import "gitHub.com/mediocregopher/radix/v4"


More flexibility in resizing positional embeddings for ViT and TnT

Key headlines:

Can now use non-square img_size for ViT and pretrained positional embeddings are resized accordingly. (before, one could use non-square img_size but pretrained embeddings were not resized accordingly, so only with pretrained=False)
Can now resize TnT positional embeddings. Like in ViT, a checkpoint filter function is used to resize pretrained embeddings.

Caveats:

I've done very basic testing (model instantiation, and forward torch zeros) but I plan to use these for a project shortly so will report back if issues crop up.
For TnT, I haven't thought so much about the implications of allowing non-square patch size, which I did allow in the code for the sake of being consistent with ViT.

@rwightman thanks for checking and merging. I'm just about to use ConViT and noticing the same issue. I'd be happy to sort it out and put in another PR but wanted to check what your preference is here.

@alexander-soare yeah, definitely useful but with some of these transformer models it'll get a bit messy as the authors didn't consider non-square inputs in their designs and that might propagate pretty deep into the model. In those cases I'm not sure it's worth it unless it's clear they are both superior and popular models....
I just merged a few more and you'll see, headaches for those ones too.


Windows Commands/xcopy: Example 9 missing a verb

Description:
As reported in issue ticket #4383 (Grammar), the description text for Example 9 is missing a verb to make complete sense.
There is also a minor grammatical error in the comment following the example.
Thanks to @S-List for noticing and reporting the issue.
Changes proposed:

Add the missing verb "copies" to complete the sentence
Change "copy" to "copies" (3rd person singular) in the comment below
Whitespace changes:

Normalize MD bullet point list spacing to 1 (6 lines)
Add 1 blank line between the metadata section and the page title

Additional notes:

Please notify me if "will copy" is preferred instead of "copies".

Ticket closure or reference:
Closes #4383

#sign-off


Added the MIT License badge and some text to Licenses section

Related Issue
Closes: #528
Describe the changes you've made
Added the MIT License badge and some text to Licenses section
Type of change
What sort of change have you made:

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] Documentation update.
[ ] This change requires a documentation update

How Has This Been Tested?

Checklist

[x] My code follows the guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented on my code, particularly wherever it was hard to understand.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have added tests that prove my fix is effective or that my feature works.
[x] Any dependent changes have been merged and published in downstream modules.

Screenshots (if applicable)
Code of Conduct

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

thank you @amanjaiman1 . Please add the gssoc labels too.


Bugfix: fix infinite loop on windows.

I try to run react-native on windows. both packager server and cli bundle meet a infinite loop.
Finally I found the reason:  root path on windows is not '/'
The better way is compare dirname with currDir self.

LGTM

Anyone tells me how can I stop adding extra commits into this pull-request?

Your PR is from your master branch so all commits to to show up here. Commit to another branch for now and in the future do your PR work on separate branches and have master only track upstream.

should I close this pr and resend it from another branch?

Whatever is convenient for you.

#2051 Resubmit at here.


wrong displayed IP adress in NR after changing IP

a little strange behavior
if I change the IP Address of a "switch" node in NR afterwards, an error message is displayed for the former, at first entered address, alternating with the new address. Of course I deployed the change.

you can see the former entered address is still showing up

what version do you use? I get a timeout error instead

I can not reproduce this even without network:


Group headers missing

It seems like since the last update (?) that group headers are missing. This is what the plugin window looks for me with no theme applied:

I've set the plugin to group by page.

fixed in 1.2.0


Fix typo in contributor guidelines

Spotted this while reading the docs. Find-and-replace didn't spot any other instances :)

Thank you!


Add (rough) Yaws data

So I got university access to an old edition of Yaws physical and Chemical Properties. I ran optical character recognition on it and extracted the important chapters, and this is the result.
It's not quite ready for prime time because there are a lot of errors in it, in the sense that the OCR didn't get quite 100% accuracy. But I figured I could upload the files now and we could work on cleaning them later. Once finished, we'll have good property data including everything necessary for the various cubic equations of state, for about 2000 organic compounds and 350 ish inorganic compounds.

 It could still use a bit of work but it will help I think. I have the vague idea to manually go over the full list with the name and CAS registry number of each compound and make sure it's correct, which will take some time, but then once that's done, the data from each chapter could be matched to each compound by name using fuzzy matching. Then it could all be combined into one large database.


[1.15.2] double bug with vertical slabs.

Hi,
i actually found two bugs with the vertical slabs,
the first one is that you can't mine vertical slabs back, when you break it, it's disappearing. (you get some back in some strange conditions.
the second one, is that when you craft a vertical slab, and place it, you can place it in an infinite amount when placed on a wall. (but it's used when placed on the floor)
i recorded those behaviors, you can find a vidéo here : https://youtu.be/D_5VD3l8JV4

Hi! Thanks for reporting this. I have discovered how to fix the issue with the item count not reducing but I'm unsure about the other issue. It could be related to the fact the item count is not decreasing.
The way these two issues are linked is the fact that the vertical slab item actually contains the horizontal slab item stack inside and it is the stack inside which is being reduced. I'll upload a new version, if you could see if it fixes both issues that would be fantastic! Thank you :)

Hi,
great and quick support, trying the update when i have a bit of time.
thanks for support.


Generating JSON Schema results in only a object hierarchy without type definitions

Describe the bug
When generating a JSON schema based on a XML schema it generates a JSON which provides information about the object hierarchy but essential information such as data type, min/max length and required/optional is missing.
Category

Frank Framework

To Reproduce
Steps to reproduce the behavior:

Load a configuration with a Json2XmlValidator, don't forget to add the attribute "targetNamespace" (please contact me if you require the specific file, I can't upload this to Github)
Start your Frank application
Browse to http://localhost/iaf/gui/#!/status
Currently the JSON schema is shown as a configuration warning, it only contains type: "object" and else it will display an empty object {}

Expected behavior
The JSON schema should provide essential information about fields which are not of the type object. It should atleast describe the following attributes:
data type, min/max length and required/optional
Screenshots
Can't provide due sensitive data
Environment:

Tomcat 7 (Frank Runner)
Chrome
7.6-20200320.120324

Additional context
None

Requested features have been implemented by:
PR #543
PR #544
PR #548


[CT-2706] [Feature] Warn users if hooks have pure functions assigned to them vs jinja string with function

Is this your first time submitting a feature request?

[X] I have read the expectations for open source contributors
[X] I have searched the existing issues, and I could not find an existing issue for this feature
[X] I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature
Our docs show that if we invoke macros from hooks, we want to use them within jinja strings - like so:
{{ config(..., post_hook = "{{ macro_foo() }}") }}

However, it is also possible to accidentally forget that you need to do and call the macro directly:
{{ config(..., post_hook = macro_foo()) }}

Which actually does not result in any errors but some interesting behaviour due to dbt's various steps (parse, compile, etc). If we have a toy setup where we're doing the wrong thing:
-- models/foo.sql
{{ config(post_hook = macro_foo()) }}
select 1 as id

-- macros/my_macros.sql
{% macro macro_foo() %}
    {% if execute %}
        {% do run_query("select 'macro_foo' as triggered_from") %}
    {% endif %}
{% endmacro %}

# dbt_project.yml
name: "postgres"
version: "1.0.0"
config-version: 2
profile: "postgres"

models:
  postgres:
    +materialized: table
    +post-hook: ["select 'project-post-hook' as triggered_from"]

02:13:42  1 of 1 START sql table model public.foo ........................................ [RUN]
02:13:42  Re-using an available connection from the pool (formerly list_postgres_public, now model.postgres.foo)
02:13:42  Began compiling node model.postgres.foo
02:13:42  Using postgres connection "model.postgres.foo"
02:13:42  On model.postgres.foo: /* {"app": "dbt", "dbt_version": "1.5.1", "profile_name": "postgres", "target_name": "dev", "node_id": "model.postgres.foo"} */

    select 'macro_foo' as triggered_from

02:13:42  Opening a new connection, currently in state closed
02:13:42  SQL status: SELECT 1 in 0.0 seconds
02:13:42  Writing injected SQL for node "model.postgres.foo"
02:13:42  Timing info for model.postgres.foo (compile): 14:13:42.146762 => 14:13:42.189660
02:13:42  Began executing node model.postgres.foo
02:13:42  Writing runtime sql for node "model.postgres.foo"
02:13:42  Using postgres connection "model.postgres.foo"
02:13:42  On model.postgres.foo: BEGIN
02:13:42  SQL status: BEGIN in 0.0 seconds
02:13:42  Using postgres connection "model.postgres.foo"
02:13:42  On model.postgres.foo: /* {"app": "dbt", "dbt_version": "1.5.1", "profile_name": "postgres", "target_name": "dev", "node_id": "model.postgres.foo"} */
  create  table "postgres"."public"."foo__dbt_tmp"
    as
  (
select 1 as id
  );
02:13:42  SQL status: SELECT 1 in 0.0 seconds
02:13:42  Using postgres connection "model.postgres.foo"
02:13:42  On model.postgres.foo: /* {"app": "dbt", "dbt_version": "1.5.1", "profile_name": "postgres", "target_name": "dev", "node_id": "model.postgres.foo"} */
alter table "postgres"."public"."foo" rename to "foo__dbt_backup"
02:13:42  SQL status: ALTER TABLE in 0.0 seconds
02:13:42  Using postgres connection "model.postgres.foo"
02:13:42  On model.postgres.foo: /* {"app": "dbt", "dbt_version": "1.5.1", "profile_name": "postgres", "target_name": "dev", "node_id": "model.postgres.foo"} */
alter table "postgres"."public"."foo__dbt_tmp" rename to "foo"
02:13:42  SQL status: ALTER TABLE in 0.0 seconds
02:13:42  Using postgres connection "model.postgres.foo"
02:13:42  On model.postgres.foo: /* {"app": "dbt", "dbt_version": "1.5.1", "profile_name": "postgres", "target_name": "dev", "node_id": "model.postgres.foo"} */

        select 'project-post-hook' as triggered_from

02:13:42  SQL status: SELECT 1 in 0.0 seconds
02:13:42  On model.postgres.foo: COMMIT
02:13:42  Using postgres connection "model.postgres.foo"
02:13:42  On model.postgres.foo: COMMIT
02:13:42  SQL status: COMMIT in 0.0 seconds
02:13:42  Using postgres connection "model.postgres.foo"
02:13:42  On model.postgres.foo: /* {"app": "dbt", "dbt_version": "1.5.1", "profile_name": "postgres", "target_name": "dev", "node_id": "model.postgres.foo"} */
drop table if exists "postgres"."public"."foo__dbt_backup" cascade
02:13:42  SQL status: DROP TABLE in 0.0 seconds
02:13:42  Timing info for model.postgres.foo (execute): 14:13:42.193663 => 14:13:42.400204
02:13:42  On model.postgres.foo: Close
02:13:42  Sending event: {'category': 'dbt', 'action': 'run_model', 'label': 'a42bf06b-92cb-4730-a528-fe32971a8838', 'context': [<snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x10aeeff70>]}
02:13:42  1 of 1 OK created sql table model public.foo ................................... [SELECT 1 in 0.26s]
02:13:42  Finished running node model.postgres.foo

We actually "execute" the post hook prior to the model being run - which can be confusing. Perhaps a warning about post hooks not being strings could help.
Of course, simply fixing the above to be:
-- models/foo.sql
{{ config(post_hook = "{{ macro_foo() }}") }}
select 1 as id

Resolves the issue straightaway:
02:15:42  1 of 1 START sql table model public.foo ........................................ [RUN]
02:15:42  Re-using an available connection from the pool (formerly list_postgres_public, now model.postgres.foo)
02:15:42  Began compiling node model.postgres.foo
02:15:42  Writing injected SQL for node "model.postgres.foo"
02:15:42  Timing info for model.postgres.foo (compile): 14:15:42.478073 => 14:15:42.485780
02:15:42  Began executing node model.postgres.foo
02:15:42  Writing runtime sql for node "model.postgres.foo"
02:15:42  Using postgres connection "model.postgres.foo"
02:15:42  On model.postgres.foo: BEGIN
02:15:42  Opening a new connection, currently in state closed
02:15:42  SQL status: BEGIN in 0.0 seconds
02:15:42  Using postgres connection "model.postgres.foo"
02:15:42  On model.postgres.foo: /* {"app": "dbt", "dbt_version": "1.5.1", "profile_name": "postgres", "target_name": "dev", "node_id": "model.postgres.foo"} */
  create  table "postgres"."public"."foo__dbt_tmp"
    as
  (
select 1 as id
  );
02:15:42  SQL status: SELECT 1 in 0.0 seconds
02:15:42  Using postgres connection "model.postgres.foo"
02:15:42  On model.postgres.foo: /* {"app": "dbt", "dbt_version": "1.5.1", "profile_name": "postgres", "target_name": "dev", "node_id": "model.postgres.foo"} */
alter table "postgres"."public"."foo" rename to "foo__dbt_backup"
02:15:42  SQL status: ALTER TABLE in 0.0 seconds
02:15:42  Using postgres connection "model.postgres.foo"
02:15:42  On model.postgres.foo: /* {"app": "dbt", "dbt_version": "1.5.1", "profile_name": "postgres", "target_name": "dev", "node_id": "model.postgres.foo"} */
alter table "postgres"."public"."foo__dbt_tmp" rename to "foo"
02:15:42  SQL status: ALTER TABLE in 0.0 seconds
02:15:42  Using postgres connection "model.postgres.foo"
02:15:42  On model.postgres.foo: /* {"app": "dbt", "dbt_version": "1.5.1", "profile_name": "postgres", "target_name": "dev", "node_id": "model.postgres.foo"} */

        select 'project-post-hook' as triggered_from

02:15:42  SQL status: SELECT 1 in 0.0 seconds
02:15:42  Using postgres connection "model.postgres.foo"
02:15:42  On model.postgres.foo: /* {"app": "dbt", "dbt_version": "1.5.1", "profile_name": "postgres", "target_name": "dev", "node_id": "model.postgres.foo"} */

    select 'macro_foo' as triggered_from

02:15:42  SQL status: SELECT 1 in 0.0 seconds
02:15:42  On model.postgres.foo: COMMIT
02:15:42  Using postgres connection "model.postgres.foo"
02:15:42  On model.postgres.foo: COMMIT
02:15:42  SQL status: COMMIT in 0.0 seconds
02:15:42  Using postgres connection "model.postgres.foo"
02:15:42  On model.postgres.foo: /* {"app": "dbt", "dbt_version": "1.5.1", "profile_name": "postgres", "target_name": "dev", "node_id": "model.postgres.foo"} */
drop table if exists "postgres"."public"."foo__dbt_backup" cascade
02:15:42  SQL status: DROP TABLE in 0.0 seconds
02:15:42  Timing info for model.postgres.foo (execute): 14:15:42.489537 => 14:15:42.711124
02:15:42  On model.postgres.foo: Close
02:15:42  Sending event: {'category': 'dbt', 'action': 'run_model', 'label': 'abff3400-8dc5-46f7-b48e-bdf518bacdb6', 'context': [<snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x10959ecb0>]}
02:15:42  1 of 1 OK created sql table model public.foo ................................... [SELECT 1 in 0.24s]
02:15:42  Finished running node model.postgres.foo

https://docs.getdbt.com/reference/resource-configs/pre-hook-post-hook
https://docs.getdbt.com/docs/build/hooks-operations

Describe alternatives you've considered
NA
Who will this benefit?
Users who are new to dbt + hooks.
Are you interested in contributing this feature?
No response
Anything else?
No response

@jeremyyeo This reminds me of another issue you opened last year: https://github.com/dbt-labs/dbt-core/issues/4785. After a lot of back-and-forth, we ended up agreeing that it's a tricky scenario, and the best we can probably do is warn users when their hooks are rendered to empty strings. "I don't think this is doing the thing you wanted. Read these docs: ..." That's still an ergonomic improvement over the debugging / docs-combing they have to do currently.

It's totally reasonable to do this:
{{ config(..., post_hook = macro_foo()) }}

Assuming that your macro is actually returning a string:
-- models/foo.sql
{{ config(post_hook = macro_foo()) }}
select 1 as id

-- macros/my_macros.sql
{% macro macro_foo() %}
    {{ return("select 'macro_foo' as triggered_from") }}
{% endmacro %}

So I think the operative check here is whether the value of the hook is an empty string. I added an example of doing that for on-run-* hooks in https://github.com/dbt-labs/dbt-core/issues/4785#issuecomment-1105028544, and I imagine we could do the same for pre/post hooks within the builtin run_hooks macro.


Leverage quick pick hover support to explain conda environment lacking a Python interpreter

Waiting on Jupyter to probably experiment first, but as soon as they have a good solution/wording, we will be ready to pick it up.

@DonJayamanne Please let us know once you have finalized the wording.

We cannot implement this because we are blocked on some python extension api

This is the blocker api https://github.com/microsoft/vscode-python/issues/20765

@DonJayamanne Do you have the wording for this in Jupyter?

Please have a look at the Jupyter extension

Verification

Create conda env without python:

conda create -n test1

Use Python: Select Interpreter command and wait for it to show up at the bottom of the list
Hover over it:


KOGITO-6673 - Wrong label in Advanced Data Properties Tab

This fixes the label. Also adds the possibility to translate it.
JIRA: KOGITO-6673

Hey @Josephblt , please let me know when this is ready to merge, I will do it. And then let's close both JIRA and github issues. Thanks a lot!