Remove websocket in favor of ws (stream version)

websocket has a malicious dependency which we are required to remove. No already-shipped code uses the malicious version so there is no need to service any existing releases.
One option would be to pin to the non-malicious version of the dependent package, but I feel like that's not a viable long-term solution; it pollutes our package.json and doesn't solve the general problem of poorly-maintained dependencies. It doesn't look like websocket is super well-maintained--been more than a year since it's had any meaningful changes, and a year since a release--so I'm more inclined to switch to ws, which is more freshly-maintained and has zero dependencies (yay!).
This PR corresponds to #1106, and is an alternate form of it that uses streams.

Verified it is working, including getting a working SSH window.

Also verified that remote debugging is working with a Node v16 application.


Add a default value to the Relatives.Type enum, for easier diagnosis. [phab:D2269]

Created by jrtom at 2018-04-30 18:50:00:

jrtom wrote at 2018-04-30 18:57:27:
The explore.go change was already submitted in an earlier diff, figuring out how to excise that.

jrtom abandoned revision at 2018-04-30 19:05:21


BatchInvoke by payload.batchId as an alternative to datasource.name

In a project I work on we have multiple resolvers using BatchInvoke with the same lambda data source. The current LambdaDataLoader implementation batch by function name which means it tries to batch all the different resolvers using BatchInvoke together no matter what resolver it is using.
My proposed solution adds the option to put batchId in the templates to be able to differentiate them and make the correct batches.

@JimmyHurrah I get your use case. That is something I did not think about. Thank you for raising this issue and opening a PR.
Your solution looks a bit hacky though.
Wouldn't it make more sense to batch the requests by field?
We now get the fieldName and fieldParent from the payload (req.payload.info.fieldParent and req.payload.info.fieldName).
We probably could do something like:
const dataResolverKey = `${this.config.name}-${req.payload.info.fieldParent}-${req.payload.info.fieldName}`
const dataLoader = getBatchDataResolver(dataResolverKey, this.config.invoke);

Would your use case be solved by doing so?

@bboure Yeah it's a bit hacky for sure and your proposed solution looks great!
However, while inspecting the request I can't see that it has any payload.info.* so I'm not sure what you mean by

We now get the fieldName and fieldParent from the payload

I interpret what you say that it would get attached automatically somehow? That would be great since then I could further simplify my mappings.

@JimmyHurrah try to rebase from master and reinstall node dependencies.
This is a new feature in amplify-cli that I included in the latest release of this plugin.

I can't find any of the fields you speak of.
Im using:
<EMAIL_ADDRESS><EMAIL_ADDRESS>Is it some kind of codegen thing in amplify-cli? all our templates are  written by hand.

@JimmyHurrah Could you add a console.log(req); here
Don't forget to yarn build --watch.
You'll also need to rerun the simulator after each change.

@bboure Ah, I see the misunderstanding now! The fields you are talking about are on the $context going into the template. We don't pass the whole context as payload hence the info field is gone when it arrive as part of the request.
With this knowledge, I might be able to reduce our templates to just 2, One for Invoke and one for BatchInvoke. Today we have the 'fieldName' and 'parentTypeName' hardcoded in each template as 'field' and 'type' 😅
Im not sure about the fix here in serverless-appsync-simulator though. It might be possible that more people does not pass the context.info into the payload 🤔

@JimmyHurrah you are right. I forgot about that "detail" 🙁
For now, I guess we could use parentTypeName and/or fieldName if present, and if not, keep doing as it is now.
Here is what my lambda-request.vtl file looks like
{
    "version": "2018-05-29",
    "operation": "Invoke",
    "payload": {
      "args": $utils.toJson($context.arguments),
      "arguments": $utils.toJson($context.arguments),
      "identity": $utils.toJson($context.identity),
      "source": $utils.toJson($context.source),
      "info": {
        "fieldName": $utils.toJson($context.info.fieldName),
        "parentTypeName": $utils.toJson($context.info.parentTypeName),
        "variables": $utils.toJson($context.info.variables),
        "selectionSetList": $utils.toJson($context.info.selectionSetList),
        "selectionSetGraphQL": $utils.toJson($context.info.selectionSetGraphQL)
      }
    }
}

```

but of course, other might just pass them directly, maybe:

````vtl
{
    "version": "2018-05-29",
    "operation": "Invoke",
    "payload": {
      "args": $utils.toJson($context.arguments),
      "arguments": $utils.toJson($context.arguments),
      "identity": $utils.toJson($context.identity),
      "source": $utils.toJson($context.source),
      "fieldName": $utils.toJson($context.info.fieldName),
      "parentTypeName": $utils.toJson($context.info.parentTypeName)
    }
}

```

So, this is not ideal...

Ideally, we would need to receive the `$context` object within the `load()` function, but that would require some changes in https://github.com/aws-amplify/amplify-cli/tree/master/packages/amplify-appsync-simulator

I guess we could try, and at the same time, implement `BatchInvoke` directly in there (right now it is implemented only here).

Not sure if and how to reopen this so I put up a new PR https://github.com/bboure/serverless-appsync-simulator/pull/30


patch: mark cloudflare:email as external for email routing api (beta)

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[x] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[x] This message body should clearly illustrate what problems it solves.
[x] Ideally, include a test that fails without this PR but passes with it.

Tests

[x] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[x] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Hey, why is this needed? Do you have any links to the docs on the feature as I'm not familiar with it

Hey, why is this needed? Do you have any links to the docs on the feature as I'm not familiar with it

Here is the example usage: https://developers.cloudflare.com/email-routing/email-workers/send-email-workers/
Very sorry, I wanted to include the docs but there was no section in the template for it.

@chientrm @benmccann
Hello,
we had an issue about node: modules not being resolved correctly, and thus making a PostgreSQL driver module unable to work
Could you please take a look into the issue and add node:* as well here ?

Please track #10544 .
Check out my comment on how to use my temporary adapter meanwhile: @chientrm/adapter-cloudflare


Landing page wireframe

Landing page wireframe

@suyashgautam sir can you please tell me how to squash the commits?


Fix #494 - cleanup vendor bundle

Use git archive HEAD --format zip --output=repo.zip if you want to test.

Hi @fredericdelordm
Did you talk about something you did not merge in the release notes ^^ ?

Hi @williamdes
What is it about? If so, it’s my mistake, not his.
SoloJe

Hi @williamdes
What is it about? If so, it’s my mistake, not his.
SoloJr

On https://github.com/Mangopay/mangopay2-php-sdk/releases/tag/3.7.0 it says "Cleanup the vendor bundle, to reduce the size of the SDK"
But my work was not merged, the release notes and changelog need to be edited


Paragraph-generator added

Title and Issue number

Close #3335

I have added the Paragraph-generator. Can it be merged now?
Checklist:

[X] I have mentioned the issue number in my Pull Request.
[] I have commented my code, particularly in hard-to-understand areas
[] I have created a helpful and easy to understand README.md

@MohitGupta121 Can it be merged now?


fix: sort the profile with "B" alphabet

Some of the B names are in the wrong place,

In this PR, B Section is sorted

Closes #1218
__
  Summary: :hammer_and_wrench: This code needs a fix  |  Tags: Inefficient

Hey, @kabir0x23 just a PRO tip:
When creating a PR and if there is some issue related to that in this case #1216, you can do something like this in the PR description Closes #1216 Fixes #1216 so it will link the issue with the PR, and when the PR is merged, it will auto-close the issue, we don't need to do it manually.:)  Here is the Official Blog
__
  Summary: :hammer_and_wrench: This code needs a fix

Hey, @kabir0x23 just a PRO tip: When creating a PR and if there is some issue related to that in this case #1216, you can do something like this in the PR description Closes #1216 Fixes #1216 so it will link the issue with the PR, and when the PR is merged, it will auto-close the issue, we don't need to do it manually.:) Here is the Official Blog

That's nice, didn't know about these before that we have to mention one of these: close, closes, closed, fixes, fixed to auto-close the Issue.
I always think that why the issues are not getting closed by themselves after the PR got merged 😅.
Thanks for the tip Pradumnasaraf😄, will keep it in mind.

Hey, @kabir0x23 just a PRO tip: When creating a PR and if there is some issue related to that in this case #1216, you can do something like this in the PR description Closes #1216 Fixes #1216 so it will link the issue with the PR, and when the PR is merged, it will auto-close the issue, we don't need to do it manually.:) Here is the Official Blog

That's nice, didn't know about these before that we have to mention one of these: close, closes, closed, fixes, fixed to auto-close the Issue. I always think that why the issues are not getting closed by themselves after the PR got merged sweat_smile. Thanks for the tip Pradumnasarafsmile, will keep it in mind.

Awesome, we are always learning :)


Broken Netlify CMS due to Github master branch name change to "main"

When a branch is not specified in config.yml, Netlify defaults to using master branch of repo.  Due to recent name change of master branch to main , this creates an API_ERROR: cannot find branch in CMS when publishing entries and 404 errors on initial CMS load.
To Reproduce

Create a new repo and project utilizing Netlify CMS, netlify-cms-app .  I used gatsby.js for my project.
Setup config.yml in project without specifying branch name under:

backend:
  name: github
  repo: org/repo

Publish a new entry in Netlify CMS

Expected behavior
Initial load of localhost:8000/admin results in 404 (that are handled well). Main problem is introduced when publishing CMS entries. API_ERROR occurs.
Applicable Versions:

Netlify CMS version: 2.12.25
Git provider: Github
Node.JS version: 13.13.0

CMS configuration
backend:
  name: github
  repo: jsl15c/repo
media_folder: static/assets
public_folder: /static
collections:
  - name: Product
    label: Product
    folder: product
    create: true
    fields:
      - { name: name, label: Name }
      - { label: Description, name: description, widget: text }
      - { label: Price, name: price, widget: number }

You'll have to set a branch manually if you want to use something else than master:
backend:
  name: github
  repo: org/repo
  branch: main

@tomrutgers I realize that, but I figured it may be good to add logic to handle this change in Githubs default naming conventions

I see, thanks for clarifying!

Could this be added to the default github config code block in the docs? 🙏 I appreciate the available options are  outlined in the account settings overview but with main being the default branch name in github now, many people who go straight to the github How To will end up with errors.

Hi @stephlocke, would you mind submitting a PR for it? You can do it by clicking edit this page here https://www.netlifycms.org/docs/github-backend/

👍 #5264

