Protocol: Blind Sigs on Pedersen Commitments

In this protocol one would create blind Pedersen commitments to their desired outputs and prove the sum with rangeproofs. The underlying values would be blindly signed, thus they can be registered as outputs separately. However merging these values (eg. coin consolidating) is not figured out.
More information on Blind Signatures on messages committed in Pedersen Commitments: http://www.cs.pwr.edu.pl/hanzlik/preludium/wyniki/paper2.pdf
Another Pedersen commitment blinding scheme is described in ACL paper: https://eprint.iacr.org/2012/298.pdf

Coin merging in this scheme isn't solved perfectly, although denominations can mitigate most of privacy risks.

@nothingmuch @seresistvanandras I'm wondering if we'd fail with the "ideal" solution with different crypto schemes we wouldn't blindly fall back to this scheme, but rather we could explore all the blind Pedersen commitment signature schemes as there are I think 3-4 variants out there.

I think this Blind Signature scheme admits a simple and elegant way to merge coins at output registration phase.
Let's assume the user has two valid signatures  on messages . In this particular blind signature scheme, the signature actually consists of two group elements, ie. . The signature verification entails checking the following pairings: .

i need to go through the algebra with fresh eyes, but this iteration seems correct to me.
as discussed on the call, ideally this should be generalized from 2 to n secret summands without revealing the intermediate sums, but even without that there is still an advantage.
for example, suppose i have 3 inputs, such that the sum of any 2 is less than my desired output amount, at input registration i can split each into multiple sub amounts.
at output registration, i would then submit at 2 or more pairs of signatures which may come from either a single input or two separate inputs (in general it'd be 1 or more, but in my example at least 2 are required because no pair of sub-amounts suffices).
so the advantage i can see to doing this is a quadratic increase in the input size for the n-partition problem[1] on the registered sub-amounts (note: this is separate from the final input/output values, and both must be addressed for privacy).
without merging, the individual sub-amounts may only originate from a single input of a strictly greater amount, which is a concern for small inputs if clients with larger inputs don't create small sub-amount.
therefore it seems that even just pairwise merging has some benefits despite not being ideal, since it can reduce the requirement to split inputs to small sub-amounts in order to obscure the relationship between inputs and outputs.
i also think that we can get something that is roughly equivalent to a generalization to n sub-amounts, but with interactivity, by adding support for reissuance (non-synchronous) during the input registration phase: if the  relation is proved with  as a secret input (knowledge of exponent), such that this value is also equal to the committed amount (this requires a third type of ZK proof for Pedersen commitment opening, also possible with a sigma protocol).
[1] commonly referred to as "subset sum", but i am willing to die on this hill ;-) also since i'm being pedantic, some of the partitions may be the empty set

I think an immediate and trivial generalization would allow us to prove  a k-to-n merging, where we would leak the integers k and n. I know that this is suboptimal from a privacy point of view, however, I feel that if we also want to hide these informations then we would need significantly more complex ZKPs, which still should be quite lightweight. I'll think about it.
Anyways, I do think that 2-to-1 merging is already a huge leap forward as users themselves or software could facilitate that we would not need more types of merging. This could be achieved if users are merging/consolidating their UTXOs before entering the CoinJoin in the first place, then 2-to-1 merging should be fine. However, I agree that this blows up blockchain footprint and might require additional txs from users, which I guess we want to avoid.

why does 2-to-1 blow up the blockchain footprint? i don't see how that matters
fwiw for reissuance what i meant is that you submit some combination of signatures, and receive a new set of signatures on an arbitrary splitting of the sum, where all amounts are blinded, i think this gets all the benefits of n-to-1 merging from a privacy point of view just with additional overhead and interactivity

What I meant is that, in case if we only implement 2-to-1 merging, then we force users to do some consolidation of UTXOs before sending their coins to the CoinJoin transaction. These consolidating transactions would cause some added footpring to the blockchain as these consolidations might have been done maybe with some more complex ZK proofs during output registration phase without issuing those consolidating/merging txs on the blockchain.

doesn't a reissuance operation address that?

I guess so, however, my understanding was that reissuance is the devil as it introduces yet another asynchronous communication round with the coordinator. Hence, we want to avoid it as much as we can.
Is this view correct @nopara73? Or a reissuance phase is okay(ish)?

it'd be much better to do this non-interactively, but the downsides of async communication (note: not a new phase, during input registration phase) are very minimal compared to a synchronous phase or to sub-optimal tx structure, so i think that would be a clear win even if we can't figure out a way to generalize

