Missing 'use' property in the Mock DR JWKS response

Describe the bug
The MockDataRecipientJwks endpoint (https://localhost:7006/loopback/MockDataRecipientJwks) is currently returning the public keys' information in the JWKS format without including the property - 'use' (Public Key Use).

Use : Implies how the key is being used. The value sig represents signature.

When this jwks endpoint is used in our DH solutions for scenarios such as encrypting JWT responses and the presence of property 'use' with either 'enc'  or 'sig' as the value is mandatory, the flows can not be proceeded.
Hence, the Mock DR JWKS can be more useful if the current JWKS can be updated with the 'use' property with the value as 'sig'.
(Since the 'key_ops' values of the current JWKS are 'sign' and 'verify', only 'sig' can be used as the value for 'use')
But as a further improvement, the JWKS endpoint can be improved to add more separate jwk sets with key_ops having 'encrypt' and 'use' property as 'enc'.
As a temporal solution, the following fix was done.

The JsonWebKey.cs model [1] was updated with the 'use' attribute by adding the following line.
public string use { get; set; }

The LoopbackController.cs jwk generation [2] is updated by adding the following line.
use = "sig",

[1] https://github.com/ConsumerDataRight/mock-register/blob/cc301185b0f6085125f41e12807aad960a75b03c/Source/CDR.Register.API.Infrastructure/Models/JsonWebKey.cs#L5
[2] https://github.com/ConsumerDataRight/mock-register/blob/cc301185b0f6085125f41e12807aad960a75b03c/Source/CDR.Register.Admin.API/Controllers/LoopbackController.cs#L43
To Reproduce

Call the https://localhost:7006/loopback/MockDataRecipientJwks endpoint.
Notice that the 'use' property is missing in the returned jwks.

{
    "keys": [
        {
            "alg": "PS256",
            "e": "AQAB",
            "key_ops": [
                "sign",
                "verify"
            ],
            "kid": "gP32GTv0be7hGek1ONMPg0T6P4RrKtRLl4l0em7XCw4",
            "kty": "RSA",
            "n": "6kpKQ674ZD6dCrJaZezah4Hpr8D5xo4Pn4TibDtWqWr42ghq2SdJ09laHil4h1t-9u3YLbLeNQlbq2izyvQv_l8mWfBRqb7-UgEfT4EFAlriD5h84xsbsK85laz7ph7LA8kj11ztxuUqjeGbircng2v6GM8nzMSk8n4g9nNSy3-G0nZcPYPqYcbISwPiFX9RN4aPKysouuJ1k1IIVdPzUVaAQwP5F9R7TEz1lWkD4Lj1nw-mx6Jxe5fiozuMS87rD8A9AXtuO-57pmW_m40fiDJRF7csYOYL1N32AUcIIrJW0KYdImWtaOMm-mAAlbGX2zz3znXElKaEm0rBqZdx5Q"
        }
    ]
}

Expected behaviour
The returned response from the MockDataRecipientJwks endpoint should be as follows.
{
    "keys": [
        {
            "alg": "PS256",
            "use": "sig",
            "e": "AQAB",
            "key_ops": [
                "sign",
                "verify"
            ],
            "kid": "gP32GTv0be7hGek1ONMPg0T6P4RrKtRLl4l0em7XCw4",
            "kty": "RSA",
            "n": "6kpKQ674ZD6dCrJaZezah4Hpr8D5xo4Pn4TibDtWqWr42ghq2SdJ09laHil4h1t-9u3YLbLeNQlbq2izyvQv_l8mWfBRqb7-UgEfT4EFAlriD5h84xsbsK85laz7ph7LA8kj11ztxuUqjeGbircng2v6GM8nzMSk8n4g9nNSy3-G0nZcPYPqYcbISwPiFX9RN4aPKysouuJ1k1IIVdPzUVaAQwP5F9R7TEz1lWkD4Lj1nw-mx6Jxe5fiozuMS87rD8A9AXtuO-57pmW_m40fiDJRF7csYOYL1N32AUcIIrJW0KYdImWtaOMm-mAAlbGX2zz3znXElKaEm0rBqZdx5Q"
        }
    ]
}

Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

This is not really a bug. Could be an enhancement.
Use of the "use" property is optional, unless the application requires its presence and it could be different from application to application. If your DH application needs it, it's expected that you change it according to your requirements (It seems you have already done and which is good).
Furthermore, this MockDataRecipientJwks endpoint (https://localhost:7006/loopback/MockDataRecipientJwks) is a temporary solution until we get our mock data holder and the mock data recipient solutions in place. Once they are ready, there will be a new jwks endpoint in the mock data recipient with multiple keys with multiple 'use' and 'alg' values.

Closing for now, feel free to reopen if they above didn't answer your query.
Thanks


WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT    spelled wrong in document

WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT    missing the H

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

ID: 2526d6f8-e90d-5ecc-dbca-14540fcad599
Version Independent ID: e308750d-5a63-db74-9113-38cad322d48c
Content: Get started with autoscale in Azure - Azure Monitor
Content Source: articles/azure-monitor/platform/autoscale-get-started.md
Service: azure-monitor
Sub-service: autoscale
GitHub Login: @rboucher
Microsoft Alias: robb

@jsandersrocks Thanks for the feedback. I have made changes to the document and the changes will be live soon.We will close the issue for now. If there are further questions , please revert and we will be glad to assist you.


Duplicate "apiOperation" when 2 HTTP methods are on the same method

Hello,
I have a Spring MVC controller class annotated with:
 @ApiOperation(value = "Do something.")
 @RequestMapping(method = {RequestMethod.GET, RequestMethod.POST})
 public String doSomething(HttpServletRequest request, HttpServletResponse response) throws  Exception {
[...]
}

and the generated swagger file contains 2 paths (expected) but with the same operationId (not expected) so swagger editor complains about it: "Cannot have multiple operations with the same operationId: doSomething"
Would be nice to have the operationId being httpMethod-methodName instead of just methodName, what do you think?
Thanks
Fanny

Duplicated by #354

This would be a tricky change based on how swagger core stores its operations map. It's definitely not impossible, though.
As a work-around, you could do something like this:
 @ApiOperation(value = "POST something.")
 @RequestMapping(method = {RequestMethod.POST})
 public String postSomething(HttpServletRequest request, HttpServletResponse response) throws  Exception {
this.doSomething([...]);
}

 @ApiOperation(value = "GET something ")
 @RequestMapping(method = {RequestMethod.GET})
 public String getSomething(HttpServletRequest request, HttpServletResponse response) throws  Exception {
this.doSomething([...])
}

 private String doSomething([...]) throws  Exception {
[...]
}

Yes of course (just did not want to change the original code, but will definitely work as well!)

My apologies but using the method as a unique operation id is a bit dubious to my opinion.
It makes the OO approach in REST implementation impossible.
If you have e.g. an interface with GET method EmployeeManagement.getEmployees(String employerId);
EmployeeManagement.getEmployees(String employerId);

and would like multiple REST service interfaces to extend this interface, you will end up with "Cannot have multiple operations with the same operationId: getEmployees"

I agree with fstrudel. I real life, I need to attach two method http at the same controller method (and I can do it with Spring) even if it's not the best REST approach.

We've ran into this issue, too. The annoying thing is that if we have 2 methods in different Java classes (and different swagger Tags), it will just prepend numbers to the operation ID silently, which is a real problem. Is there a setting to just fail at compile time if you have 2 methods with the same operation ID, instead of silently renaming them?

@who Why can't we change https://github.com/kongchen/swagger-maven-plugin/blob/master/src/main/java/com/github/kongchen/swagger/docgen/reader/SpringMvcApiReader.java#L164 from:
String operationId = method.getName();

to
String operationId = method.getDeclaringClass().getSimpleName() + "_" + method.getName() + "_" + requestMethod.name();

Works for me but maybe I'm missing something.

Hi all,
I know this is an old issue. I also ran into this problem.
Since operationId is optional (https://swagger.io/docs/specification/paths-and-operations/), can we skip generating this if not provided by user?


Buffering IModelContentChange

I am looking for code to reduce several IModelContentChange to one if someone types several characters. I cannot find something like that in VS code repo. Does something like that exist?

I don't think we have code anywhere to "compact" changes like that.


Fix app generation due to #32

Invalid, code generation is ok. Only Arc creation has changed and app generation does not use it. At least regressions are ok


Add partition key to order by clause

When the partition key is not present in the orderby clause, there is a mismatch between the sort order of the source selection and the bulk copy operation causing the exception Cannot bulk load. The bulk data stream was incorrectly specified as sorted or the data violates a uniqueness constraint imposed by the target table. Sort order incorrect for the following ..

I have fixed the issue and took the chance to cleanup and refactor the code a bit, so closing this PR as it is now fixed here:  b85f6b820c912d9160277f6270e2b938e35d127c
Will release a new version soon
Thanks!


Explain how to debug without Atom in codelab doc

Fixed in Flutter source by pointing to the Flutter.io/debugging page.


Delay rebuild?

Might it be possible to put a delay (configurable, perhaps) of some short time (say, a couple seconds) before firing off the recompile? I'm used to ghcid reacting when I save a file, but having the child GHC process maxing out the CPUs when I'm still in the middle of typing seems a bit overzealous?
AfC

I realized that I would be pretty happy with only rebuilding on error, so set out to see if I could add such a feature myself. I've been looking around in the ghcide code base and couldn't quite figure out what was triggering the shake builds. If someone could point me to which event (ie, it's not "CodeAction" or "Completions" but....) I'd be happy to try and run up a patch.

I don’t really want to change the current behavior in ghcide. If users want a delay this should imho be on the client, i.e. the editor side by limiting the rate at which it sends document updates. As for the code that triggers the updates this is in https://github.com/digital-asset/ghcide/blob/master/src/Development/IDE/LSP/Notifications.hs#L42.

@cocreature fair enough. So this is something that should be changed in the VS Code ghcide extension? (I admit I am overlapping the two conceptually)
Firing off a GHC build—and then cancelling and restarting—every keystroke is making my kernel think it is busy and really ramping the CPU up out of low power mode, resulting in massive laptop battery drain. I had to switch to vim and ghcid while commuting just so my machine would last!

If it works nicely in ghcid, maybe what you want is only checking on save? I think that's something that is in a few extensions, e.g. https://github.com/DavidAnson/vscode-markdownlint/issues/28

Most VSCode extensions offer an option to pick between instant, save or never.

@ndmitchell yeah, checking on save would be great. Changed title. Is this the right repo to have this issue open in?

(certainly a configuration setting like @domenkozar mentions would be a VS Code specific question, but does ghcide need to change to accommodate this?)

Ghcide repo includes the VS Code extension, so yes, it does. It probably also wants to be an option to the Haskell piece, so in the core.

This seems to belongs to the vscode extension so maybe should be transferred to vscode-haskell


Add support for variants

Consider the scenario where a button can have two different states: enabled and disabled. It would be nice to be able to style the button with a single identifier and set the variant one way or another. Pseudocode to illustrate:
struct MyButton: View {
    @State private var isEnabled = true
    var body: some View {
        Button(action: {
            self.isEnabled = !self.isEnabled
        }) {
            Text("Button")
        }.style("buttonIdentifier", variant: self.isEnabled ? "enabled" : "disabled")
    }
}

And then in the stylist you would have something like...
stylist.addStyle(identifier: "buttonIdentifier[enabled]") {
    // Style for enabled state
}

Oh, I thought that already worked :| Though, with the current system the style set for buttonIdentifier[enabled] won't inherit from buttonIdentifier - you would have to explicitly set everything.

OK, looking more deeply at the code, I think the interface on Stylistidentifier for variants could do with some work - currently it only really works with strings i.e. StylistIdentifier("section/element[variant]/atom") will work as expected.
However, your pseudocode doesn't hit some edge cases, like specifying which component in the identifier will have the variant applied to it i.e. in the case of StylistIdentifier("section/buttonIdentifier/atom", variant: "Enabled"). Sigh, it's tricky, and I'm tried from being on lockdown with two kids :) Any suggestions?

No suggestions so far but IMHO how identifiers are constructed should be "implementation detail" i.e. no need for user to know [x] is a variant. I might even go further and suggest identifiers should have properties of their own for sections, organisms, elements and atoms instead of just a string (ofc with some behind-the-scenes magic to make "section/organism/element/atom" also a valid identifier).
Another example where I would like to use variants would be a UI like this:

Where the tokens for "Loan" i.e. the pink, green and yellow bits are all the same atom but in different variants. How the variants are set is completely arbitrary and doesn't have a pre-defined set of values (unlike perhaps enabled/disabled or UIControl.State values).

Although I guess that's how it works atm where you can create a stylist identifier with any number of components 🤔

Also, the library has absolutely no opinion on what a variant is - it's all strings behind the scenes. That's a hard requirement as an identifier has to map to / from a string literal.

Was thinking about this last night and I think what annoys me is having to construct the string for a variant as a consumer of this library. e.g. in my example above I'd have to do something like...
struct MyButton: View {
    @State private var isEnabled = true
    var body: some View {
        Button(action: {
            self.isEnabled = !self.isEnabled
        }) {
            Text("Button")
        }.style("buttonIdentifier[\(self.isEnabled ? "enabled" : "disabled")]")
    }
}

I think it would be a nicer API if the library abstracts away how variants are encoded into the identifier string 🤔

When you ask for myIdentifier.element would you want to know the variant as well?

Yes, I think myIdentifier.element would return a Component but I do agree with the n-components as opposed to having them named. It's trivial for a user of this library to have an extension of identifier to "name" each component according to how it's called in that team.
Another question.. kinda related...
StylistIdentifier is what we use to find a style for each component i.e. a StylistIdentifier is x/y/z/atom[state] but when we nominate a component for styling we use a StylistIdentifier when in reality what we create is more like a Component? in the example above:
.style("buttonIdentifier[\(self.isEnabled ? "enabled" : "disabled")]")

but how likely/encouraged is it to style components with a string like:
.style("organism/element/buttonIdentifier")

Just realised your first comment pretty much says what I mentioned in these two last comments 🤦♂

I presume StyleIdentifier("section/buttonIdentifier/atom", variant: "enabled") would apply the variant to all of the components. I don't know if "section/buttonIdentifier/atom".applying(variant: "enabled") would also be possible or not. PRs welcome ;-)
I guess "section/buttonIdentifier/atom".applying(variant: "enabled", at: 2) would be a way of adding a variant to just one component (presuming just applying(variant:) is possible.
So far I've thought that using a string (eg .style("organism/element/buttonIdentifier")) would be the preferred way of doing things. @kerrmarin if it wasn't - how would you prefer it to work?
Actually, one of the biggest challenges for me to make this super awesome is how to handle designer to developer handoff - if you have any thoughts on that I'd be super grateful.
One thing that occurs to me (massive tangent warning, but might inform any exposure of Component) is that variants are actually used in a couple of different ways, as discussed in this article  https://www.cjcid.com/articles/ions-introduction/ - this makes me wonder whether organism/element[state:disabled;colorscheme:dark]/atom could be a thing in some future version, with just organism/element[disabled]/atom meaning element's 'state' (aka default) variant is disabled.

one other thought - conversations to this point have been that atoms wouldn't have variants, but now I think about it I'm not sure why. @cdemetriadis do you have any thoughts on this?

Atoms must be unique. Atoms can change depending on their context only.
--
Constantinos Demetriadis
Digital Designer
ohmylovely.com
On 4 Apr 2020, 19:31 +0300, Adam Hoyle<EMAIL_ADDRESS>wrote:

one other thought - conversations to this point have been that atoms wouldn't have variants, but now I think about it I'm not sure why. @cdemetriadis do you have any thoughts on this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

What's the reasoning behind atoms having to be unique?
On Sat, Apr 4, 2020 at 6:09 PM Constantinos Demetriadis <
<EMAIL_ADDRESS>wrote:

Atoms must be unique. Atoms can change depending on their context only.
--
Constantinos Demetriadis
Digital Designer
ohmylovely.com
On 4 Apr 2020, 19:31 +0300, Adam Hoyle<EMAIL_ADDRESS>wrote:

one other thought - conversations to this point have been that atoms
wouldn't have variants, but now I think about it I'm not sure why.
@cdemetriadis do you have any thoughts on this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/design-ops/stylable-swiftui/issues/1#issuecomment-609059517,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABNCIGPIKN2CLABBEE2Z6TRK5SVDANCNFSM4L4IWSJQ
.

ideally, we would want to be able to use either a String, a Component or a Stylistidentifier when we call style(_:).
We would also want a dsl to create variants of components i.e. Component("button").variant("selected") We'd also probably want helper methods on String to do "button".variant("selected")
i.e. These should all work.
style("button/title")
style("button[selected]/title")
style("Component("button"))
style("Component("button").variant("selected"))
style("button".variant("selected"))

FYI There's already a dsl for combining identifiers - you can do this.
let sectionIdentifier = StylistIdentifier("section")
let completeIdentifier = "button/title".within(sectionIdentifier)

We should also extend this to work for Components as well.
i.e.
let sectionIdentifier = StylistIdentifier("section")
let component = Component("button").variant("selected")
let completeIdentifier = "title".within(component).within(sectionIdentifier)

And, imho, while we don't want atoms to have variants, it's actually harder to prevent that than it is just to let them have the option variants and just not use that functionality :)

If the last statement is the case, sure. Let atoms have variants and we just don’t tell anyone ;)
The idea behind atoms is that they ARE unique in the the sense that we only have one title, one subtitle, one background etc. you can name them anyway you like, but you should use variants on the element or organism to change the atoms within. If that’s not the case then things get very confusing. Like, why should I use title instead if title[caps] and so forth. They lose context.
--
Constantinos Demetriadis
Digital Designer
ohmylovely.com
On 5 Apr 2020, 01:37 +0300, Sam Dean<EMAIL_ADDRESS>wrote:

ideally, we would want to be able to use either a String, a Component or a Stylistidentifier when we call style(_:).
We would also want a dsl to create variants of components i.e. Component("button").variant("selected") We'd also probably want helper methods on String to do "button".variant("selected")
i.e. These should all work.
style("button/title")
style("button[selected]/title")
style("Component("button"))
style("Component("button").variant("selected"))
style("button".variant("selected"))
FYI There's already a dsl for combining identifiers - you can do this.
let sectionIdentifier = StylistIdentifier("section")
let completeIdentifier = "button/title".within(sectionIdentifier)
We should also extend this to work for Components as well.
i.e.
let sectionIdentifier = StylistIdentifier("section")
let component = Component("button").variant("selected")
let completeIdentifier = "title".within(component).within(sectionIdentifier)
And, imho, while we don't want atoms to have variants, it's actually harder to prevent that than it is just to let them have the option variants and just not use that functionality :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

@kerrmarin I'm poking the code, and I've probably missed something, but is your whole problem fixed with this extension on String?
extension String {

    public func withVariant(_ variant: String?) -> StylistIdentifier {
        let component = StylistIdentifier.Component(value: self, state: variant)
        return StylistIdentifier(components: [component])
    }
}

with no need to make Component public at all?
This would allow things like:
"atom".within("primaryButton".withVariant("selected"))
which would remove your horrendous ternary.

I... guess? Although I'm not a huge fan of "polluting" the String API like that. It also leaves open the edge case of
"organism/section"withVariant("selected") // what does this return?

Yep, that's exactly the kind of reason why I shouldn't do that :) I'm trying to see if we can do this without making Component public, but I don't think there is anymore.

OK, the only way I can see to do this is to only allow Component when previously we have allowed full StylistIdentifiers i.e. this would no longer be allowed:
StylistGroup("component/element") {
    Text().style("title")
}

it would have to be replaced with this:
StylistGroup("component") {
  StylistGroup("element") {
    Text().style("title")
  }
}

Then, adding variants is a trivial second parameter to the StylistGroup methods i.e.
StylistGroup("element", variant: "selected) {

I wouldn't add this extra parameter to the style function, as we don't want to allow atoms to be given variants, and I've assumed that if you are calling style you're at the atom level. Though, there's nothing we can do to stop people just passing in an atom with a variant explicitly!
However, this is a breaking change - @kerrmarin you seem to be using this library most, would this affect anything you have written so far?

I would expect "section/organism".withVariant("selected") to return section[selected]/ organism[selected]
Personally I think it's nice we have the string functionality we have at the moment as it makes implementing very lightweight (at the cost of not being compiler safe)
Instead of breaking up StylistGroup, would a method like this be possible:
StylistGroup(StylistIdentifier("element", variant: "selected").within(StylistIdentifier("component")) {
    Text().style("title")
}

or even (for readability):
StylistGroup(StylistIdentifier("component").containing(StylistIdentifier("element", variant: "selected"))
Perhaps compiler safety could be a function of the generating step (eg if it generated an enum that is CustomStringConvertible)
.style(self.isEnabled ? .buttonIdentifierEnabled : .buttonIdentifierDisabled)

I can't see a use case for setting the variant at every point in a stylist identifier to the same value at the same call, so I strongly vote we don't add .withVariant() to StylistIdentifier.
Unfortunately, that makes your next idea harder (though not impossible).
We need to make StylistGroup accept either a StylistIdentifier, or a Component (or a String) - once we can do that then all these are possible.
StylistGroup("component/element")
StylistGroup("element".within("component"))
StylistGroup(Component("element", variant: "selected").within("component"))

(and, adding the containing vs. within method is trivial - one just calls the other swapping the arguments around :)

Though, do we agree that .style("atom") should only ever accept a Component, and never a full StylistIdentifier?

I'm not sure 😬
Perhaps it's a good idea to look at this from a distance and define how we think say a control which has states, would work with the Stylist.
So, given the example in this thread of a button called MyButton which has enabled and disabled states - how should that ideally be constructed with .style() and StylistGroups ?

But in UIKit a Button isn't an atom - the button's text would be the atom? i.e. the variant would be like button[selected]/title - so .style("title") wouldn't care about state.
Though, I think @kerrmarin is using this library in anger so he's probably the best placed to help here!

I'm closing this, it's been 4 months since any activity and I haven't encountered this problem since.


Re-use content of /vagrant-share/goshawk/ - looks like we have some code there

There is code in /vagrant-share/goshawk/ that looks like a contender for the original goldfinch. Re-use and merge it in.

Content now merged into goldfinch.


heimer: 3.6.2 -> 3.6.3

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/juzzlin/heimer/releases.
meta.description for heimer is: "Simple cross-platform mind map and note-taking tool written in Qt"
meta.homepage for heimer is: "https://github.com/juzzlin/Heimer"
meta.changelog for heimer is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.6.3 with grep in /nix/store/6mwv26qm04fi58k9v604szmxlbsdqpq4-heimer-3.6.3
found 3.6.3 in filename of file in /nix/store/6mwv26qm04fi58k9v604szmxlbsdqpq4-heimer-3.6.3

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
heimer

Instructions to test this update (click to expand)

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

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

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/6mwv26qm04fi58k9v604szmxlbsdqpq4-heimer-3.6.3
ls -la /nix/store/6mwv26qm04fi58k9v604szmxlbsdqpq4-heimer-3.6.3/bin

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

1 package built:

heimer

Maintainer pings
cc @dtzWill for testing.

@ofborg eval


fix(versions): update Activiti/activiti-cloud-notifications-graphql versions into master

UpdateBot pushed maven dependency: org.activiti.cloud.notifications.graphql:activiti-cloud-notifications-graphql-dependencies to: 7.1.168

UpdateBot commands:
updatebot push-version --kind maven org.activiti.cloud.notifications.graphql:activiti-cloud-notifications-graphql-dependencies 7.1.168


Disabled dates not updating when new dates are added.

Description
People need to select dates when a room is occupied. When these dates are added, I want to make them disabled in the picker so they don't get selected again. But the disabled dates don't seem to update once I add dates to the array.
Code sample
Hotel Date Picker
<HotelDatePicker
	:startDate="today"
	:endDate="new Date(new Date().getFullYear() + 1, 11, 31)"
	format="DD-MM-YYYY"
	ref="datePicker"
	:i18n="NL"
	:showYear="true"
	:disabledDates="disabledDates"
       @check-in-changed="handleCheckIn($event)"
       @check-out-changed="handleCheckOut($event)">
</HotelDatePicker>

I add dates to be disabled to the array like this:
setDisabledDates() {
	// Set empty array.
	this.disabledDates = []

	// Loop through all the dates.
	this.dates.forEach((date) => {
		let checkin = date.checkin.split("-")
		let checkout = date.checkout.split("-")

		// Get all dates between the checkin and checkout date.
		let itr = moment.twix(new Date(checkin[2] +"-"+ checkin[1] +"-"+ checkin[0]), new Date(checkout[2] +"-"+ checkout[1] +"-"+ checkout[0])).iterate("days")

		// Iterate through the dates.
		while(itr.hasNext()) {
			// Add each date to an array to be disabled.
			this.disabledDates.push(itr.next().format("YYYY-MM-DD"))
		}
	})
}

The setDisabledDates() function is triggered by a watcher.
Expected behavior: The newly added dates in the array to be disabled in the datepicker.
Actual behavior: They get disabled once I open and close it again, but not immediately when they get added to the array.
Datepicker Version
<EMAIL_ADDRESS>

Check the last v4 version

Check the last v4 version

Checked it, updated my component to V4.0.0-RC1 and all the styling of the date picker is gone... Got any idea how to fix this?

Check the last v4 version

Checked it, updated my component to V4.0.0-RC1 and all the styling of the date picker is gone... Got any idea how to fix this?

Checkout the readme file on how to use it.
You have to include the css/scss file as external file so you can change it if you need to.

Checkout the readme file on how to use it.
You have to include the css/scss file as external file so you can change it if you need to.

I've added the css file in the code and now I'm doing the exact same as before but the dates in the picker are still not being disabled when I push new data in the array. On a fresh page reload the dates are disabled but when I push them directly into the array it's not updating reactively.
Also I came across this:

I get this when I hover over today's date.

I've added the css file in the code and now I'm doing the exact same as before but the dates in the picker are still not being disabled when I push new data in the array. On a fresh page reload the dates are disabled but when I push them directly into the array it's not updating reactively.
Also I came across this:

I get this when I hover over today's date.

ok I'll reopen the case thanks for the feedback

ok I'll reopen the case thanks for the feedback

I see the problem now, you cannot use an arrow function to update an external variable. "this" in that context it is not what you expect, please use a regular anonymous function instead. Best!

I see the problem now, you cannot use an arrow function to update an external variable. "this" in that context it is not what you expect, please use a regular anonymous function instead. Best!

I see the problem now, you cannot use an arrow function to update an external variable. "this" in that context it is not what you expect, please use a regular anonymous function instead. Best!

No, this is not true. I can see in the Vue-inspector that the newly selected dates are in the attributes array so that shouldn't be a problem. I just did what you said tho and now I'm getting another 2 errors
This errors occurs when no dates are in the disabledDates array yet and I click on one of the dates to select it:

Another error occurs when 1 or more dates are in the disabledDates array and I hover over 1 of the dates that should be disabled:

I see the problem now, you cannot use an arrow function to update an external variable. "this" in that context it is not what you expect, please use a regular anonymous function instead. Best!

No, this is not true. I can see in the Vue-inspector that the newly selected dates are in the attributes array so that shouldn't be a problem. I just did what you said tho and now I'm getting another 2 errors
This errors occurs when no dates are in the disabledDates array yet and I click on one of the dates to select it:

Another error occurs when 1 or more dates are in the disabledDates array and I hover over 1 of the dates that should be disabled:

Those variables minimumRequiredPeriod and halfDayCheckOut are part of the i18n prop, the tooltip attribute.
Check the Readme file:
i18n Defaults:
i18n: {
  "night": "Night",
  "nights": "Nights",
  "week": "week",
  "weeks": "weeks",
  "day-names": ["Sun", "Mon", "Tue", "Wed", "Thur", "Fri", "Sat"],
  "check-in": "Check-in",
  "check-out": "Check-out",
  "month-names": [
      "January",
      "February",
      "March",
      "April",
      "May",
      "June",
      "July",
      "August",
      "September",
      "October",
      "November",
      "December",
  ],
  "tooltip": {
      "halfDayCheckIn": "Available CheckIn",
      "halfDayCheckOut": "Available CheckOut",
      "saturdayToSaturday": "Only Saturday to Saturday",
      "sundayToSunday": "Only Sunday to Sunday",
      "minimumRequiredPeriod": "%{minNightInPeriod} %{night} minimum.",
  },
}

Those variables minimumRequiredPeriod and halfDayCheckOut are part of the i18n prop, the tooltip attribute.
Check the Readme file:
i18n Defaults:
i18n: {
  "night": "Night",
  "nights": "Nights",
  "week": "week",
  "weeks": "weeks",
  "day-names": ["Sun", "Mon", "Tue", "Wed", "Thur", "Fri", "Sat"],
  "check-in": "Check-in",
  "check-out": "Check-out",
  "month-names": [
      "January",
      "February",
      "March",
      "April",
      "May",
      "June",
      "July",
      "August",
      "September",
      "October",
      "November",
      "December",
  ],
  "tooltip": {
      "halfDayCheckIn": "Available CheckIn",
      "halfDayCheckOut": "Available CheckOut",
      "saturdayToSaturday": "Only Saturday to Saturday",
      "sundayToSunday": "Only Sunday to Sunday",
      "minimumRequiredPeriod": "%{minNightInPeriod} %{night} minimum.",
  },
}

I'll try to update the doc page to enhance the experience.
But it seems an error in your programing (at least at this point, with little info).
If you may, please provide me with a complete working example, so I may reproduce the error that you are having and solve it. :D

I'll try to update the doc page to enhance the experience.
But it seems an error in your programing (at least at this point, with little info).
If you may, please provide me with a complete working example, so I may reproduce the error that you are having and solve it. :D

Check this article in Medium regarding the use of Vue on fiddle.net
Maybe you can create an example with the problem.

Check this article in Medium regarding the use of Vue on fiddle.net
Maybe you can create an example with the problem.

Use this as starting point https://jsfiddle.net/matup/ocavkjmu/

Use this as starting point https://jsfiddle.net/matup/ocavkjmu/

Use this as starting point https://jsfiddle.net/matup/ocavkjmu/

I've created a repesentation of what I'm trying to do in my application.
Check out: https://jsfiddle.net/a6f45jqn/65/

Use this as starting point https://jsfiddle.net/matup/ocavkjmu/

I've created a repesentation of what I'm trying to do in my application.
Check out: https://jsfiddle.net/a6f45jqn/65/

Ok, I'll check that out and get back to you.

Ok, I'll check that out and get back to you.

@iiRobin can you try with the last committed code instead of the released code?
I think you will find the solution made in the PR #266 integrated. I need that someone test the solution 😄.
🙏 please let me know if you can.

I got the code from the commit working on my project since I can see the new code in the node_modules folder. But it still doesn't seem to work for me.

No, no, if it is in the node_modules it is from a released version and this is in dev (main) version.

If it is in the node_modules it is from a released version and this is in dev (main) version so is not in npm package yet.
You must clone or download the code from here and then try it in a different environment (with npm run serve) and modifying the App.vue file probably.

If it is in the node_modules it is from a released version and this is in dev (main) version so is not in npm package yet.
You must clone or download the code from here and then try it in a different environment (with npm run serve) and modifying the App.vue file probably.

I downloaded the code and made a custom tab in your sandbox area with my code in it. The solution in the PR seems to be working!

@iiRobin this is now is resolved in v4.2, this new version has this fix and a CHANGELOG.md file


Improve tutorial.md's clarity and structure

This PR attempts to improve tutorial.md's clarity and structure.
Thank you for the PR! Contributors like you keep React awesome!
Please see the Contribution Guide for guidelines:
https://github.com/reactjs/reactjs.org/blob/master/CONTRIBUTING.md
If your PR references an existing issue, please add the issue number below:
#

These look like good improvements at first skim, will have to get some more eyes on it before merging though. I think the core team is pretty busy with the 16.3 release this week but hopefully someone can take a look soon.
Thanks!

This is great work, thank you. I think these edits make everything more explicit and I personally found it easier to follow.
There were some minor things I disagreed with (e.g. I think there are a few slightly whimsical sentences that I think are worth keeping in their current form). There were also some minor technical inaccuracies.
I tried to strike a balance and keep the tone of your edits in the ones I made on top, but please let me know if you have ideas on rephrasing on top. I admit some of my writing is a bit clumsy, but I hope you can see what I was trying to do.
Overall major props and thanks


Set query params

Hi Sunli, I am using poem::RequestBuilder to build requests for testing, how do I add query params to request?

Use the RequestBuilder::uri method, like the following:
builder.uri("/a=1&b=2")

Thanks, I didn't think about this simple solution!


proposal: Go 2: add tryfunc keyword to further reduce boilerplating for error handling

First of all, the try approach in #32437 is a huge improvement to what we have now. So, I'll be happy if that moved forward. The following proposal is slightly more radical.
Summary: Introduce tryfunc that removes all error handling boilerplate within a function.
Original:
func f1(in int) (out int, err error) {
  val, err := f2()
  if err != nil {
    return 0, err
  }
  if err := f3(); err != nil {
    return 0, err
  }
  if err := f4(); err != nil {
    return 0, fmt.Errorf("f4 failed: %v", err)
  }
  return f5()
}

New:
tryfunc f1(in int) int {
  val := f2()
  f3()
  if err := f4(); err != nil {
    return 0, fmt.Errorf("f4 failed: %v", err)
  }
  return f5()
}

A tryfunc implicitly adds an (unnamed?) error return parameter to the function.
An invocation f() that returns an error within a tryfunc will be equivalent to try(f()).
A function that does not return an error will be as if it was invoked without the try.
Just like the _, ok construct, one can explicitly request the error from a function, and that will automatically disable the error handling for that call.
A closure within a tryfunc can be a func or a tryfunc.

I see lots of :-1: reactions and no comments so I'll at least offer my reasoning for the :-1:. There's a lot of magic that happens in a tryfunc, and it takes away a lot of the explicit clarity go code usually provides. It's difficult to know at a glance which function calls within the function can cause errors and which can't. Plus, if the signature of one of those functions changes to add an error return, your tryfunc behavior will change silently. In your small example these problems aren't such a big deal, but more complex real-world code I would expect both these things to cause real bugs and real confusion.

I'll add a comment here about why there may be so many :-1: reactions, I recently added mine and I usually don't like to :-1: without a comment. Explicit error handling is important, if an error ever happens, you want to have some way of knowing which lines could have possibly caused it. For instance, take a look at this Java code:
public class Main {
    public static void main() {
        try {
            doStuff()
        } catch (Exception e) {
            System.out.println("An error occurred!")
        }
    }

    public static void doStuff() {
         callA()
         callB()
         // ....
         callZ()
    }
    // Implementations of callA, callB, etc...
}

If an error occurs, there is no way to figure out which calls could have even possibly thrown an error. Some of callA, callB, etc may throw errors, but not all of them.
The same thing in Go, with try:
import "fmt"

func main() {
    err := doStuff()
    if err != nil {
        fmt.Println("An error occurred!")
    }
}

func doStuff() error {
    callA()
    try(callB())
    callC()
    callD()
    // ...
    try(callZ())
}

// Implementations of callA, callB, etc...

This time, we can tell which functions might have thrown the error. It doesn't look quite as useful in my example, but in real-life applications it makes a huge difference to be able to know which functions may return an error.

I was just trying to think outside the func :). In any case, this is a radical proposal, and for all you know, it may not be worth it. But here's the premise:
The influence comes from the type of systems I mostly work with: distributed systems where you are called from a remote system, and have to eventually call out into an external service, which can fail. In these situations:

Almost every function must return an error.
Almost every invocation has to check and return the error up the stack, eventually to the remote caller.

If all functions in a program were tryfuncs, then it's not magic; It's understood that any function can return an error, and if so, it's guaranteed to be sent up the stack.
However, I can think of one really bad case: if someone changes a tryfunc to a func, then all errors will fall on the floor.

This proposal does not have much support.  Some cogent objections were expressed above, and we agree with them.  Therefore, this is a likely decline.  Leaving open for one month for further discussion.

There were no further comments.


Waiting For Restock - Walmart

Hi,
Items that are in stock at Walmart are not adding to cart for me. It keeps on throwing back waiting for restock and refreshing the page. Does anybody know how to fix this?
Thanks.

I have the same issue as you, I think the bot gets banned automatically whatever you do, so if it used to work, it doesn't work anymore, I'll take a deeper at it.

I'm also having this issue. I need the bot for tonight. Any chance we can get a fix for this today?

I was wondering too.. I tried it on something small I could use like deodorant.. getting a "waiting on restock".. have a feeling it doesn't work

Author hasn't updated this repo in 7+ months so not likely to get addressed any time soon.  There was a similar issue for the bestbuy script that was solved in bug 46, but code ref for bestbuy isn't found in the walmart script.
Bummer with PS5 launch happening today and all.  I actually had one in my cart the manual way after a few dozen manual spams... only to have the site crash and have it yanked out by the time I could get my cart reloaded.  FBS.


MF-253: Get translations working

The problem was with an old version of react-root-router.
https://issues.openmrs.org/browse/MF-253
https://issues.openmrs.org/browse/MF-189

Great find @brandones!

Nice spot to fix the translations @brandones! I'm just going through cleaning up some branches, is it okay to delete this one?

Yep, done!


npm install -g @graphprotocol/graph-cli fails with<EMAIL_ADDRESS>Permission denied (publickey)

I'm new to the graph and was just trying to follow from the quick start but running sudo npm install -g @graphprotocol/graph-cli is failing with the below errors:
$ sudo npm install -g @graphprotocol/graph-cli
npm ERR! code 128
npm ERR! command failed
npm ERR! command git ls-remote<EMAIL_ADDRESS>npm ERR! /bin/bash: /root/.bashrc: Permission denied
npm ERR<EMAIL_ADDRESS>Permission denied (publickey).
npm ERR! fatal: Could not read from remote repository.
npm ERR!
npm ERR! Please make sure you have the correct access rights
npm ERR! and the repository exists.

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2021-03-24T07_51_10_586Z-debug.log

node -v: v12.21.0
npm -v: 7.6.0
OS: Ubuntu 20.04.2 LTS
Relevant log bits:
1763 verbose stack Error: command failed
1763 verbose stack     at ChildProcess.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/@npmcli/promise-spawn/index.js:64:27)
1763 verbose stack     at ChildProcess.emit (events.js:314:20)
1763 verbose stack     at maybeClose (internal/child_process.js:1022:16)
1763 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:287:5)
1764 verbose cwd /home/watney/Documents/graphtry/graph-node/docker
1765 verbose Linux 5.4.0-67-generic
1766 verbose argv "/usr/bin/node" "/usr/local/bin/npm" "install" "-g" "@graphprotocol/graph-cli"
1767 verbose node v12.21.0
1768 verbose npm  v7.6.0
1769 error code 128
1770 error command failed
1771 error command git ls-remote<EMAIL_ADDRESS>1772 error /bin/bash: /root/.bashrc: Permission denied
1772 error<EMAIL_ADDRESS>Permission denied (publickey).
1772 error fatal: Could not read from remote repository.
1772 error
1772 error Please make sure you have the correct access rights
1772 error and the repository exists.
1773 verbose exit 128

Any help is appreciated

same issue, after adding my pub key to the git i'm getting a similar new one
npm ERR! code 128
npm ERR! An unknown git error occurred
npm ERR! command git --no-replace-objects clone -b feat/smaller<EMAIL_ADDRESS>/root/.npm/_cacache/tmp/git-cloneygDekp --recurse-submodules --depth=1
npm ERR! fatal: could not create leading directories of '/root/.npm/_cacache/tmp/git-cloneygDekp': Permission denied
npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2021-11-09T14_00_39_830Z-debug.log

Did you find a solutiion to this issue? I have sth similar

try yarn

I have also met, may I ask how to solve this problem?

Fixed the issue just had to upgrade to the latest version

Fixed the issue just had to upgrade to the latest version

Can you help me to solve the issue?
should I go for latest version of node?

@akshata112 I meant the latest version of graphprotocol...it kept installing a lower version until I checked the latest one and then installed while putting the version

I'd like to provide an additional example where I encountered the exact issue mentioned above. I received this error while executing npm install in this repository: https://github.com/georgeroman/erc20-subgraph.
Despite trying all the suggested solutions, what ultimately resolved the issue for me was removing the package-lock.json file and then running npm install again.

Update this to the latest version solved the problem for me
"dependencies": {
    "@graphprotocol/graph-cli": "0.89.0",
    "@graphprotocol/graph-ts": "0.32.0"
  },


update-report: Remove --local option [Linux]

Older versions of git do not support this option.

Thanks for the fixing.
Any chance to turn the safe_system to system. I don’t think a failure of the analysis/donations notice should prevent the rest of update procedures to be executed.

I prefer safe_system unless there's a particular failure mechanism that we expect and want to avoid. I'd prefer to hear about unexpected failures.

We could output warnings for the failures. The thing is that these safe_system may prevent more important codes to be executed such as homebrew core migration (functions like *_if_necessary), tap migration, etc.

You may if you like open a PR implementing this suggestion at Homebrew/brew. Linuxbrew/brew is currently being merged into Homebrew/brew, so I'm avoiding accepting PRs directly into Linuxbrew/brew.


Add variable declaration + definition shorthand

It's especially convenient when writing for statements.

Implemented in cb767eaa8fb4000acd269bba851df2d6cbc10968


Using Linode/lamp

Why not using this base image?
https://hub.docker.com/r/linode/lamp/
As this seem to be the official one?
I'm trying to figure out a config out of it, but I can't make it work:
Dockerfile:
FROM linode/lamp
RUN service apache2 start
RUN service mysql start

docker-compose.yml:
web:
  build: .
  ports:
    - "80:80"
  volumes:
    - .:/var/www/example.com/public_html/

Any idea what's wrong?

I did not use a base image because I wanted to use CentOS and was unable to find a proper one.
This is just my workaround. And I have no idea about others' images. Please contact the author of 'linode/lamp' image.


Cosmic Calculator

When https://github.com/NixOS/nixpkgs/issues/337554 will have a Nixos package, I can ping here if you're willing to add it to this flake.

Added in https://github.com/lilyinstarlight/nixos-cosmic/commit/091c4b039162c19068af6ca135e78bec1cb6ad80

Hello,
How can I benefit from this improvement?
I did
sudo nix flake update
sudo nixos-rebuild switch --show-trace --flake .#default

and rebooted my computer and can't find it. Should I add it to the list
  specialisation = {
    cosmic.configuration = {

      environment.systemPackages = with pkgs; [
        loupe
      ];

      system.nixos.tags = [ "Cosmic" ];
    }
  }

?

You add it to environment.systemPackages then rebuild as normal

it stop working for
cosmic-calculator
cosmic-forecast
cosmic-tweaks
Is there any reason?

They were renamed per upstream to cosmic-ext-calculator, cosmic-ext-forecast, and cosmic-ext-tweaks to differentiate official/unofficial cosmic apps

I should probably add helpful error messages when I rename packages though, oops


Improve error handling and general cleanup

General cleanup PR:

Better error message when there are no commits in the repo
Run Dialyzer with -Wunknown
Run Dialyzer in GitHub workflows
Fix a bunch of Dialyzer errors
Removed some unused code

Do not merge this until further notice.

This PR has been tested using Klarna's internal CI, and is ready for merging.


Chem | Elemental analysis: malformed data in dataset handling

Implement malformed data in dataset handling in Elemental analysis

Can you please provide the dataset to check and test on?
Or just steps to reproduce the issue?

smiles_malformed.csv
How to malform, an example:

Test_smiles_malformed.csv

Test_smiles_malformed.csv

Chem 1.6.7


Add a new test case for the disk is full

Fix #3062

I think there might be some misunderstanding here. We seem need use github action to create a environment that disk is full and test in a new crate.

@dqhl76 cc new changed

I think this PR is almost don, just need update the header file. You can update it when you got time @sunheyi6

I think this PR is almost don; just need to update the file header. You can update it when you have time @sunheyi6

I don't quite understand. Could you please explain it in more detail?

I don't quite understand. Could you please explain it in more detail?

We blocked here because https://github.com/apache/incubator-opendal/blob/88043915e16c3e0bc267edd7a10880457de08ecc/core/tests/behavior/file_write_full_disk.rs needs a license header like others
// Licensed to the Apache Software Foundation (ASF) under one....
....

Sorry for missing reminding. .github/workflows/fs_write_full_disk.yml also need license header


bnd node does not appear in TransModification (LigandModification)

Maybe I do not use enzyme_bnd_region and substrate_bnd_region correctly, but when I run the following script:
from kami.entities import (Gene, Region, Site, Residue, State, RegionActor, SiteActor)
from kami.interactions import (Binding, Unbinding, Modification, TransModification, AutoModification)
from kami.hierarchy import (KamiHierarchy)
from regraph import print_graph

inter = TransModification(
    enzyme=RegionActor(gene=Gene(uniprotid="P30530",
                                 hgnc_symbol="AXL"),
                       region=Region(name="Tyr_kinase",
                                     interproid="IPR020635",
                                     start=536, end=807)),
    substrate=SiteActor(gene=Gene(uniprotid="P06239",
                                  hgnc_symbol="LCK"),
                        site=Site(name="pY394",
                                  start=391, end=397)),
    target=Residue(aa="Y", loc=394,
                   state=State("phosphorylation", False)),
    value=True,
    rate=10,
    enzyme_bnd_region=Region(name="Tyr_kinase",
                              interproid="IPR020635",
                              start=536, end=807),
    substrate_bnd_site=Site(name='pY394',
                             start=391, end=397)
)

hierarchy = KamiHierarchy()
hierarchy.add_interaction(inter, anatomize=False)

print(inter)
print("printing nugget_1")
print_graph(hierarchy.graph['nugget_1'])

I get no bnd node in the nugget:
TransModification:
	Enzyme: region_Tyr_kinase_IPR020635_536_807_P30530
	Substrate: P06239_[]_site_pY394_391_397
	Mod target: Y394
	Value: True
	Enzyme binding region: region_Tyr_kinase_IPR020635_536_807
	Substrate binding site: site_pY394_391_397
	Rate: 10

printing nugget_1

Nodes:

P30530  :  {'uniprotid': {'P30530'}, 'hgnc_symbol': {'AXL'}}
P30530_region_Tyr_kinase_IPR020635_536_807  :  {'interproid': {'IPR020635'}, 'name': {'Tyr_kinase'}}
P06239  :  {'uniprotid': {'P06239'}, 'hgnc_symbol': {'LCK'}}
P06239_site_pY394_391_397  :  {'name': {'pY394'}}
mod  :  {'rate': {5}, 'value': {True}}
P06239_site_pY394_391_397_Y394  :  {'aa': {'Y'}, 'test': {True}}
P06239_site_pY394_391_397_Y394_phosphorylation  :  {'name': {'phosphorylation'}, 'test': {False}}

Edges:

P30530_region_Tyr_kinase_IPR020635_536_807 -> P30530  :  {'start': {536}, 'end': {807}}
P30530_region_Tyr_kinase_IPR020635_536_807 -> mod  :  {}
P06239_site_pY394_391_397 -> P06239  :  {'start': {391}, 'end': {397}}
mod -> P06239_site_pY394_391_397_Y394_phosphorylation  :  {}
P06239_site_pY394_391_397_Y394 -> P06239_site_pY394_391_397  :  {'loc': {394}}
P06239_site_pY394_391_397_Y394_phosphorylation -> P06239_site_pY394_391_397_Y394  :  {}

Hi!
Thanks for this issue, I found a bug, which was a very funny one. Now everything seems to work.
There is one thing to note in the design of TransModification  class though (which I also don't like, but still don't have any better solution). When enzyme_bnd_region/enzyme_bnd_site is specified (and the same for the substrate) in the nugget, distinct nodes are created, i.e. if you already have your RegionActor kinase that performs modification and then you also say that this is the enzyme binding region (the same object or kinase in the same range let's say) two distinct kinase nodes are created in the nugget: one for the actor of modification and another for the actor of binding. Of course, in the action graph they are identified as the same region, so I shouldn't be a problem for kappa-rule generation. But in case of the nugget graph itself it's still a bit weird. For example, now the result of your script is the following:
Nodes:
P30530  :  {'uniprotid': {'P30530'}, 'hgnc_symbol': {'AXL'}}
P30530_region_Tyr_kinase_IPR020635_536_807  :  {'interproid': {'IPR020635'}, 'name': {'Tyr_kinase'}}
P06239  :  {'uniprotid': {'P06239'}, 'hgnc_symbol': {'LCK'}}
P06239_site_pY394_391_397  :  {'name': {'pY394'}}
mod  :  {'rate': {10}, 'value': {True}}
P06239_site_pY394_391_397_Y394  :  {'aa': {'Y'}, 'test': {True}}
P06239_site_pY394_391_397_Y394_phosphorylation  :  {'name': {'phosphorylation'}, 'test': {False}}
P30530_region_Tyr_kinase_IPR020635_536_807_1  :  {'interproid': {'IPR020635'}, 'name': {'Tyr_kinase'}}
P06239_site_pY394_391_397_1  :  {'name': {'pY394'}}
is_bnd  :  {'type': {'be'}, 'test': {True}}
Edges:
P30530_region_Tyr_kinase_IPR020635_536_807 -> P30530  :  {'start': {536}, 'end': {807}}
P30530_region_Tyr_kinase_IPR020635_536_807 -> mod  :  {}
P06239_site_pY394_391_397 -> P06239  :  {'start': {391}, 'end': {397}}
mod -> P06239_site_pY394_391_397_Y394_phosphorylation  :  {}
P06239_site_pY394_391_397_Y394 -> P06239_site_pY394_391_397  :  {'loc': {394}}
P06239_site_pY394_391_397_Y394_phosphorylation -> P06239_site_pY394_391_397_Y394  :  {}
P30530_region_Tyr_kinase_IPR020635_536_807_1 -> P30530  :  {'start': {536}, 'end': {807}}
P30530_region_Tyr_kinase_IPR020635_536_807_1 -> is_bnd  :  {}
P06239_site_pY394_391_397_1 -> P06239  :  {'start': {391}, 'end': {397}}
P06239_site_pY394_391_397_1 -> is_bnd  :  {}

Thanks!
But effectively, two kinase regions is not what I intended. This problem seems to come back in several occasions. When we don't know if two nodes inside an interaction are actually the same. We really need a way to specify this. Could we add something like a "same" parameter to entities? It would be set to False by default, but when a user would set it to True, the algorithm would match the entity with any other entities within the interaction that are identified exactly in the same way (same "name", "start", "end", etc).

Yes, we should do something like this. But there is a lot of possible combinations of same entities, and this is the biggest problem, so our data structure can easily explode. Also, the usual strategy of our input/nugget generation pipeline is that the identification (so, the identification of things by "name", "start", "end") is done only relatively to the action graph and KAMI interaction objects define nuggets in some more syntactic way. In any case, we still need to think how can we represent this stuff. What I think would be more realistic is to have a flag to specify if in our RegionActor/SiteActor object bnd is performed by one of the components, so you would have something like this:
inter = TransModification(
    enzyme=RegionActor(gene=Gene(uniprotid="P30530",
                                 hgnc_symbol="AXL"),
                       region=Region(name="Tyr_kinase",
                                     interproid="IPR020635",
                                     start=536, end=807)),
    substrate=SiteActor(gene=Gene(uniprotid="P06239",
                                  hgnc_symbol="LCK"),
                        site=Site(name="pY394",
                                  start=391, end=397)),
    target=Residue(aa="Y", loc=394,
                   state=State("phosphorylation", False)),
    value=True,
    rate=10,
    enzyme_bnd_subactor="region",
    substrate_bnd_subactor="site",
    enzyme_bnd_site=Site(name="Site_of_Tyr_kinase_to_bind",
                              start=550, end=660),
)

Where we would have just two new arguments enzyme_bnd_subactor and substrate_bnd_subactor which can take values in gene, region, site, with the default one being gene. Then
enzyme_bnd_region/enzyme_bnd_site are interpreted as the one belonging to the  enzyme_bnd_subactor entity (the same for the substrate)

Yes, exactly! I added enzyme_bnd_site to illustrate that you can even specify some additional stuff, but now it is related to the entity which is enzyme_bnd_subactor. For, example if  enzyme_bnd_subactor is site you cannot specify enzyme_bnd_site and you get an error (as we do not allow nested sites).


Package Name wild card

I'd like to be able to Promote more than one package at a time using wild cards  such as FooPackage* or *Package.
I'm also open to other approaches to solving this if there is another way.

Will not build this in the task


[zh] Incorrect translations or incorrect formats on kubeadm

This is a Bug Report

Problem:
I read through the document of kubeadm and found some problem:

incorrect translations
Incorrect spelling of words
incorrect formatting

Proposed Solution:
Although it does not affect reading, it will be better after modification.
Page to Update:
https://kubernetes.io/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/
https://kubernetes.io/zh/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/
https://kubernetes.io/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/

Closing this issue since fixed.
/close


Improvements on pdf generation

Originally, generated cards have blurry qrcode. After a lot of adjustments in rsvg-convert, no improvements was gain. So we change the lib for generating the pdf with svglib
Results:
rsvg-convert

svglib

Looking at the image, svglib also results in an antialiased image which to me looks like it has a halo around it.
I am looking for a result like this:

Hi @kneckinator , I will close this PR as this is not needed for now.


[REVIEW ONLY] User Defined Variables, Phase I (API, FBJS only)

What's New?

Update CeleryScript in preparation for user defined variables.

Coverage remained the same at 80.277% when pulling a3d350ce9f5e6b38ae41475a8d03100c473d4f87 on RickCarlino:variables into 59a8db4ffd47e950721ab94a7b5360f39198f01c on FarmBot:staging.

Coverage increased (+0.002%) to 80.279% when pulling 7cd6cdc10ee7ea1c566f0e2a74e276b698038d3f on RickCarlino:variables into 59a8db4ffd47e950721ab94a7b5360f39198f01c on FarmBot:staging.

Coverage decreased (-0.01%) to 80.263% when pulling 68b7e511eb9d62ddd204502e032a434963bb71a0 on RickCarlino:variables into 59a8db4ffd47e950721ab94a7b5360f39198f01c on FarmBot:staging.


Code style improvements

Adjusts StyleCop configuration to better match C# coding conventions and follows code style accordingly.
Adds enums for EngineState, DatabaseState, TransactionAsyncState, TransactionMode with useful methods and updates the model to return them instead of strings.
Created solution folders structure.
Simplifies code using such language capabilities as null propagation, string interpolation, LINQ, etc.
Fixes possible NullReference warnings.

@bradlo What do you think about the enums? I argued for having them a long time ago but others were against them. The idea is that if we introduce a new engine size, we wouldn't have to release a new SDK (and users have to upgrade) to take advantage of it. Perhaps engine size is different than states though.

I really appreciate the PR, but in the future, could submit each of the bullets as separate PRs, especially StyleCop changes? PRs with 116 file changes are effectively impossible to review.

against them

@larf311 @bradlo on the other hand, having enums for that feels more natural, as we can document each item, possibly with some more details if needed (like what's the cpu/mem power, cost etc).
In addition, if we're talking about backward compatibility, we would need to be able to support XS-XL sizes in the backend anyway if we decide to rename them etc, right? If talking about additions, it should be fine to update some of the major versions of the SDK we support (and which are in use) with a patch adding more engines. The users will have to update their code anyway?

I really appreciate the PR, but in the future, could you submit each of the bullets as separate PRs, especially StyleCop changes? PRs with 116 file changes are effectively impossible to review.

It makes perfect sense, apologies for having this this big, as the amount of stylecop changes got rather huge.

enums are language dependent, in most modern languages, enums are the right thing to do. however, i added them to the python SDK based on feedback, and regret it because it just makes the code more awkward given the need to explicitly convert in too many cases. i think the C# deltas in the PR look great.


Orbital trade ship bug

Hi! Loving this mod so far, thanks for your hard work! I've encountered a bug with the orbital trade ships.
Everytime a ship comes by, they appear to:

not having money at all
not having any items

I'm using Rimworld 1.1.2618 and your latest mod release

Hi!
I tested this and I cannot reproduce it. Since this mod only triggers the event it should not affect what the trader has to sell, it only makes the event trigger.
Can you reproduce it with only this mod loaded? Do the traders have money if you trigger them using dev-tools?


all: Fix CORS handler usage

Avoid a double WriteHeader call by only calling the next handler when the request is not an OPTIONS request.
Closes #2229

LGTM

LGTM


Some issues with your updates?!

Hello again,
I was about to test the fix of a bug and saw, that the version here on git should be 2.0.1 (as mentioned in the readme). On NPM the readme still shows 2.0.0, but NPM itself has version 2.0.1. But the real problem seems to be, that the dist folder was not updated after your changes. So it looks like you've incremented the version, but did no rebuild.
There is even no release for 2.0.1.

Hey @eisbehr-, thanks for the heads up.
2.0.0 did not ship the dist folder (cf. issue https://github.com/BobKnothe/autoNumeric/issues/373), 2.0.1 fixed it by including it for the publishing to npmjs, which means if you can see a dist folder, it means it has been updated to 2.0.1.
The fact that npmjs shows the readme which mention 2.0.0 is because I published 2.0.1 while having forgot to update the readme, my bad ;P
I think to prevent this kind of incoherent information, I'll just scrap any version number reference from the readme, and let the npm badge show the latest master version.
You are however refering to changes that would not have been present in the dist files, could you please be more specific? It's possible we missed something there.

I was about to check the changes from #371 and noticed this. When I compare the files in release 2.0.0 and the current dist folder, the file contents are exactly the same. So I think there are changes missing. Even if I look in the histroy of the file, there was no changes 6 days ago, but you fixed the bug just 3 days ago.
And there seems still to be another problem. The library is even not updated on cdnjs and jsdeliver.
http://www.jsdelivr.com/projects/autonumeric (lastest: 2.0.0)
https://cdnjs.com/libraries/autonumeric (lastest: 1.9.46)

The jsdelivr bot update the library automatically since I first committed to their repository.
I noticed it usually takes a few hours (even perhaps a day) to crawl this repo and update their cdn. It should go up soon.
About cdnjs, you are the first one to made us aware about it not being updated.
We'll add this cdn to our list too, thanks :)
I'm about to push a fix for #367, so everything should be ok then.

Since issue #367 is solved, and apparently so is issue #371, it means this one is solved too!
If that's not the case, feel free to reopen it.

I'm pretty sure that jsDelivr has a problem, because it didn't noticed any changes the last days. 😉  I use jsDelivr by myself on other projects and normally it takes 0,5-3h to update.

There, it's up-to-date with v2.0.7.
Note to self; the jsdelivr bot only parse the github releases, not the npm published version.

Note to self; the jsdelivr bot only parse the github releases, not the npm published version.

You can draft a release or just tag the version, both will be noticed afaik. Glad it worked now!

Good to know, thanks


PERF: unsharpenedImage iterator in N4Bias...Filter is now "WithIndex"

Declared the unsharpenedImage iterator within N4BiasFieldCorrectionImageFilter::SharpenImage as ImageRegionConstIteratorWithIndex, instead of ImageRegionConstIterator.
Observed a significant performance improvement: 10% to 30% reduction of runtime duration on filter->Update().

Ops, wrong location! This is the right one: https://github.com/InsightSoftwareConsortium/ITK/pull/172


Update README.md

I try to use this build definition with agent queue Hosted VS2017, but not works
The correct agent queue is Hosted

@lsprado,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

Leave a comment


Upgrade kotlinx-metadata

This PR upgrade the kotlinx-metadata used by the Kotlin DSL to the latest kotlinx-metadata in the Kotlin 1.9 family: 0.8.0.
The kotlinx-metadata version used in our build is upgraded to the latest in the 0.6.x family but we should make the effort to upgrade to 0.8.0 eventually.
Reviewing cheatsheet
Before merging the PR, comments starting with

❌ ❓must be fixed
🤔 💅 should be fixed
💭 may be fixed
🎉 celebrate happy things

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle test AST

I've triggered the following builds for you. Click here to see all build failures.

AllSmokeTestsPullRequestFeedback build

@bot-gradle test AST

Perhaps there's an issue with KGP or KAPT that causes the Gradle classpath to leak into the annotation processor classpath?

Related to #30261


Add "ADLINK IPi-SMARC x86/ARM platform"

Add the sources of ADLINK IPI-SMARC x86/ARM platform

Add "ADLINK IPi-SMARC x86/ARM platform"


kata-deploy: action: reference kata-containers instead of fork

Should have been fixed before merge. Reference upstream instead of fork
of Kata.
Fixes #789
Signed-off-by: Eric Ernst<EMAIL_ADDRESS>

/test

/AzurePipelines run


Request feature: add ScanIndel indelcallers

Sorry to harass with more questions...
As I understand the documentation, mutect can be combined with one indelcaller (using the indelcaller setting) but only one. Might it, instead, somehow be possible to run all available indelcallers (scalpel, pindel, and sid) and combine the results in the same fashion as the ensemble method? To be able to utilize more callers.
Also, I saw a new tool for indel detection that at least the authors claim to be superior: ScanIndel (https://genomemedicine.biomedcentral.com/articles/10.1186/s13073-015-0251-2). This is a hybrid method that utilizes a number of other tools for calling (https://github.com/cauyrd/ScanIndel). Would it be of interest to integrate this into bcbio? If so, perhaps I could give it a go? (and practice my python).
-P

Par;
That's right, you can only use a single indelcaller to supplement the MuTect calls. We don't have an approach to run multiple callers and do an ensemble method. Practically, we didn't find scalpel or pindel performing well relative to other full featured callers like VarDict:
http://bcb.io/2016/04/04/vardict-filtering/
So aren't planning to expend a lot more effort into this approach. We have spent a lot of time trying to tune scalpel (http://imgur.com/a/7Dzd3) without much success.
ScanIndel looks great from the paper validation and we'd certainly accept a contribution implementing it. Practically it looks like it's going to be a lot of effort as the requirements are non-trivial: inchworm/trinity + a blat client and server (which is academic only licensed creating a whole additional challenge). It might be worth evaluating outside of bcbio first to determine if it's finding indels you're missing via other methods.
Hope this helps.

Okay, thanks. I saw that Rendong Yang, who develops ScanIndel, forked bcbio. Maybe he is working on something. I just sent him an email to enquire.
cheers

Thanks, this request is super old now and there hasn't been other interest in integration it, so closing it out for now. Please re-open if this is actually something folks are still interested in.


Not able to use teleporter with configuration file

OrientDB Version: 2.2.31 Community Edition
Java Version: latest
OS: Windoes
Expected behavior
Be able to load data from Oracle database with conf file. Please not that i am able to load data without conf file. It is only when adding conf file i get the error.
Actual behavior
There seems to be no way to include a conf file to the command line:
C:\Users\togjj\Desktop\orientdb-community-importers-2.2.31\bin>oteleporter -jdriver oracle -jurl jdbc:oracle:thin:@:1521: -juser  -jpasswd  -ourl plocal:$ORIENTDB_HOME\databases\teleporter_test3 -v 1 -conf $ORIENTDB_HOME\migration_conf.json
Exception in thread "main" java.lang.NullPointerException
at com.orientechnologies.teleporter.main.OTeleporter.execute(OTeleporter.java:254)
at com.orientechnologies.teleporter.main.OTeleporter.main(OTeleporter.java:219)
This is the conf file:
{
"edges": [{
"har_sniklass": {
"mapping": { "fromTable": "BCKP_H_ORGANISATION",
"fromColumns": ["H_ORGANISATION_PK"],
"toTable": "BCKP_H_SNI",
"toColumns": ["H_SNI_PK"],
"joinTable": {
"tableName":"BCKP_L_ORG_SNI_RELATION",
"fromColumns": ["H_SNI_PK"], 							"toColumns": ["H_SNI_FK"]
},
"direction": "direct" }, 								"properties": {
"KALLA_SKAPAD_AV": {
"type": "STRING",
"mandatory": true,
"readOnly": false,
"notNull": true
}
}
}
}]
}
Steps to reproduce

Add conf file to the command and execute

You get the above error immediately

#7821 - same problem reported


Autocomplete take the selected element from the renderInput and switch to the InputProps of the textfield

Hi @oliviertassinari ,
I am trying to use the new version of Autocomplete, I would like to make sure that when an element is selected from the drop-down menu, I would like to modify the input input of the textfield so as to be able to put the chip with the selected text in it.
Is there a way to know in the autocomplete renderInput the selected item?
Then pass this information to the textfield's InputProps.
Codesandbox
What I wish I could do in the end is such a thing:
react-textinput-chip

@Angelk90 I can think of 2 options.

You could use the multi-select mode while allowing the presence of a single value at the same time.
You can use the startAdornment prop to render something else and control the input value to empty the field once a value is selected

@oliviertassinari :

How do you set the multiple selection the possibility of having only one value?
I'm not sure I understood correctly, but how do you know when an item has been selected?


Choose to return raw dicts

Would it be possible to make every function return data as a raw dict? For example, I would like to check Reddit data, and dealing with raw dicts are sometimes easier than dealing with objects. I propose a switch to every function, that can get passed down to the request calls, that skips the objector. This will be very tough to handle, and may require rewriting of several functions to return directly.
I propose this to go in PRAW 7.0.0

I second this. Going through the objects is exhausting, and it's much easier just to iterate through the JSON.


PubSub - Infinite KeepAlive

Hi,
I'm building on top of the PubSub example. I'm using the default keep alive:
        mqttManager.setKeepAlive(10);
When I was disconnected for more than an hour (and then later reconnected), the client no longer tries to reconnect. How can I go about having it attempt reconnecting/ping to the MQTT Client infinitesimal every 10sec?

Hi @lauleehong,
The sample you are using only retries up to the default maximum number of retries (set here). After that a manual reconnect is required. If you want to attempt a larger number or infinite retries, you can call the setMaxAutoReconnectAttepts API. A value of -1 indicates infinite reconnect.
Please let us know if you have any further questions. Thank you for using AWS IoT.
Rahul

Please re-open if there are still issues


Development

Pull Request Test Coverage Report for Build 80

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 78.646%

Totals

Change from base Build 77:
0.0%

Covered Lines:
825

Relevant Lines:
1049

💛  - Coveralls


Implement resources for the component model

This is intended to be a bit of a tracking issue and/or brain-dump about implementing resources in the component model. The work here spans a number of repositories and isn't exclusively limited to just the Wasmtime repository, but I'm choosing here as probably one of the higher-visibility locations to write all this down.
Settle on a spec
Currently as-is in the component-model repository two resource handles of own and borrow are specified but this may change with recent thinking. Settling on this will be necessary for at least completing this work, but isn't necessarily required before any other work goes forward. This will impact the runtime implementation in Wasmtime but likely won't radically change the overall shape, mostly details instead of what each piece is precisely doing.
Implement resources in wasm-tools
Resources have had their initial implementation landed in https://github.com/bytecodealliance/wasm-tools/pull/966 for a number of crates, but not all of them. This implementation will need to be updated depending on how the above spec discussion settles, and the remaining work here is:

[x] Integrate resources into wit-parser. This involves parsing syntax, creating AST structures, tracking types-of-handles, etc.
[x] Settle on the "ABI" pseudo-language used in wit-parser to use for resources. This is the abi module of wit-parser which is used by most WIT code generators, and notably the Instruction enum will need to grow variants of what to do for resources. This will be heavily influenced by the spec above.
[x] Implement Wasm<->WIT translation for resources. This is part of the wit-component crate and dictates how WIT documents are encoded into WASM. This will require defining resource types appropriately and then referring to them via handles appropriately. This is, hopefully, not a large extension beyond what's already implemented.
[x] Integrate resources into wit-smith to fuzz the previous implementation of Wasm<->WIT translation. This should help stress this piece further to ensure all the various corner cases are covered.
[x] Integrate resources into wasm-tools component new. Like the previous point this lives in the wit-component crate and this is a bigger lift but is the location to define how core wasm actually interacts with resources. This will need to grow support for intrinsics such as new/drop for each resource type and hook those up to canon ... definitions which will be declared in the component. This is effectively defining the standard of "what actually does a guest generator do to integrate with resources".
[ ] Integrate resources into wasm-tools compose. This is the wasm-compose crate and I left panicking stubs largely during the initial implementation. It's unclear how difficult this will be because this requires a form of subtype checking which is not trivial to do with resources. This probably needs to reuse more of the validation machinery in wasmparser but that's just a vague idea I have at this time.

Much of this work on wasm-tools is sequentialized and can't be parallelized all that well as each step likely relies on the prior.
Implement resources in Wasmtime
Naturally a big part of resources is the actual runtime impelmentation in Wasmtime! The precise steps involved here are more fuzzy to me than the ones above for wasm-tools, but the rough idea I have at this time is:

[ ] Update translation to record and process resources. Right now there are todo!() or unimplemented!() statements for when resources are encountered during parsing, and effectively those need to be filled out. This will require tracking resources per-component and generally figuring out things such as how many resource tables are required by a component. Precisely how this all works depends on the spec details above but also just figuring out how to track and implement this all in Wasmtime, which I'm less certain about.
[ ] Determine how to best implement the new resource-related canon functions. More-or-less this means expanding the CoreDef enum and propagating changes outwards from there. I'm thinking there'd be new variants like ResourceNew and such.
[ ] Determine how the embedding layer will represent and track resources. For example when a component imports a resource what's actually inserted into a Linker? Additionally sketch out the runtime representation of a resource so the embedder can create resources and pass them to a component. Additionally what it might look like to receive a resource defined in a component. For example the host must be able to create a resource and pass it to a component. Conversely for all resources the host must be able to destroy the resource and possibly run its destructor.

Unfortunately I feel like at this point I've sort of gone from "draw a circle" to "finish the owl" and I'm not precisely sure what other intermediate steps there are to implement resources in Wasmtime, despite there obviously being quite a few more steps. One thing I can say though is that the Wasmtime work can, in theory, progress in parallel to the remaining wasm-tools work. Towards the "end" when the bindgen! macro gets involved they'll need to sync back up but it should be possible to implement everything related to resources in Wasmtime independent of WIT and the integration there.

I plan on starting on the wasm-tools based work in the near future and moving outwards from there, but I wanted to be sure to write down my thoughts on all this in the meantime. I can also try to keep this updated over time with more thinking.

As a bit of an update on this the main bulk of the work for wasm-tools is posted at https://github.com/bytecodealliance/wasm-tools/pull/1084 and the main missing piece in wasm-tools is wasm-compose. I've since been working on an implementation in Wasmtime and continue to be hard at work on that. Progress is apace but currently no ETA. I've got some stuff working but still need to figure out things like destructors, borrow, fused adapters, and the specifics of the embedder API.

The initial wasmtime work should now be complete at https://github.com/bytecodealliance/wasmtime/pull/6691 (pending review of course). I plan on closing this issue when that's merged and deferring further work to the linked issues from that PR.


Not able to replicate the results

Hi,
we are trying to replicate the results presented in Table 1 of the paper.  We leave everything as is and pretrain the model with the following command: python pretrain.py name=amp_b8192_cb_o4_final arch=crammed-bert-fff train=bert-o4  data=pile-readymade It trains for 1 day on a single Nvidia A100
Then we evaluate it with: python eval.py eval=GLUE_sane name=amp_b8192_cb_o4_final eval.checkpoint=latest impl.microbatch_size=16 impl.shuffle_in_dataloader=True impl.compile_torch=False
We get average GLUE score of 74%.
We also tried to train a trasnformer with the FFF layer on TinyStories dataset. We take the original model and just replace the FF layers with FFF layers. We achieve the same perplexity as a model with the MLPs completely removed. The perplexity is worse than the one achieved by the original model with FF layers.

Hi,
Thanks for getting in touch.
"Replicate" is a bit of a stretch of the term here, since you differ on crucial parameters, including the hardware used (training is wallclock-capped) and CoLA finetuning parameters (note the adjustment made to the default as per section 2.3.1 of the paper).

How many tokens and epochs does your training consume? A100s in the crammedBERT setup are powerful enough to train on more than one epoch within a day, thus leading to overfitting, since crammedBERT has dropout disabled by default. What is your training token throughput?
What is your GLUE performance without CoLA? Did you include WNLI?

Here is a short list of things to work through to help you identify the problem, given in a particular order:

Download the weights from HF and finetune as per section 2.3. Are you getting results comparable to the ones in the paper? If yes, proceed.
Train a crammedBERT baseline on 3090/A6000. Are you getting results comparable to those of the original crammedBERT paper?
Train an UltraFastBERT baseline with branching depth set to 0. This is fully equivalent to crammedBERT since no activations are masked out. Are you getting results comparable to 3.?
Train UltraFastBERTs with increasing depths as in Table 1 of the UFB paper. Do your results align?

Could you please give me instructions how to evaluate the checkpoint from HF? We tried to use the command for evaluation with the HF checkpoint mentioned in the training folder README but it does not work python eval.py eval=rte name=bert-finetuning eval.checkpoint=hf://pbelcak/UltraFastBERT-1x11-long impl.shuffle_in_dataloader=True impl.compile_torch=False
It throws the following error:
File "/raid/data/Hyner_Petr/replicate_ffft/UltraFastBERT/training/eval.py", line 33, in main_downstream_process
    model = cramming.construct_model(cfg_arch, tokenizer.vocab_size, downstream_classes=task["num_classes"])
  File "/raid/data/Hyner_Petr/replicate_ffft/UltraFastBERT/training/cramming/architectures/construction.py", line 41, in construct_model
    raise ValueError(f"Invalid model architecture {cfg_arch.architectures} given. Error: {e}")
ValueError: Invalid model architecture ['ScriptableLMForPreTraining'] given. Error: empty() received an invalid combination of arguments - got (tuple, dtype=NoneType, device=NoneType), but expected one of:
* (tuple of ints size, *, tuple of names names, torch.memory_format memory_format, torch.dtype dtype, torch.layout layout, torch.device device, bool pin_memory, bool requires_grad)
* (tuple of ints size, *, torch.memory_format memory_format, Tensor out, torch.dtype dtype, torch.layout layout, torch.device device, bool pin_memory, bool requires_grad)
*

I also checked the number of steps for training, it was 552000, not even 1 whole epoch.

The HF interface seems to be broken; you might want to debug it through that try-except in construct.py into huggingface_interface.py to see which tensor is not being initialized, and perhaps raise an issue here if it indeed just cramming-related.
Nevertheless, the HF interface is not needed. You can just download the weights (as mentioned in 1. above) and run
python eval.py eval=EVAL_CONFIG name=NAME eval.checkpoint=CKPT_ABS_PATH OTHER_SETTINGS

cramming.utils.find_pretrained_checkpoint will retrieve the checkpoint for you and cramming.construct_model will then avoid the HF interface.
Note that this codebase does not modify the cramming codebase beyond altering the implementation of the feedforward layer, so when struggling with the CLI, it is always best to first try to do it for cramming.

I also checked the number of steps for training, it was 552000, not even 1 whole epoch.

This does not say much, since cramming utilizes batch-size scheduling. If you use wandb for logging, what do tok/sec and Charts/tokens say? I found an older run that reached 14e9 tokens in roughly 21 hours on A100 80GB. That one was definitely overfitting.

Hi @pbelcak! I was also trying to evaluate the model to reproduce results from the paper. I've ran
python eval.py eval=rte name=bert-finetuning eval.checkpoint=hf://pbelcak/UltraFastBERT-1x11-long impl.shuffle_in_dataloader=True impl.compile_torch=False eval.batch_size=128
for RTE benchmark on model from HF unchanged, but got average 0.55 accuracy after 5 epochs. Maybe I'm using wrong batch size, though I didn't find it in the paper, what batch size did you use?

Hi @pbelcak! I was also trying to evaluate the model to reproduce results from the paper. I've ran python eval.py eval=rte name=bert-finetuning eval.checkpoint=hf://pbelcak/UltraFastBERT-1x11-long impl.shuffle_in_dataloader=True impl.compile_torch=False eval.batch_size=128 for RTE benchmark on model from HF unchanged, but got average 0.55 accuracy after 5 epochs. Maybe I'm using wrong batch size, though I didn't find it in the paper, what batch size did you use?

Oh dear, 128? Please remember that most of the GLUE tasks have relatively small datasets and that comparatively small learning rates are to be used for pre-training. 128 is 4x the batch size of the original BERT and 8x the batch size of crammedBERT. It also means 4x/8x fewer update steps in 5 epochs, respectively.
As repeatedly stressed above and in the preprint, the training and evaluation are based on that of crammedBERT. See the first paragraph of section 5 of the paper  for specific details.
The BERTology of GLUE evaluation dictates that you should take a median of 5 runs as the result; the individual results for RTE should be between 58.8 and 60.3. Also, when using the HF model directly, make sure that the weights are loaded into an instance of the crammed-bert-fff architecture, and not of the original crammed-bert. The latter can happen if you installed cramming in your environment before.

Thank you very much for the detailed response! I'll explore the cramming paper in more details.
I'm still learning, so batch size is not that intuitive to me and I might have overlooked such important details😅 Thanks!

Closing as stale. @Jan21 feel free to reopen if you encounter further issues.


Feature request: Option to reset selected item(s) from js

There is
wheel.selectedNavItemIndex = null; whenever you init a menu to have no item selected. Once an item is selected I don't see any way to unselect items again, besides navigateWheel(-1) which does unselect everything but also throws an exception for the navAngle.
Can we get a method for unselecting items?

I went through the wheelnav.js and found a solution. Loop through the items of the wheel you wish to reset, and set each navItem.selected = false and invoke refreshWheel() afterwards. This works perfectly.


empty iterators

Describe the bug
profile.get_followers(), profile.get_followees(), profile.get_posts all return empty iterators.
profile.followers has the correct count.
To Reproduce
fh1 = prfoll1 = next(fh1)
foll1 = next(fh1)

Expected behavior
should return iterators with data
Error messages and tracebacks
StopIteration                             Traceback (most recent call last)
Input In [24], in
----> 1 next(fh1)
StopIteration:
Instaloader version
4.9.2
Additional context
everything was fine yesterday. no code changes.

the issue was fixed by logging out and logging in again.
i guess there should be some time of error message when this happens.


Zookeeper gem fails to connect to valid zookeeper quorum

This problem has catastrophic effects on HDFS-HA when one of the namenodes are down, as chef will bounce the active one.
def znode_exists?(znode_path, zk_host="localhost:2181")
  require 'rubygems'
  require 'zookeeper'
  znode_found = false
  begin
    zk = Zookeeper.new(zk_host)
    if !zk.connected?
      raise "znode_exists : Unable to connect to zookeeper quorum #{zk_host}"
    end
    r = zk.get(:path => znode_path)
    if r[:rc] == 0
      znode_found = true
    end
  rescue Exception => e
    puts e.message
  ensure
    if !zk.nil?
      zk.close unless zk.closed?
    end
  end
  return znode_found
end

This code fails on zk.connected? on a 3 node quorum where one of the node is unreachable

chef >   zks = node[:bcpc][:hadoop][:zookeeper][:servers].map{|zkh| "#{zkh[:hostname]}:#{node[:bcpc][:hadoop][:zookeeper][:port]}"}.join(",")
chef > znode_exists?("/hadoop-ha/#{node.chef_environment}", zks)
=> true
chef > znode_exists?("/hadoop-ha/#{node.chef_environment}", zks)
=> true
chef > znode_exists?("/hadoop-ha/#{node.chef_environment}", zks)
=> true
chef > znode_exists?("/hadoop-ha/#{node.chef_environment}", zks)
=> true
chef > znode_exists?("/hadoop-ha/#{node.chef_environment}", zks)
=> true
chef > znode_exists?("/hadoop-ha/#{node.chef_environment}", zks)
=> true
chef > znode_exists?("/hadoop-ha/#{node.chef_environment}", zks)
znode_exists : Unable to connect to zookeeper quorum
=> false
chef > znode_exists?("/hadoop-ha/#{node.chef_environment}", zks)
=> true
chef > znode_exists?("/hadoop-ha/#{node.chef_environment}", zks)
=> true
chef > znode_exists?("/hadoop-ha/#{node.chef_environment}", zks)
=> true
chef > znode_exists?("/hadoop-ha/#{node.chef_environment}", zks)
=> true
chef > znode_exists?("/hadoop-ha/#{node.chef_environment}", zks)
=> true

chef > z = Zookeeper.new(zks).connected?
=> true
chef > z = Zookeeper.new(zks).connected?
=> true
chef > z = Zookeeper.new(zks).connected?
=> true
chef > z = Zookeeper.new(zks).connected?
=> true
chef > z = Zookeeper.new(zks).connected?
=> true
chef > z = Zookeeper.new(zks).connected?
=> false
chef > z = Zookeeper.new(zks).connected?
=> false
chef > z = Zookeeper.new(zks).connected?
=> true
chef >

Was able to reproduce with simple zookeper-client command. It looks like zookeeper-client chooses one node at random for kerberos authentication and does not retry on failiure. This is a potential critical bug. I'll investigate more tomorrow


'term:skip-covered' should be used in preference to 'term'

In reporting to the terminal, the pertinent information is the missing coverage - I don't need to see a long list of files with 100% coverage.  I still want that in the other reports, because e.g. my CI pipeline might set requirements on overall coverage - so I can't just put 'skip_covered = true' in my setup.cfg.

Can you just add skip_covered=true to your setup.cfg?

Unfortunately not - I tried that, but it applies to all reports, not just the one output to the terminal.  That's what I was alluding to in my original comment here.
I also tried re-setting it to false specifically in the [coverage:html] et al sections, but unfortunately it's apparently not supported in those sections (evidently they're not logical 'subclasses' of the 'report' section).

Ah, sorry; you wrote skip_missing so that threw me off.
FWIW, I like the 100% coverage output.  Unfortunately, I'm not sure this is supported by coverage.

Whoops!  Sorry for the confusion.  Properties - they're all the same, right? ;)

It is supported - AFAICT that's why 'term:missing' exists, as a special-case way to override skip_covered only for terminal output.  It unfortunately appears to be the only way to do that, and I don't see any way to otherwise modify what the coverage pygradle plugin passes to pytest w.r.t. these parameters.

FYI, this change would have to be made in PyCoverageTask.groovy:
    public void preExecution() {
        // using subArgs as these must be added after py.test
        subArgs(
            '--cov',
            project.file(component.srcDir).getAbsolutePath(),
            '--cov-report=xml',
            '--cov-report=html',
            '--cov-report=term'
        )

        super.preExecution()
    }

We would have to think about how to make this configurable since we still want to support --cov-report=term.

Agreed making it configurable would be wise.  I have no objection if I have to explicitly turn this on within build.gradle or similar - so long as there's some way for me to do so.


Fix sybase LobSchemaUpdateTest failure

Seems to me this should have a Jira as it changes user experience?

this are failure caused by this commit https://github.com/hibernate/hibernate-orm/commit/d8df261847d5fdeb8f9168b1391ec1e2f1531428

No no.  Its fine.  The original one should have had one

Does this need backported?

only to 6.,5

@sebersole I'm going to prepare the PR for 6.5

@sebersole I'm going to prepare the PR for 6.5

I'd say just cherry-pick and push it


people tests: Move test users to top of file.

I consolidate most of our users toward the top
of the file, so that we don't have to clutter
up individual tests.  This also avoids some
confusion where charles/maria got repeated
in different tests with different ids.
I also introduce a couple four-digit ids to
try to expose more bugs related to sorting.
Note that it's still easy to keep tests
isolated here, as we have always been able
to cheaply re-initialize people.js and then
add individual users back.
There are still some tests where it makes
sense to just declare users locally, especially
if we are mutating their data.
There are a few minor incidental cleanups here,
mostly involving replacing hard coded ids
with things like maria.user_id.

Testing Plan:
GIFs or Screenshots:

I believe I've addressed all of Rohitt's concerns.

The motivation for this PR was that I needed to add more tests for huddles, and I needed like four fully-formed users, and I didn't want to repeat another block of making maria/charles/ashton/linus/etc.


Add file filters support for macOS in lbg_choose_file()

Transform *.extension to UTI format:
https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/understanding_utis/understand_utis_intro/understand_utis_intro.html#//apple_ref/doc/uid/TP40001319

draft:
lbg_choosefile_opts=""

# prepare filters
if [ ${#lbg_choosefile_filters[@]} -gt 0 ] ; then
    lbg_choosefile_opts="{"

    for ((lbg_choosefile_i=0 ; lbg_choosefile_i < ${#lbg_choosefile_filters[@]} ; lbg_choosefile_i++)) ; do
        lbg_choosefile_filter="${lbg_choosefile_filters[$lbg_choosefile_i]}"

        # transform *.ext into UTI format
        echo "$lbg_choosefile_filter" | grep -E ^[*][.] &> /dev/null
        if [ $? == 0 ] ; then
            lbg_choosefile_filter="$(echo "$lbg_choosefile_filter" | sed 's/*/public/')"
        fi

        lbg_choosefile_opts+="$lbg_choosefile_filter,"
    done

    # delete last comma
    lbg_choosefile_opts="${lbg_choosefile_opts%?}}"
fi

Fixed in 65fe40f032b95e2585697cacf64ffc653819c49b


(PUP-6806) Update beaker version to 3.1.0 to allow for MacOS Sierra t…

…esting

👍

This will wait on some manual validation from myself and @Magisus . will update if those go green

CLA signed by all contributors.

All puppet tests run as expected on EL4 with beaker 3.1.0.

Blocked on https://github.com/puppetlabs/puppet/pull/5323

We have manually validated el Ubuntu and (current) windows targets, this is free to merge now.

@McdonaldSeanp or @Magisus do you happen to still have the output from those runs lying around somewhere? If so, want to link a gist?

@MosesMendoza , https://tickets.puppetlabs.com/secure/attachment/37543/windows.log is available as the log for the passing windows-2012r2 test run.

I plan to merge this Tues AM PDT (and then we can watch it go through acceptance)

The log for a Centos 4 run: https://tickets.puppetlabs.com/secure/attachment/37544/el4-beaker3.1.0-test_result.txt