Closing as stale and/or outdated.


Add a swtich to exclude code of devtools

Build with flag '-Ddisable_devtools=1' to turn on the switch.

@d0ngjun , thanks

Just a reminder:
Don't forget add reducing size info into git log.

@d0ngjun @halton

LGTM


Customizable "Project" text in top left of appbar

This would be a very useful feature, as I often have multiple windows open with different project. If the word "Project" defaulted to the name of the folder I have open in Sublime Text, I'd be able to more easily discern between multiple open projects. Love your packages, thank you for your work!

Duplicate of #5 #21


[file-format][bytecode-verifier] new bytecodes for vector operations - (92)

Motivation
Not all native functions are equal. Some native functions are more applicable in the Diem context while other are more generic and may be better supported at the language level. Vector is one example that may be promoted to have some support at the bytecode level.
Added the following new bytecodes to support basic vector operations:
VecPack(N) Create a vector of length N by consuming the last N elements from stack
VecLen Get the length of a vector
VecImmBorrow Acquire an immutable reference to the element at a given index of the vector
VecMutBorrorw Acquire a mutable reference to the element at a given index of the vector.
VecPushBack Add an element to the end of the vector
VecPopBack Pop an element from the end of vector
VecUnpack(N) Destroy a vector of length N and unpack its elements onto the stack.
VecSwap Swaps the elements at two indices in the vector
Several related bytecode verifiers are updated too, including

Bounds checker: the signature index in the bytecode is within bounds
Signature: the signature index in the bytecode corresponds to a single-token, non-reference signature
Stack usage: the vector operations consumes and also produces the correct number of values on the stack
Type safety: vector and the argument types are correct. For VecPack(N) the last N elements on the stack must have the element type.

Reference safety: vector are in a correct imm/mut state when related operations happen
Other misc but related updates include

Added new bytecodes to the zero-cost gas schedule table
Added new bytecodes to the initial gas schedule table, copying values from the native op table
Proptest fuzzers are updated to produce valid and invalid inputs regarding these bytecode

A larger context that is considered is the separation of Move stdlib and Diem framework. Promoting native vector operations into bytecode will ease the separation.
As a small side benefit, this will also improve the user experience of using Vector in Move. At least we don’t have to write use 0x1::Vector all the time for basic vector operations. And also shrink Vector.move from stdlib.
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan

cargo test --package bytecode-verifier-tests --lib -- unit_tests::bounds_tests::empty_module_no_errors --exact --nocapture
CI/CD test are covered

/canary

:sunny: Canary successful

/land


Create some "getting started" material for newcomers to Jupyter

Context
There are many cases where 2i2c hubs are used by newcomers to the Jupyter / PyData / etc ecosystem. Sometimes those newcomers aren't in an environment where they get a lot of introductory material from the instructors (e.g. as part of a hackweek). In these cases, it would help them make rapid progress if they had some high-quality notebooks / instructions / etc that they could follow in order to learn quickly on a hub.
ref: this was also noted in the Jack Eddy event:

A hub that starts with a directory of simple tutorials (and a minimal kernel that satisfies the needs of those tutorials) would be a good default "base hub" feature. Additional hub areas and custom kernels could be created depending on the subject/workshop area.

Proposal
We should define a minimal set of "getting started" notebooks that work with the "base JupyterHub environment", and an easy way for hub users to grab copies of those notebooks themselves in order to learn more what they can do with Jupyter / JupyterLab / etc.
Updates and actions
No response

@fperez created two intro folders for the Jack Eddy event here: https://github.com/jack-eddy-symposium/intro-git-jupyter
One for git and one for jupyter. They would be great starter notebooks. As an aside, I'd also suggest that sorting authentication ahead of future events (e.g., by git id or orcid id) would help with getting the most out of these hubs. I think this could be handled part of event registration. @fperez also created a small notebook that authenticated from the hub to git that made life a lot easier during the event.