assuming only pairwise merging, the example of the 3 inputs (let's say 0.5, 0.4, 0.3) required for a single output (say 1.0) might go as follows.
the specific are amounts chosen naively for clarity, to avoid i should include additional fuzzed 0 amounts. since the amounts are kept completely hidden when reissuing, the the main privacy leak is temporal, depending on how many other users have registered so far. an additional reissuance phase would categorically eliminate these leaks, but i think this is better addressed by clients to retain async properties

at input registration i might register my inputs to obtain 4 signatures in total by registering inputs, and reissue to obtain 2 new ones. the steps in bullet points are only partially ordered:

register 0.5 with blinded amounts 0.3, 0.2 receiving signatures that i then unblind as  and  [1]
register 0.4 with blinded amounts 0.4 for
register 0.3 with blinded amount 0.3
reveal  and  to request a signature,  for amount 0.7 - while keeping this total amount hidden as described above
reveal  and  to obtain  for amount 1.0

at output registration:

reveal  and amount 1.0 to register my desired output
reveal  and amount 0.1 to register change output

[1] sorry about weird indexing notation but if i write \sigma_{1,1} the whitespace looks really confusing when displayed inline

Wow! This is quite an illustrative and nice example. So reissuing can be paralellized. That's nice!
I do think we have a k-to-n merging my point is that it is not ZK, as coordinator would know that user is merging k UTXOs to n new UTXOs. But I think, this privacy leak can be thought negligible. Can we really disregard such a privacy leak?

i think that can be mitigated if a minimum number of signatures is always required (effectively making fuzzed 0 values mandatory)
can you explain how k-of-n follow trivially from 2-of-1? i'm not seeing it

You can parallelly convince coordinator that your k signatures are valid without revealing the underlying k messages in the same fashion as it was done in the 2-to-1 case.

It is also quite similar to the second step of the 2-to-1 merging but coordinator will check at the end of the protocol that . Users can show that all the elements on the left side are well-formed and correspond to secret messages proved in the first step with Chaum-Pedersen proofs. Right-hand side can trivially be computed by coordinator, hence verifying this equality in the target group of the pairing.

thanks! the Chaum-Pedersen proof is what failed to click, but i think this makes sense now.
so i think with this we have something that's pretty complete: arbitrary amounts, ability to change output amounts after input registration. i really like that double spending prevention is much simpler than the ideas we discussed in the context of a signature homomorphism based approach.
the main downsides:

requires more interaction than ideal case of offline unlinkable merging
signature algorithm requires pairing so this introduces some less standard assumptions (mainly a marketing concern, since a crypto break shouldn't result in more than a DoS vector) and higher implementation burden
not misuse resistant because merging is not fully ZK (bad client implementation of reissuance may result in privacy leaks)

which suggests these are the next problems to work on, with solutions being more of a nice to have:

can we make reissuance non interactive? (aside: maybe we want to to look at some of the impossibility results on transferable e-cash?)
can we realize the nice signature properties without a pairing function?

requires more interaction than ideal case of offline unlinkable merging

Maybe fully ZK offline unlinkable merging could be achieved with more advanced ZKP techniques?

signature algorithm requires pairing so this introduces some less standard assumptions (mainly a marketing concern, since a crypto break shouldn't result in more than a DoS vector) and higher implementation burden

I wanted to work with a blind signature scheme which can sign messages in a Pedersen-commitment as in that case we have coin merging for free essentially. The other paper which achieves this is by Georg Fuchsbauer et al. To me it seems that without pairings we cannot achieve our desired goals.

not misuse resistant because merging is not fully ZK (bad client implementation of reissuance may result in privacy leaks)

Audits (cryptographic and implementation) will be inevitable.

which suggests these are the next problems to work on, with solutions being more of a nice to have:
2. can we realize the nice signature properties without a pairing function?

We should love pairings! :)

Maybe fully ZK offline unlinkable merging could be achieved with more advanced ZKP techniques?

to make sure we're talking about the same thing - for sure it's possible to achieve with different means (e.g. the overkill approach described in #13, or maybe with some of the divisible e-cash work) - am i correctly understanding that only mean using the same general approach as here, namely blind signatures on homomorphic ammount commitments, double spending by revealing unblinded signatures, and no "heavy" ZKP techniques like zkSNARKs right?

I wanted to work with a blind signature scheme which can sign messages in a Pedersen-commitment as in that case we have coin merging for free essentially. The other paper which achieves this is by Georg Fuchsbauer et al. To me it seems that without pairings we cannot achieve our desired goals.

I think we might also look more closely at the signature scheme described in the Anonymous Credentials Light paper, as noted by @nopara73 above

Audits (cryptographic and implementation) will be inevitable.

i think it's a relatively minor issue, but it'd be nice to be able to rule out the possibility, especially since this privacy leak is at a higher level than the crypto, so i suspect people are more likely to modify client behaviour

We should love pairings! :)

i do, pairing crypto is beautiful, and that for this application the fact that it's still considered less conservative is not even a real issue, but i'm still not sure it's the most pragmatic choice...
mainly i'm concerned about the implementation challenges. if with a bit more protocol design work we can realize something similar on top of secp256k1, even something a bit less elegant, then the barrier to implementing this protocol (in C# but also more widely in the bitcoin ecosystem) will be reduced, which i think is a very important consideration. secondly, there's the the "marketing"/perceptions

I do think that the Blind Sig on Pedersen Commitment scheme will be the most performant we can come up with most likely.
My intuition is that this problem cannot be solved without pairings. We essentially have two options.

Blind Sig scheme without pairing
Most likely the hash function  of the blind sig scheme will not support algebraic statements, hence we would need to use zkSNARKs for proving relations for Keccak, SHA256 pre-images....hence at the end of the day we would need quite-heavy zkS[N/T]ARK magic.

Blind Sig scheme on homomorphic commitments
We know two schemes so far, both of them rely on pairings.

the ACL paper's signature scheme on Pederson commitments that does not rely on pairings and allows single use credentials in their construction, see sections 3-4

Hmmm...woah! Interesting, thanks! Gotta have a look at it and see if we can build coin merging on top of it!

for the record, again @jonasnick deserves all the credit for these insights, see the wasabi research club https://www.youtube.com/watch?v=pgErjQSQQsg

https://github.com/zkSNACKs/WabiSabi/issues/30


template.module fails with StrictUndefined

This fails:
from jinja2 import Environment, FileSystemLoader, StrictUndefined, Undefined
from jinja2.environment import TemplateModule
from jinja2.exceptions import UndefinedError

env = Environment(loader=FileSystemLoader(".", "utf-8"),
              undefined=StrictUndefined)

tpl = env.get_template("test.html")

print dir(tpl.module)

... when using the following test.html:

{{ yay }}

{% macro yo() %}
    YO!
{% endmacro %}

This is because making the "module" involves rendering the complete template in the background. Since "StrictUndefined" is used and "yay" can not be passed to this process it fails.
The following patch solves this problem:
Add this to "environment.py":
class _NeverFailValue(object):
    def __call__(self, *args, **kwargs): return self
    def __str__(self): return ""
    def __repr__(self): return ""
    def __getitem__(self, key): return self
    def __getattr__(self, key): return self
    def __cmp__(self, other): return 0
    def __len__(self): return 0
    def __iter__(self): return self
    def next(self): raise StopIteration

class _NeverFailData(object):
    def __getitem__(self, key):
        return _NeverFailValue()
    def __contains__(self, key):
        return True

and modify the "make_module" method:
def make_module(self):
    vars = _NeverFailData()
    shared = True # so we get vars passed to the Context
    locals = None
    return TemplateModule(self, self.new_context(vars, shared, locals))

Not sure if this would come up in practice. Closing this down unless reopened with some reasons about why this comes up.

I usually use a separate _foo.html file that contains only macros to avoid executing "out-of-macro" code when building a template module to call a macro from Python code.
However, it would be nice if tpl.module simply ignored anything outside macros. Doing so would also avoid any issues with whatever Undefined implementation is used (unless the macro itself is trying to use something undefined, which usually shouldn't be the case).

@ThiefMaster however why is there stuff in the first place. I mean undefines are clearly not the only issue there :)

With the separate html file there isn't - but for the simplest (and probably most common) case for .module where you just want to re-render something via AJAX it would often be nicer to have it in the same template, e.g. something like this:
{% macro row(item) %}

...

{% endmacro %}

    {% for x in items %}{{ row(x) }}{% endfor %}

That's intentionally not supported though.

I mean, if we want to support that we need a complete new compiler mode that also has some other potential disadvantages: eg: conditional macro defines.


Update README.md

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

Comparison is base (0eeea50) 95.06% compared to head (92d0d8f) 95.06%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##           master     #172   +/-   ##
=======================================
  Coverage   95.06%   95.06%
=======================================
  Files          21       21
  Lines         162      162
  Branches       14       14
=======================================
  Hits          154      154
  Misses          8        8

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


Update move-resource-group-and-subscription.md

Explain that the lock cannot be in the resource group or subscription. Not to get confused that the lock doesn't have to be in the resource, as sometimes the resources can have a read only lock while moving.

@mumian
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


GH action: Debian package is missing Debian revision number

Debian package created by GH action is missing Debian revision number.
Wrong: linz-lds-bde-schema_1.10.1-linz~bionic1_all.deb
Correct: linz-lds-bde-schema_1.10.1-1linz~bionic1_all.deb

Ok, this is tricky. We're going to create versions like 1.10.1-2-g0000 from commits in the stable-1.10 branch, so how are we going to control precedence ? Do you see debian changes occurring without commits to the repository ? Because commits in the repository will be already changing version, as well as tags will...

@imincik I've added the debian revision in PR #30 - please review that one

Do you see debian changes occurring without commits to the repository ?

No, you always commit all changes to repo or I don't understand your question. BTW, dch command has --increment switch. Can this help ?

Ah, I just realized. The problem is that from time to time we discover some issue with packaging and in this case we want to increment only Debian revision value and repackage (without releasing new software version). What we are going to do in this case ?

How about a DEBIAN_REVISION env variable support in the Docker image ?

While I was adding a DEBIAN_REVISION I realized what I said is still true. That is: if we find an issue with the debian package, such issue, to be fixed, will need to be addressed by committing a new change to the repository. Doing this, in turn, will result in the git describe call to return a value like 1.5.0-1-gxxxx which will be used for the debian package version, so a concept of "revision" is already in place. Only we cannot have the github-action publish those packages because we'd need a tag to trigger publication. Doing the publication manually would still work fine though.
Or, we can just tag a 1.5.0-1 explicitly and everything should work fine. In both cases I don't see the need for a debian revision at all. Enough that I'd revert 7b752ff8d7f199d6b4fa20760f57df65a8295622 in this PR. If you're ok with this I'd drop that commit, merge and tag a v3 of this repository, then move on to use the new version from packages (including linz-bde-schema for which we need a new tag)

I'll merge as-is, or can't continue

Or, we can just tag a 1.5.0-1 explicitly and everything should work fine

I don't like idea of tagging 1.5.0-1

I think what we should do is to drop Debian revision completely. debian_revision is optional, but as far as I remember, when not specifying it, you have to change package type to Debian native which is done in debian/source/format file


Traffic Monitor

I have error
ERROR: opsconfig.go:78: 2022-07-29T07:10:36.998551108Z: OpsConfigManager: MonitorConfigPoller: error instantiating Session with traffic_ops (): logging in using legacy client: logging in: requesting: Post "https://ipxxxx /api/2.0/user/login": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
{
"username": "admin",
"password": "******",
"url": "https://ipxx.xxx.xxx",
"insecure": true,
"cdnName": "cdn",
"httpListener": ":80",
"httpsListener": "",
"certFile": "/opt/traffic_monitor/key/",
"keyFile": "/opt/traffic_monitor/key/"
}
key form traffic_ops

looks like your traffic monitor can't contact traffic ops
For troubleshooting help, please join our Slack channel(s) on the ASF Slack workspace.


Complex Schema how to define subfields

Hi,
I'm trying to define subfields in autoform.
I tried to follow this guidence https://github.com/aldeed/meteor-autoform/blob/master/README.md#complex-schemas
But this example doesn't follow some showed previously schema.
I tried to access field emails.$.address with {{> afQuickField name='emails.address '}} but I get "Error: Invalid field name".
In my situation I need to attach data to a select that is inside complex schema.

You need to use the real index in autoform, i.e., emails.0.address. If you're trying to provide a way to add/remove from the array, edit multiple indexes at once, etc., then you can let afArrayField component do it for you, or you can use afEachArrayItem to help with the process.


Create Workflow (part 1), Enrich Data With Data Transform in SAP Data Intelligence, Trial Edition

Tutorials: https://developers.sap.com/tutorials/dataintelligence-trial-v2-workflow-part01.html
This tutorial is referencing deprecated objects, like "Spark Data Transform" the problem is that the new object is incompatible; in this example new "Data Transform" operator needs a "table" type; if you follow this tutorial, you don't get this input. You could say the tutorial has become obsolete as part of the mission.

I will check and get back on this

As of January 31, 2023, the DI Trial CAL image is no longer available. Please contact your account executive to explore different options available to you.
Refer the blog https://blogs.sap.com/2022/07/14/sap-data-intelligence-trial-edition-3.2/


Prefect 2.0 UI not working when ingress enabled

Helm installed Prefect 2.0 with postgresql as backend, and ingress enabled with host address  prefect.example.com
prefect config set PREFECT_API_URL="http://prefect.example.com/api"
the flow run states being stored in the database successfully, you can query them in the database table.
But nothing shown in the UI, because all the API calls from the UI page still go to local server: http://<IP_ADDRESS>:4200/api/

adding the following in the values file, kind works, but not perfect.
We limit only one way to access our service.
env:
- name: PREFECT_ORION_UI_API_URL
value: http://..***./api

@gq1 I added a docker compose example that works for me in the other issue that you mentioned above.
I was setting PREFECT_ORION_UI_API_URL to the public address and port from the outside.
And PREFECT_API_URL to a value using an internal container/pods address and port. Then
starting orion with  --host <IP_ADDRESS>
Details see in other issue. It is docker-compose but maybe it helps

@gq1 @kwmiebach can you confirm if you're still facing this issue?

Has anyone been able to get ingress working with the chart? This fixed the API calls, but I had to use my own ingress as it looks like the chart is setting the servicePort to http/80 instead of 4200 and there doesn't seem to be a way to override this

@jacobdanovitch - this should be fixed with this pr.  Planning to release this today

@jacobdanovitch - this should be fixed with this pr. Planning to release this today

Just got around to updating today and can confirm everything is working as expected. Thanks!

Hi there, I am also getting Can't connect to Orion API at http://<IP_ADDRESS>:4200/api. Check that it's accessible from your machine after the deployment using Helm.
The UI is available https://prefect.mydomain.com
What value should I set on PREFECT_API_URL?


update_items() only processes the first chunk (50 items)

Isn't there an indentation error (one tab too much) here?
https://github.com/urschrei/pyzotero/blob/fe9cd007a0216350fae405a98885c22d9308ad27/pyzotero/zotero.py#L1448
and also here:
https://github.com/urschrei/pyzotero/blob/fe9cd007a0216350fae405a98885c22d9308ad27/pyzotero/zotero.py#L1478
I've discovered that update_items() only updates the first chunk (i.e., the first 50 items) and all the remaining items do not get updated.

Hmm. Looks like it. I won't be able to fix it til Saturday, however.

Released to PyPI as 1.4.23


Add SSH_AUTH_SOCK to EnvironmentVariables.nonCachableKeys

Yet another environment variable that shouldn't trigger full package rebuilds.
Resolves rdar://107029374

@swift-ci test


[vcpkg.cmake] Fix CMP0126 warning when running in trace mode (#23784)

When running CMake 3.21 or newer in trace mode, vcpkg.cmake would trigger the CMP0126 warning. Explicitly set this policy to OLD behavior within the vcpkg.cmake policy scope to silence the warning without changing behaviour.
Fixes #23784

After reviewing the warnings I come to the conclusion that it would be safe to set the policy to NEW within the vcpkg.cmake policy scope. Opinions?

Unlike many policies, CMake version 3.26.0-rc5 does not warn when the policy is not set and simply uses OLD behavior. See documentation of the CMAKE_POLICY_WARNING_CMP0126 variable to control the warning.

does not warn when the policy is not set
-> CMake bug ? or did you change CMAKE_POLICY_WARNING_CMPNNNN ?

After reviewing the warnings I come to the conclusion that it would be safe to set the policy to NEW within the vcpkg.cmake policy scope.

vcpkg.cmake is also used by user projects. So it is not really limited to vcpkg ports. We should be careful before changing it when Kitware decided that it needs a policy.

does not warn when the policy is not set
-> CMake bug ?

IIUC the behaviours is different with trace modes.

-> CMake bug ? or did you change CMAKE_POLICY_WARNING_CMPNNNN ?

In trace mode, CMake enables all optional warnings. This is not a bug.
bool cmMakefile::PolicyOptionalWarningEnabled(std::string const& var) const
{
  // Check for an explicit CMAKE_POLICY_WARNING_CMP<NNNN> setting.
  if (cmValue val = this->GetDefinition(var)) {
    return cmIsOn(val);
  }
  // Enable optional policy warnings with --debug-output, --trace,
  // or --trace-expand.
  cmake* cm = this->GetCMakeInstance();
  return cm->GetDebugOutput() || cm->GetTrace();
}

vcpkg.cmake is also used by user projects. So it is not really limited to vcpkg ports. We should be careful before changing it when Kitware decided that it needs a policy.

vcpkg.cmake uses cmake_policy(PUSH/POP), and within these calls we can set policies without affecting user projects.

After reviewing the warnings I come to the conclusion that it would be safe to set the policy to NEW within the vcpkg.cmake policy scope. Opinions?

I don't mind setting it to new.

In trace mode, CMake enables all optional warnings. This is not a bug.

But the code also says you could actively suppress the warning if I read it correctly. (i.e. by explicitly setting it to false)

Trying to get the full picture.

The code run at top-level scope.
It is scoped by cmake_policy(PUSH/POP).
However, there are two ways how this policy setting enters the scope of the user projects:

The chainloaded user toolchain file is loaded in the same scope.
The policy setting is used by vcpkg macros which override cmake commands (#28960).

I'm not really against this change. But I want all options to be considered:

Do nothing. The user can adjust policies and warnings if desired. Standard behaviour.
Force-disable the warning. Needs care to not override an explicit user setting. Mild non-standard behaviour.
Force-enable the policy. This PR. Recommended for new CMake code, but would also apply on old find modules and package configs.

Last not least it might make sense to actually check the current warnings. In #23784, I see VCPKG_MANIFEST_DIR. This is a variable under vcpkg's control. Can we change our scripts to avoid the warning?

Avoiding the warning without modifying the policies is certainly an option. The pattern where the warning is triggered is:
if(NOT VCPKG_SOME_VAR)
    set(VCPKG_SOME_VAR some default)
endif()
set(VCPKG_SOME_VAR some default CACHE PATH "docstring" FORCE)

The minimal impact fix is
if(NOT VCPKG_SOME_VAR)
    set(VCPKG_SOME_VAR some default CACHE PATH "docstring")
endif()
set(VCPKG_SOME_VAR some default CACHE PATH "docstring" FORCE)

Or it might be more elegant to use a differently named variable for holding the default value.
If I remember correctly, only two VCPKG_* variables are affected.
I'll play with this approach.

It's better to adapt to warnings than to avoid them, and I think this one is ok.
We can check whether this warning is triggered elsewhere, and we can refer to the modification.  :)


Summary mappings

Could you please provide a quick example of how to use the summary window mappings?
The help file lists a table of mappings but I don't know how to trigger/map them properly.
I've tried lua require("neotest").summary.run() but it doesn't work.

Nevermind, I found the mappings in :h neotest.setup() :)

@dahmc This really helped me, as I was really struggling find the keybindings I needed. An expanded readme would be super useful to those of us who are less familiar with Vim :)

I've mentioned neotest.setup() as well in the README so users will easily see defaults. I've also pointed to https://github.com/folke/lua-dev.nvim which will allow users to easily get autocomplete for setup values.

@rcarriga thank you for your help and your contributions.


Add config to override JDK default compiler

This only works for running tests and when running via mvn exec:exec
This DOES NOT fix the issue when running from the container -- for that
we will need to alter the Java startup script in the base image.

@adamdickmeiss Yikes, I see that you already have a branch for this. I'lll close it then and add the exec config on top of your branch.


docs: Added up to date network options for Ethereum data source

First PR raised in this project, having read the contribution guidelines and attempts to align to previous PRs and commits as best as I saw from history. Please do let me know if you'd like me to do any further revisions to any part.
I was looking to build and deploy a subgraph for BSC and could not find the network information required for the data source inside the subgraph-manifest docs. I found the information I needed on discord as an adhoc answer to my specfic question, but also wanted to find the source information for the options available. I eventually found this inside https://github.com/graphprotocol/graph-cli/blob/master/src/commands/init.js#L43-L57, which I have linked to in this tiny update.
I would have loved to have this information easily available, and I am hoping it may help the next person. Hopefully you'll agree and we can update this part of the docs. I haven't looked at the rest of the manifest, but would also like to keep this first PR small.
Excited to contribute a tiny part to your great project.

@lutter Hi, I am not able to request a reviewer. I can see you wrote the previous commit on this file, please can you review or help this get to the right reviewer / advise what I could do differently in the flow next time?


Crash on startup on macOS 10.14.6 (3.0.0-beta5)

Checklist

[X] I have searched for existing issues
[X] I have looked through the wiki
[X] I have updated MonitorControl to the latest version

Describe the bug
MonitorControl 3.0.0-beta5 crashes on startup on macOS 10.14.6 100% of the time.
To Reproduce
Steps to reproduce the behavior:

Go to Applications/
Double click on MonitorControl
Observe icon-opening animation

Expected behaviour
MonitorControl starts, and creates a new menu in the menu bar.
** Actual behaviour**
Nothing else is observed to happen—not even an error dialog—but a new entry is created in ~/Library/Logs/DiagnosticReports/.
Additional context
I tried starting MonitorControl several times but every occasion failed in the same way.
Excerpt from MonitorControl_2021-08-09-162610_Hal.crash.gz:
Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    DYLD, [0x4] Symbol missing

Dyld Error Message:
  Symbol not found: _CoreDisplay_DisplayCreateInfoDictionary
  Referenced from: /Applications/MonitorControl.app/Contents/MacOS/MonitorControl
  Expected in: /System/Library/Frameworks/CoreDisplay.framework/Versions/A/CoreDisplay

Environment Information (please complete the following information):

macOS version: 10.14.6
Mac model: MacBook Pro (Retina, 13-inch, Early 2015) ("MacBookPro12,1")
MonitorControl version: 3.0.0-beta5
Monitor(s): Built-in only or built-in + Apple Thunderbolt Display
Apple Silicon/M1 (yes or no): no

Thanks for the detailed info!

Can you try on beta 6 and let us know if it helps?

Beta 6 appears to work properly, except for not fixing #212.


Change Entity::generation from u32 to NonZeroU32 for niche optimization

Objective

Implements change described in https://github.com/bevyengine/bevy/issues/3022
Goal is to allow Entity to benefit from niche optimization, especially in the case of Option to reduce memory overhead with structures with empty slots

Discussion

First PR attempt: https://github.com/bevyengine/bevy/pull/3029
Discord: https://discord.com/channels/691052431525675048/1154573759752183808/1154573764240093224

Solution

Change Entity::generation from u32 to NonZeroU32 to allow for niche optimization.

The reason for changing generation rather than index is so that the costs are only encountered on Entity free, instead of on Entity alloc
There was some concern with generations being used, due to there being some desire to introduce flags. This was more to do with the original retirement approach, however, in reality even if generations were reduced to 24-bits, we would still have 16 million generations available before wrapping and current ideas indicate that we would be using closer to 4-bits for flags.
Additionally, another concern was the representation of relationships where NonZeroU32 prevents us using the full address space, talking with Joy it seems unlikely to be an issue. The majority of the time these entity references will be low-index entries (ie. ChildOf, Owes), these will be able to be fast lookups, and the remainder of the range can use slower lookups to map to the address space.
It has the additional benefit of being less visible to most users, since generation is only ever really set through from_bits type methods.

EntityMeta was changed to match
On free, generation now explicitly wraps:

Originally, generation would panic in debug mode and wrap in release mode due to using regular ops.
The first attempt at this PR changed the behavior to "retire" slots and remove them from use when generations overflowed. This change was controversial, and likely needs a proper RFC/discussion.
Wrapping matches current release behaviour, and should therefore be less controversial.
Wrapping also more easily migrates to the retirement approach, as users likely to exhaust the exorbitant supply of generations will code defensively against aliasing and that defensive code is less likely to break than code assuming that generations don't wrap.
We use some unsafe code here when wrapping generations, to avoid branch on NonZeroU32 construction. It's guaranteed safe due to how we perform wrapping and it results in significantly smaller ASM code.

https://godbolt.org/z/6b6hj8PrM

Migration

Previous bevy_scene serializations have a high likelihood of being broken, as they contain 0th generation entities.

Current Issues

Entities::reserve_generations and EntityMapper wrap now, even in debug - although they technically did in release mode already so this probably isn't a huge issue. It just depends if we need to change anything here?

We might want to write a little migration script that increases the generation of every entity in a scene file by one

We might want to write a little migration script that increases the generation of every entity in a scene file by one

Do we have any prior art for this? Be good to look at before I give it a go

appears sensible, should probably merge after #9797 though

Seems like this'll need a rework after that lands, which is fine - I'll keep my eyes out for it. I'll look at doing the benchmarking after that's in and I fix things up.

The wrapping stuff

If you want to do the usual wrapping for addition of two integers, here is how (playground)
Proof that it works: adding two integers will result in exactly 0 or 1 overflows (2 × uN::MAX = (oveflow_flag, uN::MAX - 1)). The case with 0 overflows is trivial (just add them normally). If overflow happens, the result would be off-by-one with the normal wrapping. There are two extreme cases: if result was uN::MIN, adding 1 will make it NonZeroUN::MIN. If result was uN::MAX - 1, adding 1 will make it NonZeroUN::MAX. Thus, neither underflow nor overflow of NonZero domain is possible. There's also a commented out simple test for Miri, albeit it needs to be run locally.
Tl;dr: it's as simple as (x + y + overflow_flag)

@Kolsky Oh, that's really excellent :O Thanks for that!

The optimized assembly is also really clean, nice!

Still waiting on that other PR to merge, but I ran bench with 857fb9c72:
bench.txt

I'm not too familiar with those numbers, but they seem rather inconsistent between different magnitudes of test:
X5950, 32GiB ram, Running EndeavourOS with Linux 6.5.4
Shut everything down on the machine except the terminal running the test.

Yeah, the benchmarks are definitely a bit noisy, both here and in general 🤔 I can't make clear sense of this unfortunately.

Elabajaba on discord pointed out that since I'm on a Zen 3 CPU, I'm probably getting different boosts on every core. I'll try disabling that and running the tests again, see if I get something more stable and less noisey.

Yep, that was it. I disabled Precision Boost and locked my CPU scaling to 2.2GHz on linux. Much more stable, not as much swing between tests, still a little noisey. But I think maybe i need to run a few more tests, because the results are little strange in places (30% gain on events_iter??)

(Sorry about that double-push, doing it between compiles at work and thought I already ran CI locally... oops)

At this point, would it be worth re-basing on #9797 ahead of time?

Thanks Alice, I'll get on that soon

Couldn't find information on this in the migration guide

I'm deeply sorry for the inconvenience I've caused with this. I'll look into some solutions.


DSD-1645: Updating Form, Fieldset, Label, and FeedbackBox to Chakra 2.8 theme API

Fixes JIRA ticket DSD-1645
This PR does the following:

Updates Fieldset, Label, and FeedbackBox components to use the Chakra 2.8 updated API for their theme object.
Form doesn't have a theme object, so I just updated its type in order to eliminate the "any".
One thing I am noticing is that you can import some of the functions (defineStyle, defineStyleConfig, etc) from either "@chakra-ui/system"; or "@chakra-ui/react";. I assume we should make this consistent throughout, but it is not as of now.

How has this been tested?

Locally in Storybook.

Accessibility concerns or updates

None.

Checklist:

[ ] I have updated the Storybook documentation accordingly.
[ ] I have added relevant accessibility documentation for this pull request.
[ ] All new and existing tests passed.

Front End Review:

[ ] Review the Vercel preview deployment once it is ready.

@EdwinGuzman, the focus ring was looking vertically oblong because for some reason the width was no longer 40px as it is on prod. I added a new minWidth and now it's square again, but I am not sure why.


Godbound- Forever HP Short

The Godbound character sheet does not apply the con mod at 1st level, as the rulebook says to. So you're always short half your con mod in HP.

@ParadoxSong The Godbound sheet have been replaced with a better version entirely, this issue should be closed


Clock module format string regression: doesn't support some common date formats

After upgrading from 0.9.9-1 -> 0.9.9-2 from the Arch Linux repository, waybar omits my clock#time module but still draws my clock#date module with no trouble. The only error message I get when running the bar from a shell is [error] : invalid format, which makes it sound like the config has a JSON syntax error, but it worked fine in the previous version.
I prefer to have the time alone in the modules-center, and my date off to the side in modules-right. The only fix I've found to keep the format I want is to downgrade to 0.9.9-1.
This is one of my first GitHub issues, so if any more information would be helpful just let me know and I can include it. Attached are my config stylesheet.
config.txt
style.txt
.

appears to be similar to #1439. I had to change the time format to use %R to get it to work.

I filed this as https://bugs.archlinux.org/task/73982, looks like here’s the right place now, as it affects anyone building from source with up-to-date dependencies.
So %l (space-padded hour, 1–12; as an aside, I’ve always found it quite baffling that there’s mostly no unpadded hour figure in strftime—though glibc has %-I for the purpose) and %P (am/pm, lowercase unlike %p) have become broken in some dependency of this.
Actually, referring to a disgruntled comment I put in my ~/.config/waybar/config: %l and %P were already broken in clock’s tooltip-format, but worked in format. These sorts of inconsistencies (this, pango markup working in some places but not others, that kind of thing) are rather frustrating.
I suggest retitling this issue to mention that it’s a clock format string regression.
For now, I’ll stick with Arch’s 0.9.9-1 package.

According to https://github.com/fmtlib/fmt/issues/2811, the std::tm formatter no longer supports system-defined specifiers.

I was able to do the following. If that's not a problem, please use it as a reference.

~/.config/waybar/config
    "custom/clock"

    "custom/clock": {
        "format": "{}",
        "interval": 5,
        "exec": "date +%-m/%d\\(%a\\)%-H:%M",
    },

~/.config/waybar/style.css
#custom-clock,

#custom-clock {
    font-weight: bold;
    background-color: @theme_selected_bg_color;
}

