Exception in Test Generation Template Not Found: build_template.gradle

Describe the bug
I was trying the tackle test cli using the docker image and got the following exception:-
aceback (most recent call last):
File "/usr/local/bin/tkltest-unit", line 8, in
sys.exit(main())
File "/usr/local/lib/python3.8/site-packages/tkltest/tkltest_unit.py", line 67, in main
generate.process_generate_command(args, tkltest_config)
File "/usr/local/lib/python3.8/site-packages/tkltest/generate/unit/generate.py", line 50, in process_generate_command
generate_ctd_amplified_tests(config)
File "/usr/local/lib/python3.8/site-packages/tkltest/generate/unit/generate.py", line 209, in generate_ctd_amplified_tests
ant_build_file, maven_build_file, gradle_build_file = build_util.generate_build_xml(
File "/usr/local/lib/python3.8/site-packages/tkltest/util/build_util.py", line 130, in generate_build_xml
__build_gradle(app_classpath, app_name, monolith_app_path, test_root_dir, test_dirs, collect_codecoverage,
File "/usr/local/lib/python3.8/site-packages/tkltest/util/build_util.py", line 470, in __build_gradle
template = env.get_template('build_template.gradle')
File "/usr/local/lib/python3.8/site-packages/jinja2/environment.py", line 997, in get_template
return self._load_template(name, globals)
File "/usr/local/lib/python3.8/site-packages/jinja2/environment.py", line 958, in _load_template
template = self.loader.load(self, name, self.make_globals(globals))
File "/usr/local/lib/python3.8/site-packages/jinja2/loaders.py", line 125, in load
source, filename, uptodate = self.get_source(environment, name)
File "/usr/local/lib/python3.8/site-packages/jinja2/loaders.py", line 214, in get_source
raise TemplateNotFound(template)
jinja2.exceptions.TemplateNotFound: build_template.gradle
Environment information

CLI version v1.3.0
OS: macOS [ running using Docker ]

@jayantgs we are unable to reproduce this issue. When you have time can you try again the docker installation and let us know if the issue repeats?


Impersonation ServiceAccount should use HelmRelease namespace instead of targetNamespace

@hiddeco
We found out that serviceAccount impersonation is not using the hr.Namespace anymore but the hr.targetNamespace
Example:
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: echoserver
  namespace: a-ns
spec:
  releaseName: echoserver
  serviceAccountName: flux-reconciler
  targetNamespace: other-ns
status:
  conditions:
  - lastTransitionTime: "2022-06-21T18:28:06Z"
    message: failed to get last release revision
    reason: GetLastReleaseFailed
    status: "False"
    type: Ready

  Warning  error            8m22s (x11 over 21m)  helm-controller  reconciliation failed: failed to get last release revision: query: failed to query with labels: secrets is forbidden: User "system:serviceaccount:other-ns:flux-reconciler" cannot list resource "secrets" in API group "" in the namespace "a-ns"

Actual: system:serviceaccount:other-ns:flux-reconciler
Expected: system:serviceaccount:a-ns:flux-reconciler
Found this change which is probably changing how serviceAccount impersonation works in the helm-controller:
https://github.com/fluxcd/helm-controller/commit/d19b4704126eec9b9da18d1b8d115191c72ae737

Closing. Confirmed that this is fixed in the latest helm-controller release ghcr.io/fluxcd/helm-controller:v0.22.1


Misdirected span in 'recommendation not met' error message

The span at line 32 isn't a recommends clause, so I don't know what to do with this message. Recording attached.
2023-07-18-13-40-24.zip
warning: recommendation not met
  --> src/journal/PagedJournalRefinement_v.rs:32:15
   |
32 |             { Self::i_opt(*self.prior_rec, boundary_lsn).concat(self.message_seq) }
   |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
37 |         ojr.is_Some() ==> ojr.unwrap().valid(boundary_lsn),
   |         -------------------------------------------------- recommendation not met

I am dumb and read the error message backwards.

There's actually a UI issue hiding in here. The order of (offending line, recommendation violated) depends on where they appear in the file. That makes reading these messages confusing, because the subject/object order flips around.

I agree, that's confusing. I'm not sure what to do about it though, since we're relying on Rust's output mechanism ...

As this is an error message issue, closing in favor of https://github.com/verus-lang/verus/discussions/387#discussioncomment-6540541


crypto/x509/pkix: pkix.Name.FillFromRDNSequence ignores attributes other than the first

pkix.Name.FillFromRDNSequence ignores attributes other than the first in the RDN sets passed as argument. As demonstrated by http://play.golang.org/p/GPZdVHzZVb, this in turn makes x509.ParseCertificate(s) fail to locate the subject serial number for certificates where it is included in  set containing the common name.
The fix is simple, also demonstrated by the playground program, but I'm unsure if the example certificate is broken and that multiple attributes in one RDN set should be ignored. And even if so, a workaround might still be desirable: The example certificate is issued by the national Danish ID provider, "NemID" mandatory for digital banking and digital public services.
I raised the issue on golang-nuts:
https://groups.google.com/forum/#!topic/golang-nuts/1Whb4ko4zfc
but so far I've received no replies and so this issue serves as a reminder.

CC @agl

The spec for this is section 9.3 of X.501, but if you can figure out anything from that then you're a smarter man than I.
I'm guessing that it's supposed to express the fact that either the CN or "PID" value is sufficient to identify the object, but why that's information that needs to be reflected in the structure I've no idea.
The Go code tries to hammer that into a simpler model that accounts for 95% of cases: each common identifier OID is allowed a single value. I think that trying to reflect the full complexity of X.501 in Go would be a mistake so hacks to handle cases like this are done based on sufficient real-world need.

I ran into what I believe is this same problem when attempting to parse certificates generated by PKI.js, which packs multiple attributes into a single ASN.1 SET. I raised it as an issue over there and was told by the author of that library that the problem is on the Go side. I can confirm that PKI.js's certificates do parse properly by OpenSSL, in that all attributes in a set are read.
I believe (at least for my situation) the fix would not require relaxing the constraint that each common identifier OID is allowed a single value. Rather, instead of FillFromRDNSequence reading only rdn[0], have an inner loop across all values of rdn that does exactly what the single pass does now. You wouldn't have to worry about collisions of multiple values for the same OID any more than you do now, and we would gain the ability to properly parse SETs that contain more than one distinct attribute.

I recently ran into the lack of multi-valued RDN support in GO too.
@agl, As @rapropos noted, it's not the same OID that is being mapped to multiple values.  Rather, a single RDN can have more than one AttributeTypeAndValue.  From RFC 5280, the RDN is defined to be a set with a size from 1 to MAX:
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue
GO is currently assuming MAX is always = 1, which is not a correct assumption:
https://golang.org/src/crypto/x509/pkix/pkix.go?h=FillFromRDNSequence#L67
The canonical example for multi-valued RDNs is where CN is a person's name, say "Alice Smith," where there can be lots of duplicates.  To disambiguate, organizations usually then also use unique identifier, like UID.  This is rather common in LDAP and other user directories.  It sounds like the example from @eliasnaur is along those lines, but using serial number instead of UID.
As noted, OpenSSL (and others, like Bouncy Castle) support both the generation and parsing of certificates with multi-valued RDNs (just search for "multivalue-rdn"):
https://www.openssl.org/docs/manmaster/apps/req.html
Being a set, the order of the AttributeTypeAndValue is not defined, so arbitrarily picking the first one can lead to different results depending on how the certificate gets generated.
Ideally, GO would parse the DN completely or at least indicate that there is one or more multi-valued RDNs so the caller knows to parse the Issuer / Subject manually if interested in all the values.  Right now, calling code cannot rely on the results if it's possible for there to be multi-valued RDNs.  And if you're writing code that will run in environments that you do not control, running into this seems like an inevitability.
Unfortunately, looking at the existing structure of pkix.Name, I do not see an obvious way to account for multi-valued RDNs that preserves compatibility.  It seems like either new fields and/or new methods must be added or perhaps a new pkix.Name type entirely.
I understand that X509 is a beast, and that GO is still relatively young, and that there are lots of competing priorities for precious resources, but cherry-picking which parts of the X509 standard get implemented and which do not makes it more difficult and error-prone to migrate to GO from other languages / technologies that provide greater coverage.  Hopefully, GO can still go further in this regard.

It sounds like maybe if someone can propose a concrete addition (actual code), then @agl can evaluate it. But it's a bit late for Go 1.8.

I think this is fixed by 809a1de1ac, but I had it linked with a different bug (#16836).

@agl Reiterating my comment just added to the changeset https://github.com/golang/go/commit/809a1de1ac1ccc76f7a4faf630017626f2f68231 to widen visibility: While this code successfully parses a multi-value RDN, it strips the set grouping. That is, ToRDNSequence after parsing such a certificate will not result in a multi-value RDN.
As noted previously, without a breaking change to pkix.Name or the introduction of new fields/methods, I do not see a way to preserve the multi-value nature of the RDN.
While multi-valued RDNs may not be common, they are clearly part of the RDN standard in RFC 5280, not erroneous certificate constructions like Bug #16836 seems to suggest.
If you decide to keep the parsing logic, I would at least add a note documenting the loss of information about the multi-value nature of an RDN.

@ramoas I just noticed this comment; is there an open issue about this? Should this issue be reopened? Otherwise your comment will be lost.

@joneskoo, Sorry about the response delay.  I never opened a separate issue for my comment, but it  remains relevant.  I had placed my comment in multiple places at the time: this issue, the GH changeset (https://github.com/golang/go/commit/809a1de1ac1ccc76f7a4faf630017626f2f68231), and the original Gerrit CR (https://go-review.googlesource.com/c/go/+/30810#message-a29d12cfb3550dc2ce212ec60ddf32bf86363f13).  I assumed that my comment was simply dismissed given that you were the only one to ever acknowledge its existence anywhere.  The current GO implementation does not preserve the original structure of a certificate with multi-value RDNs; I still think that's worth fixing or at least documenting at a minimum, but no one else seems to think so.

Hi Omar,
Does the implementation normally preserve the structure in other cases, is
that something someone would rely on?
As it sounds like a distinct problem, please open a new issue and collect
the details to that single thread, so it’s easier to follow. At least then
it’s not lost. If it can be reproduced and the problem is clear, at least
it won’t be forgotten.
I’m sorry I didn’t read the nasty details re: ASN.1 structures, so I can’t
comment what is normal. I won’t be able to help.

@joneskoo , Yes, generally, structure is preserved.  I created #23069 with a clear reproduction.


Using dynamic=True in a keras Metric constructor should run the metric methods in eager mode

Please make sure that this is a feature request. As per our GitHub Policy, we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:feature_template
System information

TensorFlow version (you are using): 2.2.0rc4
Are you willing to contribute it (Yes/No): No

Describe the feature and the current behavior/state.
Currently, when using dynamic=True in a Metric constructor, it has no effect. All the methods are run in graph mode. Since this feature is already present in keras Layers, and that a Metric is a subclass of Layer, one would expect a metric to run in eager mode if dynamic=True is provided.
Will this change the current api? How?
No change to the API. dynamic=True is already accepted in a Metric constructor. The change would be in behavior only. The flag should trigger the eager mode. Currently it doesn't do anything.
Who will benefit with this feature?
Users who want to make custom metrics which need eager mode and want to distribute them.
Any Other info.
Here is a minimal notebook reproducing the problem. With this feature implemented, the error should not happen:
https://colab.research.google.com/drive/11EuSPoyedceHySz_uxxqjZJbU2uatpfk

Intuitively it might be easiest to just pass dynamic arg to constructor. Assuming that the Metric class inherits all relevant infrastructure from the Layer class. But looking at the Layer class code it seems that approach wouldn't work.
https://github.com/tensorflow/tensorflow/blob/2b96f3662bd776e277f86997659e61046b56c315/tensorflow/python/keras/engine/base_layer.py#L357-L360
Looking at the other metrics that inherit from Metric, it seems they use metrics_utils to handle to handle the heavy lifting.
For example in the case of the Recall class:
https://github.com/tensorflow/tensorflow/blob/2b96f3662bd776e277f86997659e61046b56c315/tensorflow/python/keras/metrics.py#L1382-L1392
So that could be the path forward.

@gabrieldemarmiesse This feature not yet implemented. Is there any actionable item like raising PR?
Please note that Keras development moved to another repository to focus entirely on only keras. Could you please repost this issue on keras-team/keras repo. Thanks!

I supposed the path forward would be to make a pull request. It's been quite a while since I last worked with deep learning so I'll let users who are interested implement it.

I opened this issue in keras-team/keras. Let's track the progress there https://github.com/keras-team/keras/issues/15758


Attach tokens to outgoing requests using other header

Is there a way to attach tokens to outgoing requests using a header other than "Authorization"?
I am deploying my Blazor app to Azure Static Web Apps and calling the Azure Functions within my solution.  The issue is, Static Web Apps overrides the Authorization header in these requests with their own.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 53f3209c-2414-9b35-6245-383c9b7c6338
Version Independent ID: cc8dfcd6-8d93-5aa3-c381-2b613e88cdbe
Content: ASP.NET Core Blazor WebAssembly additional security scenarios
Content Source: aspnetcore/blazor/security/webassembly/additional-scenarios.md
Product: aspnet-core
Technology: aspnetcore-blazor
GitHub Login: @guardrex
Microsoft Alias: riande

Hello @connor-ww ... They've marked the behavior as a 🐞 bug for resolution, and there's even an issue asking specifically about Blazor ...

https://github.com/Azure/static-web-apps/issues/34
https://github.com/Azure/static-web-apps/issues/275

It looks like one of the devs there has a workaround using a X-Custom-Authorization header instead. I don't personally have experience with the scenario, so I think you should ask that dev on the issue for additional info. Perhaps, they'd be willing to share an example project in a GH repo.
I don't think this will be actionable for us since they intend to fix it.
cc: @javiercn ... in case he has anything that he wants to add.

Hello @connor-ww ... They've marked the behavior as a 🐞 bug for resolution, and there's even an issue asking specifically about Blazor ...

https://github.com/Azure/static-web-apps/issues/34
https://github.com/Azure/static-web-apps/issues/275

It looks like one of the devs there has a workaround using a X-Custom-Authorization header instead. I don't personally have experience with the scenario, so I think you should ask that dev on the issue for additional info. Perhaps, they'd be willing to share an example project in a GH repo.
I don't think this will be actionable for us since they intend to fix it.
cc: @javiercn ... in case he has anything that he wants to add.

AFAICT since we won't address in a doc a 🐞 that they'll resolve for the service, we should close. If more readers remark on this in the meantime, then we might add a temporary NOTE. Let's see how it goes. Hopefully, they'll fix the service soon 🤞.

AFAICT since we won't address in a doc a 🐞 that they'll resolve for the service, we should close. If more readers remark on this in the meantime, then we might add a temporary NOTE. Let's see how it goes. Hopefully, they'll fix the service soon 🤞.

Thanks for your replies!  Yes, hopefully the header conflict is resolved by the Static Web Apps team.
In the meantime I've implemented a CustomAuthorizationMessageHandler such that it inherits from DeligatingHandler and implements setting authorized URLs and scopes (as mentioned in the doc) as well as adding the auth token to a custom header.

Thanks for your replies!  Yes, hopefully the header conflict is resolved by the Static Web Apps team.
In the meantime I've implemented a CustomAuthorizationMessageHandler such that it inherits from DeligatingHandler and implements setting authorized URLs and scopes (as mentioned in the doc) as well as adding the auth token to a custom header.


Environment

PATH=$PATH:/lib/native/linux:/lib/native/linux64
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/lib/native/linux64
What is the meaning of  in the above path?.. What should I write over there?

It should be: (Note that we have <release>.)
PATH=$PATH:<release>/lib/native/linux:<release>/lib/native/linux64
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<release>/lib/native/linux64

<release> is a path to k-distribution/target/release/k in your source tree.


Proposal for supporting PHP 8.2+ Disjunctive Normal Form Types in the Tokenizer

The problem
PHP 8.2 introduced Disjunctive Normal Form Types, which now adds parentheses to the tokens allowed within type declarations.
This is currently not yet supported by PHP_CodeSniffer and the PHP_CodeSniffer\Tokenizers\PHP class will not always handle tokens within DNF types correctly, which can lead to false positives/false negatives being reported for sniffs and incorrect fixes being made.
Typical issues in the Tokenizer:

The array keyword when used in a type declaration may not be retokenized from T_ARRAY to T_STRING.
The true/false/null keywords when used in a type declaration may not be retokenized from T_STRING to T_TRUE/T_FALSE/T_NULL.
The & and | characters may not be retokenized to T_TYPE_UNION/T_TYPE_INTERSECTION.

Typical resulting sniff issues:

Sniffs handling arbitrary parentheses spacing may act on parentheses in DNF types.
Sniffs listening for the array keyword may try to act on the array keyword when used in a DNF type.
Sniffs listening for bitwise and/or operators may act on the & and | characters in DNF types.
etc

These issues also impact the functioning of the following PHPCS native helper functions and by extension all sniffs which use these methods:

File::getMethodParameters() (parameter types)
File::getMethodProperties() (return types)
File::getMemberProperties() (property types)
File::isReference()

Compounding the Problem
Aside from the above, standards may want to treat (spacing around) parentheses in DNF types differently from (spacing around) parentheses used in other places in a code base.
Proposed Solution
To support DNF types the PHP_CodeSniffer\Tokenizers\PHP class will need significant updates.
When making these updates, I propose to include a change to retokenize the open and close parentheses when used in DNF types as T_TYPE_OPEN_PARENTHESIS and T_TYPE_CLOSE_PARENTHESIS respectively.
Having separate, PHPCS native tokens for the DNF parentheses will allow for sniff developers to decide on a case-by-case basis whether a sniff should or should not act on DNF parentheses.
This change also follows in the footsteps of the retokenization of the & and | tokens  (when used in types) to T_TYPE_* tokens.
As part of this change, the new T_TYPE_OPEN_PARENTHESIS and T_TYPE_CLOSE_PARENTHESIS tokens will need to be handled correctly by the PHP_CodeSniffer\Tokenizers\Tokenizer class and tokens should get the parenthesis_opener, parenthesis_closer and nested_parenthesis tokens, same as if the tokens were the "normal" T_OPEN_PARENTHESIS and T_CLOSE_PARENTHESIS tokens.
Open question
As PHP 8.2 has been out for a while, some external standards may have implemented work-arounds for the current state of things.
So, aside from opinions on the above proposal itself, I would also like to hear opinions on when this change should be made.

Should this change go into the next PHPCS 3.x minor (once the PR has been prepared) ?
Or should this change go into PHPCS 4.0 ? (expected in 3-4 months)

/cc @asispts @dingo-d @fredden @GaryJones @greg0ire @kukulich @michalbundyra @Ocramius @sirbrillig @stronk7 @weierophinney @wimg
Related issues

squizlabs/PHP_CodeSniffer#3667
#105
squizlabs/PHP_CodeSniffer#3731

Should this change go into the next PHPCS 3.x minor (once the PR has been prepared) ?

Could the old class be deprecated/left in place, while usages migrate to a new class that contains these adjustments?

Should this change go into the next PHPCS 3.x minor (once the PR has been prepared) ?

Could the old class be deprecated/left in place?

Not really. It's a monster-class without any modularity.

usages migrate to a new class that contains these adjustments?

This is exactly why I would like opinions on the timeline. PHPCS 4.0 will contain various other tokenizer changes to, so would allow for more gradual migration.

I'm always happy with more new tokens because my sniffs could be more simple :)

Should this change go into the next PHPCS 3.x minor (once the PR has been prepared) ?
Or should this change go into PHPCS 4.0 ? (expected in 3-4 months)

DNF don't work currently so I think it could go to PHPCS 3.x. However I think you should choose what is more easy for you. DNF support can wait another 3-4 months if it will make your work on PHPCS easier :)

Thanks for the complete report, easy to digest!
I like the new T_TYPE_* approach. And I think that it will make things easy for people to move on them (exisiting Sniffs).
About the target release, applying the safety-principle, I'd say 4.0, because of the potential breaking impact on already existing Sniffs out there (not sure if there is any reliable way to try to look for existing cases).
In our case (Moodle), we still have PHP 8.1 as min requirement in our current dev version, so we are DNFT-free for now.
Side-note, only partially related: One thing that always make me think about all these Tokenizer issues/changes... is how others out there (maybe using other type of - AST, ... - parsers) are impacted by PHP changes (more or less than us). Just saying, I don't know/feel that there is any easy route to provide any tokenizer <==> parser conversion easily.
Ciao :-)

I think that the proposed new tokens sound like a good approach since they have a distinct meaning.
As for timing, I agree with the above that since it's currently effectively broken, a minor version should be fine. This is at least a bug fix and at most a new feature.
That said, I can imagine that it could be considered breaking if someone hacked around these tokens already. But if they did I would hope that they posted an issue on this repo since it seems to me to be missing support? And if it does break a sniff, the fix is easy enough by pinning the previous minor version.
You have your finger on the pulse of sniff development, though, so if you think it likely that folks would be badly impacted by this change and there's no way to let them know ahead of time, then a major version is also fine. We've been behind PHP versions for quite a while now and another instance is not going to be the end of the world.

@kukulich @stronk7 @sirbrillig Thank you for your input so far.
Personally, I'm not aware of standards which have work-arounds in place (which is part of the reason for opening this issue: to try and find out).
Timing-wise, if nobody speaks up about having put work-arounds in place, I think adding this to the next minor (once the patch is available) would be best as it takes pressure off PHPCS 4.0, for which quite some work still needs to be done, and would allow for the support to reach end-users sooner, especially as it is likely to take a while before external standards will support PHPCS 4.0.

We've been behind PHP versions for quite a while now and another instance is not going to be the end of the world.

Well, I've been trying to play catch up with the PHPCS 3.8.0 and 3.9.0 releases. Syntax-support wise, this is the last "big" one we're still missing as far as I'm concerned.

I was going to say PHPCS 4.0, but if you're not aware of any current workarounds, then it makes sense to bring this forward to 3.x.

As nobody has spoken up about having work-arounds in place already, I intend to start work on this over the next few days and hope to include DNF support in the 3.10.0 release.

I've just pulled the first PR in a series of 6 PR related to this. See #461
This first PR adds the tokenizer support for DNF types as outlined above.
Once that PR has been merged, I have three PRs lined up to add support for DNF types to the File::getMethodParameters() method, the File::getMethodProperties() method and the File::getMemberVariables() method.
One small PR to add some related tests for the File::isReference() method.
And then finally a PR to handle DNF types in the Generic/PHP.LowerCaseType sniff, which is the only PHPCS native sniff which needs changes to support DNF (from what I can see. What with the new tokens, false positives in all other sniffs should automatically be fixed via the tokenizer PR).
I'd like to invite everyone to put the PR through the wringer and test it thoroughly to confirm I've caught all the edge cases and/or to find those edge cases I've still missed.
Leaving a comment saying you've tested the PR with your sniffs is appreciated as it will strengthen confidence in the implementation.

FYI: I've merged the PR with the Tokenizer changes to improve the chances of people using the master branch testing this change in hopes of any undesired side-effects being caught before the next release.
I've also pulled the changes to the File methods now (PR #471, #472, #473) and will merge those in a couple of days (providing no bugs are discovered in the PRs).

FYI: I've merged the above mentioned PRs updating the File methods to increase the surface for testing the implementation of DNF support in PHPCS via external standards.
I've also now pulled PR #478 which updates the one sniff which needed updating (AFAICS).

Just checking in to see if anyone has been testing the implementation with their external standard and if there is any feedback. If not, I intend to release PHPCS 3.10.0 later this week with this change included.


Add Builder methods "orWhereYear" and "orWhereMonth" for convenience

Laravel Version: 5.3.28
PHP Version: 7.0.13
Database Driver & Version: MariaDB - 10.1.19

Description:
It would be helpful to have methods like orWhereYear and orWhereMonth for convenience.

For suggestions and feature requests please use the https://github.com/laravel/internals repo.


[BUG] heredoc end with quotes should not expect a heredoc end with the quotes (cat << "eof")

Bash:
bash-5.1$ cat << "eof"
> eof
bash-5.1$

🌊rash$:
🌊rash$ cat << "eof"
> eof
> "eof"
🌊rash$

eof"" should work the same way.

Was fixed in #150


Beautifying CSS rules will have a newline added to the beginning of each rule, and I can't turn it off.

Description
The results of beautification are not what I expect.
There is a newline added before the beginning of the style rules. It should be added at the end of the style rules.
newline_between_rules flag has already been set to false, yet it still inserts newlines before the beginning of each style rules.
Duplicate issue:
https://github.com/Glavin001/atom-beautify/issues/709
It's opened, but it was a question, and not a bug report.
Input Before Beautification
This is what the code looked like before:

    <style>
      /*This is a body.*/
      body {
        -webkit-text-size-adjust: 100%;
      }

      /*This is a table.*/
      table[align="center"] {
        margin: 0 auto;
      }

      /*Test*/
      .THIS_IS_A_CLASS {
        blah: yes;
      }
    </style>

Expected Output
The beautified code should have looked like this:

    <style>
      /*This is a body.*/
      body {
        -webkit-text-size-adjust: 100%;
      }

      /*This is a table.*/
      table[align="center"] {
        margin: 0 auto;
      }

      /*Test*/
      .THIS_IS_A_CLASS {
        blah: yes;
      }
    </style>

Actual Output
The beautified code actually looked like this:

    <style>
      /*This is a body.*/

      body {
        -webkit-text-size-adjust: 100%;
      }
      /*This is a table.*/

      table[align="center"] {
        margin: 0 auto;
      }
      /*Test*/

      .THIS_IS_A_CLASS {
        blah: yes;
      }
    </style>

Steps to Reproduce

Add code to Atom editor
Run command Atom Beautify: Beautify Editor
This beautified code does not look right!

Debug
Here is a link to the debug.md Gist:
debug.md debug.md
Checklist
I have:

[v] Tried uninstalling and reinstalling Atom Beautify to ensure it installed properly
[v] Reloaded (or restarted) Atom to ensure it is not a caching issue
[v] Searched through existing Atom Beautify Issues at https://github.com/Glavin001/atom-beautify/issues so I know there is a duplicate issue, but no results were determined.
[v] Filled out the Input, Expected, and Actual sections above or have edited/removed them in a way that fully describes the issue.
[v] Generated debugging information and added link for debug.md Gist to this issue.

Full code:
<html>

  <body>
    <style>
      /*This is a body.*/
      body {
        -webkit-text-size-adjust: 100%;
      }

      /*This is a table.*/
      table[align="center"] {
        margin: 0 auto;
      }

      /*Test*/
      .THIS_IS_A_CLASS {
        blah: yes;
      }
    </style>
  </body>

</html>

debug.md: https://gist.github.com/anonymous/0ea0f9db48d5c036ca6aae76fd83eb14
Original File Language: CoffeeScript

It appears your debug.md is actually for a CoffeeScript file and this issue is about CSS. Please replace your debug.md with the correct one demonstrating your issue.

Sorry, this is the actual debug.md
debug.md

Hello, after numerous testing, disabling "Preserve New Lines" option doesn't seem to be helping.

I attempted to beautify the code sample in the debug.md file on http://jsbeautifier.org/ with Remove all extra newlines toggled but no luck.
Including @bitwiseman

@prettydiff - That setting on the website is not sufficient to test this.  The website does not expose the setting they are talking about.  Please try from the command-line with the desired settings.

Thanks Liam!

@tommai78101 Guidance to further test or resolve this problem was provided by bitwiseman with no further updates.  I am closing this issue as resolved.  If I am in error please reopen the issue.


Developer commands should be disabled when developer mode is off

Verification

[X] This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

Provide a detailed description of the proposed feature
When a developer mode command is issued and developer mode is off (the default), current behavior is to display the developer mode warning once and then enable developer mode.
Brew should not automatically assume the user wants to enable developer mode and tap homebrew-core or homebrew-cask.
Proposed behavior would require developer mode to be explicitly enabled by setting HOMEBREW_DEVELOPER or running 'brew developer on'.  When developer mode is off and a developer mode command is issued brew should simply display the developer mode warning and terminate.
What is the motivation for the feature?
Since installation from API was introduced, I've untapped homebrew-core and homebrew-cask since they're no longer necessary.
Although I have contributed to brew in the past, I do not actively develop brew formula.  However, I frequently will use commands like 'brew cat' to look into formula for dependencies, etc.  There are now alternatives like 'brew info --github' but muscle memory persists.
The current behavior of automatically enabling developer mode has become quite obnoxious as it results in automatically setting 'brew developer on' and re-tapping homebrew-core or homebrew-cask, requiring me to reset 'brew developer off' every time.
How will the feature be relevant to at least 90% of Homebrew users?
Developer mode is not relevant for most users simply looking to install a package.
It is counterintuitive to automatically enable this mode since it can have adverse effects on the user's installation.
Because the developer mode warning is only issued once and developer mode uses HEAD most users will not realize the implications resulting in a different and potentially less-stable experience.
In addition, homebrew-core and/or homebrew-cask will no longer be automatically tapped resulting in a large unexpected download.
What alternatives to the feature have been considered?
I looked for a variable to disable the automatic enabling of developer mode (such as "HOMEBREW_DEVELOPER=disabled" or "HOMEBREW_DISABLE_DEVELOPER_MODE=1" but such configuration is not supported.

It seems like the real problem here is that certain commands automatically tap the core and cask repos when you use them even if you're only using the API. I just checked and all of the commands we enable HOMEBREW_NO_INSTALL_FROM_API for are developer commands.
https://github.com/Homebrew/brew/blob/ed793811553eb6fca3dd602931e37b7187f86a68/Library/Homebrew/brew.sh#L785-L808
Maybe it would be enough to just make those commands require HOMEBREW_NO_INSTALL_FROM_API again and not set it automatically.
Also, for the brew cat use case maybe we should add a nudge to use the brew info command instead.

That solution would work for me.

Because the developer mode warning is only issued once and developer mode uses HEAD most users will not realize the implications resulting in a different and potentially less-stable experience.

     Aside:  Users who've entered developer mode can still make Homebrew update only to a tagged release and not to the latest commit from 'master' by setting the environment variable 'HOMEBREW_UPDATE_TO_TAG.'

Brew should not automatically assume the user wants to enable developer mode and tap homebrew-core or homebrew-cask.
Proposed behavior would require developer mode to be explicitly enabled by setting HOMEBREW_DEVELOPER or running 'brew developer on'. When developer mode is off and a developer mode command is issued brew should simply display the developer mode warning and terminate.

This would be a breaking change for brew's CLI behaviour, so it's unlikely we can do this without a protracted transition period (because it would break many users), if we even do it at all.
One thing that might be simple to do is to provide a HOMEBREW_DISABLE_DEVELOPER_COMMANDS that will make brew exit with an error if a dev command is run.

One thing that might be simple to do is to provide a HOMEBREW_DISABLE_DEVELOPER_COMMANDS that will make brew exit with an error if a dev command is run.

Let's not provide more options based on a single request.

Brew should not automatically assume the user wants to enable developer mode

I disagree with this.

and tap homebrew-core or homebrew-cask.

I agree with this. I see this auto-tapping as being very annoying. Will open a PR.


Activity 1: Your First Caption

Using the API, I have just created a file with a random octocat for you to caption. In this activity, we will learn how to make changes to files in our GitHub repository.

[x] @allthedoll
[x] @caanders1412
[x] @vudu13
[x] @zafarian

All changes have shipped. 🚢 :shipit:


Double decryption in Sprint Boot 2.4

I have custom EncryptablePropertyFilter that will match only to properties ending with '.encrypted' and custom EncryptablePropertyDetector with isEncrypted method returning always true (I dont want to deduce based on value + I want to enforce that every .encrypted will go through decryption).
The problem is that it works fine on SB 2.1, 2.2, 2.3, but it breaks on 2.4. It turns out that on 2.4 it performs the decoding twice, which breaks app.
It appear that they changed the chain of loading properties.
On 2.4

vs on 2.3

on 2.3 it goes to CachingDelegateEncryptablePropertySource -> which delegates to ResourcePropertySource
on 2.4 it goes to EncryptablePropertySourceMethodInterceptor -> which delegates to CachingDelegateEncryptablePropertySource-> which delegates to ConfigurationPropertySourcesPropertySource -> CachingDelegateEncryptablePropertySource. With this multiple steps, it gets decoded twice.
Any advice how to handle that ?
The easiest will be probably to change EncryptablePropertyFilter/Detector, but that sth that I was trying to avoid.
Edit:
Im digging deaper: org.springframework.test.context.support.AbstractContextLoader has now 7 instead of 6 ContextCustomizers, additional one is org.springframework.boot.test.autoconfigure.actuate.metrics.MetricsExportContextCustomizerFactory
which invokes https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/context/properties/source/ConfigurationPropertySources.java#L80
that will contain chained delegates. Those delegates will be further replaced with encyrptable versions and they will perform double decruption. Still dont know how to fix it.

3.0.4 released


Suomi view:  Input field title text in 'Add API' form are untranslated

Steps

Visit https://staging.apinf.io (version 0.38.0)
Change language by clicking on 'Suomi'
Sign up
Click on 'Add API'

Findings
Suomi view: Input field titles text in 'Add API' form are in English language
Screenshot

First step: Check that the texts are included in i18n file

@bajiat , verified this resolved issue on https://nightly.apinf.io v 0.40.0 and it is not reproducible.


LWRP names incorrect when using provides

LWRP names seem to be generated automatically using <coobkook_name>_<resource_name> which is correct for definitions, but not necessarily for LWRPs. According to the chef docs a "provides" can be defined, which specifies the LWRPs name (https://docs.chef.io/lwrp_custom_resource.html#provides).

@joerg can you test with 2.0, and let me know

Hi,
Glad to see that this project is being revived, but since it was dead so long I chose to work on my own project https://github.com/chefdoc which supports a more modern, cookbook centric, approach to this and it also has its own service at https://www.chefdoc.info/ modelled after rubydoc.info.
Anyways, you can close this issue if you think it is resolved.

@joerg awesome good to hear man. It looks nice


Optimize disk space usage in CI by pruning all unused Docker images

Update Docker image pruning command to remove all unused Docker images, not just the dangling ones to optimize the disk space utilization.

/skip-all


The readme still contains Keras, which is no longer supported

The Problem
I am glad, I came to this repository finding for the Keras → PMML exporter. But the new version seems not to be supporting the Keras2pmml. But the mention of Keras is still there (yes in the current version).
I tried to go back to multiple versions and finally found that Nyoka has stopped supporting Keras export since version 5.0.0. Hence the last supporting version is 4.4.0.
The solution
So, to make better usability, you should mention in the current readme that "We have stopped Keras support & to use that please consider downloading the 4.4.0 release" .
There, again we will need to face the dependencies of Keras x TF x Nyoka. Thus, I have found the following configurations for anyone who is looking for keras2pmml and came here.
More
Keras: 2.2.4
TF: 1.13.1
Nyoka: 4.4.0
Consider it installing on Google Colab or something, because the older versions of Keras and TF don't support new python. They expect python 3.6, 3.7 etc. So... try accordingly.

Hello @AayushSameerShah,
Thank you for your valuable time and mentioning about it.
The readme file is updated in the following comit: https://github.com/SoftwareAG/nyoka/commit/0214a0b44db2c107380e256d998ec1aac75d8704


Context-menu do not open with angular 5.x

Hi @isaacplmann, I recently updated my project to Angular 5.x. On inspect I see the context-menu under cdk-overlay-container, but it's not rendered on the screen.
Below is the list of dependencies:
"@angular/animations": "^5.2.0",     "@angular/cdk": "^5.1.0",     "@angular/common": "^5.2.0",     "@angular/compiler": "^5.2.0",     "@angular/core": "^5.2.0",     "@angular/forms": "^5.2.0",     "@angular/http": "^5.2.0",     "@angular/platform-browser": "^5.2.0",     "@angular/platform-browser-dynamic": "^5.2.0",     "@angular/router": "^5.2.0",     "classlist.js": "^1.1.20150312",     "core-js": "^2.4.1",     "ngx-contextmenu": "^4.1.2",     "rxjs": "^5.5.6",     "web-animations-js": "^2.3.1",     "zone.js": "^0.8.19"
Template:
<context-menu #menu>
  <ng-template contextMenuItem [subMenu]="thOpts">
    Thickness
  </ng-template>
  <context-menu #thOpts>
    <ng-template *ngFor="let thicknessOpt of thicknessOpts" contextMenuItem (execute)="customFunc(thicknessOpt.value)">
      {{thicknessOpt.name}}
    </ng-template>
  </context-menu>
</context-menu>

Trigger open of context-menu on click of custom button:
@ViewChild('menu') menu: ContextMenuComponent;

public onClick($event: any): void {
    this.contextMenuService.show.next({
      anchorElement: $event.target,
      contextMenu: this.menu,
      event: $event,
      item: null
    });
    $event.preventDefault();
    $event.stopPropagation();
  }

Are you missing the css for the context menu?  When you inspect the .cdk-overlay-pane what are the css properties?
It should look like this:

@isaacplmann , Thought I'm unsure on how it worked before with v 1.3.5, maybe the flow of implementation was incorrect.
Below is the method I followed with v 1.3.5

Now, I moved ngx-context menu component's template and scripts to Component - A to make it work.
Thanks for your support!!!


Activate pre-launch countdown page

To activate the pre launch countdown do the following in order:

[ ] Configure the correct domain, probably app.zeitgeist.pm to the app. @lsaether
[ ] Update the const launchDate = new Date("2022-08-22"); in _app.tsx to the exact launch date.
Blocked as we do not know the exact date yet.
[ ] Merge staging branch into main
[ ] Set NEXT_PUBLIC_PRE_LAUNCH_PHASE in vercel env to true. Remember to set it for production, preview and dev envs.
[ ] Redeploy

This is done, right?


[Enhancement] Better placeholder format

Maybe make a formatted placeholder so it doesn't do the whole decimal shenanigans.

Added in 1.9r-17 (%tokens_formatted%)


Sign in with Google button is not clickable in chrome extension

How to reproduce:

After installing chrome extension click play button in Figma toolbar
Try to click "Sign in with Google" button

False alaram. Google Sign In pop-up window was hidden behind Figma


options: enhance docstring and add default ErrorFunc

Codecov Report

Merging #3 (9e65290) into main (f0a3e12) will decrease coverage by 0.38%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##             main       #3      +/-   ##
==========================================
- Coverage   86.09%   85.71%   -0.39%
==========================================
  Files           3        3
  Lines         187      189       +2
==========================================
+ Hits          161      162       +1
  Misses         15       15
- Partials       11       12       +1


fix crash when selecting a file on MacOS

This variant no longer crashes on MacOS, have not tested it on other platforms yet.

Amazing! I'll take a look at this tonight

Fix released in 1.2.0

okay, wait, this was fast, also I had TODO comment and on Windows when opening a folder select dialog it does not open native picker 😨


new SingleNode style: rewrite negated Enum.any? and Enum.empty?

from @milmazz
unless Enum.empty?(something) => if Enum.any?(something)

This should be resolved by this PR.
Let me know if I missed something!


Review and edit all reference figures for CareCommunication

E.g. this figure is not aligned with the other messaging figures: https://build.fhir.org/ig/hl7dk/dk-medcom/branches/1.0.4-release-candidate/StructureDefinition-medcom-careCommunication-message.html#scope-and-usage

is handled


Add support for Ubuntu 23 testing for CWA

Description of the issue
Add support for Ubuntu 23 for CWA for our customers. In order to support it we want to test it with our integration test.
Testing
Linux Integration test run - https://github.com/aws/amazon-cloudwatch-agent/actions/runs/8288078239
License
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

lgtm


Avoid func/capture allocations for non-lazy items

Non-lazy imports were paying for capture and Func creation, despite the Func being invoked immediately after it was created. Instead take a different path for the lazy versus non-lazy case so that only Lazy exports pays for the allocations.
This was allocating about 100 MB opening and closing Orchard Core, but the end result will depend on how many lazy versus non-lazy items are in the composition graph:

This one was a bit tricky to approach to avoid leaking "this" and to handle export provider import and I took a few different paths, and ended up with this one. This one is much easier to read commit by commit.

Codecov Report

Merging #314 (8968293) into main (9f0d19b) will decrease coverage by 0.39%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #314      +/-   ##
==========================================
- Coverage   76.15%   75.75%   -0.40%
==========================================
  Files         110      110
  Lines        7187     7174      -13
==========================================
- Hits         5473     5435      -38
- Misses       1714     1739      +25

Impacted Files
Coverage Δ

...timeExportProviderFactory+RuntimeExportProvider.cs
97.65% <100.00%> (-0.10%)
:arrow_down:

....Composition.AppDomainTests/OpenGenericExport`1.cs
0.00% <0.00%> (-100.00%)
:arrow_down:

...mposition.AppDomainTests/ExternalExportOnMember.cs
0.00% <0.00%> (-100.00%)
:arrow_down:

...mposition.AppDomainTests/ExternalExportWithLazy.cs
0.00% <0.00%> (-100.00%)
:arrow_down:

...osition.AppDomainTests2/CustomMetadataAttribute.cs
0.00% <0.00%> (-100.00%)
:arrow_down:

...dTypeReceiver/PartThatImportsLazyOfEmbeddedType.cs
0.00% <0.00%> (-100.00%)
:arrow_down:

...rtThatLazyImportsExportWithMetadataOfCustomType.cs
0.00% <0.00%> (-100.00%)
:arrow_down:

...atLazyImportsExportWithTypeMetadataViaTMetadata.cs
0.00% <0.00%> (-100.00%)
:arrow_down:

...tLazyImportsExportWithTypeMetadataViaDictionary.cs
0.00% <0.00%> (-100.00%)
:arrow_down:

...ft.VisualStudio.Composition/LazyMetadataWrapper.cs
68.71% <0.00%> (-3.07%)
:arrow_down:

... and 2 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 9f0d19b...8968293. Read the comment docs.

@AArnott Can you merge this? I don't have approval.


Cursor does not lock to game screen in new ServerMod

Reproduced multiple times, whenever I use the 1.3 servermod I am unable to look around. Only way to fix it is to verify game files.

You should copy your game folders and have a separate directory for your server, otherwise you wont get the new client updates and whatnot.
So in steamapps/common you should have
"SPC Secret Laboratory" - the original game files which you use to play
"SPC Secret Laboratory - server"  - copy of above but with servermod installed.

Ive added a change to 1.4 that checks if the graphics device is null before removing the cursor lock, i stil lrecommend the above setup, but if you do use servermod client side the cursor will no longer lock.


Slack Service does not allow you to pick Channel / Username

In GitLab, the Slack Service integrations allow you to pick the Channel and Username used for Slack. GitLab CI does not offer this.

Googling brought me here... @giggsey - did you end up getting Gitlab CI to integrate with Slack? When I press the 'Test Settings' button on Gitlab CI I get 'We tried to test the service but error occured'.

We disabled it, as we didn't want it writing to the default channel.
In actual GitLab, I believe where the Slack settings are stored was
changed. Its possible the same was done for CI.
On 17 Jun 2015 23:03, "Paul Inder"<EMAIL_ADDRESS>wrote:

Googling brought me here... @giggsey https://github.com/giggsey - did
you end up getting Gitlab CI to integrate with Slack? When I press the
'Test Settings' button on Gitlab CI I get 'We tried to test the service but
error occured'.
—
Reply to this email directly or view it on GitHub
https://github.com/gitlabhq/gitlab-ci/issues/581#issuecomment-112963519.

To have Slack notifications for specific channel (or private group or yourself) you have to create new integration and select channel for it.

@ayufan Indeed, but I don't want to waste an integration just for GitLab CI.
The Slack integration in GitLab has the ability to set Channel and Username, so it makes sense that GitLab CI offers the same functionality.

@paulinder - did you get anywhere with the We tried to test the service but error occured message?

Have you managed to run any test jobs at all yet? I'm not quite sure what fixed it, but I have noticed that pressing the Test settings button tries to send the last test passed/failed message. If no tests have been run (and no pass/fail message exists) I think GitlabCI has no message to use for a test.

Thanks for the reports. I'll look into it.

Yes, this now works as we have test runs. As @paulinder says it seems to fail until there is a passed/failed message available.

No longer an issue as GitLab CI is now built into GitLab, and it shares the same Slack settings.


Update automatically-deploy-software-updates.md

I have tested this in numerous environments on version 1810 including with the hotfix applied.
It appears that once the no deployment package is selected (it can be selected either during ADR creation or by editing the ADR later) - you cannot change the option except by editing the XML with powershell.
Summarize the change in the pull request title
Describe your change, specifically why you think it's needed.
Fixes #Issue_Number (if necessary)

@JordanTheITGuy : Thanks for your contribution! The author, @aczechowski, has been notified to review your proposed change.

Thanks @JordanTheITGuy for the contribution. I've been tracking a change here with an internal issue, just hadn't gotten to it yet. I have a discussion in progress with the engineering team, I want to verify the behavior first. Standby...
(Fixes MicrosoftDocs/SCCMDocs-pr#3003)

Microsoft authors of articles need to make updates through the private repository so the updates can be staged and validated by the current validation rules. After you review staging and fix all validation issues, you can add the sign-off comment to let the PR reviewers know the updates are ready to be merged.It's easy to access the private repo version of your articles in GitHub. Just add -pr to the URL, as follows:
Public repo URL: https://github.com/Microsoft/azure-docs/blob/master/articles/azure-portal-overview.md
Private repo URL: https://github.com/Microsoft/azure-docs-pr/blob/master/articles/azure-portal-overview.md
We have closed this pull request. Please resubmit the updates through the private repo. If you need perms to the private repo, see the contributor guide instructions

I'm more than happy with your edits thanks for getting this fixed!
Let me know I there is anything else I need to do on my end.

#sign-off
Once merged, this should be live with the next daily publishing process. Right now that could be today (Wednesday, 27 February) around 11:00 Pacific time. No further action needed from you.

@GitHubber17 : Thanks for your contribution! The author, @aczechowski, has been notified to review your proposed change.


[Gap-Close OCM client] Implement github Access Method for OCM

Premise
Access methods for OCM require a github implementation. How that could look like?
name: git-source
access:
  type: github
  repoUrl: github.com/org/repo
  ref: refs/heads/main
version: 0.1.0-dev
type: <arbitrary>

Implementation Notes
The created artefact must be a blob of type TAR which contains the entirety of the repository. Alternatively, there is a REST call for GitHub to provide such a TAR archive.
The first iteration need only concern itself with public repositories. The next iteration will add Credentials and private repositories.
For now, focus on creating an access method under ocm/accessmethods.
The full implementation should live in the access method for now. Later, when there is a git context we can defer the implementation there and abstract the usage for the access method implementation.

[ ] github access method works and downloads a tar archive of the pointed repository
[ ] documentation and sample yaml exists to try out this new access method

Done already, can be closed.


Support flow:main in manifest

(I searched for an existing issue but couldn't find one so sorry if this is a duplicate)
The problem
The problem is that we want flow to understand the types of flow-typed modules correctly when requiring them.
The workaround
We currently have to keep .flow files along with .js files after they are babel compiled and that adds an extra build step and a ton of headache.
The solution
If Flow has support for flow:main (like jsnext:main for rollup), we would not have to add anything new to our build step. We can just leave the src dir in our npm package and set flow:main to src/.
This is a follow up to https://github.com/facebook/flow/pull/1459

Any update here? This prevents our entire stack from being flow typed properly!

@STRML About your comment on the PR, AgentMe/flow-copy-source doesn't integrate well with babel so I've forked the babel cli and created a dropin replacement babel-flow-cli, it works well even with the watcher and updates $.flow copies instantly

You might don't need to look for module field. Use this way
{
  "main": "./lib/index.js",
  "module": "./esm/index.js",
  "files": ["lib", "esm", "src"],
  "scripts": {
    "build:flow": "echo \"// @flow\\n\\nexport * from '../src';\" > lib/index.js.flow"
  }
}

I think that's what he was addressing under "The workaround".  It's certainly an option some libraries are taking, but it feels hacky and potentially increases bundle size.

@wtgtybhertgeghgtwtg How this increases bundle size? lib/index.js.flow file is used only by flow. Bundlers do not care about it. Also with this you don't need to duplicate types anywhere. Sust place one .js.flow reference near entry point.

Also there is #5729 with similar feature, so this can be closed
/cc @vkurchatkin

Sorry, I meant package size.
I don't think #5729 solves this issue.  Ideally, Flow types should work without an extra build step and without the consumer having to alter their configuration.

Package size? With a few bytes? Who cares? My way is pretty good for this without any new fields in package.json.

The problem is that own entry point does not solve necessary cases. For example:
import map from 'lodash/map'

requires map.js.flow file. Such cases are not solvable with simple configuration. But with .js.flow and main field we have universal way to define types. So I consider it as non-hacky and even more productive than any config and additional fields.

I've opened a PR to fix this in https://github.com/facebook/flow/pull/6504


[MRG] Adds SetRequiresGradParams

Resolves #261.
This PR restricts the matching to only using fnmatch. I made this choice because optimizer__param_groups in NeutralNet works with wildcards the same way.

Perhaps I'm missing something important, but why does this need to be a callback? Why not just a helper function set_requires_grad(net, pattern, requires_grad)? I would understand the need if the callback also reverted its actions on train end, but this is not the case.

why does this need to be a callback?

I agree that having this functionality in a callback is a little bit unintuitive. Personally, I would really prefer NeuralNet(module__embeddings__weight__requires_grad=False) to work, but oh well. The difference between your proposal and a callback is that the callback can be parametrized, meaning that I can for instance test in a grid search whether freezing some parameters is better or not.
Nonetheless, a function as you proposed it could be useful, so I wonder whether that functionality should be factored out and SetRequiresGradParams changed to use that function.

I would understand the need if the callback also reverted its actions on train end

Do you have a use case for this? Should that be an option for the callback?

Do you have a use case for this? Should that be an option for the callback?

Not really, this was just a speculative idea. But, now that you have mentioned grid search, maybe this is the use case? After trying one combination of frozen parameters you'd probably want to revert back before checking another one?

After trying one combination of frozen parameters you'd probably want to revert back before checking another one?

This should not be necessary because GridSearchCV clones the model and only then calls set_params, meaning that only the clones are modified.

NeuralNet(module__embeddings__weight__requires_grad=False) could work as long as its restricted to modifying parameters associated with torch.nn.Parameter. Parameters such as cuda or requires_grad will work as expected. Consider the following example:
class MyModule(nn.Module):
    def __init__(self, in_features, out_features=123):
        self.linear = nn.Linear(in_features, out_features)
        self.sub_module = MySubmodule(in_features=out_features)

in_features and out_features would not be supported. The following would be supported:

NeuralNet(module__sub_module__requires_grad=False)
NeuralNet(module__sub_module__cuda=False)
NeuralNet(module__linear__requires_grad=False)
NeuralNet(module__linear__weight__requires_grad=False)

What do you think?

Yes, I thought about that possibility, mainly having a list of parameter names that are "okay" to be set without needing to re-initialize modules. However, from a user perspective, it would be quite hard to tell what works and what doesn't, and keeping that list up-to-date is certainly daunting.
Moreover, we may get into trouble because the user can name their parameters whatever they like:
class MyModule(nn.Module):
    def __init__(self, requires_grad=10):
        self.linear = MySubmodule(in_features=requires_grad)

NeuralNet(module__linear__requires_grad=20)

The last line would look totally fine for skorch but would actually not work as intended. Sure, that example is contrived, but who knows what other parameter names there are that are less clear-cut. In the end, we just cannot know if setting a parameter that way would work or not, and putting that burden on the user feels like too much a burden.

I am placing this PR on hold till a decision is made in https://github.com/dnouri/skorch/issues/342.


update: add support for netavark update command

Netavark update allows container managers to update network scoped DNS servers of any configured network and notify running aarvark-dns about it.
netavark-update
Updates network dns servers for an already configured network

USAGE:
    netavark update --network-dns-servers <NETWORK_DNS_SERVERS> <NETWORK_NAME>

ARGS:
    <NETWORK_NAME>    Network name to update

OPTIONS:
    -h, --help                                         Print help information
    -n, --network-dns-servers <NETWORK_DNS_SERVERS>    DNS Servers to update for the network

Don't review it yet since it needs https://github.com/containers/netavark/pull/497 otherwise tests will fail.

@Luap99 @mheon @baude PTAL

@baude @mheon PTAL

/lgtm


Place settings menu button and color mode switch to the left and right sides of the game title, respectively

Done.


Error for Noop dependency type on Linux due to case-sensitive file name

When using on linux with PowerShell Core 6.0.1, I'm getting following error:
Get-PSDependScript : Could not find path '/root/.local/share/powershell/Modules/PSDepend/0.1.64/PSDependScripts/noop.ps1' for dependency Noop. Origin: noop.ps1
At /root/.local/share/powershell/Modules/PSDepend/0.1.64/Public/Invoke-DependencyScript.ps1:80 char:27
+         $DependencyDefs = Get-PSDependScript
+                           ~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Get-PSDependScript

This seems to be caused by the fact Noop dependency type is defined with lower case noop.ps1:
    Noop = @{
        Script = 'noop.ps1'
        Description = 'Display parameters that a depends script would receive. Use for testing and validation.'
    }

But the filename is with capital N:
$ ls PSDependScripts | grep -i noop
Noop.ps1

hiyo!  good catch!
If you have time, want to give it a shot with Script = 'Noop.ps1' and submit a quick PR if it works?
Cheers!


funni html5 error

might be in story mode

but engines cool! i like how i get 120 fps on a chromebook

videos aren't supported on html rn
i will try to fix that soon

ah i see

quick thing


test: replicator change listener

check for change listener is being returned when added to an offline replicator.
check for network retry.

link: #1457

Coverage increased (+0.8%) to 75.959% when pulling e51cc95d56aea1d8de11a00fbdf852a944e724eb on test/replicatorChangeListener into 92e965f721ef5925ed968074054f6317ba0d2d21 on master.


[WIP] Update ethereum/tests fixtures

What was wrong?
See issue #1152, in particular https://github.com/ethereum/py-evm/issues/1152#issuecomment-417284202.

The ethereum/tests git submodule in fixtures is rather old:

2017-12-08 - https://github.com/ethereum/tests/commit/47b09f42c0681548a00da5ab1c98808b368af49a - merge of PR https://github.com/ethereum/tests/pull/374.

py-evm PR #1181 enables ConstantinopleVM testing with a much newer test set; having these changes "lumped together" makes it harder to attribute CI run failures to one or the other, at least at a cursory look.

How was it fixed?

Updates the submodule to:

2018-01-22 - https://github.com/ethereum/tests/commit/db8ae9de91c303caad3eb9354015c07a0ec3adc3 - merge of PR https://github.com/ethereum/tests/pull/401.

WIP: current state
Evaluating https://github.com/ethereum/tests/pull/405, which deals with the MODEXP precompile, with a particular modlen value.
Cute Animal Picture
"Love this fixture..."

Source: elejhon @ imgur

The test I'm evaluating currently was introduced in https://github.com/ethereum/tests/pull/405 - you can try it by git checkout 9b1f07c58a70d1b17c4489c49eb9bebf4a27d290 in fixtures.
I couldn't find a rationale for it, but looks like it deals with the MODEXP precompile ("contact" 0x5, introduced in Byzantium, EIP-198), which computes (B**E)%M; and the particular case where B==1, E==1, M==999188.
Running
pytest --cache-clear --capture=no -k "test_state_fixtures[/home/veox/src/py-evm/fixtures/GeneralStateTests/stReturnDataTest/modexp_modsize0_returndatasize.json:modexp_modsize0_returndatasize:Byzantium:4]"

fails on
https://github.com/ethereum/py-evm/blob/3fef4bd3d596eb4a16fc63ae4c6795bfaa03b641/tests/json-fixtures/test_state.py#L339
The helper contract puts some results of the call to the precompile into storage, and that produces a mismatch.
ATM, still looking for the culprit.

Maybe we can uncover what is wrong with opcode level test cases assuming we know what the expected result is for the inputs you mentioned?

FYI, the mismatched state root failure case is hard to debug.  It normally requires enabling TRACE level output, running the single test and inspecting the logging output, but in this case, it's likely different because of the result being wrong and thus the storage entry that the contract is storing being wrong.
Also maybe look to see if there are VM level tests for this as they would provide explicit output for the call.

(Currently on mobile.)
Took a glance y-day, there is a modexp test file, but no test case for this is particular.
Tried inspecting the computation, the result seemed wrong - 0, not 1; but does computation have the memory as it existed when exiting the EVM call frame?..

I think the computation fails to allocate 999188 bytes in memory. That is, the failure might be coming from the precompile impl-n.
The contract in the test SSTOREs three 32-byte values: whatever is returned from CALLCODEing the precompile, whatever is at memory location 0x03e8 (hex for decimal 1000), and value of RETURNDATASIZE. These are written to storage locations 0x01 to 0x03.
I haven't gotten to inspecting actual storage post-computation - trying to find out how...

Have you looked at the TRACE level logging output.  my guess is that it'll go OOG when it tries to allocate such a large memory size.

OK, changed logging level in tests/conftest.py; gas consumption for calling the precompile is 23970528 (that's 23.97 million); tx gas allowance is 1 billion, and block limit is set at 10 billion for that test case - so no OOG.
I haven't checked yet if ~24 million is the precise expected gas consumption (the test case seems to be under-specified in this regard); the values put to storage, according to the TRACE:

1
0
999188

(Will link gist in a sec.)

What's more confusing to me is, doing this printf-style debugging, I can see that the return value length from modexp() (the precompile impl-n) is indeed 999188, but
print('computation.should_erase_return_data:', computation.should_erase_return_data)
print('len(computation._output):', len(computation._output))

at the end of test_state_fixtures(), which gives False and 0.
So, seems like somewhere between the result being returned from modexp() and the computation being returned from vm.apply_transaction(), computation._output gets truncated...

Maybe found it?..
When writing 999188 to storage slot 3 of the contract, there seems to be a value<PHONE_NUMBER> already there; so the gas cost is 5000 instead of 20000.

I've been stuck on this single test case for too long, and, to the best of my understanding, py-evm's operation is correct.
My inclination is to mark this consensus test xfail (¯\_(ツ)_/¯), and move on.
I've brought up my findings in https://github.com/ethereum/tests/pull/405 (where it was incuded).

Thanks for all the work you've put into this.  I think xfail is fine for now but we'll want to do a full re-visit of any xfail tests before constantinople because it's looking like we'll have a minimally viable client by around that time.

Squashed/rebased previous linting failure.
Also, accidentally found a typo in py-evm that caused the failure. After all, upstream was correct.
Running full state tests locally while CircleCI checks linting, will submit afterwards.

Possible candidate:
Narrowed it down to a difference in gas usage:

in "complementary" JSON from BlockchainTests, gasUsed is 0x01f250 (decimal: 127568); whereas
py-evm shows gas_used for the block at 112568.

The difference is 15000, which would suggest a miscalculation of gas use on SSTORE by one of the implementations.

@veox not sure what commit you are on, but the net gas metering for SSTORE hasn't been implemented yet so if those are constantinople tests that could be the case.
If not, the simple case is a small miscalculation, but I've found that often the gas usage difference is actually indicative of a previous error where either a value should not have been written to storage (but it was) and thus a subsequent write to that storage slot costs less than it should, or some other variant of the same thing.

@pipermerriam Thanks for the suggestion! I'm trying not to assume things; this is a Byzantium test, so net gas metering shouldn't be in play yet (I hope so!).
I've edited the previous comment to indicate the commit used, for the sake of easier reproduction.

OK, here's what's going on in this test:
There is an account 0x6295ee1b4f6dd65047762f924ecd367c17eabf8f with a storage location 0x00 already set to a non-zero value 0x01, but with no code. How? Test case magic.
A call is made by another account, 0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b, with a CREATE that would place code at 0x6295..bf8f... except it always REVERTs.
At this point - question: what is the value at storage location 0x00 of 0x6295..bf8f?

According to the test case (i.e. then-cpp-ethereum, now-aleth that generated the test); as well as geth and parity, - the storage is empty. So the two writes to empty storage consume 20000 gas each.
According to py-evm, the storage looks as it has at the beginning of the test - that is, 0x00 has value 0x01. So, the writes consume 5000 and 20000 gas for locations 0x00 and 0x01 respectively.

Is the tl;dr that a CREATE call should always start by wiping out the storage at the address (and that emptying the storage is not reverted on a REVERT)?

See https://github.com/ethereum/EIPs/issues/684

@carver

Is the tl;dr that a CREATE call should always start by wiping out the storage at the address (and that emptying the storage is not reverted on a REVERT)?

It would seem so; except the yellowpaper (Section 7, "Contract Creation") either explicitly states otherwise, is contradictory, or is under-specified:

The account’s nonce is initially defined as one, the balance as the value passed, the storage as empty (...)

But then later:

execution may exit before the code has come to a natural halting state. In this (and several other) exceptional cases we say an out-of-gas (OOG) exception has occurred: The evaluated state is defined as being the empty set, ∅, and the entire create operation should have no effect on the state, effectively leaving it as it was immediately prior to attempting the creation.

The YP does not consider a "synthetic" case, like in this test.

@holiman (near-copy from gitter chat)
It seems that https://github.com/ethereum/EIPs/issues/684 also does not consider no-nonce, no-code, some-storage accounts. The proposition is somewhat ludicrous, but here we are!
I assume the test case is being run, and passes against all the implementations handled by Hive?..

@veox it appears you've got a handle on the why (your explanation makes sense to me).  Let me know if you need guidance on how to proceed with fixing things.

@pipermerriam Cool!
Definitely confused here, might take a day or two to formulate something concise.

It seems to me that the test case is in contradiction to the yellowpaper. If so, then all the major implementations may be as well (need to verify). If so, then an exception/clarification to the yellowpaper might be inevitable; possibly complemented by a "correcting" EIP for Constantinople/Istanbul...
If my guesses above are correct, and aleth/geth/parity implement it this way, then there is no recourse but to implement it the same way also - at least for the Byzantium block dynasty. :D (Would be nice to get confirmation from these other implementations...)

TL;DR: I won't be fixing this one. q:D

The "correct" approach from the very beginning would have been immediately marking the test xfail when bumping fixtures. This highlights that a specific upstream test is failing, and makes sense no matter where the breakage originates from. I've done this now in https://github.com/ethereum/py-evm/pull/1224/commits/e02123e508368efd27c975f38646baeb4acf7978.
As to the test itself - IMO this really should be fixed upstream. Leaving a newly-CREATEd contract's state wiped after a REVERT contradicts the yellowpaper.
This difference between py-evm and (probably) every other implementation is unfortunate. However, I think it doesn't present a danger of consensus failure on its own, as the initial state that the test starts with can't (currently) be arrived at "naturally", using regular consensus rules. (This is why I called it a "synthetic" test.)
However, it seems that this particular detail is a quirk in the test definition; it's probably testing for something else. By marking the test xfail, py-evm is no longer testing for that, too (but, note: only on Byzantium; the earlier chains are still being tested).
If someone's inclined, they can push py-evm's behaviour towards that in the test, but I think this is wrong.

We recently fixed a bug for checkpointing in https://github.com/paritytech/parity-ethereum/pull/9319, and I believe right now, parity's behavior on this is the same as py-evm -- on REVERT or out-of-gas, old storage values should re-appear, if that account ever existed.

Current state might be where the "simple" fixes end.
The next merge commit in ethereum/fixtures gives 74 failures for test_state_fixtures() alone, IMO better handled in a separate PR. Also, the discussion here is getting a bit too long, and hard to navigate.
Unmarking as [WIP].
Should be OK to squash-merge, especially since there's an interim commit that failed CI.

#1181

#9532

veox : update - ethereum - test - fixtures


Fix eql? in Cask::Cask

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[x] Have you successfully run brew tests with your changes locally?
[x] Have you successfully run brew man locally and committed any changes?

This PR fixes equality checking for Casks.
Before:
➜ brew livecheck volt homebrew/cask/volt
Warning: Treating volt as a formula. For the cask, use homebrew/cask/volt
Error: undefined method `token' for #<Formulary::FormulaNamespace8375643587616545a6f8955d8b01e055::Volt:0x00007ff183b86ec0>
Please report this issue:
  https://docs.brew.sh/Troubleshooting
/usr/local/Homebrew/Library/Homebrew/cask/cask.rb:165:in `eql?'
/usr/local/Homebrew/Library/Homebrew/cli/named_args.rb:61:in `uniq'
/usr/local/Homebrew/Library/Homebrew/cli/named_args.rb:61:in `to_formulae_and_casks'
/usr/local/Homebrew/Library/Homebrew/dev-cmd/livecheck.rb:84:in `livecheck'
/usr/local/Homebrew/Library/Homebrew/brew.rb:122:in `<main>'

After:
➜ brew livecheck volt homebrew/cask/volt
Warning: Treating volt as a formula. For the cask, use homebrew/cask/volt
volt : 0.3.7 ==> 0.3.7
volt : 0.80 ==> 0.87

Review period will end on 2021-02-17 at 19:50:54 UTC.

Review period ended.


Port to ROS 2

The vast majority of the work has been done, but there is still some minor bugs and changes remaining, which I outline below. Tested against ROS 2 Humble on Arch Linux ARM.

Was not able to test traffic light, may or may not work.
Camera node path changed from /camera/image_raw to /automobile/image_raw, and I can't seem to figure out why.
There are many warnings on launch, but the majority seem to have been there prior to the port; I'd suggest cleaning those up.
map_with_all_objects.launch is a bit broken. I detail the issue in the justfile and provide a hacky workaround, but the root cause should be dealt with.
The port is to Gazebo Classic, not Ignition. I don't know how much work would be required to Ignition, but it's likely a good amount. Though Gazebo Classic is much easier to install than ROS 1, so I still consider this a win.

I'd also added some auxiliary files for use by our team, but which are not required and should probably be removed. These files do include some workaround for issues, so they are worth understanding. I can provide further details if needed. Namely:

poetry.lock and pyproject.toml to declare and lock Python dependencies with poetry.
justfile, for use with just to avoid typing ros launch ... every time.
.envrc for use with direnv

Useful links:
https://docs.ros.org/en/humble/How-To-Guides/Migrating-from-ROS1.html
https://classic.gazebosim.org/tutorials?tut=ros2_overview

PR closed and pushed to new branch.


Generate JavaScript for instance converter

Assume JSON in and JSON out. Allow for XML in or out without significant pitfalls.

I've been prototyping a JS module, and am making good progress.  This prototype will help me author a spec and scaffold the codegen.

Here's a module that appears to work properly for a trivial, flat entity instance, pointers and refs in JSON or XML.  Just a starting point.
function extractInstanceCustomer( source )
{
    let sourceNode = initSource(source, 'Customer');
    let instance = {};
    addAttachments(instance, sourceNode, source);
    instance["$type"] = "Customer";

    if (fn.exists(sourceNode.xpath("(number-node()|boolean-node()|null-node()|text())"))) {
        instance['$ref'] = fn.head(sourceNode.xpath("(*|text())"))
    }
    else {
      let id = fn.head( sourceNode.xpath("(node()/id)|id"));
      let content = fn.head( sourceNode.xpath("(node()/content)|content"));

      if (id) { instance["id"] = xs.int(id) }
      if (content) { instance["content"] = xs.string(content) }
    }
    return instance;
};

function addAttachments(
    instance, sourceNode, source
)
{
  instance["$attachments"] = source;
};

function initSource(
    source, entityTypeName
)
{
    if ( (source instanceof Document) )
      return fn.head(source.xpath("/node()"));
    else
      return source
};

To use, first
declareUpdate();
xdmp.documentInsert("/e1.xml", fn.head(xdmp.unquote(
  '<source><id>6</id><content>this is the e1 content</content></source>')));

xdmp.documentInsert("/e2.json", {source: { id:10, content: "this is the e2 content"}});

xdmp.documentInsert("/e3.json", {Customer: 10});

xdmp.documentInsert("/e4.xml", xdmp.unquote('<Customer>10</Customer>'));

Then,  in the same qc tab as the sample code
const source1 = cts.doc("/e1.xml");
const source2 = cts.doc("/e2.json");
const source3 = cts.doc("/e3.json");
const source4 = cts.doc("/e4.xml");
[
extractInstanceCustomer(source1),
extractInstanceCustomer(source2),
extractInstanceCustomer(source3),
extractInstanceCustomer(source4)
]

Along with this example, I'll be proposing that we align the SJS and XQuery code so that they look more-or-less the same, although we'll try to make them relatively idiomatic as well.

Nit picks:

let should be const wherever possible
Single quotes (basically prettier --single-quote --tab-width 2 using prettier)

…align the SJS and XQuery code so that they look more-or-less the same, although we'll try to make them relatively idiomatic as well

Idiomatic for the host language is much more important to me than consistency across languages.

"Assume JSON in and JSON out. Allow for XML in or out without significant pitfalls."
We can extend the vocabulary to specify two orthogonal code-generation preferences:
/info/preferredEnvelopeStyle := "json" | "xml" | "mixed"
/info/preferredModuleLanguage := ("JavaScript" | "XQuery")

(I've been working up such proposals for the envelope, to be recorded in another issue.)

prettier is, i will admit, an excellent thing.

prettier is, i will admit, an excellent thing.

I’ve got it working on MarkLogic. (I’d like to see a button in Query Console too.)

Reassess using an AST-based design to abstract from specific language and lend itself better to tooling, for example for schema mapping.


 remove core-js/ import

This affects angular. Because core-js is imported inside the library , the Promise  polyfill is in conflict with  zone.js. Since Excel.js puts browsers compatibility on the hands of the devs. (link) , we can add it manually in a way that does not conflict with Angular.
this PR should fix : https://github.com/exceljs/exceljs/issues/1008
This was fixe din many other package and is referenced here:
angular/zone.js#783

@bleuscyther - I'm tending to agree - though I might go one step further and remove the regenerator-runtime/runtime require as well, leaving the whole task of polyfill support to the app in question. What do you think?

that would be perfect.

@bleuscyther I've just merged - I'm going to make one further change... In order to avoid breaking changes, I'm going to copy exceljs.browser.js to exceljs.bare.js that removes all polyfills and restore exceljs.browser.js to keep them. To include the exceljs bundle without pollys, just change the import from dist/exceljs.min.js to dist/exceljs.bare.min.js

Nice i am going to test this week

There was a new error:

Uncaught ReferenceError: regeneratorRuntime is not defined

from what i see this is a babel issue related to how the file was built. https://github.com/babel/babel/issues/9849
As a quick fix, I installed the missing package :
npm install regenerator-runtime
and put the import in the polyfill for now:
import "regenerator-runtime/runtime";

Using angular i had to do the usual additional changes (tested on version 8), it works fine after that
// ./tsconfig.json
...
  "module": "esnext",
    "moduleResolution": "node",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "importHelpers": true,
    "allowSyntheticDefaultImports": true,
    "target": "es2015",
   "paths": {
        "exceljs": [
          "../node_modules/exceljs/dist/exceljs.bare"
      ],
..

Check this (link) for additional configs and updated values/fields.
...
// ./angular.json
...
"architect": {
        "build": {
          "builder": "@angular-devkit/build-angular:browser",
          "options": {
                ...
               "scripts": [
                  ...
                  "./node_modules/exceljs/dist/exceljs.bare.js"
               ]
               ...

//my .component.ts

import * as ExcelJS from 'exceljs/dist/exceljs.bare.js';
import {Row, Workbook, Worksheet} from 'exceljs';
...
    const workbook: Workbook = new ExcelJS.Workbook(); // Important don' t use Class directly the wrong module will be loaded

@bleuscyther
Great you got it working - does this leave any changes required for ExcelJS?
My thoughts are that the 'bare' option leaves all the polyfill dependencies for the app to fetch - including "regenerator-runtime/runtime" - though I should probably add this to the readme

Probably add it on the Readme. Thank you for your help.


feat: Array.mem: Avoid DecidableEq, set up decreasing_trivial

The notation a ∈ as for Arrays was previously only defined with
DecidableEq on the elements, for (apparently) no good reason. This
drops this requirements (by using a ∈ as.data as the definition`), and
simplifies a bunch of proofs by simply lifting the corresponding proof
from lists.
Also, sizeOf_lt_of_mem was defined, but not set up to be picked up by
decreasing_trivial in the same way that the corresponding List lemma
was set up, so this adds the tactic setup.

awaiting-review

I am a bit confused how this change can affect tests like
inductive Term where
  | app (f : String) (args : List Term)

def printFns : Term → IO Unit
  | Term.app f args => do
     IO.println f
     for h : arg in args do
       have : sizeOf arg < 1 + sizeOf f + sizeOf args := Nat.lt_trans (List.sizeOf_lt_of_mem h) (by simp_arith)
       printFns arg

where there is no Array around. Maybe because apply Nat.lt_trans (Array.sizeOf_lt_of_mem ?h) can fire due to unwanted defeqs even if the assumption is only talking about lists?

You should make it a structure instead of an inductive, assuming def doesn't work (it should work though).

Will do. Is there a difference between a one field structure and a one field one constructor inductive? Ive seen both patterns so far.

Structures have various additional niceties, I don't see why you would ever not use them unless you don't meet the restrictions. Do you have an example?

I've seen it mostly with rose trees recently: https://github.com/leanprover/lean4/blob/6c5f79c0df01e9cd74ac4ee411ec392a5ac1b5d3/src/Lean/Data/PrefixTree.lean#L11 (and similar data structures)
Maybe the benefit of an inductive is that you don't have to think of a name for the projection :-)

Fixed in 9a7d35063c, PTAL.

Squashed.
(And because Github is very strange in that squashing is just one click away when merging, but basically impossible without a laptop and a command line for the PR authors, in the process I wrote half a Github App that squashes PRs… :-)

Maybe the benefit of an inductive is that you don't have to think of a name for the projection :-)

My suggestion would be to just use val for one-field structures, rather than coming up with bespoke names that have to be remembered.

My suggestion would be to just use val for one-field structures, rather than coming up with bespoke names that have to be remembered.

done


Speed up clonotype distance calculation

Close #368
compute_distances new version added

Hi @felixpetschko,
I just had a look at the failing tests. Most of them are indeed direct or indirect failures due to the new distance calculator. Some of them are testing the API of the DoubleLookupNeighborFinder and are expected to fail because you changed the API (for good reasons). Those we'll have to adapt or remove eventually.
At first, I suggest you take a look at the tests in test_clonotypes -- it seems they cover some edge cases where your implementation throws an error.

LMK if anything is unclear!
Gregor

@grst Now I could make all tests pass without changing them - I didn't break the API. There are still some documentation and other refinements needed.
The next step would be to implement j_gene matching which I already did for a version that @MKanetscheider uses for his analysis by just copying the v_gene related parts of the code. Should I also do it like that here or should we introduce a more general concept, eg by just passing the column suffixes (eg ["v_call", "j_call",...]) instead of the booleans (same_v_gene, same_j_gene). I don't know if it's biologically possible to have more than those 2.

Hi @felixpetschko,
Kelvin suggests that only v and j calls are relevant, and I'd follow that advice and go with
same_v_gene: bool = True,
same_j_gene: bool = True

as an interface.
I'll leave it to you if you think it's better solved with code duplication or generalization under the hood.

I implemented j_gene matching now with that interface. test cases (for j_gene matching) and documentation are still needed.
Is there still something else missing for the clonotype distance calculation you are aware of @grst ?

Yeah, a couple of docstrings seem to got lost or need updating, but I can't think of anything else right now.

I dropped support for python 3.9 in the main branch which changed some of the formatting rules (most notably Union[A, B] is now simply A | B.
I resolved the (few) merge conflicts and hopefully didn't break anything.

Hi @grst , now I added some documentation and did some variable renaming for clarification. I also added testing for the j_gene matching.
    if partitions == "leiden":
        part = g.community_leiden(
            objective_function="modularity",
            resolution_parameter=resolution,
            n_iterations=n_iterations,
        )
    elif partitions == "fastgreedy": # <--
        part = g.community_fastgreedy().as_clustering()
    else:
        part = g.clusters(mode="weak")

I also allowed to use the "fastgreedy" algorithm for the graph partitioning since it's used for the BCR analysis. However I have been told that choosing a different partitioning method doesn't make a big difference in most cases.
There still seems to be a test case that has some problems with the python versions (conda / test (ubuntu-latest, 3.12) (pull_request)) Could you maybe take a look at it?
Besides from that I am done with my implementations so far. If everything is fine for you I would make some final test runs on the cluster tomorrow. Then we can finally finish this PR :)


make it clear that this is EF7

We actually already have a header on every page that calls out that this doc site is for EF7

Ok, https://docs.asp.net/en/latest/data/index.html doesn't show the same way as your screen shot above...does that mean it hasn't yet been merged/published to the main site?

This repo is published at http://ef.readthedocs.org/en/latest/
The site you referred is from https://github.com/aspnet/Docs repo

Ok, so it looks like I got lost in the file structure somehow. Closing.


Upgrade NuGet packages for VSTest / DevOps

Hitting an issue with DevOps VSTest. Could be due to an old version.
(v15 doesn't support net451 but v16 does.)
Machine Specifications Visual Studio Test Adapter - Error while executing specifications in assembly  - System.Runtime.Remoting.RemotingException: Object '/bc15fff7_47ac_4f9d_9061_df93953c370c/_kv9z__fqrqfm9yrzy1+38hl_6.rem' has been disconnected or does not exist at the server.
Server stack trace:
   at System.Runtime.Remoting.Channels.ChannelServices.CheckDisconnectedOrCreateWellKnownObject(IMessage msg)
   at System.Runtime.Remoting.Channels.ChannelServices.SyncDispatchMessage(IMessage msg)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at Machine.Specifications.Runner.ISpecificationRunListener.OnFatalError(ExceptionResult exception)

Looks like the bug might be related to
https://github.com/microsoft/testfx/pull/98/files