Hi 2i2c team! I'm jumping in to say that I'd love to collab and share what our Community Management team is currently gathering together as part of some GitHub onboarding (I'm one of the Community Managers at The Alan Turing Institute).

I agree that there should be some "getting started" notebooks that try and ramp up users ("60 seconds to Jupyter", "Your first 5 minutes in Python", "Quickstart to using Python and Jupyter", or similar kind of thing) that are available for users as soon as they log in to a hub.  This documentation does not need to be comprehensive but could point to additional material for further information.  The goal could be to ensure users feel like they know just enough to able to participate in the hackweek / workshop / course / community.
I know that there are many resources already out there aimed at intro to python, pydata, jupyter, visualization, git, etc. We should try and pull content from those "upstream" sources where possible.  If the Turing Institute has such materials that would be awesome, but I'll note that Project Pythia's Foundations book may be a good source.


Draft: Update Wave with Laravel 9.

This PR updates Wave's Laravel application to a base Laravel 9 version and also bumps all dependencies to support Laravel 9. This is in response to #46 and my own desire to update the base Laravel app to a newer version.
Updating to Laravel 9 will force a minimum of PHP 8.0.2, 7.4 and lesser will not work anymore since Laravel 9 forces ^8.0.2.
PR is not fully tested yet, hence why it's being submitted as a draft. Testers are more than welcome. To test, clone this PR and report any issues found back here and they'll be resolved.
Tested and working on PHP 8.1+

[x] Authentication
[x] User Profiles
[x] User Impersonation
[x] Subscriptions
[x] Subscriptions Plans
[x] User Roles
[x] Notifications
[x] Announcements
[x] Blog
[X] API
[X] Voyager
[x] Themes

lmaoo, thank goodness I saw this. I was just about to start updating wave to Laravel 9 By myself lolll

Im so happy !!!

Is there an ETA for this PR?

Is there an ETA for this PR?

Not from my point of view. It's up to the @thedevdojo team when or even if this gets merged.
If you want to use Laravel 9 instead of using Laravel 8. I've released Surf in the meantime. It's a fork of Wave that's in essence just this PR merged or you can download this PR directly from my Wave fork, or wait until it's potentially merged.

@bobbyiliev any possibilities to merge this one so we can benefit from version 9?


Ensure DB migrations work properly in a clustered setup (fabric)

Failure conditions:

We run the migration too early

We run the migration before raft is fully initialized, either against an empty DB (before raft entries have been applied) or while raft entries are being applied.
We're waiting for a cluster to be homogenous before migrating and read operations expect migration to have happened already.

We run the migration too late

We run the migration after raft is initialized, and after we've accepted changes, which are expecting to run against a migrated database.

We don't prevent an incompatible version from joining the cluster

We have a homogenous cluster, it gets upgraded and the various databases get upgraded. New updates are accepted and then an older version joins the cluster and may not correctly apply the newest journal entries.

Proposed solution:

Migrate as soon as cluster is homogeneous

This means read operations will need to be coded so that they deal with DB data temporarily in the old format

Migration is a raft journal entry, so will get kicked off by the leader and will (hopfully) happen in the right place in the raft journal
We check on startup if the DB version is greater than our version. If so, we kill the process with an error message, saying that the DB version is too high.
We check on migration command if the version is unsupported (too high). If so we kill the process as well.


Contribution

Hi,
I recently start writing for projects via utopian, may I provide some documentation like FAQ for this project.
You may also  request other forms of documents needed for the project.

Hey! I'm not sure how it would look like, could you elaborate a bit?

FAQs is a document which would help users navigate easily on the site.
It answers basic questions users can have about the project.

I don't think the FAQ for users is needed as it is a relatively simple app, but FAQ for developers (those who want to contribute, clone the project for their own idea) would be very welcome.

OK thanks,
if you need FAQs for users later on or privacy policy, you can contact me


TableName improvements

TableName should be exported from gcp.bigquery, so one can use bq.TableName?
TableName should also have a fullname property.
This extends to other types such as DataSetName.

The export was done in 3f48c8e37aba475a496ac2676cc2f0018f9f3378
As these are tuples, not classes, adding fullname is a bit more tricky - it may be possible to patch a method in otherwise we would need to make them classes.


Googlenet inference on fp16 fails in MIOpen fwd convolution call for fully connected layer

Steps to reproduce.

take a pretrained caffemodel for googlenet.
convert to IR
quantize to fp16
run anntest
throws the following error
"MIOpen-1.7.1/src/ocl/convolutionocl.cpp:1129: Fwd Convolution cannot be executed due to incorrect params"

@paveltc is this a MIOpen bug? can we transfer this issue to them?

I have already filed this issue to them.

This bug has been reported to MIOpen team.


Transfer Bitcoin

Hi. I did transfer bitcoin from my Copay account to Xapo Debit Card. Its clearly said that within 30minutes will be confirmed but rite now almost a day i didnt receive the fund from Copay to Xapo Card and its happen like this. Please do advice.

I think you have the wrong project.

Then how i wanna ask about the copay system?
On May 23, 2017 13:53, "Randall Degges"<EMAIL_ADDRESS>wrote:

I think you have the wrong project.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/rdegges/btc/issues/1#issuecomment-303297452, or mute
the thread
https://github.com/notifications/unsubscribe-auth/Abi0LYsnVNa_xsi962nTYVzgJmB-WUW5ks5r8nRSgaJpZM4NjGPJ
.

This is a command line project for coinbase. If you have a general question about bitcoin, or whatever bank you are using, you might want to try contacting the customer support for your bank! Best luck!


Leave only code input triggers and output message type

Currently, we support 3 different combinations of messaging contracts (-> means a message is sent). Let's say that we store contracts on the producer side. Our producer is service called A.

code input triggers an output message A -> B
input message triggers an output message B -> A -> B
input message gets swallowed - there's no output message B -> A

come to think of it the 2nd and 3rd scenario are actually a combination of the 1st one. Let's imagine that we have service A and B.
A -> B (case 1)
B  -> A -> B (case 2). This actually is B -> A (case 1) and A -> B (case 1 again). So we should have a contract on A and B side.
B -> A (case 3) - case 3 is actually case 1. The contract should be on the B side, not the A side.
I think that we should remove these 2 combinations.
WDYT @jkubrynski @Fitzoh @mbogoevici @dsyer

From Gitter:
Andrew Morgan @mogronalol Jul 18 18:18
B -> A -> B
Not sure I get splitting this up:
On B side calling bMethod() will send a message M1 to A
On A side consuming message M1 will send a message to B
So on A side do you still not need to do consume and produce of a message in one contract?
Then when you consume the message on A side, that needs to be trigger by running the stubs generated on b side?
(I’ve not got to the stubs yet)

Marcin Grzejszczak @marcingrzejszczak Jul 18 18:19
actually you can still split it into 2 cases... B calls A (1st case) , A calls B (2nd case). You don't necessarily want to check the logic of a processor
you want to check that on B side that A can trigger a message that you understand
and on A side that B can trigger a message that you understand

Andrew Morgan @mogronalol Jul 18 18:22
I need to experiment with the consumer side. But would you want the stub of B to produce a message M1 to A? So then when you test A, you run the stubs, and it get’s the M1 message sent to it?
So then when you verify A does the right thing when it gets the message from the stub, what do you verify?
Because I don’t necessarily think it would be so bad that it verifies that it produces another message
(In addition to anything else that is verifiable)
But then I guess, that could be separate from the CDC?

Marcin Grzejszczak @marcingrzejszczak Jul 18 18:25
so let's assume that the flow looks like this. B sends a message to A with list of tickets to buy. Then A sends back the message to B with a list of bought tickets.
So IMO we can have 2 separate cases.  A then asserts that it can properly parse the incoming message with a list of tickets.
Then B writes a contract for a message that A would send. With a list of bought tickets. Then B writes integration tests to see if it can parse the result
does it make any sense? :stuck_out_tongue:

Andrew Morgan @mogronalol Jul 18 18:26
Yes
It depends how you want to test. Because your contract in B which sends the list of bough tickets needs to be trigger by something. So you could just trigger it by a method call.

Marcin Grzejszczak @marcingrzejszczak Jul 18 18:29
exactly
that would be the case
in both contracts you would trigger by method calls

Andrew Morgan @mogronalol Jul 18 18:29
However I think could also useful be useful to trigger it from consuming a message from the stub of A
So it’s probably more of a personal preference?

Marcin Grzejszczak @marcingrzejszczak Jul 18 18:31
But then we're testing an implementation imo
We could then test if a http request triggers a message
But we don't do that for a reason

Andrew Morgan @mogronalol Jul 18 18:34
If you see the system as a black box, you could argue a message input -> outputs a message
Refactoring aswell becomes more painful if you don’t treat it that way
On the other hand it might be beastly to wire the whole app together, but you could end up doing it once and sharing it across all tests
Also, maybe that verification doesn’t belong in the contract

Marcin Grzejszczak @marcingrzejszczak Jul 18 18:43
Contract testing is not about doing black box testing of your system isn't it?

Andrew Morgan @mogronalol Jul 18 18:44
No
But it depends on how you want to do it

Marcin Grzejszczak @marcingrzejszczak Jul 18 18:44
That's true
But I think we should promote good practices

Andrew Morgan @mogronalol Jul 18 18:45
All I’m saying is it’s a grey area, stub input triggers a contract output doesn’t seem that crazy.
Who knows, if you don’t have that test then maybe when you deploy, something breaks along the way
Because you didn’t do the whole slice

Marcin Grzejszczak @marcingrzejszczak Jul 18 18:56
I'd say that the whole slice is part of end to end. But If sat that I see more value in this scenario than scenario 3

Another use case I have is if you follow the request-reply pattern with messaging. In this case, you want to define a stub just in the same way as you would a HTTP endpoint. So you would need to define an input and output message together in the contract.

It turns out that there are users who still want this feature. So I'll close this issue.

Scenario 3 seems to actually be just scenario 1 but from the consumer's perspective. Maybe it should be removed really?

Done via https://github.com/spring-cloud/spring-cloud-contract/issues/1837


LDAP User Import Error

Hi there!
I'm currently in the 'Development' Environment and am testing importing users using a CSV, with LDAP Configured to access an Active Directory Server.
When trying to import, i'm getting the following error. Could anyone shed any light? Many thanks for your help.

I should add that i'm very much a beginner with Ruby on Rails apps, so i might be missing something basic!

Thank you for the comment. This application is currently only receiving security updates. Please see https://gitlab.com/yale-sdmp/reservations for the latest updates.


Add a license to the repository

I recently came across your project Qiskit-labs and I noticed that the repository github.com/fhernandez93/Qiskit-labs currently does not have a license specified.
Why Adding a License is Important?
As GitHub documents

Public repositories on GitHub are often used to share open source software. For your repository to truly be open source, you'll need to license it so that others are free to use, change, and distribute the software.

Would be possible to add a valid license to this repository? Probably something really OpenSource such as the Apache 2.0 license would fit really well.
Thanks!

Thanks for your feedback. I just added the license.

Thank you!


move the developed code(python) for proposed data processing configuration file into separate branch

[ ] Analyse the changes in the current code
[x] separate the code from 3.7 - ( 3.7 python code for ingestion processing remains as is)

since cQube 3.7 and cQube_Edu 1.5 are in merging process, hence this is not valid here.


nixos/systemd-boot: Fix regression in builder script

Avoid running Python scripts in the root of the package, as this triggers os.listdir on the Nix store directory during import. This operation can be time-consuming on large store directories (see issue #283795 for more details).
The issue was initially fixed in #284153 but it looks like it was unintentionally brought back in in #306339.
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[X] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release 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

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

I get this error when applying the patch:
[bernie.r] building '/nix/store/ihzyrrwk7ir5hww00lyb3khgknxxw67s-system-path.drv'...
[bernie.r] building '/nix/store/jfk5pg4rapqxdnlhqs3v0nvlj61c2fgh-unit-display-manager.service.drv'...
[bernie.r] building '/nix/store/mblwfgj2b0c5hrrp5jmik5j5kxcc6cpf-X-Restart-Triggers-polkit.drv'...
[bernie.r] building '/nix/store/4hyrj7gi45d47qav8lag87cfr6xn3zqm-dbus-1.drv'...
[bernie.r] building '/nix/store/hisqa3qdhzyb61h6dj7763wh40az4lzr-etc-pam-environment.drv'...
[bernie.r] building '/nix/store/s3azl5aswrwyjkrs66yglyh4v33k8gqj-set-environment.drv'...
[bernie.r] building '/nix/store/hjm9db68skqdlxknlgjasp4j9a5q8snf-unit-accounts-daemon.service.drv'...
[bernie.r] building '/nix/store/w2z0msmn9lczlb5c2w3vl76i6wdhifcm-X-Restart-Triggers-dbus.drv'...
[bernie.r] building '/nix/store/a21jyvr23642yv8495f2pcwgkmjk6346-etc-profile.drv'...
[bernie.r] building '/nix/store/m2f75iibpb2bz3w3cgqpw7sp5634c1ap-etc-zshenv.drv'...
[bernie.r] building '/nix/store/5wa5p5ivlgcxcgbhr4kcabygw65dk02v-unit-polkit.service.drv'...
[bernie.r] building '/nix/store/ni4kxxh0r0grxn8f9vk2i78zjskn1c4s-unit-dbus.service.drv'...
[bernie.r] building '/nix/store/p33gr19vfg5pc9pngc6hf63pw6hi52ah-unit-dbus.service.drv'...
[bernie.r] building '/nix/store/ghawi9f4zfw9ii771400fib5ka1fg08w-system-units.drv'...
[bernie.r] building '/nix/store/rlqgga962a6x2cdgmgkjxbiafsykgapn-user-units.drv'...
[bernie.r] building '/nix/store/qva0w9ahi5dkjnn6r8asc1c0n12qq78g-etc.drv'...
[bernie.r] building '/nix/store/iav5f1vs09hv08afdd5vsixi2f60pdi9-nixos-system-bernie-24.11.20240707.1abf51a.drv'...
[bernie.r] /nix/store/z7q6ww8xny1bmyhh4rwvi89x0h1l8q8s-install-systemd-boot.sh: line 2: /nix/store/w9d1p49ikvm2k76ngpqkv4darggiqsw2-systemd-boot-builder: Is a directory
[bernie.r] Failed to install bootloader
[bernie.r] warning: error(s) occurred while switching to the new configuration
[bernie.r] [Command failed: 1] nixos-rebuild switch --fast --use-substitutes --option keep-going true --option accept-flake-config true --build-host '' --flake /nix/store/lg133sp9zzmvrdqrm1b7724ynv332wjx-source
[bernie.r] $ nixos-rebuild switch --fast --use-substitutes --option keep-going true --option accept-flake-config true --build-host '' --flake /nix/store/lg133sp9zzmvrdqrm1b7724ynv332wjx-source
[bernie.r] building the system configuration...
[bernie.r] /nix/store/z7q6ww8xny1bmyhh4rwvi89x0h1l8q8s-install-systemd-boot.sh: line 2: /nix/store/w9d1p49ikvm2k76ngpqkv4darggiqsw2-systemd-boot-builder: Is a directory
[bernie.r] Failed to install bootloader
[bernie.r] warning: error(s) occurred while switching to the new configuration

I get this error when applying the patch:

My bad, I thought I tried it correctly here. It should be fixed now, can you try again ? Thank you !

@JulienMalka since you wrote the original PR, do you have an opinion on this one ? Thank you !

I have tried running the tests but seems that there is still an issue:
/nix/store/7r50d66zzf5xny6qfrb10lncxnmzscr3-install-systemd-boot.sh: line 2: /nix/store/5fh2av2banx7hckx6dxiwfya7b7p4ldl-systemd-boot-builder/bin/systemd-boot-builder: Not a directory

@JulienMalka @Mic92 my bad, I fixed it and the implementation is simpler now. Nixos tests pass for me.
If you have time to review it once more. Thank you !

If you have time to review it once more. Thank you !

Will take a look at this tonight.

I have tried running the tests

Which test did you run specifically?

Result of nixpkgs-review pr 323962 run on aarch64-linux 1

1 package blacklisted:

nixos-install-tools

1 package built:

disko

can you rebase this ?
secure-boot test fails on master:
Exception: command sbctl sign /boot/EFI/nixos/*bzImage.efi failed (exit code 1)

@aktaboot I have just rebased.
Running nix-build -A nixosTests.systemd-boot works for me.


NIFI-5856: When exporting a flow that references a Controller Service…

…, also include the ExternalControllerServiceReference's in the snapshot. When importing/updating a flow, if a Controller Service that is inherited is referenced, attempt to find any one ControllerService that gets inherited whose name matches the reference and if found link to that Controller Service.
Thank you for submitting a contribution to Apache NiFi.
Please provide a short description of the PR here:
Description of PR
Enables X functionality; fixes bug NIFI-YYYY.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[ ] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[ ] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[ ] Has your PR been rebased against the latest commit within the target branch (typically master)?

[ ] Is your initial contribution a single, squashed commit? Additional commits in response to PR reviewer feedback should be made on this branch and pushed to allow change tracking. Do not squash or use --force when pushing to allow for clean monitoring of changes.

For code changes:

[ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[ ] Have you written or updated unit tests to verify your changes?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

Will review...

@mcgilman pushed a new commit to address all feedback.

I'm good with everything else in this PR, just my one comment above about checking authorizations.

Thanks @bbende I have pushed another commit to address this.

+1 Latest changes look good, going to merge

thanks emm.. I want to know  if Controller service names aren't unique,how to set a NIFI property to specify strict and nonstrict policy for multi-match.

@Franky-Jay there is way to specify strict matching, there is just a convention that when importing to the next environment if the flow previously used a service named "Foo" and there is only one service named "Foo" of the required type, then that one is selected. Otherwise you have to manually select the service you want after importing, and then this will be retained across future upgrades.


bump for Cypress 13.4.0 release

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Generic Custom Pre-Processing Traits & Caller Identity Modeling?

Overview
Would it make sense to add a generic custom pre-processing trait like @refine(functionId: String | Enum, protocols: List[shapeId]) to the core library? This can signal server stub code generators to make users register pre-processing functions which extend their built-in deserialization systems.
From a UX perspective, this lets users skip writing their own Smithy traits and the supporting code generator logic for custom type refinement and constraint traits. For users not comfortable with writing or extending code generators, this eliminates a lot of friction (kind of an extension of #117).
Background
Today, Smithy provides various type refinement and constraint traits in its core library. These traits are effectively a set of standard pre-processing directives. For example:

@default

Injects static default values (null safety in a sense).

@required

Null check.

@jsonName

Maps JSON payload fields to the modeled input (override guessed JSON field name).

@httpHeader

Maps HTTP header fields to the modeled input.

To provide a batteries-included experience, server stub code generators can augment built-in deserialization mechanisms to automatically handle these. Support across all code generators will generally be strongest for core library traits and weaker for custom traits (e.g. framework-specific).

I'm including validation in deserialization because stuff like field length validation is really just type information that's expressed as validation logic. This is done because the underlying programming language's type system isn't expressive enough to define, for example, a string type with length bounds (e.g. String<Length<2,7>>) or it's cumbersome to work with.

Unmodeled information, however, has a rougher experience.
For unmodeled traits or ones unsupported by the underyling code generator, extra validation is done in the middleware or handler layers instead. There's no guarantee that the code generator tells you it doesn't support a trait either. It might just silently ignore it.
For unmodeled members, the Smithy TypeScript and Rust server SDKs provide escape hatches for propagating unmodeled properties into the code-generated server stubs. The TypeScript server SDK has contexts while the Rust server SDK has extensions.
The data flows for the Smithy TypeScript and Rust server SDKs look like this today:

Effectively, modeled inputs are generally restricted to what default deserialization can handle while everything else is generally placed in unmodeled inputs.
Context-styled escape hatches are fine if unmodeled information is a non-essential input to a service operation (e.g. observability) but introduces room for a lot of subtle bugs if the information is essential (e.g. caller identity). An extreme example is Go's context library which many misuse as an untyped map to pass both essential and non-essential information through their programs.
Bringing more info into Smithy models lets code generators enforce more complete modeled inputs before propagating them to middlewares and handlers.
Auth Example
To paint a clearer picture, lets consider auth.
For services with auth, operations are a function of the caller identity (e.g. deleteSong(userId, songId): deleteSongOutput if I destructure deleteSongInput into 2 arguments). Since identities are a formal resource in the service (e.g. AWS IAM identities like roles and users), it seems reasonable to model them like this in Smithy:
resource User {
    identifiers: {
        userId: string
    }
    properties: {
        // What other identities can do to this resource.
        resourceBasedPolicy: document
        // What this identity can do to other resources.
        identityBasedPolicy: document
    }
}

resource Song {
    identifiers: {
        songId: string
    }
    properties: {
        // What other identities can do to this resource.
        resourceBasedPolicy: document
    }
    delete: DeleteSong
}

@http(method: "DELETE", uri: "/song")
operation DeleteSong {
    input: DeleteSongInput
    output: DeleteSongOutput
}

@input
@references([
    {resource: User}
    {resource: Song}
])
structure DeleteSongInput {
    @required
    userId: String
    @required
    songId: String
}

@output
structure DeleteSongOutput {}

In some (many?) auth schemes, however, the caller identity may not be given as a field that should be provided as-is in code-generated server stubs. Instead, it may need to be pre-processed into a usable form.
For HTTP specifically, the Authorization header may not be something that's useful to directly map onto a member in modeled input types. In fact, Smithy strongly discourages this in the @httpHeader trait documentation.
For example, AWS service requests use the AWS SIGv4 authN scheme. The AWS SIGv4 HTTP Authentication header documentation provides this example header:
Authorization: AWS4-HMAC-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request, SignedHeaders=host;range;x-amz-date, Signature=fe5f80f77d5fa3beca038a248ff027d0445342fe2855ddc963176630326f1024

An authZ middleware or business logic inside code-generated server stub implementations, however, probably instead only wants the AWS IAM unique ID (e.g. AKIAIOSFODNN7EXAMPLE) or an AWS IAM identity ARN (e.g. arn:aws:iam::111122223333:role/role-name) instead of the raw Authorization header.
Since the AWS IAM authZ APIs aren't public, lets use the Amazon Verified Permissions IsAuthorized API and AWS IAM Policy Simulator SimulateCustomPolicy API as examples. Both of these APIs generally are something like isAuthorized(callerIdentity, resource, operation, identityBasedPolicy, resourceBasedPolicy): boolean where callerIdentity isn't the raw Authorization header.
Likewise at the business logic layer, we may have a ListResources API which does a database query with a filter using a callerIdentity that isn't the raw Authorization header.
In essence, it can be useful to enforce some member transformation before finalizing modeled inputs for handoff to middlewares and business logic.
There's 2 ways I can think of doing this while keeping caller identity information in the modeled input with today's Smithy server SDKs.
Bind the Authorization HTTP Header Anyways + Use Mutating Middleware
One option is to ignore the @httpLabel guidance and bind the Authorization header anyways.
@input
@references([
    {resource: User}
    {resource: Song}
])
structure DeleteSongInput {
    @required
    @httpHeader("Authorization")
    userId: String
    @required
    songId: String
}

This might seem reasonable to do since the @authDefinition and @httpApiKeyAuth traits don't seem to let you map their caller identity info onto input shapes.
Instead, it seems like code generators need to add an additional argument to server stubs and clients that pipe caller identity information through (e.g. deleteSong(deleteSongInput, authInfo, context): deleteSongOutput) to avoid member name collisions in generated types.
AWS SDK code generators follow this style where caller identity information is separate from the modeled input. For example, in the AWS SDK for Java 2.x we can do:
import software.amazon.awssdk.auth.credentials.StaticCredentialsProvider
import software.amazon.awssdk.services.lambda.LambdaClient

final var role_a_credentials = StaticCredentialsProvider.create(/* ... */);

final var role_b_credentials = StaticCredentialsProvider.create(/* ... */);

// Default to using role A credentials.
final var lambda_client = LambdaClient
    .builder()
    .credentialsProvider(role_a_credentials);
    .build();

final var role_a_invoke_response = lambda_client.invoke(request_builder -> request_builder
    .functionName("hello")
);

// Request-level override to use role B credentials.
final var role_b_invoke_response = lambda_client.invoke(request_builder -> request_builder
    .functionName("hello")
    // https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/awscore/AwsRequest.html
    .overrideConfiguration(config_builder -> config_builder
        .credentialsProvider(role_b_credentials)
    )
);

This is what the Smithy TypeScript server SDK expects people to do manually with contexts.

Then we introduce a mutating middleware that mutates the modeled input (e.g. DeleteSongInput) before passing it to subsequent middlewares and business logic.

No unmodeled inputs in this data flow diagram for simplicity.

This, however, introduces 2 subtle semantics.
First is that we've introduced an implicit dependency between middlewares because we're modifying the modeled input. The authZ middleware may not work if the caller identity mutation middleware isn't placed before it. If the server framework tries to run middlewares concurrently as a performance optimization, this middleware dependency information isn't automatically known to the framework. More abstractly, this approach has introduced mutability which allows a swath of bugs.
Second is that we've accidentally added a protocol-specific middleware in a place that should probably be protocol-agnostic. For a multi-protocol endpoint, other protocols may map a different value onto the modeled input member. The caller identity mutation middleware could get an HTTP Authorization header string or something else and must handle all cases correctly.
Use Contexts as a Side-Channel + Use Mutating Middleware
Another option is to just default to some empty/placeholder value for the modeled input member, add the value to a context object, then use a middleware to transfer the value from the context object to the modeled input.
@input
@references([
    {resource: User}
    {resource: Song}
])
structure DeleteSongInput {
    @required
    // This can get uglier if there's a @pattern trait on the referenced member.
    @default("")
    userId: String
    @required
    songId: String
}

If the context object is solely for capturing values to store in the modeled input, we can throw away the context afterwards like in the above diagram.

This is better than the other approach because the protocol-specific context creator can ensure the unmodeled input value it extracted is protocol-agnostic.
We still have the same mutation semantic though so we still have room for subtle ordering and concurrency bugs.
Wish List
Essentially, we'd like some standard trait respected across server code generators that lets users extend built-in deserialization in a safe and easy manner. This reduces the number of situations requiring less safe unmodeled input logic and middlewares that mutate modeled or unmodeled inputs.

With a generic custom pre-processing trait, we could do something like this in our Smithy models:
use aws.protocols#restJson1
use aws.protocols#awsJson1_1

@input
@references([
    {resource: User}
    {resource: Song}
])
structure DeleteSongInput {
    @required
    @refine(functionId: "http_auth_SIGv4_deser", protocols: [restJson1, awsJson1_1])
    userId: String
    @required
    songId: String
}

A server stub code generator could then generate this:
public enum FunctionId {
    HTTP_AUTH_SIGV4_DESER="http_auth_SIGv4_deser"
}

public abstract class MusicServiceStub implements Service { /* ... */ }

public class SmithyHttpServer {
    // Used to check if all refiners were registered. Complain if not.
    private Set<FunctionId> expectedRefiners = Set.of(FunctionId.values());

    public void registerService(final Service service) { /* ... */ }

    public void registerRefiner(final FunctionId functionId, final Callable<SmithyHttpRequest> refinerFunction) { /* ... */ }

    public void start() { /* ... */ }
}

Users would then register their service and refiners with the HTTP server implementation.
public class MusicService extends MusicServiceStub { /* ... */ }

final var music_service = MusicService.create();

final var smithy_http_server = SmithyHttpServer.create();

smithy_http_server.registerService(music_service);

final var refiner = /* Create a refiner function. */;

smithy_http_server.registerRefiner(FunctionId.HTTP_AUTH_SIGV4_DESER, refiner);

smithy_http_server.start();

This is probably a horrible sample implementation for many reasons but hopefully it gets the idea across.
A more robust solution might look something like Java's JSR-330 dependency injection annotations (@Inject, @Named) and how Dagger 2 uses them. Dagger lets you define a dependency graph of value providers based on explicit @Named annotations and type inference. It then uses code generation at build time to create the dependency injection wiring logic.
Assumptions to Question
All the previous points are based on these premises/assumptions:

Code generation can make modeled inputs safer than unmodeled inputs.
Caller identity (auth) information should be part of modeled inputs instead of unmodeled/side-channel inputs.
This trait as proposed is only expected to be respected by server code generators for doing raw request to modeled input deserialization.

1 is primarily an implementation detail so safety is highly dependent on how well the code generators are designed.
2 is probably where opinions will differ. Should all auth and caller identity related things be encapsulated in authentication traits and passed separately from modeled inputs? What effects does this have on the readability of Smithy models or client code generation (can we still easily pass caller identity information separate from modeled inputs like the current AWS SDKs)? Am I just splitting hairs about whether to put some info in one function argument versus another?
3 it's not clear how client generators are also expected to interpret this trait. It seems like it might be too server-centric though @clientOptional exists. Also if this is applied to an output shape, is this a signal to have a client side refiner for raw response to modeled output deserialization? In that case, the trait is anisotropic in a weird way that has different meanings between input and output shapes.

Thanks for this detailed writeup!

[Reducing] the number of situations requiring less safe unmodeled input logic and middlewares that mutate modeled or unmodeled inputs

I think this actually dovetails into another problem we've been kicking around for a while that we're currently working on heavily: document schemas. Bear with me. You mention yourself that context is treated as an unmodeled bag of data, difficult to work with largely because you need to assemble the concrete representation yourself from it. This is essentially the same situation we find ourselves in with documents. Documents sometimes have defined schemas, and we therefore want a way to be able to easily construct concrete types from them.
I've actually got a working, hand-written example of this working in Python. Here's an example from the tests:
def test_doc_to_shape():
    document = Document(
        {
            "birdId": "123456",
            "location": {
                "latitude": "52.5163",
                "longitude": "13.3777",
            },
            "notes": "Has black spots in the grey hood area.",
        }
    )
    shape = CreateSightingInput(
        bird_id="123456",
        location=Location(latitude="52.5163", longitude="13.3777"),
        notes="Has black spots in the grey hood area.",
    )

    assert document.as_shape(CreateSightingInput) == shape

So if I were using a Python server implementation, I could do something like:
@dataclass(kw_only=True)
class AuthContext:
    id: str

    def serialize(serializer: ShapeSerializer): ...

    def deserialize(deserializer: ShapeDeserializer): ...

class BirdWatcherService:
    async def create_sighting(input: CreateSightingInput, context: Document):
        id = context["auth"].as_shape(AuthContext).id
        ...

In this case the AuthContext class would be generated from a shape that looks like:
// Marked as internal so as to not be generated into clients.
@internal
structure AuthContext {
    id: String
}

What's critical here is that that deserialize method is the same method we would use to deserialize the shape if we were instead parsing from a JSON or XML formatted byte stream over HTTP. So any constraints, validation, or other logic would carry over. This is also true for serialize.
You still of course need your middleware to take from the input, perform any necessary validations / transformations, and then populate the context. But with this you would be able to ensure that your context is consistently structured:
async def auth_middleware(
    request: HTTPRequest,
    context: Document,
    next: Callable[[HTTPRequest, Document], Any]
) -> None:
    id: str = await validate_auth(request.headers["Authorization"])
    context["auth"] = Document.from_shape(AuthContext(id=id))
    next(request, context)

All this of course relies on the ability to have shapes in the model not connected to an operation, which is something we will be adding. It also requires a pretty hefty refactor of the way clients and servers work, but that's also something we want to do where possible. I'm working on this right now for smithy-python, which has the advantage of not having been made GA yet.
To address some of your assumptions:

Code generation can make modeled inputs safer than unmodeled inputs.

Essentially what I've outlined above is a strategy to bring any-type data into a similar realm of reliability as normally structured data.i

Should all auth and caller identity related things be encapsulated in authentication traits and passed separately from modeled inputs?

Yes. Auth is expected to change, and to do so as backwards compatibly as possible. Having to change the code for every operation and operation invocation would be a major hassle. Comparatively it's often possible to simply smooth over the config changes on the client side. On the server side, the middleware can similarly present the necessary information (e.g. customer id) in a consistent way despite the auth type having different inputs.

This trait as proposed is only expected to be respected by server code generators for doing raw request to modeled input deserialization.

With the strategy outlined above, you don't need a trait, just some shapes. They can be made internal or otherwise be tagged to filter out during client code generation.

This thread is getting rather long and hard to understand exactly what's being asked, but I'll add some thoughts.

If we want to add a small transformation for a specific field, we have to completely replace the default deserializer with our own or use a mutating middleware instead of just registering a small function the default deserializer can defer to when handling this special field.

We don't want to ever support customizing a specific field's serialization or deserialization in a way that isn't called out by some protocol specific trait. This kind of customization has a cascading effect on all implementations across every programming language. It causes subtle incompatibilities between implementations that don't understand the customization. Smithy as an IDL, framework, and its serialization formats are supposed to allow interoperability between compliant client and server implementations; customizing the wire contract works against that. Maybe this is part of the motivation for this write-up, but I think it makes more sense to just not ever customize serialization and avoid the added complexity of trying to account for it in the model in a generic way.
What I think I'm reading in this thread is a tension between modeling everything in the Smithy IDL vs letting a framework provide additional context. I think a framework should be responsible for providing a common architecture and domain for describing things like identity, how something is authenticated, etc. The framework can be informed by things in the model like auth traits and find the matching implementation in that programming language (e.g., using an SPI in Java to match trait names to implementations). Code generated input structures don't have to carry this context. A context object can be added to whatever code is responsible for handling input or output on the client or server, and the context doesn't have to be totally open-ended either; you can make a dedicated placeholder for identity, and other common framework level context.


Manual approval required for workflow run<PHONE_NUMBER>: Aprove of release on Prod environment

Please approve or deny the deployment of the relaese version to the Prod environment.
Workflow is pending manual review.
URL: https://github.com/Water-XP-Scrumban-Fall/BigProject/actions/runs/5986581219
Required approvers: [DrShadowPLay]
Respond "approved", "approve", "lgtm", "yes" to continue workflow or "denied", "deny", "no" to cancel.

yes

All approvers have approved, continuing workflow and closing this issue.


Design for direct chat in member details page

According to https://github.com/vector-im/vector-web/issues/2099
The joined rooms should be displayed before the "start direct chat button".
We need a design for the mobile clients.

The current design is fine


Speed up division by bucket's size

By choosing primes which allow for faster division, we can shave off some time.
The exact performance depends on the architecture. The worst possible case is aarch64, where
(due to GHC shortcomings) we cannot benefit from faster division algorithms at all.
Nevertheless, there are some modest gains, mostly because the divisor is now passed unboxed
and remainders forced, so they are unboxed Int# as well. Here are numbers on macOS M2:
Comparison
  1000000
    insert
      vector-hashtables boxed:        OK
        35.6 ms ± 590 μs,  3% less than baseline
      vector-hashtables unboxed keys: OK
        25.2 ms ± 486 μs,       same as baseline
      vector-hashtables:              OK
        6.59 ms ± 115 μs,       same as baseline
    insert (resize)
      vector-hashtables boxed:        OK
        47.1 ms ± 480 μs, 10% less than baseline
      vector-hashtables unboxed keys: OK
        32.9 ms ± 498 μs, 10% less than baseline
      vector-hashtables:              OK
        9.79 ms ± 110 μs, 11% less than baseline
    insert, delete
      vector-hashtables:              OK
        10.4 ms ±  55 μs,  1% less than baseline
    find
      vector-hashtables:              OK
        4.28 ms ±  53 μs,  2% less than baseline
      vector-hashtables (frozen):     OK
        1.28 ms ±  15 μs, 14% less than baseline
    lookupIndex
      vector-hashtables:              OK
        2.40 ms ±  31 μs, 11% less than baseline
    fromList
      vector-hashtables: OK
        12.6 ms ±  75 μs,  7% less than baseline
    toList
      vector-hashtables:              OK
        56.7 ms ± 1.4 ms,       same as baseline

Running the same benchmark on x86_64 demonstrates much more pronounced benefits, up to 3x faster:
Comparison
  1000000
    insert
      vector-hashtables boxed:        OK
        44.8 ms ± 370 μs,  9% less than baseline
      vector-hashtables unboxed keys: OK
        32.2 ms ± 800 μs,  9% less than baseline
      vector-hashtables:              OK
        10.5 ms ±  55 μs, 26% less than baseline
    insert (resize)
      vector-hashtables boxed:        OK
        57.5 ms ± 223 μs, 18% less than baseline
      vector-hashtables unboxed keys: OK
        40.3 ms ± 295 μs, 24% less than baseline
      vector-hashtables:              OK
        16.2 ms ±  22 μs, 41% less than baseline
    insert, delete
      vector-hashtables:              OK
        16.2 ms ±  86 μs, 36% less than baseline
    find
      vector-hashtables:              OK
        3.91 ms ±  18 μs, 62% less than baseline
      vector-hashtables (frozen):     OK
        2.44 ms ±  14 μs, 68% less than baseline
    lookupIndex
      vector-hashtables:              OK
        3.78 ms ±  26 μs, 57% less than baseline
    fromList
      vector-hashtables: OK
        26.9 ms ± 157 μs, 14% less than baseline
    toList
      vector-hashtables:              OK
        61.7 ms ± 157 μs,  1% less than baseline

    find
      vector-hashtables:              OK
        3.91 ms ±  18 μs, 62% less than baseline
      vector-hashtables (frozen):     OK
        2.44 ms ±  14 μs, 68% less than baseline

That's a really impressive result.
    insert
      vector-hashtables:              OK
        6.59 ms ± 115 μs,       same as baseline
    insert (resize)
      vector-hashtables:              OK
        9.79 ms ± 110 μs, 11% less than baseline

That's probably because the new sequence of sizes grows a bit faster, so fewer resizes happened. Which isn't a bad thing.

@klapaucius @swamp-agr @ulysses4ever anything else you'd like me to do here? Or is it acceptable?

Impressive. Thank you :)