Hi @spencer-maaaaan , please see https://github.com/Alexays/Waybar/issues/1469#issuecomment-1441870125

Hi @spencer-maaaaan , can you close the issue as a duplicate pf #1469 please?

It should be the other way round: this covers the entire range of regressions (%0I, %-I, %P, and anything else, frankly), whereas #1469 only covers %0I (… and it even misspells it as %OI in its title!).
(In light of the successful landing of glibc padding stuff, I’ve submitted a patch for %P in https://github.com/fmtlib/fmt/pull/3314.)


hlint doesn't compile with ghc 8.8.1 because haskell-src-exts doesn't and it has no maintainer

hlint doesn't compile with ghc 8.8.1 because haskell-src-exts doesn't and it has no maintainer:

On Mon, Sep 2, 2019 at 8:48 AM Matthew Pickering<EMAIL_ADDRESS>wrote:
I'm not the maintainer of the library anymore. As far as I know it is unmaintained.
Cheers, Matt
On Mon, 2 Sep 2019, 12:47 George Colpitts<EMAIL_ADDRESS>wrote:
Hi Matthew
haskell-src-exts doesn't compile with ghc 8.8.1. Any chance that you could fix this soon?

ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.8.1

cabal install haskell-src-exts
...
                             [Fixity] -> Exp SrcSpanInfo -> m (Exp SrcSpanInfo)
    • In the first argument of ‘(<=<)’, namely ‘infFix fixs'’
      In the expression: infFix fixs' <=< leafFix fixs'
      In an equation for ‘applyFixities’:
          applyFixities fixs'
            = infFix fixs' <=< leafFix fixs'
            where
                infFix fixs (InfixApp l2 a op2 z)
                  = do e <- infFix fixs a
                       ....
                infFix _ e = return e
   |
72 |   applyFixities fixs' = infFix fixs' <=< leafFix fixs'
   |                         ^^^^^^^^^^^^

src/Language/Haskell/Exts/Fixity.hs:92:25: error:
    • Could not deduce (MonadFail m) arising from a use of ‘infFix’
      from the context: Monad m
        bound by the type signature for:
                   applyFixities :: forall (m :: * -> *).
                                    Monad m =>
                                    [Fixity] -> Pat SrcSpanInfo -> m (Pat SrcSpanInfo)
        at src/Language/Haskell/Exts/Fixity.hs:92:3-15
      Possible fix:
        add (MonadFail m) to the context of
          the type signature for:
            applyFixities :: forall (m :: * -> *).
                             Monad m =>
                             [Fixity] -> Pat SrcSpanInfo -> m (Pat SrcSpanInfo)
    • In the first argument of ‘(<=<)’, namely ‘infFix fixs'’
      In the expression: infFix fixs' <=< leafFixP fixs'
      In an equation for ‘applyFixities’:
          applyFixities fixs'
            = infFix fixs' <=< leafFixP fixs'
            where
                infFix fixs (PInfixApp l2 a op2 z)
                  = do p <- infFix fixs a
                       ....
                infFix _ p = return p
   |
92 |   applyFixities fixs' = infFix fixs' <=< leafFixP fixs'
   |                         ^^^^^^^^^^^^

Crapola. Someone want to volunteer to fix haskell-src-exts? It's probably not too hard to fix.

I have Tweeted out in order to inspire some brave soul: https://twitter.com/ndm_haskell/status/1168635862797737985?s=20

This has been fixed for months in head.hackage: https://gitlab.haskell.org/ghc/head.hackage/blob/master/patches/haskell-src-exts-1.21.0.patch.

And a similar PR: haskell-suite/haskell-src-exts#431. The lack really does seem to be a maintainer to merge & cut a new release.

Regarding haskell-src-exts: I've been given hackage & github privileges, tested & merged this PR (nearly identical to the head.hackage patch), and uploaded a new version to hackage: http://hackage.haskell.org/package/haskell-src-exts-1.21.1

Thanks Dan! Works for me, I can now successfully compile hlint which also
seems to work
On Tue, Sep 3, 2019 at 3:18 PM Dan Burton<EMAIL_ADDRESS>wrote:

Regarding haskell-src-exts: I've been given hackage & github privileges,
tested & merged this PR
https://github.com/haskell-suite/haskell-src-exts/pull/431 (nearly
identical to the head.hackage patch), and uploaded a new version to
hackage: http://hackage.haskell.org/package/haskell-src-exts-1.21.1
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ndmitchell/hlint/issues/755?email_source=notifications&email_token=ABQIJ6Y3JRKFG6PFYD4WBSDQH2S6TA5CNFSM4IS57JA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5ZDDKI#issuecomment-527577513,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABQIJ64A6LVYFFO4IN5MHS3QH2S6TANCNFSM4IS57JAQ
.

