Provide hints for implementing a backend for a minimized version of Solidity

I'm trying to understand what it means to compile a smart contract language to/through Cairo and still have it execute.
To get the ball rolling, here is a minimized variant of Solidity:
contract Puzzle {
    function puzzle(int a, int b, ERC20 coin) public {
        if (a^2 + b^2 == 458) {
            coin.transfer(caller, 1);
        }
    }
}

If I were to just compile this into EVM, I'd eventually have a CALL opcode that is triggered by some logic.
Questions:

What could this example be extended with to provide a useful off-chain proving-of-something?
If we don't target EVM, how do we eventually achieve something comparable to an on-chain CALL?

Is it only a portion of the code that gets compiled to Cairo? Or is EVM eventually produced by Cairo?

I'll extend the example to coincide with the example given on Discord of a trustless on-chain lookup into an off-chain database, since that appears to be one minimal example (in the sense of understanding, rather than implementation). Perhaps then another minimal example (in the sense of implementation) could also be made.
@MichaelRiabzev-StarkWare wrote on Discord:

For example, assume you want to connect your dApp to a big key-value database (billions of records), and allow the contract to "query" the database trustelssly. The simplest solution would be to store the entire database in you dApps contract storage. But this would be very expensive.
An alternative is to store on your dApp contract only the hash of your database, and keep the database offchain. Whenever there is a need to pass (trustlesly) a record from the offchain database to the smart-contract you prove to it instead that you used a Cairo program which queried a database having the same hash kept onchain, and the value of the required key there is value.
You can think about the on-chain verifier (in this case) as something containing a function verify(proof, db_hash, key, value), and if the proof does not satisfy the statement "I know a db which has hash digest db_hash, and it has value at key", it reverts.
Actually, because the verifier is universal, looks something as follows: verify(proof, cairo_program_hash, outpub_blob) and it reverts if the proof does not prove the statement "I know a cairo program with hash digest cairo_program_hash and some private input to this program making it output output_blob".
For the case above you can think output_blob encodes (db_hash, key, value). This encoding is defined by the cairo_program.

There are two definitions for verify() here. I don't know which is preferred in terms of modelling, but I suppose that the second is a generalisation of the first, so that the particular parameters of the first coincide with being arbitrary program inputs/outputs.
I assume that  proof is a piece of EVM bytecode? Otherwise, I'm not sure how to encode "I know a Cairo program ...". The following is pseudo-Solidity; proof could have been executed on-chain in advance of making the contract call, rather than get passed as an argument... either way, those exact semantics don't seem important.
contract Contract {
    function verify(bytecode proof, uint256 db_hash, uint256 key, uint256 value) public {
        if (proof(db_hash, key, value)) {
            ...;
        } else {
            REVERT;
        }
    }
}

Given my interpretation, it seems to me that a "Solidity -> Cairo" back-end would actually need to generate EVM code at some point for this on-chain verifier. Isn't there a "... -> Solidity/EVM" component here at which the "I know a Cairo program ..." proof must compile with in order to make the verify(...) call?
I think a high-level description of the pipeline would help me here.

I'll extend the example to coincide with the example given on Discord of a trustless on-chain lookup into an off-chain database, since that appears to be one minimal example (in the sense of understanding, rather than implementation). Perhaps then another minimal example (in the sense of implementation) could also be made.
@MichaelRiabzev-StarkWare wrote on Discord:

For example, assume you want to connect your dApp to a big key-value database (billions of records), and allow the contract to "query" the database trustelssly. The simplest solution would be to store the entire database in you dApps contract storage. But this would be very expensive.
An alternative is to store on your dApp contract only the hash of your database, and keep the database offchain. Whenever there is a need to pass (trustlesly) a record from the offchain database to the smart-contract you prove to it instead that you used a Cairo program which queried a database having the same hash kept onchain, and the value of the required key there is value.
You can think about the on-chain verifier (in this case) as something containing a function verify(proof, db_hash, key, value), and if the proof does not satisfy the statement "I know a db which has hash digest db_hash, and it has value at key", it reverts.
Actually, because the verifier is universal, looks something as follows: verify(proof, cairo_program_hash, outpub_blob) and it reverts if the proof does not prove the statement "I know a cairo program with hash digest cairo_program_hash and some private input to this program making it output output_blob".
For the case above you can think output_blob encodes (db_hash, key, value). This encoding is defined by the cairo_program.

There are two definitions for verify() here. I don't know which is preferred in terms of modelling, but I suppose that the second is a generalisation of the first, so that the particular parameters of the first coincide with being arbitrary program inputs/outputs.
I assume that  proof is a piece of EVM bytecode? Otherwise, I'm not sure how to encode "I know a Cairo program ...". The following is pseudo-Solidity; proof could have been executed on-chain in advance of making the contract call, rather than get passed as an argument... either way, those exact semantics don't seem important.
contract Contract {
    function verify(bytecode proof, uint256 db_hash, uint256 key, uint256 value) public {
        if (proof(db_hash, key, value)) {
            ...;
        } else {
            REVERT;
        }
    }
}

Given my interpretation, it seems to me that a "Solidity -> Cairo" back-end would actually need to generate EVM code at some point for this on-chain verifier. Isn't there a "... -> Solidity/EVM" component here at which the "I know a Cairo program ..." proof must compile with in order to make the verify(...) call?
I think a high-level description of the pipeline would help me here.