Chat do not open on firefox

Environment
I've installed the plugin in Firefox version 111.0.1 and set layout.css.overflow-overlay.enabled.
Problem
On the Bing site, I cannot click the Chat button.  During site inspection, I found out that link for the button is set to href="javascript:void(0)"

Mozilla is still reviewing the newest version (1.0.6). Can you check if the issue persists on the newest version?

I can confirm it's not working for me. Every time I click the "Chat Now" button, it opens another tab with the same modal displayed.

Likely that v1.0.7 will fix this. Unsure why Mozilla is taking forever to review the app.

I don't know why by it start working on "<IP_ADDRESS>" plugin version. Thanks for your help :))

I don't know why by it start working on "<IP_ADDRESS>" plugin version. Thanks for your help :))


upload to artifactory fails without username/pwd

I'm using an artifactory instance with no username/pwd protection.
Since the plugin does not find any username/password in settings file, it refuses to upload.
Actual behavior:
[ERROR] Failed to execute goal com.kiwigrid:helm-maven-plugin:3.4:upload (default-upload) on project helm: Execution default-upload of goal com.kiwigrid:helm-maven-plugin:3.4:upload failed: Credentials has to be configured for uploading to Artifactory. -> [Help 1]
Expected behaviour:
Make the error a warning and continue upload
Workaround is to provide a (dummy) username/pwd in the settings file