Thanks @DanBurton!


Refactor comms trace parser and deprecate support for basic and Kineto traces

Summary
Refactored the commsTraceParser to enhance readability and maintainability.
Removed deprecated support for parsing "basic" and "Kineto" traces; only Chakra host execution traces are now supported.
Added detailed logging to handle undecimal process group names with warnings instead of exceptions.
Modified _parse_proc_group_info and _parse_comms_op_node for improved processing of process group info and communication operations.
Updated comms_utils to support additional data types (signed char, unsigned char).
Adjusted the command-line interface to reflect the updated trace type options.
Test Plan
$ comm_replay --trace-type et --trace-path /home/sanshang/021_debug/000_code/param/trace/traces_megatronlm_gpt_43B_32ranks_pytnightly0703/execution_trace

@TaekyungHeo and @Sergei-Lebedev, I fixed the parser for version 1.1.1, which missed passing commArgs. Also I saw _getTensorInfoFromPyTorchETEntry and tensorDtypeMap are no longer used, shall we clean them up. Thanks

@TaekyungHeo, test 2 rank Resnet run failed with the following call stack:
ank0]:   File "/data/users/shengfu/fbsource/buck-out/v2/gen/fbcode/6ef5f323b6193f0f/param_bench/et_replay/comm_replay/comm_replay#link-tree/run_lpar_main.py", line 73, in
[rank0]:     __invoke_main()
[rank0]:   File "/data/users/shengfu/fbsource/buck-out/v2/gen/fbcode/6ef5f323b6193f0f/param_bench/et_replay/comm_replay/comm_replay#link-tree/run_lpar_main.py", line 35, in __invoke_main
[rank0]:     run_as_main(module, main_function)
[rank0]:   File "/data/users/shengfu/fbsource/buck-out/v2/gen/fbcode/6ef5f323b6193f0f/param_bench/et_replay/comm_replay/comm_replay#link-tree/par/meta_only/bootstrap.py", line 98, in run_as_main
[rank0]:     oss_run_as_main(
[rank0]:   File "/data/users/shengfu/fbsource/buck-out/v2/gen/fbcode/6ef5f323b6193f0f/param_bench/et_replay/comm_replay/comm_replay#link-tree/par/bootstrap.py", line 94, in run_as_main
[rank0]:     main()
[rank0]:   File "/data/users/shengfu/fbsource/buck-out/v2/gen/fbcode/6ef5f323b6193f0f/param_bench/et_replay/comm_replay/comm_replay#link-tree/et_replay/tools/comm_replay.py", line 1682, in main
[rank0]:     traceBench.runBench(commsParams)
[rank0]:   File "/data/users/shengfu/fbsource/buck-out/v2/gen/fbcode/6ef5f323b6193f0f/param_bench/et_replay/comm_replay/comm_replay#link-tree/et_replay/tools/comm_replay.py", line 1330, in runBench
[rank0]:     self.benchTime(commsParams)
[rank0]:   File "/data/users/shengfu/fbsource/buck-out/v2/gen/fbcode/6ef5f323b6193f0f/param_bench/et_replay/comm_replay/comm_replay#link-tree/et_replay/tools/comm_replay.py", line 1242, in benchTime
[rank0]:     self.replayTrace(commsParams=commsParams, warmup=True)
[rank0]:   File "/data/users/shengfu/fbsource/buck-out/v2/gen/fbcode/6ef5f323b6193f0f/param_bench/et_replay/comm_replay/comm_replay#link-tree/et_replay/tools/comm_replay.py", line 1069, in replayTrace
[rank0]:     (latency, global_latency) = self.runComms(
[rank0]:   File "/data/users/shengfu/fbsource/buck-out/v2/gen/fbcode/6ef5f323b6193f0f/param_bench/et_replay/comm_replay/comm_replay#link-tree/et_replay/tools/comm_replay.py", line 808, in runComms
[rank0]:     self.collectiveArgs.srcOrDst = curComm.srcOrDst
[rank0]: AttributeError: 'commsArgs' object has no attribute 'srcOrDst'
Please take a look. Thanks

Thanks, @shengfukevin . We will take a look.

This commit should be moved to this PR for fix:
https://github.com/facebookresearch/param/pull/148/commits/cacba6dc0b501ac322b14ee500c71f032113845a

Please see if this works: https://github.com/facebookresearch/param/pull/156


Add support for WeMo Humidifier

Description:
Adds support for the Holmes WeMo Smart Humidifier device.
Related issue (if applicable): None
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#4192
Example entry for configuration.yaml (if applicable): Not applicable (extends the existing wemo component)
Checklist:
If user exposed functionality or configuration variables are added/changed:

[X] Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:

[ ] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[X] New dependencies have been added to the REQUIREMENTS variable ([example][ex-requir]).
[X] New dependencies are only imported inside functions that use them ([example][ex-import]).
[X] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[x] New files were added to .coveragerc.

Hi @sqldiablo,
It seems you haven't yet signed a CLA. Please do so here.
Once you do that we will be able to review and accept this pull request.
Thanks!

I'm having some trouble getting tox setup, since this is my first time contributing to Home Assistant. I'll work on that and fixing this issues that houndci-bot found this week.

I was finally able to setup a good dev/test environment and get tox to work. All tests passed on python 3.4. @andrey-git, can you please review this PR and let me know what you think?

@pavoni & @balloob, would you mind reviewing this PR as well? I'm new to developing for HA, so please let me know if I need to make any changes to better fit with existing standard/precedents.

I've made the changes requested, and functional testing in my local install works great.

If you don't want to wait for a review from another member regarding the new service etc, in the fan base component, my suggestion is to move all of that into the wemo fan platform. Look eg at the sonos media_player platform how a platform can register services.
If more fan platforms come along that require the humidity service we can move it to the base fan component at that time.
The above is the only thing in my view that's holding this off from being merged.

That's not a bad idea. I don't suspect many fans have/need humidity control. I'm out of town right now, so I'll work on that next week.
-- Adam
(Sent from my mobile device)

From: Martin Hjelmare<EMAIL_ADDRESS>Sent: Saturday, December 30, 2017 6:39 PM
To: home-assistant/home-assistant
Cc: Adam C. Belebczuk; Mention
Subject: Re: [home-assistant/home-assistant] Add support for WeMo Humidifier (#11076)
If you don't want to wait for a review from another member regarding the new service etc, in the fan base component, my suggestion is to move all of that into the wemo fan platform. Look eg at the sonos media_player platform how a platform can register services.
If more fan platforms come along that require the humidity service we can move it to the base fan component at that time.
The above is the only thing in my view that's holding this off from being merged.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/home-assistant/home-assistant/pull/11076#issuecomment-354575059, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABn-cm2rR1YQXF7wvNtGKzemq-RjBDGaks5tFsmpgaJpZM4Q84O-.

This PR seems to have gone stale. Closing it. You can reopen it when you're ready to finish it.


snakemake version

since the creation of HAMLET Snakemake has been updated. In this new version 'count' has become a key word, but 'count' is used as a variable in HAMLET.
Version 5.14 works for me and version 5.18 does not. You should update your readme or change the variable name.

I've added a line to the readme to clarify that Snakemake should be installed using the environment.yml file to make sure users install a supported version of Snakemake


Kernel Info Reply mime_type

The Kernel Info Reply message should have a mime_type, as specified in https://jupyter-client.readthedocs.io/en/stable/messaging.html#kernel-info
https://github.com/gibiansky/IHaskell/blob/cc427517a59bfc8e1014c7e02fe5cfe0ce7e5eef/ipython-kernel/src/IHaskell/IPython/Types.hs#L294-L301
https://github.com/krassowski/jupyterlab-lsp/issues/313#issuecomment-672058096
I think the mime_type should be "text/x-ihaskell"?

The mime_type should be "text/x-haskell".
https://jupyter-client.readthedocs.io/en/stable/wrapperkernels.html

The MIME type key should be "mimetype".


After a Graph is made , we cannot make another graph

#2 Fixes this issue.

Issue: After you make a graph you cannot make another graph until you destroy or upgrade the Chart.

I see, but your PR has conflicts with the main branch. Please resolve these conflicts and then I will accept it 👍

@intrepidbird Done.

Thanks! 👍


Decide/document if current version is backwards compatible  to 0.7.3

If the version on current main branch is not backwards compatible to 0.7.3, the next release should be 0.8.0 and not 0.7.4 . Also the release notes should list what users should be aware of. This should be done before #281

Since there were many updates, new version was set to 0.8.0 and release notes can be found here.


"Malformed calls from JS: field sizes are different " when useing Header

 "react-native": "0.58.6",
"react": "16.6.3",
 "native-base": "2.12.1",

issue code
import React from 'react'
// import { StatusBar } from 'react-native'
import {Header} from 'native-base'

export default function EleHeader() {
  return (
    <Header/>
  )
}

it works fine when we use 0.57。 After upgrade to 0.58.6, this code will cause error.
Invariant Violation: [659,"RCTView",71,{"backgroundColor":4294967295,"flexDirection":"row","paddingLeft":10,"paddingRight":10,"justifyContent":"center","paddingTop":42,"borderBottomWidth":0.5,"borderBottomColor":4294759270,"height":"<<NaN>>","elevation":3,"shadowColor":4278190080,"shadowOffset":{"width":0,"height":2},"shadowOpacity":0.2,"shadowRadius":1.2,"top":0,"left":0,"right":0}] is not usable as a native method argument

And then, i give it a height, it works,
import React from 'react'
// import { StatusBar } from 'react-native'
import {Header} from 'native-base'

// export default function EleHeader() {
//   return (
//     <Header/>
//   )
// }

export default function EleHeader() {
  return (
    <Header style={{height: 50}}/>
  )
}

should update the theme by manual.
https://github.com/GeekyAnts/NativeBase/issues/2581
https://github.com/GeekyAnts/NativeBase/commit/4c8a68b1886bfd1eca8d976d72726ffe6062bc94

should update the theme by manual.
https://github.com/GeekyAnts/NativeBase/commit/4c8a68b1886bfd1eca8d976d72726ffe6062bc94
https://github.com/GeekyAnts/NativeBase/issues/2534#issuecomment-459931809
https://github.com/GeekyAnts/NativeBase/issues/2581

This was fixed with 2.12.1

So why is this throwing this error? It was working fine in 0.57+, do we know what changed?


Add ID provider map to gen_server's state

Instead of creating and managing dedicated process for ID provider, we can manage to keep that id map into gen_server's map.

i think this will take bit of time as there are other things to build first.


Implement vagrant push scripting for demo app

Pushing back

We use travis script for deploying of the tracker binary. The demo app at the moment is not deployed. The user can run the app from Android Studio.


Add mobile landing page

Is your feature request related to a problem? Please describe.
Yes: #161
Describe the solution you'd like
If I point to the app in mobile, I should see "What is TQEC?" and "GitHub repo" buttons, not the circuit editor
Describe alternatives you've considered
Building a mobile phone-friendly version should wait until we have everything we want working in the browser.
Additional context
Specifically redirect smartphone users

Specifically redirect smartphone users, definitely not desktop, and maybe tablets

For the moment I agree with the "nobody except computer-users".
In the long run, ergonomics could be improved to also accommodate tablet users as I can see this as a real plus.

This issue is not relevant anymore. Closing it. See #323 for more details.


Password overwriting. Clang as default compiler. Lots of re-factoring. Updated Readme

Just a quick look over the code and you introduced a bug in the test vectors with strncpy. UTF-16 passwords will be at most 1 character.
 This will cause bugs in other people's code. I do not know who came up with this idea but it has no use.

Hi.
Thanks for your input. I can't really follow you on your first issue. The catena_test_vectors.c is used exclusively for generating test vectors.
I added the strncpy to allow the test vectors to work when the new password-overwrite option is enabled.  I'm unable to see how anyone would be able to supply a a UTF-16 or UTF-32 password to this part of the code without casting to uint8_t first. As the test_output function isn't announced in any header file, is see no reason to generalize it to support wchar_t.
The constant pointer->pointer conversion you are reffering to is the call from PHS to __catena, right? That's totally my fault of not considering things any further. In my defence I can assure you that even though the const is removed the pointer that was const will never be modified. Anyways I will take the full blame for this and fix it ASAP.


Date picker accessibility: Choose/Change date and closing dialog via keyboard

As a user, I want to use the datepicker via keyboard.

Choosing a date with keyboard should be possible
Choosing a date range with keyboard should be possible
Change date with keyboard should be possible
Close datepicker with keyboard should be possible

Jira Ticket:https://haiilo.atlassian.net/browse/COYOFOUR-21893

Duplicate of #310. After short investigation I can say that flatpickr library doesn't allow keyboard navigation if allowInput config is on(and in catalyst this flag is always true).


improve checkwhitespace

output line numbers
report files with invalid UTF8

helped in finding issues when checking phobos in https://github.com/D-Programming-Language/phobos/pull/3474

Auto-merge toggled on


[BUG]

Bug description
error when typing cmake --build build

Installing extension for VS code ( CMake, Git, ...  )
Compiling the initial project
Installing the libraries

It should not be about bug in your code!

What are the error messages you get in the console ?

cl : ligne de commande  error D8021: argument numérique non valide '/Wextra' [C:\Users\Axel.warin\OneDrive - ESTIA\Documents\Projet_Genie_Info\pgi-2024-the_grateful_rhinos\buil
d\freud.vcxproj]
Step to reproduce
What were you doing when the bug happened.
Info about your config

Path to your project folder : In the folder where the Readme is, open a CMD (type CMD in the path on top, type pwd)
Version of mingw/gcc  (type gcc -v in the CMD)
$Path (type echo %path% )

(Clic Preview to see the image below)

Screen shot

When I do CTRL + SHIFT +P and type cmake configure I have the following error message

Issue is that your config is using MVSC and not the MINGW compiler

Delete the build directory
Select the MIngw/gcc kit
build again.


Add coordinator Setup functions to the Path type

closes: #3999

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

Comparison is base (ec3196d) 80.10% compared to head (7e36fbb) 80.07%.
 Consider uploading reports for the commit 2fd02d0 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5397      +/-   ##
==========================================
- Coverage   80.10%   80.07%   -0.04%
==========================================
  Files         189      189
  Lines       13142    13106      -36
==========================================
- Hits        10528    10495      -33
+ Misses       2201     2199       -2
+ Partials      413      412       -1

see 3 files with indirect coverage changes

Thanks @chandiniv1, it looks like there are still some compilation errors, specifically uses of suite.coordinator.Setup (which is not defined)

Thanks @chandiniv1, it looks like there are still some compilation errors, specifically uses of suite.coordinator.Setup (which is not defined)

@chatton I have fixed the compilation errors


Building docs broken on mac

$ m . /docs/dev
...
error: Package ‘python3.8-watchdog-2.1.2’ in /nix/store/kapfg8wxbnxrd74l75j03jj3l7qv2vcw-source/pkgs/development/python-modules/watchdog/default.nix:46 is marked as broken, refusing to evaluate.

I got several errors running this command on my pc

I got several errors running this command on my pc

Can you please share the output for debugging?

It's the same error. I see you're on darwin too. I'll try to get this fixed soon. Thanks!

You're welcome, if you need something else, you can ask me.


Use singular method

Click here if you want to create rubocop's auto-correct Pull Request

See the documentation if you want to get more information about auto-correct.
Document

👍


Add the missing overwrite and verbose parameters to Transform.save

There were some parameters that write_transform has but Transform.save does not. This adds them.

Thanks @wmvanvliet


Added seperate PR for Task 2

Issue: #3
seperate PR

Hey @Paraspandey-debugs
Thanks for opening this PR 🚀. Mentor will review your pull request soon and till then, keep contributing and stay calm.
Thanks for contributing in OpenCode'24 ✨✨!

Yup, here's your 10 points for task2

for getting your 10 points for task3, make another PR referencing issue: #4


request for new option

hi, your package is really amazing. it is truly acting live real browser but when i saw in whoer.net it shows defferent timezone and language. if this funtion added in next update i thing it will be best package. thanks for creating such a nice package...

The library has been updated, please check again.

this update was amazing. but timezone was not updating using my ip address. i have writen a code to update my timezone using my ip. i thing you should add that in your nezt update as far you have done a nice work.
before:

after:

my next automation package..

this update was amazing. but timezone was not updating using my ip address. i have writen a code to update my timezone using my ip. i thing you should add that in your nezt update as far you have done a nice work. before:  after:
my next automation package..

Hello, this is a general problem caused by puppeteer. The reason it is detected is that the ip and browser timezone values do not match. Until then, you can check the values below and add the codes. Sites can read your browser language and timezone value in many values such as browser.languages and Intl.DateTimeFormat().resolvedOptions() in the header sent when requesting. You need to change this according to your ip address.

check: https://webbrowsertools.com/timezone/
Intl.DateTimeFormat().resolvedOptions()
add args: ['--lang=en-GB',  '--timezone=Europe/London']
add code:
 await Page.emulateTimezone('Europe/London');
 await Page.setExtraHTTPHeaders({
     'Accept-Language': 'en-GB,en;q=0.9,en-US;q=0.8,en;q=0.7'
 });
 await page.evaluateOnNewDocument(() => {
        Intl.DateTimeFormat.prototype.resolvedOptions = function () {
            return {
                locale: 'en-GB',
                "calendar": "london",
                "numberingSystem": "latn",
                "timeZone": "Europe/London",
                "year": "numeric",
                "month": "2-digit",
                "day": "2-digit"
            };
        };
    });
  await page.evaluateOnNewDocument(() => {
        Object.defineProperty(navigator, "language", {
            get: function () {
                return "en-GB";
            }
        });
        Object.defineProperty(navigator, "languages", {
            get: function () {
                return ["en-GB", "en"];
            }
        });
    });


ARROW-2704: [Java] Change MessageReader API to improve custom message handling for streams

Made a number of improvements to make stream processing for messages easier without having to load Arrow record and dictionary batches
Changes Made

Changed MessageReader from interface to abstract class and introduce a MessageReadHolder class to store data as messages are read. See details below.

Added static function in ArrowStreamWriter to write the EOS identifier

Moved intToBytes to MessageSerializer (where bytesToInt is), and now works with an existing byte array

Removed the abstract identifier in beginInternal and endInternal of ArrowReader so that subclasses are not forced to implement if they are not needed.

Made deserialze* functions in MessageSerializer more consistent.  In general, each can deserialze from a ReadChannel or from data directly.

MessageReader API
The changes to MessageReader are to make it easy to subclass and implement custom handling of reading messages/data.  This is done by overriding the 2 abstract methods: readMessage to do reading of the flatbuf Message, and readMessageBody to read the data.  Using the class, repeated calls to readNext will invoke the 2 methods above (only read body if a body length is set) until it returns false to indicate EOS. This encapsulates the logic of the stream format so that subclasses don't need to check if a message body needs to be read and when the EOS is reached.
readNext input is a MessageReadHolder instance which is passed to the readMessage and readMessageBody methods to store message data during the read. This can also be subclassed to add additional variables to the holder during a read. This makes it possible to propagate intermediate data from reading a message (length and buffer) through reading a complete message + body.
Usage in ArrowStreamReader
There is one implementation of MessageReader, MessageChannelReader which reads the body data into an offheap ArrowBuf. ArrowStreamReader uses this implementation to do the message reading and then handles the deserialization of batch data into vectors.
Testing
Updated existing tests for new APIs, added test for write/read of zero-length record batch and for message alignment.

These changes were pretty useful when working on https://github.com/apache/spark/pull/20725
@icexelloss @siddharthteotia please take a look if you can, thanks!

Update
I made some changes to MessageReader that will solve the issues I've been dealing with.  I'll do a better write up later, but here is the gist of the latest changes:  MessageReader is now an abstract class with a single public method readNext. This can be called repeatably and return false when no more messages in the stream. It takes in a MessageReadHolder class that will have variables populated with all data used in the reading of a message, like length, the raw buffer and Message.  There are 2 abstract methods readMessage and readBody that are invoked by readNext.
There is one concrete implementation of MessageReader that is MessageChannelReader that implements the above methods with input from a ReadChannel and loads message body data into an ArrowBuf.  This reader is used by ArrowStreamReader to read messages/data and deserialize into Schema and Record/DictionaryBatches.
When making a custom MessageReader you can extend the MessageReadHolder as needed and implement the readMessage and readMessageBody methods to populate it.

@icexelloss I'll do a more thorough writeup and probably add some tests later, but if you could take a look and let me know your thoughts on this approach, I'd appreciate it.  Thanks!
Also, since there are some API changes, maybe best to send out to the dev list to get feedback..

@BryanCutler Could you please sum up the purpose of the API change?

Thanks @elahrvivaz !  @icexelloss I'll add a summary of the API change in the description

@BryanCutler Thanks! There seems to be fair amount of API changes in the MessageSerializer class. It would be good to understand better the rational behind the API changes.

Codecov Report

Merging #2139 into master will decrease coverage by 2.39%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master    #2139     +/-   ##
=========================================
- Coverage   86.47%   84.08%   -2.4%
=========================================
  Files         244      288     +44
  Lines       41808    43749   +1941
=========================================
+ Hits        36155    36785    +630
- Misses       5653     6933   +1280
- Partials        0       31     +31

Impacted Files
Coverage Δ

cpp/src/arrow/python/helpers.cc
79.87% <0%> (-3.23%)
:arrow_down:

python/pyarrow/parquet.py
90.46% <0%> (-0.08%)
:arrow_down:

python/pyarrow/tests/test_types.py
100% <0%> (ø)
:arrow_up:

cpp/src/arrow/python/common.h
100% <0%> (ø)
:arrow_up:

python/pyarrow/tests/test_schema.py
100% <0%> (ø)
:arrow_up:

go/arrow/type_traits_numeric.gen.go
4.09% <0%> (ø)

go/arrow/math/int64_avx2_amd64.go
0% <0%> (ø)

go/arrow/type_traits_boolean.go
0% <0%> (ø)

go/arrow/array/array.go
58.97% <0%> (ø)

go/arrow/memory/buffer.go
58.53% <0%> (ø)

... and 46 more

Continue to review full report at Codecov.

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

Thanks for the review @icexelloss, I'll ping @siddharthteotia again to see if he has any input on this.

I'll leave this open for another day and merge it on Friday if no objections

Thanks @BryanCutler. Since we're so close to 0.10.0 if there are any changes required obviously it would be good to address them now

@BryanCutler Please give me a few more days to review since I am still traveling. I will try to take another look on 22nd.

Thanks for the review and suggestions @jacques-n! I don't think the flatbuffer message can be constructed from an ArrowBuf, which is why ByteBuffer is used. I'll think about the interface a bit more to see if it makes sense having a single method readNextMessage.

I refactored a little to improve on some things. @jacques-n if you could take another look when you have time, that would be much appreciated!  I still think the MessageReader class should have a separate method to read the message body so that a custom reader could handle the body data differently than reading to an ArrowBuf if needed. I tried to simplify the classes and I'll sum up the changes below.  Thanks!

Update 2
I removed the MessageHolder classes and replaced with MessageResult which is returned when a message is read so that the user does not have to create an instance on each read. If the message has a body, then the class MessageResultData will wrap the MessageResult and add an object to hold the message body data, using a type param T.
MessageReaderBase is an abstract class that includes logic to read messages and populate the MessageResult class above. Users would call public MessageResultData<T> readNext() to get an object that will indicate if there is a valid message and contains all relevant data.  Implementations only need to define a method to read the message body with the signature protected abstract T readMessageBody(MessageResult holder).
The implementation MessageReader defines protected ArrowBuf readMessageBody(MessageResult result) which is used by ArrowStreamReader, similar to before.
I think this new design makes it a little more clear what data is being used where and easier to make a custom MessageReader by just defining a type for the message body and a method to read to it.

@wesm , it looks like this needs some more discussion before it can be merged. I really wanted to get this into 0.10.0 because I plan to update Spark with this version and this would help clean up quite a few details. It's not a hard requirement though, so I don't want to delay the release. Should I remove the target version for this and if it by chance gets resolved in time, then maybe we can fit it in?

Thanks @jacques-n , iiuc I think you are looking for a pure interface definition, which is fine with me. I would still like something that I could extend which encapsulates the message stream handling details, but let me try to define an interface without mixing any particular implementation.

Here is a proposal with an interface that is free from any implementations (let me know it's preferable to have all this in a google doc to discuss).  Apologies for backtracking a little, but I put back in the MessageHolder class because my implementation ended up quite awkward otherwise. @jacques-n let me know if you still prefer not to use a holder class this way.
Interface
class MessageHolder {
  public Message message;
}

interface MessageReader<T extends MessageHolder, U extends Exception> extends AutoCloseable {

  boolean readNext(T holder) throws U;

  void close() throws U;
}

Partial Implementation using ReadChannel
This does define how to read a message body, but encapsulates stopping at the EOS and reading the body data only in the body length is > 0.

// Adds the raw message buffer to MessageHolder
class MessageChannelHolderBase extends MessageHolder {
  public int messageLength;
  public ByteBuffer messageBuffer;
}

abstract class MessageChannelReaderBase<T extends MessageChannelHolderBase> implements MessageReaderInterface<T, IOException> {
  protected ReadChannel in;

  public MessageChannelReaderBase(ReadChannel in) {
    this.in = in;
  }

  @Override
  public boolean readNext(T holder) throws IOException {
    MessageResult result = MessageSerializer.readMessage(in);

    if (!result.hasMessage()) {
      return false;
    }

    holder.message = result.getMessage();
    holder.messageBuffer = result.getMessageBuffer();
    holder.messageLength = result.getMessageLength();
    handleMessage(holder);

    return true;
  }

  @Override
  public void close() throws IOException {
    in.close();
  }

  // Hook to override handling after reading a message, default behavior is to read body
  protected void handleMessage(T holder) throws IOException {
    if (holder.message.bodyLength() > 0) {
      readMessageBody(holder);
    }
  }

  protected abstract void readMessageBody(T holder) throws IOException;
}

Implementation with ReadChannel
This reads the message body from a ReadChannel into an ArrowBuf
class MessageChannelHolder extends MessageChannelHolderBase {
  ArrowBuf bodyBuffer;
}

class MessageChannelReader extends MessageChannelReaderBase<MessageChannelHolder> {
  protected BufferAllocator allocator;

  public MessageChannelReader(ReadChannel in, BufferAllocator allocator) {
    super(in);
    this.allocator = allocator;
  }

  @Override
  protected void readMessageBody(MessageChannelHolder holder) throws IOException {
    holder.bodyBuffer = MessageSerializer.readMessageBody(in, holder.message.bodyLength(), allocator);
  }
}

Alternatives

Add ArrowBuf into MessageHolder since this is the most common case, and my implementation would just not use it.  I could eliminate the MessageChannelReaderBase then, but keeping it would be my preference.

It might not be necessary to keep messageLength and messageBuffer in the MessageChannelHolder because I think these can be accessed from the flatbuf.Message. But since they are being created in MessageSerializer.readMessage anyway, I don't think it hurts to keep them so that would be my preference.

Thanks in advance for reviewing!

Thanks @BryanCutler. Since we're so close to 0.10.0 I'm going to check in roughly daily to make sure this keeps making progress. If it seems like the work is being rushed then we should release 0.10.0 without this

@BryanCutler , can you expound on your usecase where you aren't using ArrowBuf?

To be clear, my understanding of the above is that the ByteBuffer used above would only hold a Flatbuffer, not the message body. @BryanCutler is that not the case?

I think there are two things: messages and data bodies. I consider them two parts of the a single object. I'm proposing that the interface get those back together. The message is generally small and should be treated as a pojo. The data body is larger and should be using ArrowBufs. Thus my question of in what situation ArrowBufs would be insufficient/wrong for the data body. (Let me know if I'm missing something here.)

Per my comment above, if the message happens to use a ByteBuffer, that should probably be the concern of the message object. And we can make message objects autocloseable if there is a situation where the message objects can't rely on gc.

To be clear, my understanding of the above is that the ByteBuffer used above would only hold a Flatbuffer, not the message body

Yes, MessageChannelHolder base contains the result of reading a flatbuffer Message object, not the message body.  This include the length of the message read, the ByteBuffer the message was read into, and the realized Message object.

@BryanCutler , can you expound on your usecase where you aren't using ArrowBuf?

My specific use case is that I am trying to read an Arrow stream in Spark and parallelize the record batches so that they are distributed in the Spark cluster. I have to work within the existing mechanism to parallelize, so that puts the constraint that the record batch needs to be a byte array. These byte arrays exist for the duration of the DataFrame and trying to change this to use an ArrowBuf and BufferAllocator would require significant changes. It might be possible to change this in the future, because it probably would be better to use off heap memory, but for now I need to make it work under that constraint.
So to process the stream, I need to read the flatbuf Message and inspect the Message type.  If it is a RecordBatch, then I can look at the body length and create a byte array that will fit the message+body.  If I have the raw buffer of the flatbuf Message, I can copy that over to the byte array (should be a small copy). Finally, I then read the message body into the byte array and have a complete RecordBatch message.  I need to avoid making copies of the the message body data, because that will be expensive.
Hopefully that makes sense. I think it's probably not common to read the message body this way, but I think it's likely users would read a Message (without body) to inspect it and do some action before reading the message body.

Alternative, bare-min design
This simplifies the classes and holders so that an ArrowBuf is always included. Not my preference, but at least I could override the default usage and just not use the ArrowBuf.  This removes the handleMessage hook, which isn't necessary (maybe useful?) and also assumes I can get the correct message length and ByteBuffer from the flatbuf.Message itself, which I'm not 100% sure about.
Interface
class MessageHolder {
  public Message message;
  public ArrowBuf bodyBuffer;
}

interface MessageReader<T extends MessageHolder, U extends Exception> extends AutoCloseable {

  boolean readNext(T holder) throws U;

  void close() throws U;
}

Implementation with ReadChannel
class MessageChannelReader<T extends MessageHolder> implements MessageReader<T, IOException> {
  protected ReadChannel in;
  protected BufferAllocator allocator;

  public MessageChannelReaderBase(ReadChannel in, BufferAllocator allocator) {
    this.in = in;
    this.allocator = allocator;
  }

  @Override
  public boolean readNext(T holder) throws IOException {
    holder.message = MessageSerializer.readMessage(in);

    if (message == null) {
      return false;
    }

    if (holder.message.bodyLength() > 0) {
      readMessageBody(holder);
    }

    return true;
  }

  @Override
  public void close() throws IOException {
    in.close();
  }

  protected void readMessageBody(T holder) throws IOException {
    holder.bodyBuffer = MessageSerializer.readMessageBody(in, holder.message.bodyLength(), allocator);
  }
}

@BryanCutler, I'm okay with the new interface and the new the generics for base MessageHolder. Just wanted to make sure it is was a real use case. In general, I don't think we should try to support on-heap arrow batches as it would be a massive amount of effort.

Why would MessageChannelReaderBase not be ArrowBuf based? ReadChannel basically is.

Thanks @jacques-n , I agree that we should encourage or support on-heap batches - this is probably a pretty isolated case.

Why would MessageChannelReaderBase not be ArrowBuf based? ReadChannel basically is.

Yes, but ReadChannel also reads into a ByteBuffer, which is what I can use.  Ideally, I would like to use a ReadableByteChannel in MessageChannelReaderBase, but this makes a problem since ReadChannel wraps a ReadableByteChannel instead of extending it.  So to be able to do this with MessageChannelReader I would need to add a method ReadChannel.getReadableByteChannel() to return the wrapped channel.  Does that sound ok to you?

I think we're trying to support two many different situations with these interfaces. Ideally, ReadChannel should be made more generic. Exposing the internal objects makes it less generic. Can you point at the consumer of this code you're trying to customize for? We should decide if we just have two different interfaces.

I think you're right @jacques-n , this should be kept simple and it doesn't make sense to try to support too so many things. Here is what I tried that seems to be a little better:

I got rid of MessageChannelReaderBase because you're right that ReadChannel is pretty much based on ArrowBuf and it's overkill to make an additional interface for a ReadableByteChannel.

I kept the class MessageChannelResult that is returned when reading a flatbuf Message from a ReadChannel. This wraps some of the specifics in dealing with the flatbuf Message, and I think we can probably replace with with a pojo Message, which I will create a followup JIRA to do.

With the above changes, I can implement my own MessageReader, and make use of the MessageChannelResult and other static function in MessageSerializer to make it work without dealing with the low level details.  Hopefully, this sounds ok still.

Hey @jacques-n , that's fine. I don't think we should define an interface if we are not sure it will be useful.  I only added that because I thought that's what you were requesting. The only things helpful to my use case are really just the static functions added here that hide some of the low level stream handling. I'll cut this down to only the things that are useful to me or I felt made the API's more consistent.

This PR looks generally OK to me. I am not a big fan of the MessageChannelResult (seems not ideal to have a class just to hold the deserialized bytes of a flatbuf message) and have methods return just the flatbuf message is a cleaner API. But I am not going to block this PR because of this either. Hopefully we have chance to clean this in the future if there turns out to be a better way.

Thanks @icexelloss , I agree that it could probably be improved and maybe use a pojo Message instead of exposing flatbuf in our public APIs. So do you approve this PR to be merged?

I'm going to have a look through this so I can understand a bit better some of the controversy. We have similar classes for dealing with message streams in C++

Thanks @wesm and all others who reviewed! I'll create a followup to address your comments.


Develop narrative on jump dynamics

It appears that large jumps are an important characteristic of the dynamics in this system. Both for translational and rotational motion. This is going to need some narrative, or cohesive idea to tie the results I have together.
The general result is taking the different means of the relaxation times (#27) however this has to fit into the wider discussion on breakdown of Stokes--Einstein. Comparison with Diffusion constant and rotational relaxation.

This will also be discussing the image in #28

Idea that jump dynamics are the cause of dynamic heterogeneities, rotational and translational diffusion both scale together with temp.


Tutorials recommend installing vscode extensions

BUT we should be able to do that in the devcontainer.json so that the user does not have to.
However, I'm having trouble getting pylance to install at container create time. Investigating ...

Its some kind of race condition as closing vscode after first devcontainer creation and reopening finds all the extensions installed correctly.

I think this will be fixed soon assuming this is the issue https://github.com/microsoft/vscode-remote-release/issues/8097

these reviews are no longer relevant as the framework has changed significantly.


Added order_by to list of report options.

I found out there is a bug in the v3 API for report service which throws an API error for sort_by modifier. However, using 'order_by' works in this case. sort_order works fine along with order_by, so I did not need to add anything else. I left sort_by and just added the order_by modifier to the reportService. Hope this helps someone else as well.

Thanks @chas688! I would like to see if the API team can fix it and we don't have to work around. I will merge it or not based on what I hear from them.

Yeah, It is clearly something wrong on their end, maybe you can make some headway with it in your position. Let me know. Thanks!

Absolutely @chas688! I see Leela is following up on the forum, I will let her take this up with the API team, I'll made sure we solve for it. Will close the PR.


docs: update commit message link

Description
Include a summary of the change and relevant motivation/context. List any dependencies that are required for this change.
Fixes # [ISSUE]
Flutter Channel:

[ ] I have used the Flutter Beta channel on my local machine

Type of Change:
Delete irrelevant options.

Code
Quality Assurance
User Interface
Outreach
Documentation

Code/Quality Assurance Only

Bug fix (non-breaking change which fixes an issue)
This change requires a documentation update (software upgrade on readme file)
New feature (non-breaking change which adds functionality pre-approved by mentors)

How Has This Been Tested?
Describe the tests you ran to verify your changes. Provide instructions or GIFs so we can reproduce. List any relevant details for your test.
Checklist:
Delete irrelevant options.

[ ] My PR follows the style guidelines of this project
[ ] I have performed a self-review of my own code or materials
[ ] I have commented my code or provided relevant documentation, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] Any dependent changes have been merged

Code/Quality Assurance Only

[ ] My changes generate no new warnings
[ ] My PR currently breaks something (fix or feature that would cause existing functionality to not work as expected)
[ ] Any dependent changes have been published in downstream modules

I will close! this was for demonstration @Techno-Disaster :P for the intro to open source

But this isn't this a valid PR @isabelcosta  🤔

thank you for the approval however @Techno-Disaster


step function doesn't accept closure

hello, thank you for this codebase. however, the step docstring says it should accept a closure. but it has none on the input. how can this be run?

This is what I've added, works fine:
    @torch.no_grad()
    def step(self, closure: Callable[[], float] | None = None) -> float | None:  # type: ignore
        """
        Performs a single optimization step.

        Arguments:
            closure (`Callable`, *optional*): A closure that reevaluates the model and returns the loss.
        """
        loss = None
        if closure is not None:
            with torch.enable_grad():
                loss = closure()

The doc string is wrong (it is from the adam the code we started), the code should work as it is.

oh, thank you - but HF Accelerate adds the closure, so I had to add that.

will merge that soon.


Sentry rarely captures exceptions that cause CLI commands to fail and terminate

Environment
PHP 7.4.13 (cli) (built: Nov 28 2020 06:24:43) ( NTS )
How do you use Sentry?
Sentry SaaS
Which SDK and version?
sentry/sdk                            3.1.0
sentry/sentry                         3.3.1
sentry/sentry-symfony                 4.1.4

Steps to Reproduce

Create CLI command.
Have CLI throw an uncaught exception.

Expected Result
Exception is captured by framework and submitted to Sentry.
Actual Result
Nothing. No issue created or updated because no event captured. Program just dies without ever informing anyone there was a problem.
Note that in older versions, this seemed to work quite consistently. I'm sorry I could not say which version broke this exactly, but I could swear, at one point, this behaviour was working as expected. More recent versions have all but broken this functionality.

Have you tried creating a simple command that only throws? Or one that manually captures a message without throwing? Did you try the sentry:test command?

Hmmm...
$ bin/console sentry:test
DSN correctly configured in the current client
Sending test message...
Message not sent!
<warning>Check your DSN or your before_send callback if used</warning>

If you have differences between CLI and web, you may need to check your php.ini, which may be different.
A common mistake is an outdated CA bundle.

The ini files are mostly the same, therefore I would expect the CA bundles to be the same on CLI and web. I'm more concerned that dev is different from prod than web is different from CLI, though both are a concern I suppose.
My most pressing concern is that the test tool does not expose the cause of the failure: if nothing else comes of this ticket, at the very least, I think this is something that needs to be fixed. The real reason for the failure must be present in the response from the server, but is lost through many layers of abstraction currently.

I'm really trying my best here but it's not easy. Someone decided it was a good idea to just swallow all exceptions with no notification whatsoever. If we modify the source to dump the exception, all I get is the following

GuzzleHttp\Promise\RejectionException: The promise was rejected in vendor/guzzlehttp/promises/src/Create.php on line 62

This is completely meaningless to me. "The promise was rejected" is not an HTTP error and I don't know what could cause this.

The reason for swallowing exceptions there is to avoid a loop in which a failure triggers firing another event.
We discussed before to add the possibility to use a logger there, and IIRC there's already a small possibility to inject one somewhere.

Just wanted to give you a quick update since I'm working with the enlightened @kelunik to figure out what's really going on here. There's a crazy stack of dependencies, as you may or may not be aware, where you rely on Guzzle, which relies on Symfony/HttpClient which relies on either curl or Amp, depending on the version of curl installed. Thus we can explain the divergence in behaviour between dev and prod, because my dev is using curl 7.77.0 and prod is using curl 7.58.0. When curl is less than 7.61 it uses Amp instead, but Amp has bugs which we're currently looking to resolve. I suppose you could close this since it seems to be an Amp bug right now.

Reproduction using amphp/http-client with symfony/http-client if ext-curl is not available or too old.
<?php

require __DIR__ . '/vendor/autoload.php';

Sentry\init(['dsn' =><EMAIL_ADDRESS>]);

$hub = Sentry\SentrySdk::getCurrentHub();
$client = $hub->getClient();

print $hub->captureMessage('Test message');

➜ AMP_DEBUG_HTTP2_FRAMES=1 php -dzend.assertions=1 test.php
send SETTINGS <flags = 00, stream = 0, length = 24>
recv SETTINGS <flags = 00, stream = 0, length = 18>
send SETTINGS <flags = 01, stream = 0, length = 0>
send HEADERS <flags = 04, stream = 1, length = 200>
send DATA <flags = 01, stream = 1, length = 307>
recv WINDOW_UPDATE <flags = 00, stream = 0, length = 4>
recv SETTINGS <flags = 01, stream = 0, length = 0>
recv HEADERS <flags = 04, stream = 1, length = 73>
send WINDOW_UPDATE <flags = 00, stream = 0, length = 4>
send WINDOW_UPDATE <flags = 00, stream = 1, length = 4>
recv RST_STREAM <flags = 00, stream = 1, length = 4>
send RST_STREAM <flags = 00, stream = 1, length = 4>

The server sends a RST_STREAM indicating a protocol error, not sure which condition triggers this, yet.

Something in the stack sets the te header field, which isn't supported for HTTP/2 unless it's set to trailers.
  [10]=>
  array(2) {
    [0]=>
    string(2) "te"
    [1]=>
    string(4) "gzip"
  }
  [11]=>
  array(2) {
    [0]=>
    string(2) "te"
    [1]=>
    string(7) "deflate"
  }
  [12]=>
  array(2) {
    [0]=>
    string(2) "te"
    [1]=>
    string(7) "chunked"
  }

Fixed in https://github.com/amphp/http-client/releases/tag/v4.6.1. The cause is https://github.com/php-http/client-common/blob/4751c8ffc38ea18e3c77c1b9215f719fda6bd01d/src/Plugin/DecoderPlugin.php#L62 setting the te request header field, which is invalid for HTTP/2 requests.

Fixed in https://github.com/amphp/http-client/releases/tag/v4.6.1. The cause is https://github.com/php-http/client-common/blob/4751c8ffc38ea18e3c77c1b9215f719fda6bd01d/src/Plugin/DecoderPlugin.php#L62 setting the te request header field, which is invalid for HTTP/2 requests.

Confirmed this fixes it for me.

Thank you for reporting it back! Can you report it to HTTPlug too?

@Jean85 There's not too much they can do, because they don't know whether the request will be transferred using HTTP/1.x or HTTP/2.
https://datatracker.ietf.org/doc/html/rfc7540#section-<IP_ADDRESS> suggests they should be stripped by an intermediary, so that's what amphp/http-client does now.


Installation from scratch on Mac OSX M1 doesn't work due to outdated dependencies

Currently installing via pip install apache-superset fails because the version of outdated dependencies with grpcio, numpy, pandas and pyarrow that are referenced in setup.py won't build on arm64.
How to reproduce the bug

Follow installation instructions on a Mac with a M1 processor

Expected results
The installation should succeed
Actual results
Several errors occur building dependency packages

Dont think its superset issue,numpy didn't have support for M1 last time I checked so had to use other hacks to make it work.

I'm running into the same issue, can't go down the docker installation path either due to https://github.com/apache/superset/issues/14104.
@claytongulick did you find a workaround by any chance? Or is superset simply not supported for m1 users at the moment?

Try installing in Rosetta mode, and then run in normal mode.


Adding SSL certs unsupported

I see the CloudFormation template creates a bucket to keep this stuff, however a user cannot upload their own cert files. This blocks configuring proper SSL for UCP access. Also the appropriate --san parameters needs to be passed to the various ucp commands. Given the template does ask for the UCP subdomain the template should forward the information where appropriate.

@ahawkins next version of UCP would let you add them directly in UI for now please follow this doc on ALL controllers:
https://docs.docker.com/ucp/configuration/use-externally-signed-certs/


Fix the prbolem in which Markdown parser extracts url in image  as a …

Fix #706

Coverage decreased (-0.02%) to 90.808% when pulling c46fe9585e49d85867a0dff6929529bf42e6384c on takahi-i:fix-no-label-image-md into 7b7fb951b0651d3914ac2ad751d353a1a032fba9 on redpen-cc:master.

Coverage decreased (-0.02%) to 90.808% when pulling c46fe9585e49d85867a0dff6929529bf42e6384c on takahi-i:fix-no-label-image-md into 7b7fb951b0651d3914ac2ad751d353a1a032fba9 on redpen-cc:master.