The proof is not an EVM bytecode at all, it is a STARK proof (academic paper:https://eprint.iacr.org/2018/046.pdf , lighter medium posts describing it: https://medium.com/starkware/tagged/stark-math).
At a high level, a STARK proof attests to the knowledge of a valid execution trace, given some boundary constraints. For the case of Cairo we prove there is knowledge of a valid Cairo (architecture) trace, and the boundary constraints are:

The program counter register (pc) points to an address in the memory, where is written a known (public) program. The program can take as many memory entries as it needs, it is all part of the boundary constraints.
The values returned by the program are written to a predefined memory area, and their values should be equal to some expected values.

Now, we will see how does the proof looks like (simplified).
Imagine you want to check if an x86 trace (a table showing the changes of the CPU registers at each cycle) is valid or not. Notice verification of a trace can be thought of as (almost) a local problem. I can choose a random row in the trace, read it and the instruction executed on it (e.g. move eax, ebx). This provides some restrictions on the next line (e.g. ecx should stay the same, and now eax should equal ebx). Randomly checking the consistency of pairs of such trace line pairs is not sound enough. Even if we add to it checking explicitly the boundary constraints. But his is good enough intuition to how the proof looks likes - some random sampling of trace line pairs. The verification, at a high level, would be to verify the consistency of such trace lines (and the boundary constraints). This is merely for intuition, to actually understand how a STARK proof really looks like I encourage you to go over the links above.
This explanation mostly focus on what a STARK proof is, and not as much on the higher flow, but I hope it does shed some light, does it help?

The proof is not an EVM bytecode at all, it is a STARK proof (academic paper:https://eprint.iacr.org/2018/046.pdf , lighter medium posts describing it: https://medium.com/starkware/tagged/stark-math).
At a high level, a STARK proof attests to the knowledge of a valid execution trace, given some boundary constraints. For the case of Cairo we prove there is knowledge of a valid Cairo (architecture) trace, and the boundary constraints are:

The program counter register (pc) points to an address in the memory, where is written a known (public) program. The program can take as many memory entries as it needs, it is all part of the boundary constraints.
The values returned by the program are written to a predefined memory area, and their values should be equal to some expected values.

Now, we will see how does the proof looks like (simplified).
Imagine you want to check if an x86 trace (a table showing the changes of the CPU registers at each cycle) is valid or not. Notice verification of a trace can be thought of as (almost) a local problem. I can choose a random row in the trace, read it and the instruction executed on it (e.g. move eax, ebx). This provides some restrictions on the next line (e.g. ecx should stay the same, and now eax should equal ebx). Randomly checking the consistency of pairs of such trace line pairs is not sound enough. Even if we add to it checking explicitly the boundary constraints. But his is good enough intuition to how the proof looks likes - some random sampling of trace line pairs. The verification, at a high level, would be to verify the consistency of such trace lines (and the boundary constraints). This is merely for intuition, to actually understand how a STARK proof really looks like I encourage you to go over the links above.
This explanation mostly focus on what a STARK proof is, and not as much on the higher flow, but I hope it does shed some light, does it help?

I think a high-level description of the pipeline would help me here.

I hope it does shed some light, does it help?

Not really. What does a someCoin.transfer(caller, 1) become in Cairo?

I think a high-level description of the pipeline would help me here.

I hope it does shed some light, does it help?

Not really. What does a someCoin.transfer(caller, 1) become in Cairo?

The shortest answer: we just published a related blog post: https://www.cairo-lang.org/cairo-for-blockchain-developers
The short answer:
It does not change. It does not move to Cairo, it stays in solidity.
The long answer:
Let's generalize this code, to something like this:
contract Puzzle {
    function puzzle(solution, ERC20 coin) public {
        if (is_valid_solution(solution)) {
            coin.transfer(caller, 1);
        }
    }
}

When the verification of a solution is a short computation, as described before (a^2 + b^2 == 458), there is actually no need to use Cairo at all.
Now let's assume the verification of a solution is actually a very long computation. For example, the solution is a 64 bit integer n. It is valid if it is a prime. The naive way to verify the number is a prime is to make sure it does not divide any number in the range 2 - sqrt(n). While the is_valid_solution(n) function can be easily implemented with a simple loop, it would probably require too much gas, and we practically won't be able to execute it.
On the other hand, we can implement the same logic in Cairo as well. We can use it to generate a proof, and verify the proof instead (simplified for the sake of clarity, more details in the blogpost). This would make us to change the contract to be something like this:
contract Puzzle {
    function puzzle(solution, proof, ERC20 coin) public {
        if (is_valid_solution(solution, proof)) {
            coin.transfer(caller, 1);
        }
    }
}

Where is_valid_solution(solution, proof) verifies the STARK proof instead of naively executing the long computation over solution. The gas consumptions of the proof verification scale poly-logarithmically with the original execution time, and actually consumes constant gas for any practical use case.
This, of course, does not allow one to send funds directly on Ethereum, so how does StarkWare scalable exchange (L2) solution look like? It is very similar to common banks - the Cairo never changes actual asset ownership, only balance records (just like bank transfers don't make the bank employees move around cases full of dollars from one account to another).
In StarkEx all the funds are kept on the StarkEx smart contract (think of it as the federal reserve), and the balance state is represented on-chain solely by its hash (merkle root).
When there are operations only between StarkEx accounts, we only update the hash of the balances:
contract MyExchange {
    function update_state(new_state_hash, proof) public {
        if (is_valid_state_update(current_state_hash, new_state_hash, proof)) {
            current_state_hash = new_state_hash;
        }
    }
}

The Cairo program enforces the exchange rules (no creation of money out of thin air, no taking of money belonging to others with no permission, etc), and the proof attests that the new state_root is a valid new state - reached by applying only allowed operation on the previous state.
Does this help?

The shortest answer: we just published a related blog post: https://www.cairo-lang.org/cairo-for-blockchain-developers
The short answer:
It does not change. It does not move to Cairo, it stays in solidity.
The long answer:
Let's generalize this code, to something like this:
contract Puzzle {
    function puzzle(solution, ERC20 coin) public {
        if (is_valid_solution(solution)) {
            coin.transfer(caller, 1);
        }
    }
}

When the verification of a solution is a short computation, as described before (a^2 + b^2 == 458), there is actually no need to use Cairo at all.
Now let's assume the verification of a solution is actually a very long computation. For example, the solution is a 64 bit integer n. It is valid if it is a prime. The naive way to verify the number is a prime is to make sure it does not divide any number in the range 2 - sqrt(n). While the is_valid_solution(n) function can be easily implemented with a simple loop, it would probably require too much gas, and we practically won't be able to execute it.
On the other hand, we can implement the same logic in Cairo as well. We can use it to generate a proof, and verify the proof instead (simplified for the sake of clarity, more details in the blogpost). This would make us to change the contract to be something like this:
contract Puzzle {
    function puzzle(solution, proof, ERC20 coin) public {
        if (is_valid_solution(solution, proof)) {
            coin.transfer(caller, 1);
        }
    }
}

Where is_valid_solution(solution, proof) verifies the STARK proof instead of naively executing the long computation over solution. The gas consumptions of the proof verification scale poly-logarithmically with the original execution time, and actually consumes constant gas for any practical use case.
This, of course, does not allow one to send funds directly on Ethereum, so how does StarkWare scalable exchange (L2) solution look like? It is very similar to common banks - the Cairo never changes actual asset ownership, only balance records (just like bank transfers don't make the bank employees move around cases full of dollars from one account to another).
In StarkEx all the funds are kept on the StarkEx smart contract (think of it as the federal reserve), and the balance state is represented on-chain solely by its hash (merkle root).
When there are operations only between StarkEx accounts, we only update the hash of the balances:
contract MyExchange {
    function update_state(new_state_hash, proof) public {
        if (is_valid_state_update(current_state_hash, new_state_hash, proof)) {
            current_state_hash = new_state_hash;
        }
    }
}

The Cairo program enforces the exchange rules (no creation of money out of thin air, no taking of money belonging to others with no permission, etc), and the proof attests that the new state_root is a valid new state - reached by applying only allowed operation on the previous state.
Does this help?


feat(ui): design guidelines repo

Tailwind + DaisyUI configuration that follows our design guidelines. This repo could potentially contain a showcase and UI components that could be shared across multiple packages and products

instead of a new repo would it make sense to just put this under /branding? like in some folder: /branding/tailwind/ with a README.md describing how to utilize the config? and out of curiosity what kind of re-usable components do you imagine we'd have? if we are using daisyUI isn't that already the component library and all you need is the tailwind config file? if we were using flowbite i could see it making more sense.

Sounds good, branding is a good name. I'll change that... Not sure I understood when you say "instead of a new repo", you mean there is no need for a package?, but instead a simple branding/tailwind folder under mono-repo root? Ideally this configuration should be our base one, and each product could extend it. It should have its own version and dependencies, so I see it as a package.
Regarding having re-usable components, this is just an idea. We might want to have some base components, which styling is based on props rather than classes, but the downside of that is that they'll be coupled to a framework such as Svelte. E.g. <Button type="primary" size="small" /> instead of <button class="btn btn-primary btn-sm" />. This is more declarative... but again, since they would be tight to the framework, this might not be something we really want to do.

Oh, I just realized there is already a package called branding. Ok, in that case I can add the configuration under Tailwind folder. What do you think @d1onys1us ?

@jscriptcoder do you think this PR is still needed? It's been here for quite some time.

Closing it as we can base the configuration on the work done in the Bridge UI v2


feat(viewer): make default viewer layout configurable

In ndviz I set the default layout to xy. Mostly it's for legacy reasons, but I find it useful for data that is anistropic or not properly downsampled -- improves load times a bit. This change makes the default layer layout configurable so I can override it in the ndviz viewer constructor.

On second thought, it looks like I can access the layout member directly from an extended viewer class. Nevermind!


samples/Pulls/ListPulls.hs does not compile

https://github.com/phadej/github/blob/master/samples/Pulls/ListPulls.hs does not compile with the latest version of the library

The samples which aren't part of samples sub-package bitrot. Any help to make them live again is welcome!


Use Library For Reconnecting Websocket

Current Situation
Currently we implement our own reconnecting webscoket which is deficient in one way I do know, and probably others I'm unaware of. The one I know, is that we don't stop trying to reconnect after the connection is closed due to an error. Keeping track of how to respond in the case of each error code isn't something we should have to deal with. We should just use a library.
Proposed Actions
Use https://github.com/pladaria/reconnecting-websocket

Related: https://github.com/reactive-python/reactpy/discussions/1098#discussioncomment-6442720

I think I'm going to try deploying on GCP and will prioritize this if I think this will make it possible/easier to do so. A lot of people seem to be trying out ReactPy that way.

I ended up developing a robust reconnecting websocket within ReactPy-Django that can be ported over in future versions.
The websocket can be configured within Python via settings.


JOSS: Update documentation of examples and paper summary

I updated the documentation in the examples to better describe the model physics and thus the real-world analysis.
@shamsiharis: Do the changes reflect the concerns in your review? You can access the documentation directly via https://github.com/RWTH-EBC/AixCaliBuHA/tree/32-Update-documentation-of-examples-and-paper-summary/examples/docs
I will also update the paper based on your review in this PR. Please check my latest question regarding related simulation environments.
Furthermore, I added the new example-file converter CI job to convert our examples directly into markdown and jupyter notebooks. Thus, the description is now better visualized in the examples\docs folder.
Also, in future versions we can integrate e.g. mybinder to enable online execution of the jupyter notebooks.

@shamsiharis: I updated the paper.md to reflect your review regarding the "broad picture of the scope of AixCaliBuHA". From our point of view, the broad picture is the dynamic calibration of building and HVAC models. If this scope does not fit your concern, could you elaborate?
One different kind of scope, the design choices of the python code, we did not mention explicitly in the paper. Instead of developing new optimization and simulation methods, we tried to wrap various existing ones into common classes and made them accessible via configuration.
Also, instead of describing the usability over different simulation environments, I described the possibility to use other environments such as EnergyPlus.

Since 74 % of calibrations are performed manually [@coakley2014review], there is a desperate need for an automated software tool.
As building energy systems are inherently time dependent, such a tool should enable dynamic calibration.
Therefore, we developed AixCaliBuHA to automate the calibration process of dynamic building and HVAC system models.
AixCaliBuHA was developed and tested for Modelica models.
However, other simulation environments, for instance EnergyPlus, could also be integrated.
As long as an FMU of the model is given, or an API to python exists, the simulation environment can be coupled to AixCaliBuHA.


Emblem Bug?

Had an error with the program not being able to find the colours or emblems. I tried to follow the error instructions but have only had some of the emblems get fixed. I have tried reinstalling and the issue has persisteded.

@Sundered-Star did you figure out your issue? Or did you close this by accident?


[Test Wallet - New Design] - add new images

Add the new Layout images:
https://www.figma.com/design/b0Q8gZa5UXkSZEiEMilTwZ/Test-Wallet-Redesign?node-id=0-1&t=d2xT6n3TmhVZZjKp-0
https://drive.google.com/drive/folders/1gna_Z5RAQAOvnmXGbP84visALgD8JxCt

Closed by #1425.


Rebuild libcrux's Cargo.lock in CI

This is  so that libcrux can stop maintaing that file as they have no use for it and it creates conflicts.

This was done a while ago, the blocker is doing it in Eurydice, where getting the right commits info from the nix flake is tricky


testers wanted

We need some people to test this plugin

Works!

We still need testing for additional features like admin settings etc...


[StarRocks On ES][Bug-Fix] handle limit operator push-down correctly

What type of PR is this：

[x] bug
[ ] feature
[ ] enhancement
[ ] refactor
[ ] others

Which issues of this PR fixes ：

Fixes https://github.com/StarRocks/starrocks/issues/9225
Problem Summary(Required) ：

if all conjunct can not processed by ES, limit operator can not be push down

run starrocks_admit_test

@Mergify

https://github.com/Mergifyio backport branch-2.1

@@Mergifyio  backport branch-2.1

https://github.com/StarRocks/starrocks/issues/3667

@Mergifyio backport branch-2.2 branch-2.3 branch-2.4

@Mergifyio backport branch-2.2

@Mergifyio backport branch-2.3

@Mergifyio backport branch-2.4

@Mergifyio backport branch-2.2 branch-2.3 branch-2.4

@Mergifyio backport branch-2.1


Many measurements say failure = true & anomaly = false

It was pointed out that this is the case for measurements in MY by @ kaerumy in https://github.com/ooni/api/issues/32#issuecomment-340647624.

The root cause of this bug is actually inside of the pipeline though. @darkk do you have any ideas why this may be happening?

It's not just MY, but also KH
https://api.ooni.io/api/v1/measurements?offset=100&input=https%3A%2F%2Fwww.cambodiadaily.com%2F&limit=100&probe_cc=KH
https://explorer.ooni.torproject.org/measurement/20180209T061659Z_AS38901_n9ZzV6qX24wiMWjFykrOTHZM1iY0Qy9Tl7Apq4vuR9DENUZEq4?input=https:%2F%2Fwww.cambodiadaily.com%2F

So I am looking at the DB rows for a sample of these measurements running the query:
SELECT
	measurement.test_runtime,
	input.input,
	measurement.measurement_start_time,
	report.probe_cc,
	report.probe_asn,
	report.probe_ip,
	report.report_id,
	http_verdict.http_experiment_failure,
	http_verdict.blocking,
	measurement.anomaly,
	measurement.msm_failure,
	measurement.exc,
	measurement.residual_no,
	residual.residual
FROM measurement
JOIN input ON input.input_no = measurement.input_no
JOIN report ON report.report_no = measurement.report_no
JOIN http_verdict ON http_verdict.msm_no = measurement.msm_no
JOIN software ON software.software_no = report.software_no
JOIN residual ON residual.residual_no = measurement.residual_no
WHERE probe_cc = 'MY'
LIMIT 10;

I notice that they all have anomaly and msm_failure set to NULL and have a non-null residual_no (which is a condition to mark the measurement as failed).
Here is a sample of a residual from a measurement:
{"test_keys": {"agent": "", "queries": [{"engine": "", "query_type": "", "resolver_port": null}], "retries": null, "requests": [{"response": {"response_line": ""}}, {"response": {"response_line": ""}}, {"response": {"response_line": ""}}], "socksproxy": null}, "probe_city": null, "annotations": {"platform": "", "engine_name": "", "engine_version": "", "engine_version_full": ""}, "bucket_date": "", "test_helpers": {"backend": {"type": "", "address": ""}}, "backend_version": null, "data_format_version": ""}

My understanding is that the residual is stuff that the pipeline doesn't know how to ingest properly and it will therefore not mark the measurements in any way.
Is this correct?

I've updated the title to reflect reality a bit better.
The story is:

every measurement that has some non-ingested (unknown values, unknown fields, malformed data in fields) data is flagged as "failed"
the reason is — there is something going on there that pipeline does not know how to handle, so it does it's "best", flags the measurement and moves on
the reason for high percentage of "failed" measurements is that any automatic reasoning on top of data needs reliable signals. No signal is better than lots of false alarms.
I see no good reason to invest time into data cleanup if the signal we get after cleanup is "too weak" to be useful (if it has too high number of false positives)

So I would say, if you know what you're doing and you're sure about the data then feel safe to ignore failure: true marker, it's probably not of great use right now :-)
The overall plan to reduce number of measurements flagged as failure: true is

enrich web_connectivity test to get more new signals and get more detailed signals
ingest the signals and build heuristics on top of the signals
do data cleanup as new signals will make the data more "actionable" for robots
alert on high amount of "failed" measurements to catch bugs in OONI Probe

every measurement that has some non-ingested (unknown values, unknown fields, malformed data in fields) data is flagged as "failed"

Can you link me to where I can see what the schema the pipeline expects is? I can maybe see if I can adjust the parser to make it happy about the above.
Or do you understand from the residual, what fields are unexpectedly missing or present?

the reason is — there is something going on there that pipeline does not know how to handle, so it does it's "best", flags the measurement and moves on

I guess this makes sense, yet we should document what to do in this case and how we can resolve it.

the reason for high percentage of "failed" measurements is that any automatic reasoning on top of data needs reliable signals. No signal is better than lots of false alarms.

This makes sense.

I see no good reason to invest time into data cleanup if the signal we get after cleanup is "too weak" to be useful (if it has too high number of false positives)

I am not sure this is the case for these particular types of measurements as it seems like there is enough data to draw some conclusion, my understanding is that the ingested data contains several extra fields that the pipeline does not recognise.
I am thinking that in general, perhaps, it's wise if we can still ingest data and mark things as we should so long as it contains a subset of the required data. If it contains more data than it should I think we should maybe flag it as "some extra data is there", but still ingest it.
What do you think?

Can you link me to where I can see what the schema the pipeline expects is?

The schema is the code itself. It's done that way as OONI did not enforce schema on incoming data for years and enforcing that now will likely break something. The process to change that (slowly, without loosing any data) and, maybe, introduce schema validation eventually is the story of those "residuals". "Residuals" are approximation of "the fields unknown to the pipeline" (data in "residuals" scheme is dropped, but data type is preserved, so similar residuals are groupped together).

we should document what to do when the pipeline flags the measurement and moves on and how we can resolve it.

I have some process in mind, but to make the process practical, it needed some code. Namely:

partial re-processing, so re-processing of the single measurement from the bucket does not trigger re-processing of the whole bucket — that was done long time ago
fast filter for "similar" webpages to lookup candidates for reprocesing when new webpage fingerprint is added — that finally converged ~ a week ago
avoid re-computation of simhashes on re-ingestion as it takes really significant portion of CPU time

The similarity story was a requirement as blockpage fingerprint is currently single "reliable" datapoint to mark the anomaly confirmed and re-processing of whole dataset checking for regexp takes days (it actually took almost a month and triggered hardware incident during last full-scan), so speedup is crucial here.
So, finally, the hard part of step-one of the aforementioned process is almost over (there is some manual labor regarding data markup, but 1) it's trivial and 2) it's not blocker for Khairil's use-case), so finally step-two makes sense to take.

I am not sure this is the case for these particular types of measurements

Exactly! On one hand, that's why I could live in happy stoicism having ~100% failed measurements when update of blockpage fingerprint dataset was prohibitevly slow, and on another hand, that's why I have "do data cleanup for the measurements showing blockpages / resolving domains to blockervers" as the second bullet point in the plan.
Indeed, as soon as we can update blockpage fingerprint dataset easily (without waiting for days for each single update to happen) data quality starts to matter. One of the ways to resolve that is to draw a borderline if "unknown" fields matter or not in some specific cases. Another way is to do cleanup having a way to define a slice of the dataset that "matters most".
I'm going to follow the second way for a while (as it's more "generic" way and does not introduce any "special" cases) and if it turns out to be impractical, I'd switch to the first one.

it's wise if we can still ingest data and mark things as we should so long as it contains a subset of the required data. If it contains more data than it should I think we should maybe flag it as "some extra data is there", but still ingest it.

Pipeline ingests all the data that can be ingested trivially and slightly more.
And failed flag presented in the API is actually a combination of various flags present in the database.
I'm not 100% confident that it's the best way to handle all the cases, but I currently treat semantics of three API flags in a following way:

confirmed — we believe that the measurement contains sample of network filtering
anomaly — we believe that the measurement contains some network anomaly
failed — if the flag is clean, we believe that the datapoint can be used in automatic processing and does not need human attention that much

"We believe" disclaimer is important — all of these flags may change when we add various heuristics, here are some imaginary examples:

confirmed false → true: we add new fingerprint of the blockpage
confirmed true → false: we refine fingerprint of the blockpage as the old fingerprint captured some news article in some media
anomaly false → true: measurement failed to dial TH, so OONI Probe was unable to register anomaly autonomlulsy, but the fetched page matches fingerprint, so it becomes confirmed anomaly
anomaly true → false: we add heuristic that filters out anomalies for well-known GeoDNS load-balanced domains that present different content depending on the expected user's language
failed true → false: we extend pipeline to ingest previously unknown fields
failed false → true: we enforce schema and mandatory fields are missing

FWIW, I've just been hit by this issue for Jordan. Then come back to the issue, re-read the whole thread and remembered the whole story. It's fine, I guess, to basically ignore failure for now. (TBH it seems to me that this should probably be called automatic_processing_possible but that's a second order comment.)

I have ran into issues related to this while working on the metrics for explorer.
What I have noticed is that:
SELECT * FROM measurement WHERE confirmed!=null AND measurement_start_time > current_date - interval '30 day';

SELECT * FROM measurement WHERE anomaly!=null AND measurement_start_time > current_date - interval '30 day';

Both will return 0 rows (basically all recent measurements have the anomaly and confirmed columns set to NULL).
Many of these measurements actually have a good signal in them and should be flagged at the very least as anomaly and some probably as confirmed.
@darkk can you advise on what is the best way to move forward on this? I would be glad to help out with this issue and write some code to fix the ingestion of these measurements.

I started digging a bit into this, and I cannot seem to find where the anomaly and confirmed flags are being set by the pipeline (for example in: https://github.com/ooni/pipeline/blob/master/af/shovel/centrifugation.py).
The only reference to anomaly and confirmed is in: https://github.com/ooni/pipeline/blob/master/af/oometa/005-anomaly-flags.install.sql#L28, but it seems like this is not run on every tick of the pipeline. Is this the case?

Speaking of failure the story is very simple and iterative: residuals should be cleaned up and starting with the "most relevant" subset helps a lot to focus. Yes, we do know the unknown fields, they're listed as residuals. However, there is a minor problem to solve here: IIRC residual and exc fields are not updated on reprocessing. Reprocessing touches only defined subset of tables and corresponding subset of code paths, so cleaning exc on reprocessing is an incorrect action to do. It's reingestion that should update exc. I don't remember if it actually updates exc, but it's trivial to test that.

Is this the case?

It is. We never converged on a precise definition of confirmed given a complex history of "in-depth measurements" projects, so confirmed and anomaly currently are just proof-of-concept stubs(!). Some time ago we agreed that having non-updated PoC was a reasonable way to signal the lack of consensus while having some sample data for Explorer mock-ups. As we see, the state of the affairs has not changed much and those discussions are still deadlocked after both being moved forward and being rolled back.
I think, the practical way to serve the current needs of Explorer UI/UX development is to shilly-shally a bit further and codify the aforecited rules into something that is updated regularly and can be trivially updated with some other set of rules. Although, I still consider those rules too questionable for my interpretation of the word "confirmed".

: residuals should be cleaned up and starting with the "most relevant" subset helps a lot to focus.

I have updated the relevant pipeline issue on this and your input and comments there are required:
https://github.com/ooni/pipeline/issues/112#issuecomment-476188316

confirmed and anomaly currently are just proof-of-concept stubs

I see, it was not clear to me from the documentation or discussions that this was the case.
I have filed a ticket for work related to this in: https://github.com/ooni/pipeline/issues/146

it was not clear to me from the documentation or discussions

I'm sorry that miscommunication happened. I assumed that it was clear as you also were naming those columns "dummy" in discussions :-)

We have now rolled out a update to the pipeline which populated the anomaly and confirmed flags properly for all measurements. 🎉
There are still several measurements which say failure=true due to there being some unparsed data in them (this issue is tracked as part of: https://github.com/ooni/pipeline/issues/112).
@kaerumy can you see if it's now working for your use-case?
You may also be interesting in setting up your own copy of our metadb and synching it. The completion of this is tracked as part of: https://github.com/ooni/sysadmin/issues/272.

Epic news!!!

Great work!
Initially working for some Malaysian data for 2019.

Now we can start seeing overview anomalies, confirmed and test coverage across our region (and others)

That is great to hear @kaerumy. If you have any other issues please to let us know either by opening a new issue or on slack.


Questions regarding generalization

First of all... Great idea - interactivity of polygons is something I have been trying to achieve for months now using different methods. The BEST and quickest approach I have seen to date while maintaining data accuracy remains that of the recently released giscloud.com guys.
Now, in terms of this project, I would be interest to know how yours compares in terms of speed and accuracy and generalization (especially when dealing with thousands or even a million feature polygons)?
One thing which struck me right away is that there seems to be a real issue in terms of accuracy using your approach. Could it be that this is just due to me using an iPad or is this a known problem using a UTF-grid as the means of pushing the data to the canvas? Also, in terms of performance/accuracy is this approach better than pushing vector data through clipped/simplified JSON tiles using x/y/z coordinates?
Chris

Hi Chris,

Now, in terms of this project, I would be interest to know how yours compares in terms of speed and accuracy and generalization (especially when dealing with thousands or even a million feature polygons)?

Since they're entirely different approaches, I haven't really done a 'head to head competition', and I think that one's a bit dishonest, much like the giscloud blog post. This lets you have accurate, detailed base maps, and interaction thereof.  'Running numbers' is silly, because the product and the production is wildly different, and I wouldn't want to do something so misleading.

One thing which struck me right away is that there seems to be a real issue in terms of accuracy using your approach.

Can you be more specific? What problem of accuracy? Provide a screenshot, maybe?

Also, in terms of performance/accuracy is this approach better than pushing vector data through clipped/simplified JSON tiles using x/y/z coordinates?

Better is a relative term. This approach is better because it degrades to normal interactivity in older browsers, rather than completely failing like a complete-vector approach. And, with a more precise grid, it'll end up being very similar in accuracy/resolution to what-have-you simplified polygons.

would it make any sense to utilize http://mbostock.github.com/d3/ to render vectors in your opinion?

No: as noted before - this isn't rendering vectors, it's rendering rasters. And d3 doesn't really provide any assistance in rendering vectors - it's a great visualization library, and focuses on other problems.


Add Károli University

Károli Gáspár University of the Reformed Church in Hungary

@vetszabolcs Pull request merged. Thank you!


Locator reports thruGw==true for Agents

The location module is reporting thruGw == true for Agents which is never a valid value. This happens when the endpoint is not on the location table. A possible fix for this is to pre-load all routes in the location module for DOMAIN_INGRESS_ROUTING and DOMAIN_EGRESS_ROUTING.

A side effect of this issue is that any request calling and Agent not already in the location table, will cause the location module to add the Agent as if it was thruGw==true making this first available route for subsequent requests.


Scroll bar. Make scroll bar better

Description
Currently, when scroll bar appears it takes separate place on the screen what causes the jerky effect.
For the Basket it resolves by that:
https://github.com/novasamatech/nova-spektr/pull/1968
basically we need to add through the whole application

I suggest to create separated utility component ScrollArea, that handle that case and also solve some css flexbox issues.


Fixed missing setup-node

#1200  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @CatChen and the rest of your teammates on  Graphite


python310Packages.fastbencode: 0.0.12 -> 0.0.13

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.fastbencode is: "Fast implementation of bencode"
meta.homepage for python310Packages.fastbencode is: "https://github.com/breezy-team/fastbencode"
meta.changelog for python310Packages.fastbencode is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.0.13 with grep in /nix/store/y965k2xhkggrq2xad27vf9v3n3wgwh2d-python3.10-fastbencode-0.0.13
found 0.0.13 in filename of file in /nix/store/y965k2xhkggrq2xad27vf9v3n3wgwh2d-python3.10-fastbencode-0.0.13

Rebuild report (if merged into master) (click to expand)

17 total rebuild path(s)

17 package rebuild(s)

First fifty rebuilds by attrpath
breezy
cabal2nix
dep2nix
devpi-client
flatpak-builder
haskellPackages.cabal2nix-unstable
hydra_unstable
nix-prefetch-bzr
nix-prefetch-scripts
nix-update-source
python310Packages.breezy
python310Packages.check-manifest
python310Packages.fastbencode
python39Packages.breezy
python39Packages.check-manifest
python39Packages.fastbencode
vcstool

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/y965k2xhkggrq2xad27vf9v3n3wgwh2d-python3.10-fastbencode-0.0.13 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python310Packages.fastbencode https://github.com/r-ryantm/nixpkgs/archive/87356efbeab46f38376ceda667cb0108cf7be1a4.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/y965k2xhkggrq2xad27vf9v3n3wgwh2d-python3.10-fastbencode-0.0.13
ls -la /nix/store/y965k2xhkggrq2xad27vf9v3n3wgwh2d-python3.10-fastbencode-0.0.13/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

15 packages built:

breezy (python310Packages.breezy)
cabal2nix
dep2nix
devpi-client
flatpak-builder
hydra-unstable (hydra_unstable)
nix-prefetch-bzr
nix-prefetch-scripts
nix-update-source
python310Packages.check-manifest
python310Packages.fastbencode
python39Packages.breezy
python39Packages.check-manifest
python39Packages.fastbencode
vcstool

Maintainer pings
cc @marsam for testing.

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

1 package marked as broken and skipped:

hydra-unstable

15 packages built:

breezy (python310Packages.breezy)
cabal2nix
dep2nix
devpi-client
flatpak-builder
hydra_unstable
nix-prefetch-bzr
nix-prefetch-scripts
nix-update-source
python310Packages.check-manifest
python310Packages.fastbencode
python39Packages.breezy
python39Packages.check-manifest
python39Packages.fastbencode
vcstool


obsidian: 1.5.11 -> 1.5.12

Description of changes

Updated hashes of binaries

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

[ ] 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.05 Release Notes (or backporting 23.05 and 23.11 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.

Result of nixpkgs-review pr 300964 run on aarch64-darwin 1

Result of nixpkgs-review pr 300964 run on x86_64-darwin 1

Hello folks! Is there any plans to backport changes to stable branch?


mzML to parquet?

I saw you are introducing parquet as output format. It would be great if the user would be able to use mzML as input and convert it to that format. Great tool!!

Hi @soerendip thanks for using the TRFP! Conversion from a non-RAW format to other formats is not really something we're planning to include. There are mzML readers available in a lot of languages that you could use as a starting point. Let us know if you want more fields in the parquet output though.


Select appropriate cubemap shadow sizes

Forgive me, I got a little carried away while testing your PR :P
This PR does 3 things to your PR:

We select a smaller cubemap, instead of selecting the largest cubemap smaller than 2 times the size of the quadrant (typically quadrant size) we select the largest cubemap smaller than the quadrant. This makes intuitive sense because you take the 6 faces of the cubemap and spread it over the quadrant. So it makes no sense for each face of the cubemap to be larger than the quadrant. From empirical testing, you start to notice artifacts when selecting the next smallest level cubemap as well. So getting the largest cubemap smaller than the quadrant seems to be the sweet spot.
Asks users to restart when changing atlas shadow size for directional and for omnilight
Allocates a much larger cubemap array. This is necessary to make 1) work properly.

The result of this PR combined with yours is substantially better shadow quality for little additional cost.
In testing with 32 moving lights all with shadows on, I found a slight performance decrease with this PR. However, the quality is so much better that users will be able to get away with smaller atlas sizes. So the benefits are worth it.
Before 4096 atlas size; PCF13

After 4096 atlas size; PCF13

Wow! This is outstanding. Makes sense to me and the "carried away" was certainly worth it 😃


Add hmac pkg

This patch set adds a new top level pkg called hmac which provides an interface to the OpenSSL hmac api to be compatible with Go's stdlib crypto/hmac api (tests are directly taken from Golang src itself and they are all green).
engines is cleaned up to be more Go idiomatic also and it's renamed to just engine (OpenSSL like).
NewWithEngine is added to hmac api even if it's not part of Go's stdlib api.
The only limitation of the hmac pkg is that not all possible Go's hash.Hash are supported because there aren't OpenSSL EVP_* functions for any given hash.Hash implementor. The main ones are supported though.

/cc @vbatts

Updated and reworked sha256 & sha512 pkgs

LGTM

LGTM


Fixed the error that Files were named Folder

Summary of the Pull Request
Repairs that a file is in the subtitle also called file. Introduced in #6600.
PR Checklist

[x] Applies to #6028
[x] CLA signed. If not, go over here and sign the CLA
[x] Tests added/passed

Info on Pull Request
Repairs that a file is in the subtitle also called file. This has not been shipped into a version.
Validation Steps Performed
Query a File with PT Run

this should be moved to a resource file. @ryanbodrug-microsoft did we do a scrub here for plugins as well?

I know that for Folders subtitles are also hardcoded strings. I can change them into resources if you want.

@crutkas I have replaced the values to the resources and saw that we didn't use it for some others, so also added them.

That were all the strings in Plugin.Folder :)

thanks for the updating the others, we're trying really hard to get loc in a good spot so 0.25 we can start rolling stuff in.

this should be moved to a resource file.  @ryanbodrug-microsoft did we do a scrub here for plugins as well?

I think we have to do this for other plugins too. For example the application types (sub title) in program plugin or the subtitle in uri plugin.

@crutkas I think I changed it to what It should be. Can you confirm that?

Looks good.  Funny enough, i created #6834 a few days ago to prevent just this scenario of copy / pasting from happening for culture issues.

Lets get past the CI and we'll merge


feat: add React-Context guide article in english

Created an article for Context API under React Category, in english.

[x ] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #10223

Thank you @cbonaudo for the great write up. Congratulations on your first PR merge to this repo. 🎉


Vue + Typescript produces wrong SourceMaps and prevents correct debugging in vscode

Version
4.5.13
Reproduction link
https://github.com/bromix/vue3-sourcemaps-not-working
Environment info
System:
    OS: Windows 10 10.0.19042
    CPU: (8) x64 Intel(R) Core(TM) i7-4910MQ CPU @ 2.90GHz
  Binaries:
    Node: 12.22.1 - C:\Program Files\nodejs\node.EXE
    Yarn: Not Found
    npm: 6.14.12 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 90.0.4430.212
    Edge: Spartan (44.19041.964.0), Chromium (90.0.818.62)
  npmPackages:
    @vue/babel-helper-vue-jsx-merge-props:  1.2.1
    @vue/babel-helper-vue-transform-on:  1.0.2
    @vue/babel-plugin-jsx:  1.0.6
    @vue/babel-plugin-transform-vue-jsx:  1.2.1
    @vue/babel-preset-app:  4.5.13
    @vue/babel-preset-jsx:  1.2.4
    @vue/babel-sugar-composition-api-inject-h:  1.2.1
    @vue/babel-sugar-composition-api-render-instance:  1.2.4
    @vue/babel-sugar-functional-vue:  1.2.2
    @vue/babel-sugar-inject-h:  1.2.2
    @vue/babel-sugar-v-model:  1.2.3
    @vue/babel-sugar-v-on:  1.2.3
    @vue/cli-overlay:  4.5.13
    @vue/cli-plugin-babel: ~4.5.13 => 4.5.13
    @vue/cli-plugin-eslint: ~4.5.13 => 4.5.13
    @vue/cli-plugin-pwa: ~4.5.13 => 4.5.13
    @vue/cli-plugin-router: ~4.5.13 => 4.5.13
    @vue/cli-plugin-typescript: ~4.5.13 => 4.5.13
    @vue/cli-service: ~4.5.13 => 4.5.13
    @vue/cli-shared-utils:  4.5.13
    @vue/compiler-core:  3.0.11
    @vue/compiler-dom:  3.0.11
    @vue/compiler-sfc: ^3.0.11 => 3.0.11
    @vue/compiler-ssr:  3.0.11
    @vue/component-compiler-utils:  3.2.0
    @vue/devtools-api:  6.0.0-beta.10
    @vue/eslint-config-prettier: ^6.0.0 => 6.0.0
    @vue/eslint-config-typescript: ^7.0.0 => 7.0.0
    @vue/preload-webpack-plugin:  1.1.2
    @vue/reactivity:  3.0.11
    @vue/runtime-core:  3.0.11
    @vue/runtime-dom:  3.0.11
    @vue/shared:  3.0.11
    @vue/web-component-wrapper:  1.3.0
    eslint-plugin-vue: ^7.9.0 => 7.9.0
    typescript: ~4.2.4 => 4.2.4
    vue: ^3.0.11 => 3.0.11
    vue-eslint-parser:  7.6.0
    vue-hot-reload-api:  2.3.4
    vue-loader:  15.9.7 (16.2.0)
    vue-router: ^4.0.8 => 4.0.8
    vue-style-loader:  4.1.3
    vue-template-es2015-compiler:  1.9.1
  npmGlobalPackages:
    @vue/cli: 4.5.13

Steps to reproduce
For Vue v3 change to the "vue3app" directory and then run the following commands.
npm install
npm run serve
code .

In Visual Studio Code just start the debugger with F5 and then click on one of the buttons.
What is expected?
That the breakpoints jump to the right place in the code.
What is actually happening?
Either nothing happens (if a breakpoint is set) or the debugger jumps to the wrong place (if debugger statement is used).

For a direct comparison, I have attached the same project with Vue v2 (everything works there).
I describe the case here in more detail, because we are working on a large project for about a year. We use Vue v2, Vuetify and Composition API. We use only TypeScript (we have additional experience with C/C  , Python and C#/dotnet and are used to work with a debugger for more complex errors).
We have prepared everything thanks to the Composition API addon for Vue v3 and now in the first tests we found that we can't debug properly.
If there is anything further I can try or test, just give me instructions. Currently, my guess is that the source maps are not being created correctly. But only if TypeScript is used. In pure JavaScript there are no problems, but this is not reasonable from a certain size of project.

Here are the screenshots that are also included with the sample project with description.
wrong file

source-map not the same as with vue v2

I am curious why more people are not +1'ing this issue. I have never had any success debugging Vue3 composition API, with Typescript, in VSCode. It is substantially broken.

I am curious why more people are not +1'ing this issue. I have never had any success debugging Vue3 composition API, with Typescript, in VSCode. It is substantially broken.

+1, exactly the same.
and I am curious about this too.

I, too, wonder why more people haven't asked about this issue. This excellent article, with some minor changes and customizations, got me to a working solution:
Vue + TypeScript & Debuggers

@hamstreet Probably because I'm using vue-cli v5.0.0-beta.7, no App.vue(?xxxx) in the Chrome source tab has the template/script tags, so that article got off to a bad start. I guess I'll have to keep dreaming of the day when I can set a breakpoint in VSCode rather than littering debugger; statements everywhere.

Link to issue #11023, Generate distinct paths for supporting .vue files in sourcemaps.

I, too, wonder why more people haven't asked about this issue. This excellent article, with some minor changes and customizations, got me to a working solution:
Vue + TypeScript & Debuggers

@hamstreet  Care to share your changes? I figured out I had to change _sourceMap to _sourceMapAsObject but had no more time to spend on it after that.

Still having this problem. I spent 4 hours on this.
Are the any workaround or fix?

@onurusluca I finally got this working. The information in this comment was the holy grail. I also wrote-up my experience in a later comment.
If that issue is ever closed, hopefully the workaround won't be needed. But it works for now.

I've tried in vain to get this working with no joy, even with andrewmackrodt's hard work.
This is Vue 3.

Vue + TypeScript & Debuggers

That's pretty good article.

Workaround from this https://github.com/vuejs/vue/issues/11023#issuecomment-789137369
Works for me. I`m able to debug vuejs in Chrome


Add blackhole, a delete element, in contrast to cloner

hey, i think you need to create a black-hole element as it'd help to create a moving animation. you see i wanted to create a flowing animation, like water or rain, but the elements a cloner produced would easily fill the canvas.

Yeah we need this

Yes please!

Cool idea


Adding get_memory_manager

Feature request
Currently Numba supplies set_memory_manager, which allows the user to swap in an external memory manage for Numba. It would be useful to have a get_memory_manager to access the underlying memory manager.

@jakirkham that sounds like a reasonable request, thank you!

What do you want to do with it once you have it?

It's a good thing for sanity checking. Also good for downstream users to identify if/how this might have been changed. Finally this could be useful if people want to swap out which allocator is used (admittedly this might not be a thing we can do today).

Could be useful for unit tests? (I'm more or less repeating after John 😅)


3 days mining but any final payments to my wallet, please help!

3 days mining but any final payments to my wallet, please help! Pending balance increasing, but no Paid balance coming to my wallet

This has to do the with pool you are mining with, not electrum


Introduction update

What does this PR do?
Makes the README & docs/index more beginner friendly.
Motivation
The goals were:

to make it clearer that Traefik is "magic" and requires little configuration
to make it "I just cast a glace at the product" friendly with catch phrases (in bold)
to make the "official" quick start more visible

More

[x] Added/updated documentation

Additional Notes
For now, the quick start repository is located at geraldcroes/traefik-quickstart.
If the PR is accepted, it would move to containous/traefik-quickstart.

@mmatur I've udpated the quickstart to use a single file (according to our discussion).


Ascent/Descent Rate Calculation Issues

Something is not right in the ascent/descent rate calculations on the tracker. They seem to over-read the ascent and descent rates. This might be something to do with changes made to the calculations recently.
Ascent rate calculations are done around here: https://github.com/projecthorus/sondehub-amateur-tracker/blob/main/js/tracker.js#L2707
Thing to look into:

Check incoming telemetry is de-duped properly before it is used for these calculations.
Check the filtering is working correctly
Use ascent_rate field data if it is provided in the telemetry if it is available.

Have reverted a bit of the calculations as a test, it's possible working better?
We're not just using the previous to current position, and filtering the ascent rate.


Task History By Name - Reverse Chronological Order

Feature request: /history/by_name/:name in reverse chronological order
history displays in reverse chronological order. Intuitively, one would expect /history/by_name/:name to do the same, but there doesn't seem to be a logical ordering currently.

It appears that /history/by_name/:name now displays in chronological order. Not what was requested here, but least it makes sense. Closing this issue!


feat: review invites components and functionality

Description
review invites components and functionality

Hi @eburck.
The error is related to TypeScript's type checking. Function getEventTypesFromApi_v2 is expected to return a Promise.
I thought I'd fix it after testing but ok I'll fix it now


Install fail

When running  bower install angular-surveys --save, has error:
bower jquery-ui#>=1.9                    validate 1.12.1 against https://github.com/components/jqueryui.git#>=1.9
bower Sortable#dev                   ENORESTARGET Tag/branch dev does not exist

got the same problem lol.

got the same problem lol.

should checkout source code and using in your project :D

In bower.json changing the version of Sortable: dev to Sortable: <your_version> under dependencies worked for me :).


Add jsonpath as dependency

Without the dependency, when using jsonpath in --expression property, I get the following error.
2016-04-13T12:19:33.29-0700 [APP/0]      OUT Caused by: org.springframework.expression.spel.SpelEvaluationException: EL1022E:(pos 0): The function 'jsonPath' mapped to an object of type 'class org.springframework.expression.TypedValue' which cannot be invoked

With this change, I can interact with the payload as:
stream create --name filterTest --definition "http | transform --expression=\"#jsonPath(payload,'$._output')\" | log" --deploy

This is applicable for any application that supports --expression property; hence, it is included in the root pom.
note: this change needs ported over to app-starter eventually; the assembly mechanism is different there since we do not have a root-level pom

@sabbyanandan ,
should we really apply this change to the modules, since the workaround is enough simple with an additional dependency at runtime?
Maybe we should just document the IMPORTANT note here?..
I tried to test it locally in the transform-processor:
@Autowired
@Qualifier("&jsonPath")
private SpelFunctionFactoryBean jsonPathSpelFunctionFactoryBean;

Without success, because json-path dep must be declared explicitly in the modules pom, on in the root pom, but already in the <dependencies> block not only in this <dependencyManagement>.
From one side it looks better to specify such a dep only in those modules which may rely on the SpEL, like this transformer or splitter. But from other hand we can't predict which end-user application may expose similar SpEL behavior, so #jsonPath() would be good there as well. So, from here it might be better to always provide the json-path dependency and allow picky users to exclude it in his environment.
Plus, as we talked privately, the spring-integration-xml with its built-in #xpath() should be there as well for the same SpEL reason.
So, my position is like:

Do nothing here in modules, unless document.
apply json-path and spring-integration-xml deps in the apps as top-level for all applications.
Let end-user to exclude them on at pleasure.

Any other ideas ?

So, from here it might be better to always provide the json-path dependency and allow picky users to exclude it in his environment.

I like the idea of including jsonpath and spring-integration-xml to both <dependencies> and <dependencyManagement> sections in the root pom.
Any OOTB or custom app that doesn't care for it can always exclude it easily anyway.

See the polishing for your confirmation: https://github.com/artembilan/spring-cloud-stream-modules/commit/e84b7e0e63e6f02c9ecbb74070b5cc2cdd3bbf6d

Merged as https://github.com/spring-cloud/spring-cloud-stream-modules/commit/a17169f5542c054f6d0da03e5f322b7287f8841d.
Maybe we need such a story in the https://github.com/spring-cloud/spring-cloud-stream-app-starters?..


fix typo

1、fix keeplive typo
2、remove node_modules

@yingnansong can u merge the two minor change into therepo?


Database provider should be asynchronous

This would be nice addition if database provider could implement async/await.

The database provider is asynchronous but it doesn't use async/await, it uses threads directly.
Unfortunately we cannot add async/await syntax because it is not available on all versions of Unity we currently support.


Fix heatmap layer selecting when other layers hidden

[x] joeferner
[x] mwizeman joeybrk372 jharwig sfeng88

Heatmap layer needed a way to set it was hidden by default
Also adds some more clickable area around the visibility checkbox in layer
list

Points of Regression: Map layer list
NO CHANGELOG heat map added in 4.1

LGTM


Historical funding rate

Is it possible to read from the datastore contract to get oracle prices and the historical funding rate?

In the current version of the SDK, no.
However, I believe with some tweaks to the this line by specifying the block range it is. You would need to be using an archive node and a standard RPC likely would not work.
I will create a new branch for it
https://github.com/snipermonke01/gmx_python_sdk/blob/main/gmx_python_sdk/scripts/v2/gmx_utils.py#L33

Thanks for the comment. I'm working on it.


Typescript declarations bugs (minor)

Hey!
Here are two minor typescript declarations errors that appeared:
1.) Currently, the typescript declaration says: getNdefMessage(bytes: number[]).  But getNdefMessage should not take any parameter.
2.) The function setEventListener(name: NfcEvents, callback: OnNfcEvents)  should also accept null as a callback according to examples.
Edit:
Made a fix. See the pull request: https://github.com/whitedogg13/react-native-nfc-manager/pull/233

PR merged, thanks for the contribution!


release with vclib 3.8* and KMP-Crypto 3.2.0

should i just republish over the old snapshot?

Sure, and after vclib 3.8.0 is released, we'll release here.


[🐞] Weird location.hash / window.history behaviour

Which component is affected?
Qwik Runtime
Describe the bug
Issue Overview
This report outlines an observed inconsistency in the behavior of the <a> and Qwik Link elements when used for scrolling to a target element in a Qwik application. The behavior varies between local and Stackblitz environments, and also changes after a routeAction$ is invoked upon form submission.
<a> Element Behavior
The <a> element initially performs as expected, scrolling to the target element and opening the details element that contains the target when clicked. However, after a routeAction$ is triggered upon form submission, subsequent clicks on the <a> element have no effect. This behavior is consistent in both local and Stackblitz environments.
Qwik Link Element Behavior
The behavior of the Qwik Link element differs significantly between local and Stackblitz environments. In a local environment, the Link element, despite having the same href as the <a> element, does not respond to clicks even before form submission. Conversely, in the Stackblitz environment, the Link element functions as expected both before and after form submission.
Reproduction Steps
Both the local and Stackblitz applications share the same codebase, including the package.json. Detailed instructions for reproducing the issue are provided on-screen in both applications.
Reproduction
https://github.com/Sport-Thieme/qwik-scroll-issue
Steps to reproduce
Qwik Scroll Issue Demo
This repository contains a demo for the Qwik scroll issue. Follow the instructions below to clone and start the repository:
Cloning the Repository

Open a terminal.

Navigate to the directory where you want to clone the repository.

Run the following command:
git clone https://github.com/Sport-Thieme/qwik-scroll-issue

Starting the Repository

Navigate into the cloned repository's directory:
cd qwik-scroll-issue

Install the dependencies:
npm install

Start the application:
npm start

The application should now be running at http://localhost:5173.
Issue Description
This repository demonstrates an unexpected behavior in Qwik related to the <a> element and the Qwik Link element when used for scrolling to an element with a specific id.
<a> Element Behavior
The <a> element behaves as expected, scrolling to the target element and opening the details element that contains the target when clicked, until a routeAction$ is called upon form submission. After the form submission, clicking on the <a> element has no effect. This behavior is consistent both when running the application locally and on Stackblitz.
Qwik Link Element Behavior
The behavior of the Qwik Link element differs between running the application locally and on Stackblitz.
Local Environment
In a local environment, the Link element neither scrolls to the target element nor opens the details element, even before form submission.
Stackblitz Environment
On Stackblitz, the Link element behaves as expected, both before and after form submission. It scrolls to the target element and opens the details element when clicked.
Testing the Issue
Detailed instructions on how to test this issue will be displayed on the screen when you run the application.
System Info
System:
    OS: macOS 14.4.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 138.08 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.17.1 - ~/.nvm/versions/node/v18.17.1/bin/node
    Yarn: 1.22.21 - ~/.nvm/versions/node/v18.17.1/bin/yarn
    npm: 9.6.7 - ~/.nvm/versions/node/v18.17.1/bin/npm
    pnpm: 9.0.5 - ~/.nvm/versions/node/v18.17.1/bin/pnpm
  Browsers:
    Chrome: 124.0.6367.92
    Safari: 17.4.1
  npmPackages:
    @builder.io/qwik: ^1.5.2 => 1.5.2
    @builder.io/qwik-city: ^1.5.2 => 1.5.2
    undici: * => 6.15.0
    vite: ^5.1.6 => 5.2.10

Additional Information
Please, make sure to check the behaviour both on Stackblitz and by running the app locally after cloning it.

@jordanw66 thanks a lot. I was pretty sure stackblitz is reloading, but wasn't that smart to check network tab 😶🌫
we will try with location.href even if this is a downgrade.
Can you point me in the right direction in qwik? Not sure if we could check if the element is visible and if not, use location.href in qwik instead?

@jordanw66 it seems that anchor tag works before the first Form submission and it does scroll to the element before it is visible (opens the details element) - it's only Link that will not open the details element (and works if it's already open).
However, we tried setting
location.url.href = `${location.url.href}#content`

both in the onClick$ of the <a> and the Link and when logging the location.url.href after that, the href is really set, but it doesn't help the situation. Link still scrolls only if the details are open and the <a> still only opens and scrolls until the Form is submitted. If we're doing something wrong, could you please drop a few more details how to try this out so that we proceed in the right direction?
In the meantime we'll do a workaround with a custom context.


Can't decrypt recently crypted links

Hi,
I use https://robinmoisson.github.io/staticrypt/ to crypt some links for my one-page html app.
I'm changing these links every year.
The problem is that I can decrypt the links created last year, but when creating a new link with the same password the decrypt function doesn't decrypt it.
	encryptedHMAC = encryptedMsg.substring(0, 64);
	encryptedHTML = encryptedMsg.substring(64);
	decryptedHMAC = CryptoJS.HmacSHA256(encryptedHTML, CryptoJS.SHA256(passphrase).toString()).toString();

For old links encryptedHMAC/decryptedHMAC are equal, but for the newly created links they differ.
function decrypt (encryptedMsg, pass) {
		var keySize = 256;
		var iterations = 1000;
		var salt = CryptoJS.enc.Hex.parse(encryptedMsg.substr(0, 32));
		var iv = CryptoJS.enc.Hex.parse(encryptedMsg.substr(32, 32))
		var encrypted = encryptedMsg.substring(64);
		var key = CryptoJS.PBKDF2(pass, salt, {
				keySize: keySize/32,
				iterations: iterations
		});
		var decrypted = CryptoJS.AES.decrypt(encrypted, key, {
				iv: iv,
				padding: CryptoJS.pad.Pkcs7,
				mode: CryptoJS.mode.CBC
		}).toString(CryptoJS.enc.Utf8);
		return decrypted;
}

Are there any recent changes on staticrypt resulting in this issue? Please contact me at<EMAIL_ADDRESS>if you need a detailed example and old and new encrypted strings for a test.
Happy New Year!
Sergey

Hey Sergey - what version of Staticrypt are you using? Are you using a custom password template?
In February there was a breaking change release bumping the version number to 2.0. The salt is now passed separately from the ciphertext, to allow the remember-me feature to work.
If that's your issue you can either pin the staticrypt version to < 2.0 or update your password template to handle the new parameters.
Does that look like this might be your issue?

Hi Robin,
Thank you for your answer!
I use Staticrypt from this link https://robinmoisson.github.io/staticrypt/ and don't see a way to "pin the staticrypt version to < 2.0" on site. I'm just encrypting the links to my Google drive spreadsheets which I use in my playn html app.
I've gotten the decrypt function, mentioned above, from your example site's html, so obviously I have to update it.
Thanks again and best wishes,
Sergey

Hi Sergey - interesting, thanks for reporting more details. Yes, pinning the version only works when using staticrypt as a command line tool, the website always uses the latest version.
If you generate encrypted HTML from the website the embedded decryption logic should be renewed each time you generate the encrypted file, so you should be able to decrypt it through the page. Does it not work for you?
Or are you using the content that's displayed in "Your encrypted string" and trying to decrypt that through your own process, so you're not using the generated "login" page? Or is your process something else?
Thanks!

Hi Robin!
Yes, I'm using the content that's displayed in "Your encrypted string" and I'm decrypting it through my own process.,  I updated it because I have my own login page which is displayed even when the "Remember me" was checked, so I have also "Forget" button on it. I also implemented encryption in my app and will not depend on future changes on your web site :-)
Best regards!


contracts: Add payToWallet action

It makes sense to have this as a separate Trace action since transferring funds is a function of the wallet, not of the contracts

The idea is that this represents a "user action", whereas contract payments always look like "pay to some pubkey (which may or may not be associated with a wallet, who knows)"?
Would be worth adding something about that to the haddock, if so.

The idea is that this represents a "user action", whereas contract payments always look like "pay to some pubkey (which may or may not be associated with a wallet, who knows)"?

Yeah that's one one way of looking at it. "Pay to wallet" is a user action, and "run this contract" is also a user action.
In theory we could write a payToWallet :: PubKey -> Value -> PlutusContract s e (), which would look up the wallet's public key. I don't think that's a good solution though, because these kind of payments are really part of the wallets and not of specific contracts. A wallet is just a set of "own funds" and a means to transfer those funds to some address, and within a Trace we should be able to use this wallet feature independently of any contracts that are currently running.

Sounds good to me, just worth a note.


Added Flappy Bird Game.

Added Flappy Bird Game made in HTML, CSS and JS.

Thanks for the PR. It has been merged.


Process-CPU Tracking

Urgent:  CPU-Process Data does not show any spikes/real time information.
Sadly the replacement of top by ps has some backlashes.
ps only tracks the CPU-Usage of a process over its whole runtime as an average and not like top within the last minutes.
I've noticed that even with Top showing a java usage of 100% (related to #49 ), ps does not show these spikes.
The ps manual says following:
CPU usage is currently expressed as the percentage of time spent
       running during the entire lifetime of a process.  This is not ideal,
       and it does not conform to the standards that ps otherwise conforms to.
       CPU usage is unlikely to add up to exactly 100%.

I'm still seaching for a pre-installed non-interactive version to track the cpu usage of certain processes.

The best solution is to re-introduce TOP.
Top does not work with RAM due its truncation issue even in -b-Mode.
Also the SPP-Servers do not support the -E option.
Therefore PS would be best to collect RAM and storage information, while TOP is able to collect % CPU usage.


FancyZone problems after version upgrade

Microsoft PowerToys version
0.67.1
Installation method
GitHub
Running as admin
Yes
Area(s) with issue?
FancyZones
Steps to reproduce
two kinds of problems(A, B).
A. turn off & turn on computer
B. use [shift] to activate a zone
✔ Expected Behavior
A. fancyzone area setting remains the same
B. right after i type [shift] the zone where mouse cursor located activates (without moving mouse afterwards.)
→ this was the behavior in prior version of powertoys
❌ Actual Behavior
A. fancyzone area setting initializes (3 sections setting)
B. after typing [shift] i have to move mouse cursor for activating a zone
Other Software
none

Are you still experiencing this issue? /needinfo


Accessibility in Dark Mode

The labels are hardly readable in dark mode:

Maybe dark mode should be investigated overall regarding accessibility.

Yes, please, I have to switch browsers to use quiver currently. Help us dark mode afficionados :-)

Resolved in 9c4a9f1

Nice! Can be closed now IMHO.


Update traefik to latest version

We are pretty far out of date. Updating to latest.

Has anybody tried working on this update yet?

No
On Thu, Jul 27, 2017 at 7:49 AM anton<EMAIL_ADDRESS>wrote:

Has anybody tried working on this update yet?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/mantl/mantl/issues/2011#issuecomment-318385146, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAU0vTppxiOY1oEL-jvTUcit0RPrsaWMks5sSKNhgaJpZM4Nv7yY
.

--
Thomas Vincent

I am currently working with Traefik on a project at work, I might take a stab at this once I am done.

This will not happen for Mantl 1.x as we are only supporting 1.x as an LTS. There is too much bit-rot to build upon and we have to get away from maintaining a k8s fork. We are currently planning the re-write of Mantl from scratch, you can view the progress and contribute here: https://github.com/cloud-endeavor/endeavor


isClerkAPIResponseError is not a function

Preliminary Checks

[X] I have reviewed the documentation: https://clerk.com/docs

[X] I have searched for existing issues: https://github.com/clerk/javascript/issues

[X] I have not already reached out to Clerk support via email or Discord (if you have, no need to open an issue here)

[X] This issue is not a question, general help request, or anything other than a bug report directly related to Clerk. Please ask questions in our Discord community: https://clerk.com/discord.

Reproduction
Will create if needed
Publishable key
Will add if needed
Description
I'm upgrading to v6 and cannot use the provided error handlers:
⨯ TypeError: (0 , clerk_nextjs_errors__WEBPACK_IMPORTED_MODULE_4_.isClerkAPIResponseError) is not a function
Error handler:
...
import {
    isClerkAPIResponseError,
} from '@clerk/nextjs/errors';
...

export function withErrorHandler(handler: Handler): Handler {
    return async (req: NextRequest, ...args: any[]) => {
        try {
            return await handler(req, ...args);
        } catch (error: unknown) {
           ...
            if (isClerkAPIResponseError(error)) {
                return NextResponse.json(
                    new ApiError(
                        error.message,
                        500,
                        ApiErrorCode.INTERNAL_SERVER_ERROR
                    ).toJSON(),
                    { status: 500 }
                );
            }
...
        }
    };
}

Route that throws the error:
async function deleteHandler(request: NextRequest): Promise<NextResponse<OrganizationLeaveResponse>> {
   ...
    await client.organizations.deleteOrganizationMembership({
        userId: userId,
        organizationId: orgId,
    });
   ...
}

export const DELETE = withErrorHandler(deleteHandler);

Actual error from logs:
[07:09:06.220] ERROR (api-error-handler/26689): API Error occurred
    error: {
      "status": 400,
      "clerkTraceId": "0128e81e3b5242bd15a9da2e54cf54eb",
      "clerkError": true,
      "errors": [
        {
          "code": "organization_minimum_permissions_needed",
          "message": "minimum organization permissions needed",
          "longMessage": "There has to be at least one organization member with the minimum required permissions",
          "meta": {}
        }
      ]
    }

Instead of isClerkAPIResponseError executing, I get an import failure. Full stack trace:
 ⨯ TypeError: (0 , _clerk_nextjs_errors__WEBPACK_IMPORTED_MODULE_4__.isClerkAPIResponseError) is not a function
    at eval (webpack-internal:///(rsc)/./app/api/api-error-handler.tsx:48:94)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async eval (webpack-internal:///(rsc)/./node_modules/.pnpm/@sentry+nextjs@8.38.0_@opentelemetry+core@1.27.0_@opentelemetry+api@1.9.0__@opentelemetry+ins_pukndwabmym6vqunvov2jrcvsm/node_modules/@sentry/nextjs/build/cjs/common/wrapRouteHandlerWithSentry.js:40:30)
    at async /home/lmyslinski/Dev/cv2b/cv2b/web/node_modules/.pnpm/next@14.2.18_@babel+core@7.26.0_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/compiled/next-server/app-route.runtime.dev.js:6:55831
    at async eO.execute (/home/lmyslinski/Dev/cv2b/cv2b/web/node_modules/.pnpm/next@14.2.18_@babel+core@7.26.0_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/compiled/next-server/app-route.runtime.dev.js:6:46527)
    at async eO.handle (/home/lmyslinski/Dev/cv2b/cv2b/web/node_modules/.pnpm/next@14.2.18_@babel+core@7.26.0_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/compiled/next-server/app-route.runtime.dev.js:6:57165)
    at async doRender (/home/lmyslinski/Dev/cv2b/cv2b/web/node_modules/.pnpm/next@14.2.18_@babel+core@7.26.0_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/server/base-server.js:1353:42)
    at async cacheEntry.responseCache.get.routeKind (/home/lmyslinski/Dev/cv2b/cv2b/web/node_modules/.pnpm/next@14.2.18_@babel+core@7.26.0_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/server/base-server.js:1575:28)
    at async DevServer.renderToResponseWithComponentsImpl (/home/lmyslinski/Dev/cv2b/cv2b/web/node_modules/.pnpm/next@14.2.18_@babel+core@7.26.0_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/server/base-server.js:1483:28)
    at async DevServer.renderPageComponent (/home/lmyslinski/Dev/cv2b/cv2b/web/node_modules/.pnpm/next@14.2.18_@babel+core@7.26.0_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/server/base-server.js:1911:24)
    at async DevServer.renderToResponseImpl (/home/lmyslinski/Dev/cv2b/cv2b/web/node_modules/.pnpm/next@14.2.18_@babel+core@7.26.0_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/server/base-server.js:1949:32)
    at async DevServer.pipeImpl (/home/lmyslinski/Dev/cv2b/cv2b/web/node_modules/.pnpm/next@14.2.18_@babel+core@7.26.0_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/server/base-server.js:921:25)
    at async NextNodeServer.handleCatchallRenderRequest (/home/lmyslinski/Dev/cv2b/cv2b/web/node_modules/.pnpm/next@14.2.18_@babel+core@7.26.0_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/server/next-server.js:272:17)
    at async DevServer.handleRequestImpl (/home/lmyslinski/Dev/cv2b/cv2b/web/node_modules/.pnpm/next@14.2.18_@babel+core@7.26.0_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/server/base-server.js:817:17)
    at async /home/lmyslinski/Dev/cv2b/cv2b/web/node_modules/.pnpm/next@14.2.18_@babel+core@7.26.0_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/server/dev/next-dev-server.js:339:20
    at async Span.traceAsyncFn (/home/lmyslinski/Dev/cv2b/cv2b/web/node_modules/.pnpm/next@14.2.18_@babel+core@7.26.0_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/trace/trace.js:154:20)
    at async DevServer.handleRequest (/home/lmyslinski/Dev/cv2b/cv2b/web/node_modules/.pnpm/next@14.2.18_@babel+core@7.26.0_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/server/dev/next-dev-server.js:336:24)
    at async invokeRender (/home/lmyslinski/Dev/cv2b/cv2b/web/node_modules/.pnpm/next@14.2.18_@babel+core@7.26.0_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/server/lib/router-server.js:173:21)
    at async handleRequest (/home/lmyslinski/Dev/cv2b/cv2b/web/node_modules/.pnpm/next@14.2.18_@babel+core@7.26.0_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/server/lib/router-server.js:350:24)
    at async requestHandlerImpl (/home/lmyslinski/Dev/cv2b/cv2b/web/node_modules/.pnpm/next@14.2.18_@babel+core@7.26.0_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/server/lib/router-server.js:374:13)
    at async Server.requestListener (/home/lmyslinski/Dev/cv2b/cv2b/web/node_modules/.pnpm/next@14.2.18_@babel+core@7.26.0_@opentelemetry+api@1.9.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/next/dist/server/lib/start-server.js:141:13)
 DELETE /api/organization/membership?orgId=org_2oxqsB3fT0xf6VMfn5rX413Ye7K 500 in 1258ms
[07:09:06.220] ERROR (api-error-handler/26689): API Error occurred
    error: {
      "status": 400,
      "clerkTraceId": "0128e81e3b5242bd15a9da2e54cf54eb",
      "clerkError": true,
      "errors": [
        {
          "code": "organization_minimum_permissions_needed",
          "message": "minimum organization permissions needed",
          "longMessage": "There has to be at least one organization member with the minimum required permissions",
          "meta": {}
        }
      ]
    }

Environment
System:
    OS: Linux 5.15 Ubuntu 22.04.4 LTS 22.04.4 LTS (Jammy Jellyfish)
    CPU: (12) x64 AMD Ryzen 5 5600X 6-Core Processor
    Memory: 4.50 GB / 7.72 GB
    Container: Yes
    Shell: 5.8.1 - /usr/bin/zsh
  Binaries:
    Node: 20.16.0 - /run/user/1000/fnm_multishells/952_1731821102536/bin/node
    npm: 10.8.1 - /run/user/1000/fnm_multishells/952_1731821102536/bin/npm
    pnpm: 9.7.0 - ~/.local/share/pnpm/pnpm
  npmPackages:
    @clerk/nextjs: ^6.3.4 => 6.3.4
    @clerk/types: ^4.34.0 => 4.34.0

    @types/node: ^20.14.1 => 20.17.6
    @types/pg: ^8.11.6 => 8.11.10
    @types/react: ^18.3.3 => 18.3.12
    next: ^14.2.8 => 14.2.18
    tsx: ^4.11.2 => 4.19.2
    typescript: ^5.4.5 => 5.6.3

Hey @lmyslinski thanks for discovering this bug. If you were to upgrade to next 15 the error message would change to describe the issue better. Ultimately the issue is that we re-export the  isClerkAPIResponseError under a "use-client" barrier which makes is non existent in your server-only bundle for Route handlers.
We will be fixing this soon, but as a workaround please import the utility from '@clerk/shared/error' (you might need to install the package explicitly).
A follow-up question I have is, from which @clerk/nextjs are you upgrading from, since this bug seems to existed since v5.

@panteliselef Thanks for the response. I'm upgrading from:
    "@clerk/clerk-sdk-node": "^5.0.22",
    "@clerk/nextjs": "^5.2.11",
    "@clerk/types": "^4.10.0",

However I haven't used this method before, decide to improve the error handling along with the upgrade. As a workaround I've just implemented a similar method myself so I'm good for now.


Add inline help for background inputs

Add helps texts explaining background types and poster images.

Coverage remained the same at 99.031% when pulling df666c53e527432b0b657285eddd2057b13782e3 on tf:background-inline-help into 8370c625de0a309a07cb8b94b4884685f7df6bfa on codevise:master.

Coverage remained the same at 99.031% when pulling df666c53e527432b0b657285eddd2057b13782e3 on tf:background-inline-help into 8370c625de0a309a07cb8b94b4884685f7df6bfa on codevise:master.


feat: update to support API v1

I updated the calls to be compatible with v1 of the API.
Also included a small change to bind to the current server IP when used in a server which has multiple IPs.

Any news about this PR ?


chore: avoid deprecation warning when used with poetry-core >= 1.3

Alternative approach to #138, since we can't bump poetry-core here until a new poetry release which is compatible with that core version. However, it would be nice to avoid the deprecation warning in the upcoming poetry release.

Looks like mypy requires appeasement

Hmm, seems I have to fight some sort of PyCQA/isort#1839


[BUG] Camera View/Preview glitches in the UI when system call

@FulcrumOne Hello, how are you? :)
When I am in Camera View or Camera Preview screen and a call comes to my phone, the UI gets corrupted and freezes. Can you check this?
Thank you.

Hey @clbemre,
I have tested this on iOS 18 and the problem does not appear there. Could you please give me more details?
Thanks


React Native Android GCM (Google Cloud Messaging) Roadmap

Currently React Native supports Push Notifications in iOS. Setting that up seems straightforward, however achieving the same functionality in Android seems much more challenging. Currently I don't see anything in the docs regarding setting up GCM (Google's push notification service) in React Native. The only module I have seen for GCM allows the service only on iOS. Is GCM on the roadmap for React Native Android?

cc @mkonicek
that said this should be pretty easy to set up yourself?

The Android Facebook Ads Manager uses push notifications. @foghina is the implementation battle tested and generic enough to open sourced?
As a side note, I think in general it's great if there are community modules for features like this at https://react.parts/native
Ideally if there are a few implementations, we can all learn from each other and come up with the best API over time.

The Ads Manager implementation is not generic enough - it's tied with FB infra and pretty specific to Ads Manager itself.
The reason why this is a significantly harder problem on Android than on iOS is because Android gives you much more flexibility in dealing with push notifications. On iOS, when the server sends a push notification, no application code is invoked in the app, instead a notification is shown based on the payload and the app is invoked if/when the user taps on it.
On Android, the push notification actually triggers a BroadcastReceiver that is then responsible for reading the payload and deciding what to do with it. It can show a notification based strictly on the payload content or start a Service to make a network request to pull more info before showing one. Or, it can decide to ignore the push. Basically, you can run any code on a push.
This makes it hard because we want to have the business logic of handling a push in JS. This means running JS in a Service without a UI (so no ReactRootView...), ideally with a minimal / different / smaller bundle than the main app, for performance reasons (this is run while the device is awake just to process push notifs, doing any extra work will result in your app using too much battery power).
In Ads Manager, the business logic is in Java, simply because we know what the payload is, how to create a UI notif from it and what Intent to launch when the user taps on it.
Furthermore, while iOS is (I think) tied to APNS for push delivery, on Android there are alternatives, e.g. Amazon Device Messaging. Ideally our APIs would be extensible enough to allow plugging alternative delivery methods.

@foghina thanks for the detailed overview! Really informative and actually reminds me a lot of iOS push notifications once you go past the super basic stuff. Same kinds of constraints like writing your notif handling in native so you don't have to spin up a JSContext :)

Wait, what do you mean by "notif handling"? Do you mean handling the user tapping on it or handling the push payload? IIRC the latter is not possible on iOS but maybe things have changed? I'm not very up-to-date on iOS dev.

Both under certain conditions. The specifics are a bit handwavy based on the APNS payload and various app entitlements but if you try all the combinations you can handle notifs without user interaction sometimes.

What was the direction here for push notifications on Android?

Hello, I am interested in react-native for android as well.

No ETA yet but we should eventually have support for push notifs on Android. Please post / vote here so we know how to prioritize: https://productpains.com/product/react-native/?tab=top
I'm currently working on open sourcing more internal modules and view managers. Push notifications will require a bit more work because as Felix said this will need to be a different implementation from what we use internally.

You can try my module https://github.com/oney/react-native-gcm-android

@oney Cool! :+1:

@oney Can I use it in production?
@mkonicek Have you tested it?
Thanks !

@samuelcastro To be honest, I am not very professional with Android. I am more familiar with iOS. So maybe this module has some bugs and it isn't tested in all circumstances.

can anyone here good with Android fix the Contacts plugin by @rt2zz?
On Nov 22, 2015 9:58 PM, "Howard Yang"<EMAIL_ADDRESS>wrote:

@samuelcastro https://github.com/samuelcastro To be honest, I am not
very professional with Android. I am more familiar with iOS. So maybe this
module has some bugs and it isn't tested in all circumstances.
—
Reply to this email directly or view it on GitHub
https://github.com/facebook/react-native/issues/3423#issuecomment-158839064
.

so currently no push notification for Android in RN and no ETA?

See https://productpains.com/post/react-native/get-android-to-feature-parity-with-ios/

+1

+1

There's a lot of RN apps, presumably some of them are using push notifications. Anyone know whether there's an open source alternative to use until it gets into RN core? I've been looking around and can't find anything. I just want the ability to have a server-side notification about an event that, when tapped, takes the user back to the app.

@pickhardt found anything usable? Looking for same

any updates? really look forward to PushNotification for Android

i got it work with https://github.com/oney/react-native-gcm-android react native v 0.20  connectd issue: #3683

Hi there! This issue is being closed because it has been inactive for a while.
But don't worry, it will live on with ProductPains! Check out its new home: https://productpains.com/post/react-native/react-native-android-gcm-google-cloud-messaging-roadmap
ProductPains helps the community prioritize the most important issues thanks to its voting feature.
It is easy to use - just login with GitHub. GitHub issues have voting too, nevertheless
Product Pains has been very useful in highlighting the top bugs and feature requests:
https://productpains.com/product/react-native?tab=top
Also, if this issue is a bug, please consider sending a pull request with a fix.
We're a small team and rely on the community for bug fixes of issues that don't affect fb apps.

Hi dude, i have also find out one good example

Android Push Notifications using Google Cloud Messaging GCM - Android Example

If you are using zo0r's react-native-push-notifications for android push notifications then you should check this answer.


Server listening on localhost has not been accessed error

I filled the ClientID, ClientSecret and Port fields according to the instruction
After clicking Get Devices button the browser opens and I receive the following error in a few seconds.

In the browser I receive an error: ERR_CONNECTION_REFUSED
I've tried several different free ports but the problem remains. Also I've tried running Chrome in safe mode but that didn't helped.

OS:  Windows 10
Version 1.3.0

I ve managed to fix this problem:

Opened the port in the firewall
Clicked GetDevices button
Copied the url from the Chrome when it opened before showing the error
Closed the error message and closed the browser
Clicked GetDevices button again and rapidly closed the browser before the page loaded
The BeatBind application frozen at that moment
Pasted the url into Chrome in a safe mode

Seemed like Chrome was redirecting from http to https by default

Isn't it possible to make the application listening the https callback?

Glad you managed to figure it out, but sorry you had to go through all that haha it should just work. I haven't seen that error yet, and I'm not too sure how to reproduce that.

Isn't it possible to make the application listening the https callback?
I'm not sure, I'll have to look into it when I have time, but the reason it's http is because that's what Spotify's examples were using https://developer.spotify.com/documentation/web-api/concepts/apps

@GOOSLI I added BeatBind-https.zip to the release. Let me know if that fixes anything for you https://github.com/justinknguyen/BeatBind/releases/download/v1.3.0/BeatBind-https.zip

Thank you for the response (and also thank you a lot for an application ❤)!
I've checked the BeatBind-https.zip, but behaviour didn't changed a lot. Now BeatBind application doesn't show an error, but nothing happens and browser shows ERR_CONNECTION_REFUSED

Thank you for the response (and also thank you a lot for an application ❤)!
I've checked the BeatBind-https.zip, but behaviour didn't changed a lot. Now BeatBind application doesn't show an error, but nothing happens and browser shows ERR_CONNECTION_REFUSED

hmm and I’m guessing you’ve already set the Redirect URI on the Spotify app to include https?

Like that?

I did like that. Is that correct?

Yea, just testing it myself and it looks like the callback can't be https

Also FYI I've found out that HSTS setting for localhost in my browser for some reason was turned on and was permanently redirecting me to https. Top answer from here solved my problem and I excluded localhost from HSTS. So maybe you can put it in FAQ section.

Also FYI I've found out that HSTS setting for localhost in my browser for some reason was turned on and was permanently redirecting me to https. Top answer from here solved my problem and I excluded localhost from HSTS. So maybe you can put it in FAQ section.

Awesome! Thanks for letting me know, and I'll add that to the FAQ for sure. Thank you


chore(deps): removed core-dependency crypto

@flohoch this dependency is not needed anymore because crypto is part of the internal Node packages