Please feel free to create an PR for this.
We will not implement this because we do not have this scenario.


Revert "Use default value of jdisc.debug.resources."

Reverts vespa-engine/vespa#19303
@bjorncs @baldersheim this turned on debug references for all of CD 😝

Are you sure it was not because of the related feature flag change?

Hmm, this wasn't quite right, but the logservers were set to debugging mode, and they got so slow everything failed :)

Yes, the feature flag affected all admin type of clusters. We could not restrict the flag to metricsproxy only.

Couldn't you fetch with the CLUSTER_ID dimension set to the cluster name, i..e "metrics" for the metrics proxy?
It's a slight contract violation of CLUSTER_ID, as it is supposed to be com.yahoo.config.provision.ClusterSpec.Id::value, but as long as the serialized feature flag overrides matches whatever is done in code it should be fine.  We could update the CLUSTER_ID doc about this since the model and service monitor cares more about the cluster name (aka cluster id in service monitor) than the node's cluster spec ID.
Alternatively we could add a CLUSTER_NAME.


Return an error if GetIPs failed

Previously, GetIPs was returning an empty slice if it failed, this
change adds support for bubbling up the error. Will address Virtualbox
error handling in a follow up PR>
Issue: #12
@variadico  @zquestz

LGTM!


assets: removed redundant bootstrap reference

bootstrap-sprockects is the same as bootstrap, but with the files
splitted so it's easier to embed in sprocket's workflow.
Signed-off-by: Miquel Sabaté Solà<EMAIL_ADDRESS>

ok. I'll trust you with that :). lgtm


Changed iptables to not lookup hosts

Should be faster lookup on iptables if firewall rules contain lots
of host IP addresses (no need for a DNS lookup on each one!)

Agreed! It's not displaying to the user, so this should be acceptable

Good catch :)


GInterface properties

Hello @badcel, @firox263 ,
I think we have to review the way to handle GInterface properties. I'm currently working on the widget catalog samples, I'm seeing that for now the generator is creating empty GInterfaces. I think we can at least generate an inner Native class which will contain the list of property names of that interface, so for example in the Box class we will have:
public static readonly Property<Orientation> OrientationProperty = Property<Orientation>.Register<Box>(
    Orientable.Native.OrientationProperty,
    nameof(Orientation),
    (o) => o.Orientation,
    (o, v) => o.Orientation = v
);

Also, since the Orientable interface for example can be used by many classes, I think it will be better to have the property descriptor in the interface, but not the properties.
public partial interface Orientable
{
    #region Properties

    public static readonly Property<Orientation> OrientationProperty = Property<Orientation>.Register<Orientable>(
        Native.OrientationProperty,
        nameof(Orientation),
        (o) => o.Orientation,
        (o, v) => o.Orientation = v
    );

    Orientation Orientation { get; set; }

    #endregion

    #region Native

    public static class Native
    {
        public const string OrientationProperty = "orientation";
    }

    #endregion
}

So in the implementations like Box we have:
public partial class Box : Orientable
{
    public Orientation Orientation
    {
        get => GetProperty(Orientable.OrientationProperty);
        set => SetProperty(Orientable.OrientationProperty, value);
    }
}

Like that we will not rewrite property descriptors in every implementations (what seems strange for me...).
What do you think ?

@na2axl :I think we can at least generate an inner Native class which will contain the list of property names of that interface

Yes you can do this as we have the same for classes already :+1:. The Native class should probably be protected or internal.

I think it will be better to have the property descriptor in the interface

This is the big question at first I intended to do this in the interface PR but then skipped over it, because for classes the property descriptors are public. And if we implemet an interface in the classic way, like we decided in #99, then the classes would have the public properties of the interface, too. But if they have the public properties, they should have the public property descriptors of the interface, too. But if we use the default interface implementation feature for the interface property descriptors, those are not visible on the class. This is the reason why i skipped it, it is just not consistent.
@na2axl what are your thoughts on this?
We could consider adding them as a temporary workaround as long as the generator is not rewritten #100, too.

But if we use the default interface implementation feature for the interface property descriptors, those are not visible on the class. This is the reason why i skipped it, it is just not consistent.

@badcel I think this is not really necessary, if we implement descriptors in interfaces we can always use them anywhere else, even when doing something like:
var box = new Box(Orientation.Vertical, 16);
Orientable.OrientationProperty.Set(box, Orientation.Horizontal); // This will work because Box is an Orientable

Or in object initialization/bindings:
var box = new Box(Orientation.Vertical, 16)
{
  // We have not properties indexers yet, but it's planned ;-)
  [Orientable.OrientationProperty] = Orientation.Horizontal,
};

Also this can make sense to users because in the real life the orientation property is defined in the Orientable GInterface, so it's a bit normal to see the descriptor of that property in our Orientable interface.

@na2axl Yeah I think it is matter of preference. I think I would prefer the solution which is better from an API point of view, not from a code generation point of view.
For myself I have currently no strong opinion on this. For me both solutions are okay (implementing property descriptor in class vs implementing in interface).
I think it is a little bit easier to find the descriptor, if it is on the class for the user. We would need no additional documentation for this. If they are on interfaces it should probably be clarified in the documentation.
Otherwise, what about generating the descriptors for both?

I think I would prefer the solution which is better from an API point of view, not from a code generation point of view.

Ok so we are on the same side 🙂. From an API point of view, I think implementing GInterface properties in C# interfaces will have the same behavior of Attached Properties in XAML-based languages (it's another concept of the DependencyProperty family). An attached property is just a property which is declared in a class and not used by this one, but instead by another classes. For example we have the Grid widget, which have the descriptors of ColumnSpan and RowSpan properties, but those properties will never be used by the Grid itself but instead by its children. So in XAML we will have something like:
<Grid Columns="2" Rows="2">
  <Image Source="test.png" Grid.Column="0" Grid.Row="0" Grid.RowSpan="2" />
  <Label Weight="Bold" Color="Red" Grid.Column="0" Grid.Row="1">My Image</Label>
  <Button Click="OnDeleteButtonClick" Grid.Column="1" Grid.Row="1">Delete</Button>
</Grid>

And even in C# we can have something like:
Grid.ColumnProperty.Set(label, 1);
Grid.ColumnProperty.Set(button, 0);

So in other frameworks it's already normal to see something like that from an API point of view.

I think it is a little bit easier to find the descriptor, if it is on the class for the user. We would need no additional documentation for this. If they are on interfaces it should probably be clarified in the documentation.

Yes you are right, the way we choose must be documented. But we also don't have to forget that peoples coming here will have at least a little knowledge on GTK and his GNOME friends, so from my point of view if they know that the orientation property is defined in the GtkOrientable interface it will surely not a surprise to see the C# descriptor of that property in an Orientable interface.

Okay, so let's do it. I think we will see how we like the feature if we use it more in practice. :+1:


JSON web token appears to be doing no work in app

Related to #5, but more extreme. Even within a session, it appears that the JSON web token is doing nothing. In my fork in which I have uninstalled json-web-token (https://github.com/rjmk/learn-json-web-tokens), I have identical behaviour to the web app. Namely:

Seeing the video when the correct credentials are supplied
Never being able to access '/private' (even directly after authenticating)

Perhaps more illustratively, if you add a console.log for req.headers.authorization at the top of the listener, you will see it is always undefined.
I am not sure if the way you are using the authorization header to spec (http://www.ietf.org/rfc/rfc2617.txt). It appears to be only a meaningful header on the client request. The response may feature a www-authenticate header, which I have tried using with this app but to no avail yet.
Let me know if I've misunderstood anything (which is, of course, pretty likely!)

Finally someone is paying attention...! :smile:
You are 100% correct Rafe. :white_check_mark:
The req.headers.authorization will always be undefined because the client is not saving the JWT the server is sending on auth so the client is not sending it back to the server...
What needs to be done to make this example "real wold" is:
a) need to save the token on the client (e.g. to localStorage) so it can be sent back to the server on each subsequent request.
b) add a link to /private that the person needs to explicitly click in order view the video.
And... if the person has not authenticated then visiting /private should fail because they don't have a JWT in their header.
You have not misunderstood you've done the homework and spotted the opportunity to finish the example app. Do you have time to help "fix" this?

Sure, I'd love to help finish the app!
Before I get to work, it would be great to get an answer to https://github.com/dwyl/learn-json-web-tokens/issues/47 so I know which kind of storage I should use! Also, it would seem to suggest reconfiguring this app to be a one pager. I am happy to do that, but just want to check it is the appropriate approach.

@rjmk You're such a :star2:

This is issue is being automatically closed as it's more than a year old. Please feel free to reopen it if it's still relevant to your project.


cypress edit date picker helper [6]

###Description of the Tech Debt###
###Tech Debt Triage#
Add a cypress function for editing a date, code is duplicating in various reports that requies a date.
Risk Value Scoring:

Level
Value

High
3

Medium
2

Low
1

Technical Debt - Risk Types
Level
Value

Business Area Risk - Risk of business area visibility / damage to user experience
Low
1

Developer Fault Risk - How likely will this tech debt cause a future error related to coding on top of it
Low
1

System Fault Risk - Risk of system errors or application downtime
Low
1

Time Scale Risk - Compound risk effect if left alone. How much more difficult to fix or dangerous will this become over time?
Med
2

Time Sink Risk - How much will this tech debt slow the development process down
Low
1

TOTAL SCORE:

6

@LindsayMacfarlane nothing to test.


ci: add current git sha to version in build-wheel job

Description
This PR proposes the following changes:

remove the obsolote VERSION variable from init.py
add the current git SHA to the version in build-wheel job

Motivation and Context
As discussed in the slack channel yesterday, this was desired by @jochenklar.
Originally the build-wheel job was introduced in #812.
It created a python wheel (including the JavaScript frontend code bundled with webpack) under the name
rdmo-{version}dev{pr_number}-py3-none-any.whl
e.g. given
version = 2.0.2 and pr_number = 833
rdmo-2.0.2dev833-py3-none-any.whl
@jochenklar suggested the new wheel name to include the git SHA (7 chars short version) to ease deploying multiple times from the same PR (possibly long living like the dev2.1.0).
However the suggested form of
rdmo-{version}.dev{sha}-py3-none-any.whl
is invalid, due to PEP440 and Version specifiers.
dev can only be followed by an integer, which the PR number was.
I chose this new pattern instead:
rdmo-{version}.dev0+{sha}-py3-none-any.whl
which is valid. Another possibility would be:
rdmo-{version}+{sha}-py3-none-any.whl
What do you think?
How has this been tested?
Tested locally.
$ python -m pip install rdmo-2.0.2.dev0+553c22a-py3-none-any.whl

$ pip show rdmo
Name: rdmo
Version: 2.0.2.dev0+553c22a
Summary: RDMO is a tool to support the systematic planning, organisation and implementation of the data management throughout the course of a research project.
Home-page:
Author:
Author-email: RDMO Arbeitsgemeinschaft<EMAIL_ADDRESS>License: Apache-2.0
Location: /home/afuetterer/workspace/github/rdmo-fork/.venv/lib/python3.12/site-packages
Requires: defusedcsv, defusedxml, django, django-cleanup, django-compressor, django-extensions, django-filter, django-libsass, django-mathfilters, django-mptt, django-rest-swagger, django-settings-export, django-split-settings, django-widget-tweaks, djangorestframework, drf-extensions, iso8601, markdown, pypandoc, requests-toolbelt, rules
Required-by:

Types of Changes

[x] Other (please describe):

Checklist

[x] I have read the contributor guide.
[x] My code follows the code style of this project.
[x] All new and existing tests passed.

Hmm, you are right, we had something like rc1 before. I don't know if we will have that any time soon, since this was mainly to create a version on PyPI. Now that we have the wheels this is not needed anymore to deploy a development version.
I think I like the +1234567 with out the dev part more. It would also work if there is a more complicated version already in rdmo/__init__.py. I don't think that the PR number needs to be in the filename. But maybe @MyPyDavid will disagree.
I we can keep __version__ the only thing in __init__.

If the version is the only thing in ini.py, I will adapt the replace the current version with the suffixed version. Then rc, dev, etc, is not going to be a problem.
I can remove the middle part .dev0+.
Let's hear from @MyPyDavid about the PR number.
I will adapt this PR, as soon as all agree.

It could be
rdmo-{version}.dev0+{pr-number}-{sha}-py3-none-any.whl

Think that the commit {sha} will then be sufficient, it's unique and findable.
We could change the version in __init__.py to be similar as they do in django https://github.com/django/django/blob/main/django/init.py ?

I think the get_version and having the version in single components like Django does is overkill.
Can we decide on a pattern for the build wheel patch? Then I will adapt this PR.
If pr number is not needed, should dev0+ be included or just +{sha}? Both work for me. No preference.

just +{sha}, maybe we will use dev1... in the future manually.

thanks, yes looks like the get_version is relevant mainly for alpha, beta, rc releases


"responsive" parameter is set to false by default

Wavesurfer.js version: 2.0.5
"responsive" parameter is set to false by default but documentation says it's true.
For me, it should be true by default so a code change is required.

@MoogyG where is this incorrect documentation?

Opened #1358 for this.

Fixed.


Introduce skipInjectNamespaces option to the helm chart

This would fix #76

Codecov Report
Patch and project coverage have no change.

Comparison is base (2c56b80) 67.69% compared to head (9fb0a16) 67.69%.

:exclamation: Current head 9fb0a16 differs from pull request most recent head b60cd39. Consider uploading reports for the commit b60cd39 to get more accurate results

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the GitHub App Integration for your organization. Read more.
Additional details and impacted files
@@           Coverage Diff           @@
##           master      #79   +/-   ##
=======================================
  Coverage   67.69%   67.69%
=======================================
  Files           6        6
  Lines         839      839
=======================================
  Hits          568      568
  Misses        234      234
  Partials       37       37

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

LGTM. Thanks @tothdavid. Will ask for @yonatankahana for approval.

Thanks @tothdavid and @jessehu
It will be released soon in the next version


TypeError: Cannot read properties of undefined (reading 'push') when launching shell

When i launch my application using module federation i get the following error
TypeError: Cannot read properties of undefined (reading 'push')
When i enter inside the code of the federation module i noticed that this part is causing the error inside index.cjs

     name: 'watchLocalSharedImportMap',
    apply: 'serve',
    config: function config(_config3) {
      _config3.optimizeDeps = defu.defu(_config3.optimizeDeps, {
        exclude: [getLocalSharedImportMapPath()]
      });
      _config3.server = defu.defu(_config3.server, {
        watch: {
          ignored: []
        }
      });
      var watch = _config3.server.watch;
      watch.ignored = [].concat(watch.ignored);
      watch.ignored.push("!**" + getLocalSharedImportMapPath() + "**");
    }
  }];

when i log the value of the watch variable i get false but it should be
watch: {
          ignored: []
        }

So i initialized it to this value and its working i can run the shell and the remote loaded in the shell

       name: 'watchLocalSharedImportMap',
    apply: 'serve',
    config: function config(_config3) {
      _config3.optimizeDeps = defu.defu(_config3.optimizeDeps, {
        exclude: [getLocalSharedImportMapPath()]
      });
      _config3.server = defu.defu(_config3.server, {
        watch: {
          ignored: []
        }
      });
      var watch = _config3.server.watch;
      console.log(watch)
      watch =  {
        ignored: []
      }
      watch.ignored = [].concat(watch.ignored);
      watch.ignored.push("!**" + getLocalSharedImportMapPath() + "**");
    }
  }];
}

here the value of watch inside _config3.server is false and the code should change this value
 _config3.server = defu.defu(_config3.server, {
        watch: {
          ignored: []
        }
      });

But its not overriding the value of watch . I dont know if this error is happening for a specific case in my project  since i'm using analog js as a host or it should be corrected when the value is false it should be initialized if the defu function does not update the value my project can be found on github vite-module-federation-angular-test.

Hi @Seifenn I didn't look into the code yet
What's the difference between your example and the official one?

The difference is that i'm using an analogjs project as a host not only bare angular. The problem appeared when using analog since i have another example with angular vite that is working correctly.


python{27,39,310,311,312,313,314}: use a bootstrap SDK on Darwin

Not sure why this is necessary now, since it should already be handled as part of the bootstrap. This might not be the right fix but it does fix eval.
cc @NixOS/darwin-core since Randy might have to clean up my mess after.
This also only affected explicitly‐versioned SDKs, as apple-sdk.stdenv and apple-sdk_10_12.stdenv are different bootstrap stages; I’m not sure if that’s intentional or not.

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release 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.

Add a :+1: reaction to pull requests you find important.

Fixed more properly by https://github.com/NixOS/nixpkgs/pull/354286.

Nope, turns out we need this one too.


Not caching files that doesn't end with file extension

Using Okhttp as Downloader cache for Picasso library.
Images from url's that ends with (example) ".png" are cached offline, but when url has some parameters (example) "...image.png?152354254" they are not cached offline at all. Default Downloader has same issue.
I had found problem when looking at that comment to other issue as I suspected wrong HTTP headers from server (which was not the case in my case): https://github.com/square/picasso/issues/237#issuecomment-25356614
Maybe showing some error in log and trying to cache it with removing everything after ".png? (jpg.. etc.) would be good solution?

It's actually the query string that's interfering. Here's a comment from the relevant code:
// As recommended by the HTTP RFC and implemented in Firefox, the
// max age of a document should be defaulted to 10% of the
// document's age at the time it was served. Default expiration
// dates aren't used for URIs containing a query.

The fix is for your server set a Cache-Control header explicitly.


Application crashes on SQL injection

Hey,
I was running Juice-Shop in docker. The application crashes, when injected the following SQL statement in the search input
foobar')) UNION SELECT email, (SELECT sql FROM sqlite_master WHERE tbl_name = 'Users' AND type = 'table'), '3', '4', '5', '6', '7', '8' FROM User--

Request, that was sent
GET /rest/product/search?q=foobar'))%20UNION%20SELECT%20email%2C%20(SELECT%20sql%20FROM%20sqlite_master%20WHERE%20tbl_name%20%3D%20'Users'%20AND%20type%20%3D%20'table')%2C%20'3'%2C%20'4'%2C%20'5'%2C%20'6'%2C%20'7'%2C%20'8'%20FROM%20Users-- HTTP/1.1
Host: localhost:3000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0
Accept: application/json, text/plain, */*
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://localhost:3000/
DNT: 1
Connection: close
Cookie: continueCode=1Eoybezjgr9n6QGlaHKhDcWIPTwsbF7Hqu2cMhD3TveCoj0V2lv3m4DR7xMq; cookieconsent_status=dismiss; language=de_DE; io=_nY1ybmMqpLknnXAAAAE
Pragma: no-cache
Cache-Control: no-cache

Error message, that was produced.
/juice-shop/node_modules/sqlite3/lib/trace.js:27
                    throw err;
                    ^

TypeError: Cannot read property 'indexOf' of undefined
    at Statement.afterExecute (/juice-shop/node_modules/sequelize/lib/dialects/sqlite/query.js:150:64)
--> in Database#all('SELECT * FROM Products WHERE ((name LIKE \'%foobar\')) UNION SELECT email, (SELECT sql FROM sqlite_master WHERE tbl_name = \'Users\' AND type = \'table\'), \'3\', \'4\', \'5\', \'6\', \'7\', \'8\' FROM Users--%\' OR description LIKE \'%foobar\')) UNION SELECT email, (SELECT sql FROM sqlite_master WHERE tbl_name = \'Users\' AND type = \'table\'), \'3\', \'4\', \'5\', \'6\', \'7\', \'8\' FROM Users--%\') AND deletedAt IS NULL) ORDER BY name', [], [Function: afterExecute])
    at Promise (/juice-shop/node_modules/sequelize/lib/dialects/sqlite/query.js:259:38)
    at Promise._execute (/juice-shop/node_modules/bluebird/js/release/debuggability.js:313:9)
    at Promise._resolveFromExecutor (/juice-shop/node_modules/bluebird/js/release/promise.js:483:18)
    at new Promise (/juice-shop/node_modules/bluebird/js/release/promise.js:79:10)
    at executeSql (/juice-shop/node_modules/sequelize/lib/dialects/sqlite/query.js:107:21)
    at Database.database.serialize (/juice-shop/node_modules/sequelize/lib/dialects/sqlite/query.js:278:20)
    at resolve (/juice-shop/node_modules/sequelize/lib/dialects/sqlite/query.js:102:21)
    at Promise._execute (/juice-shop/node_modules/bluebird/js/release/debuggability.js:313:9)
    at Promise._resolveFromExecutor (/juice-shop/node_modules/bluebird/js/release/promise.js:483:18)
    at new Promise (/juice-shop/node_modules/bluebird/js/release/promise.js:79:10)
    at Query.run (/juice-shop/node_modules/sequelize/lib/dialects/sqlite/query.js:100:12)
    at Promise.try.then.connection (/juice-shop/node_modules/sequelize/lib/sequelize.js:558:20)
    at tryCatcher (/juice-shop/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/juice-shop/node_modules/bluebird/js/release/promise.js:512:31)
    at Promise._settlePromise (/juice-shop/node_modules/bluebird/js/release/promise.js:569:18)
    at Promise._settlePromiseCtx (/juice-shop/node_modules/bluebird/js/release/promise.js:606:10)
    at _drainQueueStep (/juice-shop/node_modules/bluebird/js/release/async.js:142:12)
    at _drainQueue (/juice-shop/node_modules/bluebird/js/release/async.js:131:9)
    at Async._drainQueues (/juice-shop/node_modules/bluebird/js/release/async.js:147:5)
    at Immediate.Async.drainQueues (/juice-shop/node_modules/bluebird/js/release/async.js:17:14)
    at runCallback (timers.js:705:18)
    at tryOnImmediate (timers.js:676:5)
    at processImmediate (timers.js:658:5)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>start: `node app`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/juicer/.npm/_logs/2018-11-15T14_57_14_188Z-debug.log

Is this related to #155 ?
Best regards
Christian

I'll try to reproduce it and see if I can catch errors like this somehow.

The query dies somewhere so deep in sequelize, it does not even reach the first line of my promise callback. Means, I don't really have anything I can do... Sorry, just like #155 this is one of those uncatchable errors.


HIP draft – HNT redenomination

Here is the link to the rendered view of the proposal. https://github.com/jmfayal/HIP/blob/72ead15e30d84bf6b89ce44f425eed4c981af57c/00XX-hnt-redenomination.md

👎 from me.

Any specific concerns worth discussing?

Most recent Example of a split. Now this is still a long term strategy. and i completely understand the point of trying to do this. and to reach more volume at a lower price. However. Apple has done this very same exact thing. that i traded very successfully by the way. however, the Apple High was at $157.26, which apple has yet to breakout above this price after the split. Normally with spilts like this, it will go down and consolidate for a long time creating a new support floor. Now can Apple breakout above the $157.26 level in the future, yes potentially. now how long will that take and is it even necessary, bc the volume coming in has NOT increased like the strategy suggested after a split due from the pandemic free money volume. apple. since the split Apple is down 18% . and has been a downward trend. This is one example, which is the most recent , and Extremely Valuable Company. Now i totally understand the point of this strategy, but just be aware of the complete opposite reaction to the market. However, that being said, will people be more inclined to buy helium at a lower price than the current market price. in the REAL World., where do you  BUY ANYTHING for CHEAP that has HIGH VALUE? so I ask the community, What is the TRUE value of the Helium Blockchain? Do you BELIEVE in the enhancement we are creating with the LoRaWAN and 5G decentralized Wireless network infrastructure we are building? Is our goal to appease the minds with mind tricks and copy other crypto project market strategies? or ARE we HERE to BECOME a LEADER in a New SPACE which we Become examples of Organic Beginnings and allowing the Market to be the Market and Give Us the True Market Value without "blatant" manipulation. This is tough, and i understand both sides of the fence, here, but at the same time, I DO BELIEVE in the Helium Blockchain and its VALUE. That we do NOT need to manipulate markets to make PEOPLE WANT to buy MORE HNT. in the Markets, People DOUBLE DOWN and TRIPLE DOWN on High Value items, not because the PRICE is CHEAPER, but BC there is TRUE VALUE behind our Mission.  Lets talk more and i am always willing to listen to any counter debate, and IF I END UP WRONG< then I HAVE NO PROBLEM giving you the Rep. >

Big no for this

Incentive Unit Bias: For most of Helium’s history gateway owners have enjoyed earning mining rewards in excess of 1 HNT per day (historically much higher), but with the HIP-20 halving and a 10 fold-plus increase in gateway deployments in 2021 those earnings have been reduced to partial fractions of an HNT. Even though the market price of HNT has increased approximately 20X since August 2020 and the median $ earnings per hotspot has remained generally consistent, there has been growing discontent with the HNT earning rate!!!!
👍
You know the problem and fix it not turn arround it!!!

What would the validator stake turn into?

Quindi se ho ben capito, si è deciso di rideterminare il prezzo dagli attuali 47/50 dollari a 0.05 per hnt 1:1000. Che benefici avrà questa riconversione ? Averne in sostituzione per ogni hnt posseduto, 1000? Far aumentare la capitalizzazione di mercato ? Si spera che a 0,05 il prezzo si più appetibile ? Consentire ai possessori di hs di minare non più 0,3/0,4/0,7 a settimana ma 700/800 hnt a settimana ? Lo stesso fece Apple, ne a tratto benefici ? Mah non ho la presunzione di saperne di più di chi ha proposto e sta votando nella direzione della rideterminazione. Speriamo bene. Voi cosa ne pensate ?

👎 I do not see a need for this change.


SvelteKit support?

Do you have any examples of how to use this with a SvelteKit Typescript project?

Good idea, I should have time to put one together today!

Error: [vite]: Rollup failed to resolve import "$app/stores" from "src/components/Auth.svelte".  so i've copied svelte preprocessors list and also should manually recreate some aliases or maybe i can find it somewhere in .svelte-kit

Sorry re-opened, need to fix the alias issue tony mentioned.

TLDR; Vitebook works with SvelteKit now but you can't view application components that are part of SvelteKit which use it's APIs. I recommended splitting your application into components and using props to pass SvelteKit state in. For example, a <Header /> component that might show links to certain pages should not use the pages store directly but rather accept it through a pages property. You can then view all your application building blocks (ie: components) in Vitebook, and handle application-level stuff in your SvelteKit environment.

This issue is actually tricky depending on the type of SvelteKit support we want. The easy part is viewing isolated Svelte components that don't use any SvelteKit API's (you can use the SvelteKit example I put together to do that).
The components that do use SvelteKit API's such as routes/pages won't work because it's not a simple matter of configuring some aliases. SvelteKit is a complete solution for building applications and runs on both the client/server. I thought about emulating some of the API's such as the stores for pages, navigation and what not but that still won't resolve other things like the fact that you can have nested layout files, hooks etc.  None of those will work in Vitebook because that's all run inside a SvelteKit application.
To implement true support for all SvelteKit API's, we need to figure out a way to extend Vitebook with the SvelteKit core. It might be possible to implement an interface for how pages/routes are handled in Vitebook so it can delegate that work to a "special" plugin. Essentially we need to abstract out the code responsible for running a dev envinroment in @vitebook/core, and to be able to let something like an AppPlugin to do the work of resolving routes/pages and other stuff (eg: SvelteKit).
This will clearly be a lot of work and I'm not sure if it's worth it. I feel the solution above in the TLDR should suffice as it's the natural way we build apps.
Closing for now, but let me know if you have any thoughts and I can re-open if needed.

You can then view all your application building blocks (ie: components) in Vitebook, and handle application-level stuff in your SvelteKit environment.

Yes, this is how a component mocking/documenting workbench should work so nothing further is needed for my use case. Your simple example was all I needed to get going.

@mihar-22

For example, a <Header /> component that might show links to certain pages should not use the pages store directly but rather accept it through a pages property.

It's called "Pure Component". A SvelteKit example app has Header.svelte that uses pages store. One can purify that component by moving all actual component stuff into e.g. PureHeader.svelte, and load it in Header.svelte that would pass pages stuff down as a property. The story should only show PureHeader.svelte component (since the Header.svelte would be only a wrapper component, without any UI of its own).
BTW, Storybook has exactly the same issue, and they talk about pure components in their docs.


KAFKA-14862: Outer stream-stream join does not output all results with multiple input partitions

Stream-stream outer join, uses a "shared time tracker" to track stream-time progress for left and right input in a single place. This time tracker is incorrectly shared across tasks.
This PR introduces a supplier to create a "shared time tracker" object per task, to be shared between the left and right join processors.

Merged to trunk and cherry-picked to 3.5 and 3.4 branches.