atc-api generate should update all ATC package references

Describe the bug
When running atc-api generate server all on an existing project, after a new version of ATC has been released, not all of the ATC package references are updated to the latest version.
This is an example output from a solution that used version 1.0.170:
Updating Atc packages
  Determining projects to restore...
  Writing C:\...
info : Adding PackageReference for package 'Atc.Rest.Extended' into project '..\xxx\Xxx.Api.csproj'.
info :   CACHE https://api.nuget.org/v3/registration5-gz-semver2/atc.rest.extended/index.json
info :   GET https://nuget.pkg.github.com/egil/atc.rest.extended/index.json
info :   CACHE https://api.nuget.org/v3/registration5-gz-semver2/atc.rest.extended/page/1.0.6/1.0.128.json
info :   CACHE https://api.nuget.org/v3/registration5-gz-semver2/atc.rest.extended/page/1.0.129/1.0.254.json
info :   CACHE https://api.nuget.org/v3/registration5-gz-semver2/atc.rest.extended/page/1.0.256/1.0.278.json
info :   NotFound https://nuget.pkg.github.com/egil/atc.rest.extended/index.json 709ms
info : Restoring packages for C:\source\xxx-api\src\xxx.Api\Xxx.Api.csproj...
error: NU1605: Detected package downgrade: Atc.Rest from 1.0.278 to 1.0.270. Reference the package directly from the project to select a different version.
error:  Xxx.Api -> Atc.Rest.Extended 1.0.278 -> Atc.Rest (>= 1.0.278)
error:  Xxx.Api -> Atc.Rest (>= 1.0.270)
info : Package 'Atc.Rest.Extended' is compatible with all the specified frameworks in project '..\Xxx.Api\Xxx.Api.csproj'.
info : PackageReference for package 'Atc.Rest.Extended' version '1.0.278' updated in file 'C:\source\xxx-api\src\Xxx.Api\Xxx.Api.csproj'.
info : Committing restore...
info : Generating MSBuild file C:\source\xxx-api\src\Xxx.Api\obj\Xxx.Api.csproj.nuget.g.props.
info : Writing assets file to disk. Path: C:\source\xxx-api\src\Xxx.Api\obj\project.assets.json
log  : Failed to restore C:\source\xxx-api\src\Xxx.Api\Xxx.Api.csproj (in 393 ms).

@egil I think we should just close this since this doesn't really have anything to do with the ATC itself


ios feat: Add thumbnail for displaying share action sheet

What does this implement/fix? Explain your changes.
Add thumbnail and title while displaying share action sheet
Remove iOS 8 compatibility code.
Does this close any currently open issues?
https://github.com/OneKeyHQ/TaskHub/issues/255
Pull request type

Put an x in the boxes that apply

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

Where has this been tested?
…
Any other comments?
…

git没有追踪工程文件，新增加文件需要执行下 copy_back_changes.sh

@liuzjalex 已经加好了工程文件的changes


Problems with the twilight forest mod and Advanced Rocketry

Version of Advanced Rocketry
1.12.2-1.7.0-232
Have you verified this is an issue in the latest unstable build
Y,N, N/A Y
Version of LibVulpes
1.12.2-0.4.2-75
Version of Minecraft
[insert here] 1.12.2
Crash report or log (if applicable)
http://pastebin.com is a good place to put them
crash reports that are put in the issue itself are
hard to read
Description of the problem
When going into the twilight dimension there is an oxygen problem when there shouldnt be one, i've see some other posts about it, but the solutions are complicated and I have no idea how to solve them, looking this issue up on youtube bring up no related searches.
[How can you reliably reproduce the problem]
Going into the twilight forest

Make sure your planetDefs.xml does not have that dimension id dim mapped to the dimension that twilight forest. As that has been known to be the culprit.

Make sure your planetDefs.xml does not have that dimension id dim mapped to the dimension that twilight forest. As that has been known to be the culprit.
Do you have a youtube video showing how to fix it? If not can you be a bit more specific where I find these files and change them?

inside your world folder you will find a planetdefs.xml. look at the config file for twilightForest in  the config folder look for its id. then change the Dim id in the Planetdefs.xml or add oxygen to that planet.


https://www.ietf.org/blog/

URL: https://www.ietf.org/blog/
The IETF blog (“IETF News”) used to have a feed but I can no longer find it.

IETF feed added in https://github.com/simevidas/webplatformnews-feeds/commit/11f9823da0799af9ec8be1ba3a6ac315cdfc92fd


strict_rfc3339 and isodate validate timezones differently

Below is the code for validating a date-time formatted field:
try:
    import strict_rfc3339
except ImportError:
    try:
        import isodate
    except ImportError:
        pass
    else:
        @_checks_drafts("date-time", raises=(ValueError, isodate.ISO8601Error))
        def is_datetime(instance):
            if not isinstance(instance, str_types):
                return True
            return isodate.parse_datetime(instance)
else:
    @_checks_drafts("date-time")
    def is_datetime(instance):
        if not isinstance(instance, str_types):
            return True
        return strict_rfc3339.validate_rfc3339(instance)

Strict_rfc3339 and isodate both accept a string like "2016-11-05T23:59:59+01:00", but strict_rfc3339 rejects the similar string "2016-11-05T23:59:59+0100" while isodate accepts it. Since python's "%z" format refers to tz offset strings formatted as "+0100" it makes more sense to me to use isodate's validation, and I'd like to make a pull request removing strict_rfc3339 in favor of isodate.
So before I write any code, I have a few questions:

Do you agree with my proposal to accept +0100 formatted tz offset strings?
What is the reason for supporting both libraries?

Ah, after more investigation I see that it was changed because the json schema definition only supports rfc3339. Nevermind then.

Just discovered this. Damn, we've been using +/-hhmm for timezone offsets everywhere prior to JSON schema 😞


[Feature Request] mac禁用彩蛋

Checklist

[X] I searched exising issues and no one else requests similar feature.
[X] I think that 25%+ users are positive towards this feature.

Describe the feature
todo
Additional context
No response

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days


Exporting from a table no longer includes only the queried result but all entities

Storage Explorer Version: 1.29.0-dev
Build Number: 20230331.8
Branch: feature/table-explorer-react
Platform/OS: Windows 10/Linux Ubuntu 22.04/MacOS Ventura 13.3 (Apple M1 Pro)
Architecture: ia32/x64/arm64
How Found: From running test cases
Regression From: Previous release (1.28.1)
Steps to Reproduce

Expand one storage account -> Tables.
Right click one table -> Click '[2] Open'.
Add some entities. (Like the below)

Click 'Query' -> Execute query "PartitionKey eq '1' and RowKey eq '2'".
Click 'Export -> Export All...' -> Click 'Save'.
Open the exported csv file.
Check whether only queried entity is exported.

Expected Experience
Only queried entity is exported.
Actual Experience
All entities are exported.

Verified this issue on the build main/20230406.3. Fixed.


rink: fix darwin build

Motivation for this change
ZHF: #122042
cc @NixOS/nixos-release-managers
Hydra failure: https://hydra.nixos.org/build/142995091/nixlog/1
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 123501 at c452ca10 run on x86_64-linux 1

2 packages built successfully:

rink
tests.trivial


Check for forks when generating back link

If a step is reached by taking a fork, the back-links middleware doesn't recognise this as it only checks the 'next' property to pick up paths to a step.
Forks should be included in the previousSteps variable at the top of the middleware.

Include forks in previousSteps variable which is checked against step history

LGTM @easternbloc @gavboulton ?

Looking.

@JoeChapman @joefitter forking is a HOF thing. I'm not sure this belongs here.

@joefitter can you answer @easternbloc?

@easternbloc I added this here as it is where the back-links middleware exists, and there isn't really any nice way of hooking into the middleware at hof-controllers level at present.
If we move this to hof-controllers we would probably need to hook into the locals method and overwrite backLink by repeating the code here, extended with forking logic.
Let me know if you can think of another way?

If this functionality is purely for HOF it doesn't belong here. I think we should exhaust every possibility before we resort to something like this.

(At which point we may need to fork! :-( )

I think the time to fork may have come

@JoeChapman I think we need to have a very strong reason to fork. I'd much rather move logic to the hof-controllers unless this can't be done for some reason.

I think ideally forks should be a concept at this level, as this is the level that middleware is applied, backlinks are generated, steps are validated etc, a fork would be a nicer option (IMO) than trying to overwrite all of these things further down the tree

Would it be worth discussing moving forking logic from hof to this level rather than forking? It could be used by any form that uses passports-form-wizard, not only hof. As it is an opt-in service it would be backwards compatible

@joefitter: I suspect that would be a tough sell for @gavboulton (??) as, as far as I am aware, they are not doing forking in HMPO. We would be complicating the module just for our own purposes.
I'm a little worried about the edit functionality in forms and especially forks. It seems to me that in these regards we are probably hitting the limits of the form-wizard's architecture. i.e. It is possible to have all kinds of complicated form validation, that relies on fields from previous steps, but the form-wizard works on the basis of validating on a step by step basis. It seems to me that if someone goes back and edits their form, in general, the entire form needs to be revalidated.
Perhaps one solution would be, that if the user goes back to edit step 2 (let's say) we remove steps 2 onwards from the completed steps. This means more work for the user, but it should ensure that the resulting form is always valid.

@daniel-ac-martin
"Perhaps one solution would be, that if the user goes back to edit step 2 (let's say) we remove steps 2 onwards from the completed steps. This means more work for the user, but it should ensure that the resulting form is always valid."
^ this would be a PITA. The edit functionality allows a user to return to a step, edit and return to the /confirm step. Removing all values from steps following the step they are editing would be a pretty crappy  user experience, IMO.
Although I am reticent to do so, could we add another middleware to HOF to handle this (checking for a fork before generating a back link) without duplicating work? I suspect not. I'm not even sure it is possible.
I suppose it depends on the order in which middleware are executed. E.g., if the backlinks are generated in HOF using the presence of forks as a determining factor, and then the backlinks are generated in HMPO wizard, which does not use forks, the backlinks will be blown away and rebuilt without forks as a consideration.

@gavboulton @easternbloc @daniel-ac-martin @joefitter
Firstly, I need to introduce you to Joe Fitter. He has joined me in Service Optimisation and is helping to migrate lots of forms from an old system to HOF.
We want to improve the experience of using HOF, adding features and improvements, to the benefit of downstream services gaining the shared functionality.

In regards to the conversation above. How does @gavboulton feel about extending the HMPO wizard interface to accept other middlewares? Middleware will always be a problem for downstream dependencies because they are a closed system. Middleware might be able to replace existing middleware, or simply be placed first or last in the stack, therefore giving the downstream services some control over how their session based parameters are augmented.
Otherwise, each time we need to make this type of change, we will open the same can of worms.
And I don't really want us to fork the Wizard.

We can apply any number of middleware functions in the HOF base controller constructor beneath the super call here https://github.com/UKHomeOffice/hof-controllers/blob/master/lib/base-controller.js#L9 and they will be applied after the wizard middleware functions are called, but they will be repeating the same actions, albeit slightly amended, as previously called in the wizard.
@JoeChapman your suggestion of potentially overwriting core middleware by extending the wizard interface would solve the problem of the action being repeated, but it would still result in a lot of repeated code in the wizard middleware and the one provided when starting the wizard.  We could potentially get around this if the middleware functions are refactored to be extensible classes?  A problem with this way is that the wizard is called in the form application, so this boilerplate code to extend and pass in middleware would need to be repeated in each form app

Note: I'm not suggesting deleting everything they've entered from the session. Just removing the steps from the list of completed steps.
I'm most cases they could just keep clicking next to get back to the confirm page. That seems to be the normal way to handle this. I agree it's a suboptimal user experience but it's probably the safest way to ensure you get a valid form out at the end.
@easternbloc and I discussed one compromise which would be to leave it up to the developer that introduces complicated validation to ensure that they account for excited forms.
On 19 April 2016 14:17:44 BST, Joe Chapman<EMAIL_ADDRESS>wrote:

@daniel-ac-martin
"Perhaps one solution would be, that if the user goes back to edit step
2 (let's say) we remove steps 2 onwards from the completed steps. This
means more work for the user, but it should ensure that the resulting
form is always valid."
^ this would be a PITA. The edit functionality allows a user to return
to a step, edit and return to the /confirm step. Removing all values
from steps following the step they are editing would be a pretty crappy
user experience, IMO.
Although I am reticent to do so, could we add another middleware to HOF
to handle this (checking for a fork before generating a back link)
without duplicating work? I suspect not. I'm not even sure it is
possible.
I suppose it depends on the order in which middleware are executed.
E.g., if the backlinks are generated in HOF using the presence of forks
as a determining factor, and then the backlinks are generated in HMPO
wizard, which does not use forks, the backlinks will be blown away and
rebuilt without forks as a consideration.

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/UKHomeOffice/passports-form-wizard/pull/52#issuecomment-211920152

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

@joefitter
your suggestion of potentially overwriting core middleware by extending the wizard interface would solve the problem of the action being repeated, but it would still result in a lot of repeated code in the wizard middleware and the one provided when starting the wizard.

If the middleware were named methods of an middleware 'object', they could be overwritten by middleware functions that could exist in the downstream service, i.e., GRO, BRP. And shared if and when necessary, e.g. added into HOF if suitable.
It is also feasible that the existing wizard middleware be sliced vertically, increasing the number of middleware functions, but potentially decreasing the loc in new middleware functions intended to replace existing ones.
A problem with this way is that the wizard is called in the form application, so this boilerplate code to extend and pass in middleware would need to be repeated in each form app

We wouldn't need to recreate it each time, write it once to a module, and require it as a dependency into whichever wizard instance required it.

IMO, forks are session based parameters. Potentially, they need knowledge of steps, values and current location, therefore, the middleware seems the logical place to keep that logic.

I agree with @JoeChapman that the best place to keep the forking logic is middleware.
As far as I can see there are 3 options to achieve this:

Hook into HOF BaseController constructor and apply forking middleware, this would also need to apply amended versions of check-progress and back-links middleware at this stage
@JoeChapman's suggestion of using a hash of named middleware, this could then be overwritten by middleware provided through settings on initialisation of the wizard. Middleware should also be refactored to use prototypal inheritance so functionality could be extended further down the line rather than thrown away
My earlier suggestion that we move the forking logic to the wizard as an opt-in, backwards compatible feature at middleware level and take this into account (if utilised) when applying back-links and check-progress middleware.

After giving this a lot more thought I strongly feel the latter would be the best way forward in regards to simplicity, extensibility and maintainability.
The first option is far from ideal for obvious reasons - we would be copying and pasting code from the wizard, and re-applying a slightly amended version just after the first is called. Also if we went down this route, we would come up with the same issues every time we come up against a similar issue that is best addressed at a middleware level
The second option would be a good compromise but would involve in adding more complexity around the way middleware is constructed and applied, requiring changes to all existing middleware and the wizard itself, as well as a hof-wizard extension to provide extended middleware to passports-wizard. It would also result in the added feature only being available to applications specifically using HOF so if further down the line passports required a fork, the functionality wouldn't be available.  I have started this work on a branch to see how feasible it would be and will paste a link shortly
While I understand @daniel-ac-martin's point that passports doesn't currently require forking functionality I don't think this is a reason not to apply the forking logic at this level, if we are building a framework for creating Home Office Forms then IMO we should be applying features and fixes at the correct point in the architecture, and if a code/feature freeze is in place at the passports/wizard level then I believe we should be forking the repo and continuing development.

POC for the extending middleware option - https://github.com/UKHomeOffice/passports-form-wizard/commit/794bfaafb8f0ac3eb0816e0b296aa3744ff1f697

Hi all,
Apologies, I've been away. Good discussions. I think it's time to seriously consider handling forked journeys at a lower level than HOF controllers. HMPO don't currently need this functionality but the use of these modules is quickly snowballing. I haven't thought enough about forked journeys to comment on what needs to be done though. Should we simply add to the wizard? Should we extend it? Should we split out the middleware? Should we put all the controllers in one module?

To briefly summarise our discussion earlier, it's time to add forked journeys into the wizard. It would be good to get all the known scenarios so that we can get this addition right.
Back links, edit journeys and field/step invalidation seem to pose the toughest challenges.
Is the first step to make the middleware overridable/extendable?

@gavboulton @JoeChapman @daniel-ac-martin @easternbloc mind giving this a once over? It will work as before if forks are not included but should now also work with forks too. This fixes the issue with backLinks and prereqs on forked steps

So @joefitter @gavboulton this could be thought of as the "first step". IMO it places the fork feature in the correct place and fixes the creation of backlinks when forking.
I would like us to be able to incorporate this change as step 1.
Step 2: Make middleware overridable
Step 3: revisit the concept of forks.
This PR LGTM, anyone else? @UKHomeOffice/hof

@JoeChapman this isn't the forking logic, just the inclusion of forks when working out backlinks and prereqs - the linked PR for forking is https://github.com/UKHomeOffice/passports-form-controller/pull/37
Also I have a few further changes to be applied once these PRs are merged - step invalidation:
https://github.com/UKHomeOffice/passports-form-controller/commit/11ef15fadd6473444003ba9efe0b4125ca279391 and https://github.com/UKHomeOffice/passports-form-wizard/commit/5db203a280ec61cf979f198d6b9ee171577eb8bc
With these changes, I don't think we will need to make middleware overridable - applying forking at this level fixes the middleware issues we were experiencing and any further middleware can be applied at the hof base controller or individual controller level
thoughts @UKHomeOffice/hof ?

@JoeChapman If step 3 is revisiting the concept of forks, is there something you think can be improved before any of these new additions are merged?

We were discussing perhaps expanding the concept of next to accept a function rather than supplying an array of forks, however the iterative approach would be to move the forking functionality over first, then perhaps revisit it in the future

With the current way we have explicit fork targets and conditions which can be easily used to invalidate unused paths when the form is edited though, so perhaps keeping forking as it is would be better. If we expand next to accept a function it would be a lot harder to predict potential paths through the form

@joefitter we need to take small bites. @gavboulton we may revisit forks and perhaps even move the responsibility to next if it suits, however, it is all very much speculation at the moment. I would very much like to improve what we do have before refactoring a fairly sound idea. Many of the arguments against the continued use of forks as they are, sound highly speculative and conceptual. We need to strike a balance between being idealistic and pragmatic.
@gavboulton do you need any more info?

It's also probably a good time to update the example in this repo.

@gavboulton good plan - have done

@gavboulton @JoeChapman @easternbloc how are we feeling about this PR? @gavboulton I rebased your changes into my branch and removed proxyquire

@JoeChapman updated

@joefitter LGTM but, I remember we discussed about reflecting significant changes to the example app. Can it be done for this. My pondering is should it be done pre or post merge? What do people think?

I would vote for post merge, as the example app would still be using the current version assuming this gets a major bump. It should be updated in the example app when it is bumped IMO, but yes, we do need to keep on top of updating the example, not sure if there is a nice way to manage it?

@daniel-ac-martin made a point in regards to which comes first in an unrelated comment on the this issue of testing example for when HOF changes are PR'd. (https://github.com/UKHomeOffice/hof/issues/73)
The example form needs the changes in HOF and the changes in HOF need to be reflected in the example form. I think the best of an imperfect situation is that HOF changes are published first.

@joefitter perhaps a PR could be raised on the example app referencing this commit hash? and then rebased on merge?

@joefitter Or is that too many hoops?

I think it could be a little hoopy - also it would need to be after the new tag is pushed, not this specific merge. Can we automatically submit an issue on the example-app repo when a major version of a dep is pushed?

Greenkeeper raises PR's about new versions of dependencies. That could be a start. I.e, a PR raised by Greenkeeper on example form to update to latest HOF version
And also worth checking to see if Greenkeeper can raise issues, e.g, "HOF version updated with changes xxx, make sure example for is up to date"

Sounds like exactly the kind of thing we are after

And also worth checking to see if Greenkeeper can raise issues, e.g, "HOF version updated with changes xxx, make sure example for is up to date"

Sadly I don't think that's a thing but greenkeeper solves the first part!

So to move us back on track... I'm happy for this to be merged.

LGTM too. @gavboulton do you have any reservations? Otherwise I am happy to merge this

And https://github.com/UKHomeOffice/hof-example-form/issues/44

I mentioned updating the example app in this repo. It's probably good to do it now along with the readme.

@gavboulton @JoeChapman @easternbloc I have updated example app to show a forked step, also added a link in readme to forking docs

Super looks good to me.

@JoeChapman have done

It shouldn't be a blocker to merging this PR, it's a conversation for another issue, but when reading the example, I can't help but wonder why 'female' is the value of next and 'male' the value of the forks' target. It's a completely arbitrary decision, I'm sure, but it gives weight to one value, as if the 'female' path is the default (which is kind of is). It goes back to something @daniel-ac-martin said, but I can't remember exactly what it was. It was something along the lines of everything being a value of next and a next param taking a function, or even an object, just as forks do.
next: {
    '/female_url`: 'female_value_selected',
    '/male_url': 'male_value_selected'
}

anyway LGTM.

@gavboulton?

@gavboulton is this ok to merge?

Do you have any other ideas for a forked journey example? I don't know if defaulting a journey based on gender is a good idea for an example use case.

@JoeChapman @easternbloc @gavboulton are we G2G with this? IMO the example form changes should really have been a separate PR and not affected this change, this is a bugfix which addresses an issue with forking.

@gavboulton I tend to agree with @joefitter on this one. Can we get this bugfix merged and we can raise a separate PR for the example form changes?

Okay. Remove the example form updates and we can get it merged.

@gavboulton @easternbloc @JoeChapman @daniel-ac-martin example form updates are now here - https://github.com/UKHomeOffice/passports-form-wizard/pull/60
This PR has been updated - are we good to merge?

Do you need me to publish?

@gavboulton yes please, would just be a patch I imagine as b/c and just addresses a bug in forking

<EMAIL_ADDRESS>published.


feat: Logins log for Fail2Ban

I'm not sure if this is the function that was requested, which is why I welcome ideas on how to improve it. Every time a login fails, the logs are both displayed in the console and saved in the root folder in a file named login-logs.txt #985
logs:
{"level":"error","message":"Passport Local Strategy - Password does not match","parameters":[{"name":"isMatch","value":false}],"timestamp":"2023-09-23T23:24:38.786Z"}
{"level":"error","message":"[Login] [Login failed] [Username<EMAIL_ADDRESS>[Request-IP: 45.xx.xx.238]","timestamp":"2023-09-23T23:24:38.786Z"}

Change Type

[x] New feature (non-breaking change which adds functionality)

Testing
check if the log and the .txt works properly
Test Configuration:
Checklist

[x] My code adheres to this project's style guidelines
[x] I have performed a self-review of my own code
[x] I have commented in any complex areas of my code
[x] I have made pertinent documentation changes
[x] My changes do not introduce new warnings
[x] I have written tests demonstrating that my changes are effective or that my feature works
[x] Local unit tests pass with my changes
[x] Any changes dependent on mine have been merged and published in downstream modules.

it works, but... the log works if you enter wrong logical data. e.g. username<EMAIL_ADDRESS>password: 123456789
but with wrong non logical data, like username: 123 password: 123 [which doesn't work because the username has to be an email and the password has to be min. 8 characters long] it won't be logged! i think that would be important to add.

I know, I did it on purpose this way! I thought the logs would help you understand if someone wanted to attempt to brute force the password, etc..

I know, I did it on purpose this way! I thought the logs would help you understand if someone wanted to attempt to brute force the password, etc..

No, the wish was to make librechat compatible with fail2ban xD

it works, but... the log works if you enter wrong logical data. e.g. username<EMAIL_ADDRESS>password: 123456789 but with wrong non logical data, like username: 123 password: 123 [which doesn't work because the username has to be an email and the password has to be min. 8 characters long] it won't be logged! i think that would be important to add.

this is a good point, it should count as a login fail when the validation fails @Berry-13


Standardize link styles throughout frame

This PR satisfies the requirements of MUMUP-2688
In this PR:

All links that are styled like buttons will have no underline when hovered
All regular links will have underline when hovered
Mascot image no longer shows a different background color when hovered (that was an unintended effect of making it a md-button)
Removed a lot of unused .less variables
Commented some .less files for clarification of their content
Fixed some typos

Coverage remained the same at 33.61% when pulling 9ed3d141482076912edeefe2a3262ac1403b8016 on thevoiceofzeke:linkStyles into 9bb8b866a290656bd85c93db7484e0a295060b8b on UW-Madison-DoIT:master.


sap_hana_preconfigure: Add package compat-openssl10 for RHEL 8 (lsr/sap-hana-preconfigure issue #146)

Copy of https://github.com/linux-system-roles/sap-hana-preconfigure/issues/146#issue-798222172 (comment by berndfinger):
to support the installation of HANA Cockpit

The SAP note 2772999 still does not contain the package compat-openssl10.


build(deps): Update x-component version to 3.0.0-alpha.213

EX-7347

Problems with Jenkins, closing the PR to make it again.


How to install on ubuntu?

I have a fresh ubuntu. What steps are required to install this?

Hi @Eddcapone! You'll need to install ruby however that is done on Ubuntu, then gem install mailcatcher. You may need some other packages to compile the required gems. I can't advise further, I don't use ubuntu as my primary system.


404 error when edit my draft release in Google Chrome

Gogs version (or commit ref): <IP_ADDRESS>1

Git version: 2.10.1 (Apple Git-78)

Operating system: macOS Sierra

Database (use [x]):

[ ] PostgreSQL
[ ] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gogs.io:

[ ] Yes (provide example URL)
[x] No
[ ] Not relevant

Log gist (usually found in log/gogs.log):

Description

Hi, version too old.


[BUG] Different results with same parameters depending on HPO vs multi-GPU vs single GPU

Bug Report Checklist

[] I provided code that demonstrates a minimal reproducible example.
[ ] I confirmed bug exists on the latest mainline of AutoGluon via source install.
[ x] I confirmed bug exists on the latest stable version of AutoGluon.

Describe the bug
Consider the two attached scripts.  These scripts follow the tutorial, Hyperparameter Optimizationin in AutoMM very closely.  One of these scripts uses HPO, the second just takes the parameters discovered by the HPO (as reported in params.json) and uses them directly without HPO.  I have run the latter script in two different versions:  In a Jupyter notebook, which means that I use only one GPU and at the command line (using jupyter nbconvert --to script  "{notebook_prefix}.ipynb"), where I can run with 4 GPU's.
The three notebooks yield three different results for predictor.evaluate(test_data) although config.yaml is identical (except for the above-mentioned differences regarding num_gpus and strategy for the 4 GPU run).
Note that, in particular, the results produced by predictor.evaluate(test_data) are lower when the parameters are specified with Second_part_of_HPO_demo_specified_params.ipynb vs when they are derived by HPO with Second_part_of_HPO_demo.ipynb (regardless of whether the "specified_params" version is run in a notebook or via as a Python script).  This is similar to what I see in production situations with the data on which I am researching.  I get much better test results when fitting a model with the discovered HPO parameters.
Expected behavior
I would expect that the three runs described above would yield the same results.
To Reproduce
See attached two scripts
Screenshots / Logs

Installed Versions

INSTALLED VERSIONS
------------------
date                   : 2023-05-17
time                   : 21:24:14.825170
python                 : 3.9.16.final.0
OS                     : Linux
OS-release             : 5.10.157-139.675.amzn2.x86_64
Version                : #1 SMP Thu Dec 8 01:29:11 UTC 2022
machine                : x86_64
processor              : x86_64
num_cores              : 48
cpu_ram_mb             : 191087
cuda version           : 11.515.65.01
num_gpus               : 4
gpu_ram_mb             : [2663, 2533, 2533, 2533]
avail_disk_size_mb     : 1567517

accelerate             : 0.16.0
autogluon.common       : 0.7.0
autogluon.core         : 0.7.0
autogluon.eda          : 0.7.0
autogluon.features     : 0.7.0
autogluon.multimodal   : 0.7.0
autogluon.tabular      : 0.7.0
autogluon.timeseries   : 0.7.0
boto3                  : 1.26.134
catboost               : 1.1.1
defusedxml             : 0.7.1
evaluate               : 0.3.0
fairscale              : 0.4.13
fastai                 : 2.7.12
gluonts                : 0.12.8
hyperopt               : 0.2.7
ipywidgets             : 8.0.6
jinja2                 : 3.1.2
joblib                 : 1.2.0
jsonschema             : 4.17.3
lightgbm               : 3.3.5
matplotlib             : 3.6.3
missingno              : 0.5.2
networkx               : 2.8.8
nlpaug                 : 1.1.11
nltk                   : 3.8.1
nptyping               : 2.4.1
numpy                  : 1.23.4
omegaconf              : 2.2.3
openmim                : None
pandas                 : 1.5.1
phik                   : 0.12.3
PIL                    : 9.5.0
psutil                 : 5.9.5
pytesseract            : 0.3.10
pytorch-metric-learning: None
pytorch_lightning      : 1.9.5
ray                    : 2.2.0
requests               : 2.29.0
scipy                  : 1.10.1
seaborn                : 0.12.2
sentencepiece          : 0.1.99
seqeval                : None
setuptools             : 67.7.2
skimage                : 0.19.3
sklearn                : 1.2.2
statsforecast          : 1.4.0
statsmodels            : 0.13.5
tensorboard            : 2.13.0
text-unidecode         : None
timm                   : 0.9.2
torch                  : 1.13.1+cu117
torchmetrics           : 0.8.2
torchvision            : 0.14.1+cu117
tqdm                   : 4.65.0
transformers           : 4.26.1
ujson                  : 5.7.0
xgboost                : 1.7.5

Here are the jupyter notebooks mentioned in the bug report
Two notebooks.zip

Should be fixed now with https://github.com/autogluon/autogluon/pull/3222


Update Transfer tutorial to download Apalache through CLI

Modelator CLI now has the command check-apalache-jar that downloads Apalache jar file if it doesn't exist.
Tutorial file: https://github.com/informalsystems/atomkraft/blob/dev/examples/cosmos-sdk/transfer/transfer.md

This is a part of a bigger issue #92 , closing this one


MEXC - Unsupported order type: OrderType.MARKET

Describe the bug
When running a cross-exchange market-making strategy and MEXC connector is used as the taker exchange, the order fails to get executed with the following error.
2021-12-10 03:30:39,335 - 14776 - hummingbot.core.utils.async_utils - ERROR - Unhandled error in background task: Unsupported order type: OrderType.MARKET
Traceback (most recent call last):
  File "/home/ubuntu/mexc/hummingbot/core/utils/async_utils.py", line 9, in safe_wrapper
    return await c
  File "/home/ubuntu/mexc/hummingbot/connector/exchange/mexc/mexc_exchange.py", line 731, in execute_sell
    raise Exception(f"Unsupported order type: {order_type}")
Exception: Unsupported order type: OrderType.MARKET

Tried using the exchange in an arbitrage strategy however, there was no error in the bot however there was no executed arbitrage order on the mexc side.
Steps To Reproduce
Here are the steps to reproduce the issue (see attachments in the section below):

Create a cross-exchange market making strategy
Set MEXC connector as the taker exchange
Set low minimum profitability for a higher chance of executing a trade
Start the strategy
Check the history and observe the logs when there is a filled event.

Screenshots
Release version
0.46.0
Attachments
logs_conf_xemm_1.log
WARNING: Do NOT publish any exchange API keys or your wallet's private key. Whoever has access to them may steal your assets!
Optional: your discord username:

same issue now, had no trades at all on mexc side, despite the logs saying the strategy completed

Hi
I'm also facing this issue on an arb strategy
ingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.0, "order_id": "sell-ABC-USDT-16016", "order_type": "OrderType.MARKET", "event_name": "MarketOrderFailureEvent", "event_source": "mexc"} 2022-08-04 01:39:31,037 - 1 - hummingbot.core.utils.async_utils - ERROR - Unhandled error in background task: Unsupported order type: OrderType.MARKET

Any idea in how to resolve this? I'm also getting this error

Severity: P3
Bounty: 10 000 HBOT (https://hummingbot.org/maintenance/bugs/)
Rationale: Bug related to MEXC exchange (or component)

@nikspz I will take it

Removing this bounty, since PR to refactor MEXC is ongoing. This one is achieved.


just in case that both functions are valid. I found this when I try t…

When I add h264 in our repo via sdpFilter, it never runs. Then I found it is overwritten by the sdpfilter.

Hey Jeff - yep, can definitely see how that could be problematic.
I'm wondering if instead of running them both (which might also cause confusion) we just throw an error if both are configured and then put the responsibility for determining which option to pass back onto the implementer.
Alternately, if you think there is value in being able to chain sdpfilters, it might be better to handle things by reducing over an array.
Thoughts?

I'd suggest reducing over the array. Just my 2c worth.

@nathanoehlman maybe you could update the PR with what you think?


Comma separator

Compound sentence: two built-in sentences with a noun and a verb must be separated by a comma.

Hi, sorry I don't think this is an improvement.


Ability to use a plain color as splash screen rather than an image

Since many games would rather have their own animated splash screen, it would be nice to be able to set a color to the splash that would be applied to the whole window during loading (and instead have a pure black color during engine loading, for example).
Currently, you have to use a pure black image as splash, it's kind of a hack (since you need an image editor to change the color).

There is already boot_bg_color. The problem is that if you don't specify a custom splash screen, the default one will be used instead of none.

I agree that there is the need for an option to simply disable the boot splash, since loading a black image is a hack.

What would be the best way to handle it? Adding another project setting is probably out of question, so maybe this could depend on image name? The default would be changed to "Godot" or "default" and it would mean to use the Godot logo. Setting the path to non-existing file (especially empty string) should just display the clear color, instead of being full-white.

@KoBeWi A new project setting sounds fine to me, especially as you may want to specify a boot splash color in addition to an image. The boot splash color would be used to fill the areas outside the image.

Closing in favor of https://github.com/godotengine/godot-proposals/issues/1445, as feature proposals are now tracked on the Godot proposals repository.


Payload metrics for each request

Hi,
Is it possible to get the metrics for payload size of each request hitting the nginx server using nginx-vts-exporter?
Thanks,
Sushant

maybe inBytes is the thing you want?

you mean nginx_upstream_bytes this metric? or is their something else ?

yep, and the nginx_server_bytes

but it does not give payload size for each request? it gives total requests in and out !


Add "remix" page

The remix page includes:

a call to action for the "remix cooperation" being announced on monday.
a list of CC0 resources that can be downloaded and remixed.

The resources should be:

grouped by project/kind/platform and/or be displayed in a table with the options to sort, group, and filter.
discovered dynamically using queries on wallet and/or target collection address.
rendered on the server, if feasible.

Resources include:

Mixtape Vol. 1:

Full-length Mixtape MP3/WAV (WAV not on-chain yet) from Zora.
Individual tracks from catalog.
Stems from zora
Mixtape artwork from zora.
Individual track artwork from catalog.

Cloaks (TBD)

All of the files will be stored on arweave with tags for grouping and filtering.
To avoid spam, the owner address needs to be part of the query and the signature may need to be verified... unless the network guarantees a valid signature?

In #26, a detailed tag spec is provided for future use. For now, we'll just be uploading just the files with the appropriate tags along with a manifest to enable downloads with friendly path names and extensions.
The manifest is enough to support a simple listing, but #26 will have to be implemented more fully to support dynamic grouping, filtering, and sorting of artifacts.

TODO:

write a script to upload each file—one at a time—with the appropriate tags.
create and upload a manifest file.
use txId to load manifest file and render links. manifest can be committed in this repo if needed.

DOne


Add comment in README.md about go version

This adds a short line to the README.md which highlights the recommended go version that should be used to run Bud.
I was caught out by #45 too. Please let me know if you have any questions and great job on Bud so far - I've been searching for something like this for a while.

Thanks @joshuatalb for kicking this off! Just reviewed

Going to merge the suggestion above since I need to make another adjustment to the Readme. If there's anything you'd like to change, let me know @joshuatalb.


does materialize support custom elements and shadow dom?

Most of the selectors work on classes, some on HTML5 elements.

Just a heads up (you can leave this closed) The wave does not work inside
the shadow Dom. I'll be putting an issue on that repo though.
On Apr 26, 2015 6:42 PM, "Alvin Wang"<EMAIL_ADDRESS>wrote:

Closed #1224 https://github.com/Dogfalo/materialize/issues/1224.
—
Reply to this email directly or view it on GitHub
https://github.com/Dogfalo/materialize/issues/1224#event-290383880.


Tooltip variants

Suggestion / feature request
Tooltip variants
Currently there is only one style for all tooltips. I would like to be able to either choose between different variants of tooltips sytles, e.g. Primary, Secondary, Warn, error, ... or I want to be able to choose colors for background and an optional border+arrow.
An example of what I imagine:

Hi @florianprechtl, thanks for your request, we will discuss this internally.
Do you have a few examples in which situations you would rahter see a different style?

Hey @silviowolf,
My example:
I want to use it to stress the importance or intent of a tooltip.
In my case I want to show that a user has to do something before being able to press a button. The tooltip appears either if the user hovers over the button that is disbaled or pops up if the user presses enter while the form is not filled out correctly yet.
I used this approach as there is only input validation for input fields but not for ix-select fields. Otherwise normal input validation would may be the better approach. (Or maybe I just didn't find out how to use the input validation for ix-select fields yet 😅)
Styles I would like to see:

warn
error
success
normal
info

Other approach
Maybe it would suffice to have a primary color (for text and an optional border) an a secondar color for the background. But that wouldn't be so standardised.

Hi @florianprechtl,
ah OK, I understand your usecase now. This would be used especially for tooltips not raised by the users mouse pointer but by a system trigger like a validation, and therefore it needs more attention. We will discuss this in a next planning.
For your info: The validation for iX selects is indeed not available yet but already planned. Let's see what we can release earlier.

Hi @silviowolf , if you have made a decision about this issue, I can work on this issue.


fix: preserve ordering of cache behaviors

Description
Separate variables for default and ordered cache behavior.
Ordered cache behavior is now a list so that ordering is respected.
Motivation and Context

It preserves the ordering of cache behaviors, so that the resulting precedence is correct.

Fixes issue 11.
Breaking Changes

Yes, because a variable has been removed (cache_behavior), and two new ones were added (default_cache_behavior and ordered_cache_behavior).

It is necessary because the root of the problem was in the variable definition itself, i.e. using a map to store an ordered list.
How Has This Been Tested?

I adapted the examples/complete and planned it.

Additionally, we used our local fork with this change to create a new distribution with many cache behaviors. We did not encounter any issue, and the order of the cache behaviors was correctly preserved.

I also adapted the README.

Hello @antonbabenko  I didn't know you had the semantic check, would you like me to amend my commit message and issue a new PR?

Hello @antonbabenko  I didn't know you had the semantic check, would you like me to amend my commit message and issue a new PR?

No problems, I will take a look at this once I have some time (probably by the end of this week). Thank you for this PR.

No problems, I will take a look at this once I have some time (probably by the end of this week). Thank you for this PR.

@lejeunen thank you, the fix works like a charm
@antonbabenko can we have it merged?
p.s. thanks for the module 🥇

@lejeunen thank you, the fix works like a charm
@antonbabenko can we have it merged?
p.s. thanks for the module 🥇

Thanks for this PR!
v1.5.0 has been just released.

Thanks for this PR!
v1.5.0 has been just released.


[BUG] Timing not sample accurate

NAM does not report PDC to host correctly, resulting in a delay vs an unprocessed track.
To reproduce:

Duplicate audio track in DAW
Insert NAM plugin to one of the channels. Use a fairly clean capture.
Play both channels together. You should hear severe phase problems.
If not, render both tracks and inspect them visually by zooming in. NAM track will be several samples late.

More over, the delay seems to vary between captures. Typical delay seems to be around 9-13 samples.

NAM does not report PDC to host correctly

What does it report, and what do you expect instead?
I suspect this is not actually an issue with the plugin. The trainer needs to align the output and input since most DAWs don't get the latency compensation exactly correct (and some don't do it at all).  The model emulates the reamped rig with the calibrated time delay.
If you know what the time delay is for your DAW, you can provide it explicitly during training. Otherwise, you'll need to time-align by hand.
Closing this for now. However, if you can answer the PDC question above that there is a bug with the plugin, feel free to re-open.

Commenting a bit late, sorry about that.
Not sure how to explain this more clearly but I'll try. In VST plugins, if processing causes latency, plugins report the delay back to the host so the host can compensate and keep audio in sync. This is called Plugin Delay Compensation (PDC). I believe in iPlug2 framework this is done by calling the SetLatency method.
As far as I can see, NAM reports latency as 0, but in fact has latency of around 10 samples, resulting in a short delay that causes problems - the worst ones being phase issues for example when an unprocessed track is mixed with a track processesed by NAM.
Furthermore, to make things worse, this latency is not constant but seems to depend on the actual NAM model. Thus, setting PDC manually is not a real solution.
Now, I do not know whether this latency originates from the training process or in the plugin itself. But I believe it should be possible to fix this in the plugin, for example by processing a test signal and measuring the latency when a model file is opened and then calling SetLatency accrodingly.
Hope this helps!


Initializing conda shell integration on self-hosted runner

This issue is a continuation of https://github.com/conda-incubator/setup-miniconda/issues/203.
My reasons to create a new issue are:

to stop abusing the other issue - it is somehow related but it is also closed
now I have some progress with running setup-miniconda on self-hosted runner and maybe the new issue is a bug

Here I was able to use setup-miniconda in a self-hosted runner:

I've created a custom script that setups Conda:

#!/usr/bin/env bash

export CONDA="/home/ubuntu/miniconda/"
export PATH="$CONDA/condabin:$PATH"

# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/home/ubuntu/miniconda/bin/conda' 'shell.bash' 'hook' 2> /dev/null)"
if [ $? -eq 0 ]; then
    eval "$__conda_setup"
else
    if [ -f "/home/ubuntu/miniconda/etc/profile.d/conda.sh" ]; then
        . "/home/ubuntu/miniconda/etc/profile.d/conda.sh"
    else
        export PATH="/home/ubuntu/miniconda/bin:$PATH"
    fi
fi
unset __conda_setup
# <<< conda initialize <<<

sourced it at the top of the runner's runsvc.sh (this is the script called by systemd's ExecStart=...)

The new problem is: https://github.com/martin-g/zeppelin/runs/4532009932?check_suite_focus=true
Initializing conda shell integration...
  Removing "/home/ubuntu/.bashrc"
  Removing "/home/ubuntu/.profile"
  /home/ubuntu/miniconda/condabin/conda init --all
  no change     /home/ubuntu/miniconda/condabin/conda
  no change     /home/ubuntu/miniconda/bin/conda
  no change     /home/ubuntu/miniconda/bin/conda-env
  no change     /home/ubuntu/miniconda/bin/activate
  no change     /home/ubuntu/miniconda/bin/deactivate
  no change     /home/ubuntu/miniconda/etc/profile.d/conda.sh
  no change     /home/ubuntu/miniconda/etc/fish/conf.d/conda.fish
  no change     /home/ubuntu/miniconda/shell/condabin/Conda.psm1
  modified      /home/ubuntu/miniconda/shell/condabin/conda-hook.ps1
  no change     /home/ubuntu/miniconda/lib/python3.8/site-packages/xontrib/conda.xsh
  no change     /home/ubuntu/miniconda/etc/profile.d/conda.csh
  modified      /home/ubuntu/.bashrc
  modified      /home/ubuntu/.zshrc
  modified      /home/ubuntu/.config/fish/config.fish
  modified      /home/ubuntu/.xonshrc
  modified      /home/ubuntu/.tcshrc

  ==> For changes to take effect, close and re-open your current shell. <==

  Renaming "/home/ubuntu/.bashrc" to "/home/ubuntu/.profile"

Error: ENOENT: no such file or directory, rename '/home/ubuntu/.bashrc' -> '/home/ubuntu/.profile'

It seems to me that setup-miniconda removes ~/.bashrc and ~/.profile and later complains that they are not existing.

OK. I think I've found the problem.
All is good after removing everything between # >>> conda initialize >>> and # <<< conda initialize <<< and setup-miniconda do all this!

Oh, nice! Yes, I guess once shouldn't initialize the local installation and let the action do it for them instead. Thanks for debugging!

One question:
On Github runners (x86_64) a project uses:
 - name: Setup conda environment with python ${{ matrix.python }} and R
        uses: conda-incubator/setup-miniconda@v2
        with:
          python-version: 3.7
          ...

But on my self-hosted runner I installed Miniconda myself with
wget https://repo.anaconda.com/miniconda/Miniconda3-py38_4.10.3-Linux-aarch64.sh -O miniconda.sh
bash miniconda.sh -b -p $HOME/miniconda

i.e. Miniconda + Python 3.8.
Do I need to install a second Miniconda3 with Python 3.7 in another folder and use runner labels to decide on which runner to run the job depending on ${matrix.python} ?
Or by using:
with:
          python-version: 3.7

it will do some magic and work as desired ?

As long a conda installation is in the system, the action will create envs / adapt python versions as needed. I don't know how concurrency is handled though, I get a feeling that the action is written with the assumption of "each machine running is a VM that will get cleared once we are done" so it's not clear what will happen if two jobs are using the same self-hosted machine with no VM abstraction (don't know if that's your case).

As long a conda installation is in the system, the action will create envs / adapt python versions as needed.

That's good!

two jobs are using the same self-hosted machine with no VM abstraction (don't know if that's your case).

This is the case here!
Self-hosted runners are not disposable VMs. Github Actions just guarantees that a single runner always runs at most one job. Once the job is done the runner might be used as is for another job.
I have 6 runners on the same VM, so I will see soon whether collisions will break something.
Is there a way to clean up Miniconda related stuff at the end of a job ?

You can have the action install a Miniconda of your choosing via installer-url (or similar, check the README). Then maybe you can add a cleanup step (or maybe the action cleans after itself?) to remove the directory. Adding a job identifier to the installation path might help too?

It is a bit more complicated - the setup works fine for ubuntu-20.04 (i.e. Github hosted runner). I am trying to add testing on Linux ARM64 to the setup (hence the self-hosted runners).
If I add installer-url then it will affect the x86_64 runners too.
I try to avoid making changes in the job definitions. The best would be if the only change in the workflow YAML is in runs-on.
setup-miniconda modifies ~/.bashrc/~/.profile, right ? It seems this causes problems on the self-hosted runner (one VM with several runners) - each job overrides these files


React does not recognize the disableRipple prop on a DOM element.

I have the following error in the console when loading with the latest version

I had no luck reproducing that
can you share your Mui versions? plz start with the basic setup example: https://codesandbox.io/p/sandbox/standard-x24pqk


[FEAT] save fiat amount in api_create_invoice

save user input into extra when he chooses a currency for api_create invoice

Codecov Report

Merging #1869 (6edeb36) into main (f096b51) will decrease coverage by 2.45%.
The diff coverage is 50.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##             main    #1869      +/-   ##
==========================================
- Coverage   55.73%   53.28%   -2.45%
==========================================
  Files          48       48
  Lines        7328     7330       +2
==========================================
- Hits         4084     3906     -178
- Misses       3244     3424     +180

Files Changed
Coverage Δ

lnbits/core/views/api.py
38.65% <50.00%> (+0.04%)
:arrow_up:

... and 7 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Update to management of parquet

Read and writing to parquet does not specify the engine. Will default to pyarrow, followed by fastparquet. Pyarrow is preferred for 64-bit python, but unavailable for 32-bit python. fastparquet may require additional install of Microsoft Build Tools.
-setup.py modified to require pyarrow for 64-bit but fastparquet for 32-bit
-parquet file updated with no compression
Resolves #92

@bl-young i assume you tested the install from github after the changes?  since the setup.py is a py file it makes sense to be able to add an if statement to it, but i've never seen this and want to make sure it's been tested

Yes, I have both 32 and 64 bit python so i tried installing to both via the command line from my branch, one will use fastparquet, the other installs pyarrow


Contentful key in config.rb

HI there,
I notice you have your contentful access token and space id in the config.rb file - Is this safe?
Thanks for the great examples,
Mike

Hey @MichaelSimmonds,
Delivery API tokens are read-only keys, therefore safe to share if content is not sensitive/private.
You should store them on the environment or use other techniques if your content is not meant to be publicly available through means other than your applications.
Hope that helps,
Cheers

I understand. Thanks for clarifying - I hadn't realised they are read-only.
Many thanks,
Mike
On 20/04/17 13:07, David Litvak Bruno wrote:

Hey @MichaelSimmonds https://github.com/MichaelSimmonds,
Delivery API tokens are read-only keys, therefore safe to share if
content is not sensitive/private.
You should store them on the environment or use other techniques if
your content is not meant to be publicly available through means other
than your applications.
Hope that helps,
Cheers
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/contentful/contentful_middleman_examples/issues/4#issuecomment-295686196,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AYjBxSIyt_E9z1oYMioTUHTgx9i059Ouks5rxzxYgaJpZM4NCoFf.

No problem!
Glad to help,
Cheers


[NCPI Catalog] Update GTM outbound link configuration

Need
Outbound links should track the source URL.
Definition of Done
Additional outbound link information is accessible in the query manager for prod and staging:

[x] NCPI Dataset Catalog - GA4 (https://ncpi-data.org/)
[x] NCPI Dataset Catalog CC Staging - GA4 (https://ncpi-data.dev.clevercanary.com/)

Working on both Catalog & Prod @MillenniumFalconMechanic
Prod:

Staging:

Thanks Jonah!


Update ci

Description
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request.
If it fixes a bug or resolves a feature request, be sure to link to that issue.
Fix gh action ci.yml.
Type of change
What type of changes does your code introduce to the kube-prometheus? Put an x in the box that apply.

[ ] CHANGE (fix or feature that would cause existing functionality to not work as expected)
[ ] FEATURE (non-breaking change which adds functionality)
[ ] BUGFIX (non-breaking change which fixes an issue)
[ ] ENHANCEMENT (non-breaking change which improves existing functionality)
[x] NONE (if none of the other choices apply. Example, tooling, build system, CI, docs, etc.)

Changelog entry
Please put a one-line changelog entry below. Later this will be copied to the changelog file.

GH action ci update.

Hi @paulfantom, I have impression the order of steps was missing additional wait lookup before hitting step with make test-e2e target. Both runs in my fork repo were turning green: https://github.com/drdkadtr/kube-prometheus/actions.

I am closing this PR as the changes proposed here do not improve our CI system. If you think otherwise, please reopen the PR.


Add OP-TEE support for Verdin iMX8MP

Commits in this PR:

u-boot: change Verdin iMX8MP DRAM banks when building with OP-TEE
linux: add config fragment for OP-TEE
optee: add append files for OP-TEE recipes
tdx-optee.bbclass: introduce class to enable OP-TEE support
README.md: add documentation about OP-TEE

Build and tested on Verdin iMX8MP.

@sergioprado Out of curiosity, is there any reason the same implementation wouldn't work on a Verdin-iMX8MM?

Out of curiosity, is there any reason the same implementation wouldn't work on a Verdin-iMX8MM?

@rborn-tx each SoC in optee_os might require a specific configuration to work. See for example in the makefile below that the configuration for machines in mx8mm-flavorlist differ from the machines in mx8mp-flavorlist:
https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/plat-imx/conf.mk
But probably (and hopefully) using the mx8mmevk machine configuration will work for verdin-imx8mm. :-)


2020 local authority regions update

Update the search, including the map, to respect the 2019 and 2020 local authority name and boundary changes

Changes have deployed


@OrderBy annotation does not apply

As stated in my stackoverflow question there appears to be a bug causing the ArrayCollection to be unsorted when I'm retrieving the entity with find(1). The whole thing miraculously works when I use findOneBy(array('id' => 1)). Please check the link mentioned above for further detail.
Hope I wrote this in the right section and it's going to be resolved. Best regards

This might be related to Issues #4256 and #4739 .
Try removing fetch="EAGER"

Closing as a duplicate of #4256


Remove obsolete version tracking assertions in exercises

Some tracks have added assertions to the exercise test suites that ensure that the solution has a hard-coded version in it.
In the old version of the site, this was useful, as it let commenters see what version of the test suite the code had been written against, and they wouldn't accidentally tell people that their code was wrong, when really the world had just moved on since it was submitted.
If this track does not have any assertions that track versions in the exercise tests, please close this issue.
If this track does have this bookkeeping code, then please remove it from all the exercises.
See https://github.com/exercism/exercism/issues/4266 for the full explanation of this change.

As this track only has 3 exercises implemented I quickly scanned them and I can not find any hints to version assertions in this track.
Please close this issue.

Thank you @NobbZ !


Remove TODOs from workflows.

Of course I still have to make corresponding changes in https://github.com/mgr0dzicki/cargo-semver-action-ref-slice.
But first, I wanted to ask to be 100% sure. @obi1kenobi, since v2 using baseline choosing logic of cargo-semver-checks is merged into main, we can safely change the version in tests from 1.2.2 to 1.2.1, can't we?

I'm honestly not sure either. I don't remember what that TODO was for, and it doesn't say which bad thing happens if the version were to change inappropriately. This is why writing detailed TODOs is important while you still have all the details in mind :)
If you think it's safe, go for it.

Oh so here are the details :). When I was preparing the first tests, the action was still using the bash script to select the baseline. Its logic had a flaw - it was selecting the highest version strictly smaller then current and not smaller or equal. This is why the test crate has version 1.2.2, while the latest published on crates.io is 1.2.1. The problem is - if suddenly version 1.2.2 of official ref_slice is published, the baseline for tests changes and they might fail. But now, since we use the logic built in cargo-semver-checks, I believe we can safely change the version of the test crate to 1.2.1 and it will be still compared to 1.2.1 published on crates.io. This is what the TODO was about.

Awesome, sounds reasonable so let's try it!

I've already changed the versions in cargo-semver-action-ref-slice, the CI passes, so I guess now we can safely remove the TODOs ;)


Allow merging bundles that have a fixed-reg def

The previous check was overly conservative: we only need to reject bundles that have multiple uses in the same instruction.
This can only happen with an early use and a late def, so we round the start of each range containing a fixed def up to the start of its instruction to detect overlaps.

At the very least this did fix the fuzzbug that I encountered when I simply removed the previous check. But sure, I'll run the fuzzer overnight to see if it hits anything.

Fuzzer ran all day and night without issues. The new check is still somewhat conservative but at the very least it should be a net improvement over the current situation.
I believe the fully precise condition is:

There is a late fixed def in the merged bundle.
The merged bundle is live over the early part of the instruction with the fixed-def.
There is an early fixed use at the same instruction as the fixed-def with the same preg outside the merged bundle.


Create '.keepme' files in directories

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

[x] Have you successfully run brew tests with your changes locally?

In favor of https://github.com/Homebrew/brew/issues/6263
The top-level directories in /usr/local e.g. /usr/local/sbin should have a .keepme file or similar created in them to avoid their removal in the macOS Catalina 10.15 installer.

I'm not sure about specs – is any example how I could test install routine?

I'm not sure about specs – is any example how I could test install routine?

Probably fine without specs in this case!


kube-dns pod should have a param for root domain

The default is "kubernetes.local" but others may want to change it.

the pod manifest allows for this param already.


build: update tsconfig target

:tada: This PR is included in version 1.4.41 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


As a user, I want to add/remove liquidity manually so I can earn yield on user transfers

Problem
We need a way for liquidity to be added to the ecosystem in order to support fast transfers at scale.
Users want to be liquidity providers for a given token+chain in order to earn yield.
There's no way to to this today without backend engineering work.
Ideas to solve this
We create a new UI for users to add liquidity for a given token+chain to a pool.
See spec here
https://www.notion.so/connext/Pool-and-Swap-UIs-wip-63b33149f8074d25b231500122202864
Acceptance Criteria
MVP
Left pane

Able to choose token and chain

Display relevant info on pool already available from SDK

Liquidity
Volume

Add/remove buttons added

Adding liquidity

Able to select amounts for token pairs
Able to successfully supply tokens to a liquidity pool

Removing liquidity

Checks and displays user’s # of LP tokens in a pool
user can specify # of LP tokens to redeem
user is able to approve + remove from pool, and is paid in the two tokens

Questions

Coinhippo build UI
SDK = addLiquidity , removeLiquidity, and ability to access relevant info on pools and users
Subgraphs need to have the data about pools, need to update Cartographer
Contract - Do we need event changes? Unlikely
Should this be permissioned to routers

P0

@just-a-node Please push what you can and we can move the rest to backlog


Manually running the 'StaticSitesClient upload' command from the container (mcr.microsoft.com/appsvc/staticappsclient) fails to upload the artifacts

I'm using this container mcr.microsoft.com/appsvc/staticappsclient:stable.
I use this command in bash:
./bin/staticsites/StaticSitesClient upload --verbose true --apiToken {MY_TOKEN} --workdir /tmp/src --app Client --api Api --outputLocation wwwroot --DeploymentProvider DevOps

Shows error Failed to upload build artifacts..
Full output:
DeploymentId: 7c149b5c-02e4-48cd-8b86-81a70785dd51

Verbose logging enabled
Build timeout not specified, defaulting to 15 minutes
App Directory Location: 'Client' was found.
Api Directory Location: 'Api' was found.
Starting to build app with Oryx
Azure Static Web Apps utilizes Oryx to build both static applications and Azure Functions. You can find more details on Oryx here: https://github.com/microsoft/Oryx
---Oryx build logs---

Operation performed by Microsoft Oryx, https://github.com/Microsoft/Oryx
You can report issues at https://github.com/Microsoft/Oryx/issues

Oryx Version: 0.2.20201112.1, Commit: a120bb248aa8d208ca5e02d7d9d075196e79cffd, ReleaseTagName: 20201112.1

Build Operation ID: |/JnC5/YYTlA=.3778b4b_

Detecting platforms...
Detected following platforms:
  dotnet: 3.1.12

Source directory     : /tmp/src/Client
Destination directory: /ss-oryx/app

Using .NET Core SDK Version: 3.1.406
  Determining projects to restore...
  Restored /tmp/src/Client/Client.csproj (in 363 ms).
  Restored /tmp/src/Shared/Shared.csproj (in 363 ms).

Publishing to directory /ss-oryx/app...

Microsoft (R) Build Engine version 16.7.2+b60ddb6f4 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
  Shared -> /tmp/src/Shared/bin/Release/netstandard2.0/Shared.dll
  Client -> /tmp/src/Client/bin/Release/netstandard2.1/Client.dll
  Client (Blazor output) -> /tmp/src/Client/bin/Release/netstandard2.1/wwwroot
  Client -> /ss-oryx/app/
Preparing output...

Removing existing manifest file
Creating a manifest file...
Manifest file created.

Done in 46 sec(s).

---End of Oryx build logs---
Oryx build has completed. Took 49.6618832 seconds. Exit Code: 0
Finished building app with Oryx
Starting to build function app with Oryx
---Oryx build logs---

Operation performed by Microsoft Oryx, https://github.com/Microsoft/Oryx
You can report issues at https://github.com/Microsoft/Oryx/issues

Oryx Version: 0.2.20201112.1, Commit: a120bb248aa8d208ca5e02d7d9d075196e79cffd, ReleaseTagName: 20201112.1

Build Operation ID: |B5MiwmmE1gA=.612e6ab1_

Detecting platforms...
Detected following platforms:
  dotnet: 3.1.12

Source directory     : /tmp/src/Api
Destination directory: /ss-oryx/api

Using .NET Core SDK Version: 3.1.406
  Determining projects to restore...
  Restored /tmp/src/Api/Api.csproj (in 655 ms).
  1 of 2 projects are up-to-date for restore.

Publishing to directory /ss-oryx/api...

Microsoft (R) Build Engine version 16.7.2+b60ddb6f4 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
  Shared -> /tmp/src/Shared/bin/Release/netstandard2.0/Shared.dll
  Api -> /tmp/src/Api/bin/Release/netcoreapp3.1/bin/Api.dll
  Api -> /ss-oryx/api/
Preparing output...

Removing existing manifest file
Creating a manifest file...
Manifest file created.

Done in 9 sec(s).

---End of Oryx build logs---
Oryx build has completed. Took 13.2416586 seconds. Exit Code: 0
Found Oryx manifest file, checking for function language
Found Oryx function language: dotnet
Function Runtime Information. OS: Windows, Functions Runtime: v3, .NET Core version: 3.1
Finished building function app with Oryx
Could not find staticwebapp.config.json file.
Determined default file to be: index.html
Found and validated 'routes.json' within build artifacts folder.
Zipping App Artifacts
App Zip will be created from directory: /ss-oryx/app/wwwroot
Done Zipping App Artifacts
Zipping Api Artifacts
Api Zip will be created from directory: /ss-oryx/api
Api Content Hash: 751309de059df5c97d77ef77a2844c7f
Done Zipping Api Artifacts
Uploading build artifacts.
Failed to upload build artifacts.

For further information, please visit the Azure Static Web Apps documentation at https://docs.microsoft.com/en-us/azure/static-web-apps/
If you believe this behavior is unexpected, please raise a GitHub issue at https://github.com/azure/static-web-apps/issues/
Exiting

And the status in the portal stays this:

What could be the issue ?
Note that the Static Web App (https://salmon-beach-0b176f003.azurestaticapps.net) deploys correctly from GitHub Actions.

We don't recommend running the container outside of our officially supported tools (currently the Static Web Apps GitHub Action and soon the Azure Pipelines task).

I'll close this for now. Tracking the Azure DevOps task at #5


fix(bch-js): Selecting custom server when not using JWT token

:tada: This PR is included in version 1.11.18 :tada:
Your semantic-release bot :package::rocket:


cordova datepicker plugin is not working in ios

i ham using cordova datepicker plugin but it is working good in android but its not working in my iphone 5s can anyone tell me whats the issue what i have to do

for me in iphone 5s working late after keypad./.


默认开启tts

💻 变更类型 | Change Type

[ ] feat
[ ] fix
[ ] refactor
[ ] perf
[ ] style
[ ] test
[ ] docs
[ ] ci
[ ] chore
[ ] build

🔀 变更说明 | Description of Change

📝 补充信息 | Additional Information

Summary by CodeRabbit

New Features

Text-to-speech functionality is now enabled by default, enhancing accessibility and user experience.

只是开关开启，如果没有配置模型，实际上应该还是不能使用吧？


[WIP] Optimize data Import (Fix #125)

Hi all! I was working to fix #125 . I want some feedback about the work, specially two things:

This part of the code adds the irregularities path for the reimbursements command. But, in my opinion, it's weird cause, for reimbursements_path there is no need to use --reimbursements_path and, in this case, we need to use --irregularaties-path.

The identation on this part of the code is horrible. I want some suggestions on how to make it better.

Please, tell me everything you think I have to change!

Hi @Guilhermeslucas! Once more we're glad to have your contribution and enthusiasm!
First of all, can you rebase this branch so it doesn't include code from other PRs (eg. #142)? Otherwise the diff from master is so complex that makes it impossible to do a proper code review  — and, yet, you  bring in errors from that WIP PR too ; )
Regarding your questions:
To pass irregularities_path without the --xpto or -x, just don't pass the first two positional arguments ; )
The lines you highlighted you don't have to open files to pass them to Pandas's read_ csv. :
    @property
    def reimbursements(self):
        """Returns a Generator with a Reimbursement object for each row."""
        print('Reading reimbursements dataset…')
        reimbursements = pd.read_csv(self.reimbursement_path, dtype=object).fillna('')

        print('Reading irregularities dataset…')
        irregularities = pd.read_csv(self.irregularities_path, dtype=object).fillna('')

        print('Merging datasets…')
        on = ('applicant_id', 'year', 'document_id')
        for _, row in pd.merge(reimbursements, irregularities, on=on).iterows():
            yield Reimbursement(**self.serialize(row.to_dict()))

Besides that, some hopefully hints:

I would import pandas as pd(it's also a kind of convention within Python community)
Use prospector to spot things you can enhance in terms of code quality ; )
When in a unpacking (eg. what happens in the for loop above) you don't use one variable, you just name it _ (it's also a convention within Python community)
I like to add print (we could improve and use proper logging, but anyway…) to help the user knwo what's happening behind the scenes ; )

Can you give me some help rebasing? I did it just once and I'm afraid off messing up stuff.

I suck at git, but that's how I'd do it:

Kind of save these changes you have in branch different than master: git checkout -b guilhermeslucas-optimize-imports-old
Go to the master branch: git checkout master
Pull from the main repo: git pull origin master -f (maybe you have upstream as this repo, and origin as your fork, IDK), but this step is tricky because your master is ahead of the main repo master branch — not sure how to align that, I'd have to do some research; anyway the point is to have your master branch exactly as this repo's master branch ; )
Create a new branch based on the master: git checkout -b guilhermeslucas-optimize-imports
Cherry pick the commits from guilhermeslucas-optimize-imports-old to guilhermeslucas-optimize-imports: git cherry-pick 0f956fd (and repeat for all commits you want to bring on board)
Delete the old messed up branch: git branch -D guilhermeslucas-optimize-imports-old

But maybe someone more expert in git can help you better than that.

I'll do it soon, but hard reset m master branch with the upstream. Have you merged my past commits on a branch, different than master, right? Just to be sure i won't lose this. Thanks!

I'll close this pull request after the changes and open another one with the branch updated. Is that ok?

Have you merged my past commits on a branch, different than master, right?

Yep, they're at cuducos-company-activity-as-json branch now.


browsing pages are all empty with the current data

It seems some error concerning loading roles information.

It is because no scoring is calculated so the default score 0 is below the criterion to be displayed. As of now, we plan to hide the entire section.


VagrantBox Mac OS Ventura Host Only bug

There is a current Vagrant issue plaguing the Mac community on the new Ventura OS.
The fix involves adding the following to your Vagrantfile for each server:
For example, I'm referencing Chapter 3's Vagrantfile definition of Application server 1:
config.vm.define "app1" do |app|
  db.vm.hostname = "orc-app1.test"
  db.vm.network :private_network, ip: "<IP_ADDRESS>"
end

A resulting vagrant up command will properly provision the box to a point... only to error on something like:

... If you're running on MacOS Ventura, you have to add the virtualbox__intnet: true flag on each "app".vm.network.  So the above becomes:
config.vm.define "app1" do |app|
  db.vm.hostname = "orc-app1.test"
  db.vm.network :private_network, ip: "<IP_ADDRESS>", virtualbox__intnet: true
end

Now, that all said, I'm reading this book to learn ansible as well as vagrant... so I am in no position to propose a solution for ALL or even a subset of OSes that can be used to run vagrant... What I am proposing is a disclaimer that users of MacOS Ventura note this subtle but potentially breaking changes that were introduced via Ventura.
Cheers, loving the book so far and the videos!

Honestly I'm considering moving to a new model instead of Vagrant (or at least Vagrant + VirtualBox) for the book examples... we'll see.

Thanks for posting the solution @KPomorski.

This is happening to me as well on Catalina 10.15.7, adding virtualbox__intnet: true did make the error disappear. VBox 7.02

I'm still on Montery and am having this problem. I confirm that adding virtualbox__intnet: true works for me too.
using vagrant and virtualbox was clever, but I wonder if it's time to test out vagrant and docker? https://developer.hashicorp.com/vagrant/docs/providers/docker

@ajisrael @KPomorski Could you please post your fully working Vagrant file from chapter 3? I've tried to manually edit, but something is still tripping me up. Thanks!


Changed behavior of stats command and added a players command.

The stats command's behavior has been to ping every person already
playing. The solution placed into practice here is to split the
more annoying (and frankly, mostly unnecessary) half of the command
into a different command for use when actually wanted/needed.

Oh wow good job update the repo six months late after I submit the patch.


Align latex with text

Summary
Align text with the latex.
Ticket Link
https://mattermost.atlassian.net/browse/MM-45466
Release Note
Fix inline latex alignment

@jgilliam17 For testing this, apart of what is in the ticket, would be great to test the behavior with other markdown structures, like inline images, and any other combination that may move things around in the text. Thanks!

Building app in separate branch.

Successfully building:
https://circleci.com/gh/mattermost/mattermost-mobile/27068
https://circleci.com/gh/mattermost/mattermost-mobile/27067

Artifact links:
https://output.circle-artifacts.com/output/job/dc210b8e-bbd2-4af2-bc2c-4f0fec813e67/artifacts/0/tmp/artifacts/Mattermost_Beta.apk
https://output.circle-artifacts.com/output/job/c16c4b84-a2d6-4aa3-a081-05e3e4cde543/artifacts/0/tmp/artifacts/Mattermost_Beta.ipa

Thanks @larkox
I see an issue with bolding of the text.
Custom emoji and text are displaying as expected, as well as latex and inline latex as originally reported


Add API function for list of allowed commands with number of parameters

When loading missions for agents to run, it is sometimes important to know what actions the mission permits. This happens when the agent is able to cope with both discrete and continuous actions, for example. We see this in the human action component and the rl-framework.
For discrete commands it makes sense to have an API function that returns a list of the allowed commands: { "move 1","turn 1", ... }. For continuous actions this is less obvious, but maybe a list of the verbs is useful: { "move", turn", ... }

Suggestion:
vector<string> MissionSpec::getListOfCommandHandlers() const;
vector<string> MissionSpec::getAllowedCommands(const string& command_handler) const;


Map Search: API Caching

AWS MAP_SEARCH_API is caching result which is a problem because new searches returns and old response. @a6wu

@i8wu I've removed the cache

After some painstaking trial and error I've gotten API caching working with query strings.
Dev API URL
Basically:

Enable API cache in Stages
Add query string parameters to Resources > GET > Method Request and check caching

Additional steps if above didn't work:
-Flush API cache
-Clone API and re-deploy (if you get 500 error try re-adding lambda method in Resources > GET > Method Request)


Remove the need to specify IDL env var location

This PR removes the need for the RS_MATTER_IDL_DIR environment variable that points to the location of the Matter Clusters' IDL file.
The inconvenience of this environment variable should not be underestimated:

While the rs-matter project does have a .cargo/config.toml file listing the env var, this is only helping the Continuous integration build of the rs-matter library itself
Yet, when listing a dependency to rs-matter, the user still has to declare its own version of the env var which ideally must point to... the same IDL file which is checked-in in the rs-matter GIT repo. So in a way, the user must have the rs-matter repo checked out somewhere, just because of the IDL file; UPDATE: moreover, the checked out rs-matter GIT repo should correspond exactly to the one published on crates.io or else, it might mis-compile itself, if we - ourselves - use the IDL file to generate our own clusters - which is already the case albeit for demoing purposes - with the on_off cluster.

The PR completely bypasses all of this by

Moving the rs-matter/idl folder as a sub-folder of rs-matter-macros-impl/src
Using include_str! to include the content of the IDL file - at build time - in the macro generating code

@andy31415 @kedars ^^^

@ivmarkov should we add a separate issue to support custom clusters?
Right now our macros will include all CSA-spec defined clusters (and a unit-testing one) however custom app clusters would need a different IDL.
Low priority since anyone can use the example in rs-matter-macros to create their own macro.

Yes, let's at least have an issue for that.


No error on bind to non-existing exchange

I try to bind queue to non-existing exchange, but future is not resolved with error, instead I get such lines in log
[2019-08-06T12:26:34Z ERROR lapin::channel] Channel 3 closed by 50:20 => Soft(NOTFOUND) => NOT_FOUND - no exchange 'non_existing_exchange' in vhost '/'
[2019-08-06T12:26:34Z ERROR lapin::connection] Connection error

and future stays unresolved forever.
You may see failing test here https://github.com/fan-tom/lapin/blob/96e481b4e7953795a83ceb972af78c1536427ce7/futures/tests/connection.rs#L60

Thanks, will give it a look once I get back from vacations
On Tue 6 Aug 2019 at 14:34, Alexey Gerasimov<EMAIL_ADDRESS>wrote:

I try to bind queue to non-existing exchange, but future is not resolved
with error, instead I get such lines in log
[2019-08-06T12:26:34Z ERROR lapin::channel] Channel 3 closed by 50:20 => Soft(NOTFOUND) => NOT_FOUND - no exchange 'non_existing_exchange' in vhost '/'
[2019-08-06T12:26:34Z ERROR lapin::connection] Connection error
and future stays unresolved forever.
You may see failed test here
https://github.com/fan-tom/lapin/tree/bug/bind_to_nonexisting_exchange
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/sozu-proxy/lapin/issues/191?email_source=notifications&email_token=AABWNXUPV4CE2A43ATCCB6TQDFVUTA5CNFSM4IJV3SK2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HDT27KA,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABWNXSHHFWUJSVN4IWE5ILQDFVUTANCNFSM4IJV3SKQ
.

Didn't properly dig into it yet, but could you try again with 0.26?

Unfortunately, no. Error handler set on client is invoked, but future is not resolved

Hmm, 0.26.1 might be better then. 0.26 fixed some connection error handling, 0.26.1 fixes the same wrt channel errors

Oh, this one is a little bit trickier than I thought. I'm fixing it now

This is now fixed in 0.26.3


Docker Deployment

The changes to maxcut.lst, qiskit.py and QiskitMaxCutSolver.java will be updated in #12 which streamlines external handling of solver files. From what I can tell, the rest of of docker deployment isn't affected by this though.

The changes to maxcut.lst, qiskit.py and QiskitMaxCutSolver.java will be updated in #12 which streamlines external handling of solver files. The rest of of docker deployment might not be affected by this. However you seem to copy gams and qiskit folders explicitly. In #12 those folders will be moved to the resources folder. This might need to be adjusted here as well.

I don't think Python or GAMS can read files from within JARs, so it's kind of unnecessary to package the scripts with the JAR file. I could just copy the src/main/resources folder to the docker container but that seems kind of unnecessary. Is #12 urgent or can it wait until we had the time to discuss this?


Add Bits.sub - jonathanrlouie

Update to the new syntax from Moonad#16

This is nice, but a bit too long. We should just use the same algorithm as Bits.inc?

@MaiaVictor I'm not seeing how Bits.sub can use the same algorithm as Bits.inc. Can you elaborate a bit on how that would work?

Just had a realization. Would this be better?
Bits.sub(a: Bits, b: Bits): Bits
  Bits.reverse(Bits.sub.go(a, b, Bits.e))

Bits.sub.go(a: Bits, b: Bits, bits: Bits): Bits
  case b {
    e: case a {
      e: bits,
      o: Bits.sub.go(a.pred, b, Bits.o(bits)),
      i: Bits.sub.go(a.pred, b, Bits.i(bits))
    },
    o: case a {
      e: Bits.sub.go(a, b.pred, Bits.o(bits)),
      o: Bits.sub.go(a.pred, b.pred, Bits.o(bits)),
      i: Bits.sub.go(a.pred, b.pred, Bits.i(bits))
    },
    i: case a {
      e: Bits.e,
      o: Bits.sub.go(a.pred, Bits.inc(b.pred), Bits.i(bits)),
      i: Bits.sub.go(a.pred, b.pred, Bits.o(bits))
    }
  }

I also realized that I can't update this branch, since I don't have permissions. Do I need to create a separate PR?

I meant in the sense of creating a Bits.dec algorithm and then applying it n times. But in retrospect, that will be slow in non-optimal evaluators. Your code is clean and nice. Seems like it is conflicting though. @MaisaMilena can you check if it type-checks and merge?
Thanks for the contrib! (:

@jonathanrlouie can you open a new PR with your solution? As you can't update this PR I will close it.


Doc Fixit: examples/cpp/helloworld/README.md

Use 'RegisterService' for registering async services.

LGTM. Doc change only. Merging


fix: header authorization

:tada: This PR is included in version 1.0.4 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


False "unresolved import" error for "use chrono_tz::Tz"

I get an incorrect "unresolved import" on the use chrono_tz::Tz; line in
// Cargo.toml dependency: chrono-tz = "0.5"
use chrono_tz::Tz;

fn main() {
    let _tz = &Tz::Zulu;
}

with VS Code, latest automatically installed rust-analyzer. cargo check returns no errors.

You need to enable proc-macro support using
{
    "rust-analyzer.cargo.loadOutDirsFromCheck": true,
    "rust-analyzer.procMacro.enable": true,
}

You need to enable proc-macro support using
{
    "rust-analyzer.cargo.loadOutDirsFromCheck": true,
    "rust-analyzer.procMacro.enable": true,
}

Doh, I should have checked that, thanks. Can I just close this issue?

Doh, I should have checked that, thanks. Can I just close this issue?

Yes :-)

Yes :-)


Can anyone, please recompile the Bytecode for ESP8266

It seems to me that the bytecode for ESP8266 only works for Micropython version 1.9.1
Can anyone please recompile for version 1.9.3 and/or 1.94?
Thanks

Using mpy-cross is a quick and painless way to compile bytecode. You need to make sure you pip install the correct version for your micropython version though.

I've just built it myself for 1.11 but maybe some people find it helpful if there is a download link for the latest micropython versions, time is scarce!

mpy_cross ina219.py -march=xtensa
should output ina219.mpy. copy that over to the ESP and it should work like a charm. This has the advantage that they can do it for any version they please.


⬆ Migrate to upath >= 0.2.0

Tried to migrate and got a bug https://github.com/fsspec/universal_pathlib/issues/216

Nice! This is much prettier.


hydration/caching gives me unexpected results

Hydration is not giving me the expected information in the given scenario.
I'm executing a filtered query, which will return some fields for given user _ids.

    $qb = $this->dm->createQueryBuilder('CSP\Domain\User\Document\User')->select($fields)->field('_id')->in($oids);
$users = $qb->getQuery()->execute();

After that, If I execute a findOneBy to a previous used _id (previous query), it will return the previous cached/hydrated document (filtered) instead of the new one (full document)

    $userDocument = $this->userDocumentRepository->findOneBy($criteria);

My guess is that hydration should only affect to exact queries, as it is not the same: "db.users.find({id:1}, fields)" != "db.users.find({id:1})"

I believe there's not much we can do automatically, your first query has registered documents in the UnitOfWork and later queries for these documents will return that very instances (their data could be updated by calling ->refresh() while building query but unfortunately there's no way to pass that hint via DocumentRepository).
The situation can be fixed manually by calling $dm->refresh($userDocument) after fetching it if you know that previously you were querying for part of objects.

If mongo information changes between both queries, because an update query, is this situation still happening?
Refresh could be a solution, I'm actually doing queries with hydrate(false) to avoid this problem.

If mongo information changes between both queries, because an update query, is this situation still happening?

If you run an update with Query then yes, we have scheduled a documentation improvement for this (#880 with all discussion). There's a lot of place to improve here but it's also hard to make a good change.

Documentation has been added to #1203.


Address 66062 - summary report support for sub-results

Description
See https://bz.apache.org/bugzilla/show_bug.cgi?id=66062
we need a way to control sub-results in the summary report from jmeter's GUI.
Motivation and Context
Cannot see the sub-results in situations where you need them.
How Has This Been Tested?
Tested on our data sets, and JUnit included.
Types of changes
Add new ability to control the summary results for sub-results. Previously they are not shown at all.
Checklist:

[ ] My code follows the code style of this project.
[ ] I have updated the documentation accordingly.

awesome looks like there are already messages so i can switch over to using JMeter ui elements
sample_scope_all=Main sample and sub-samples
sample_scope_children=Sub-samples only
sample_scope_parent=Main sample only

Codecov Report

Merging #715 (994c562) into master (cbacd08) will increase coverage by 0.03%.
The diff coverage is 83.78%.

@@             Coverage Diff              @@
##             master     #715      +/-   ##
============================================
+ Coverage     55.23%   55.26%   +0.03%
- Complexity    10382    10391       +9
============================================
  Files          1061     1061
  Lines         65763    65789      +26
  Branches       7530     7533       +3
============================================
+ Hits          36322    36358      +36
+ Misses        26841    26829      -12
- Partials       2600     2602       +2

Impacted Files
Coverage Δ

...a/org/apache/jmeter/visualizers/SummaryReport.java
83.87% <83.78%> (+11.42%)
:arrow_up:

.../java/org/apache/jmeter/samplers/SampleResult.java
81.46% <0.00%> (+0.22%)
:arrow_up:

...c/main/java/org/apache/jmeter/util/Calculator.java
53.75% <0.00%> (+2.50%)
:arrow_up:

Continue to review full report at Codecov.

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


Shorten the Windows build-from-source path.

This is to keep the total length down below the 260 character limit imposed by Windows by default.
Signed-off-by: Chris Lalancette<EMAIL_ADDRESS>This should fix #2604

Only removing 9 characters makes me think that we might run into this issue again in the future, but if it fixes the current issue, then LGTM!

Yeah, we probably will.  Especially if we choose a distribution name that is slightly longer.  This does fix it currently, so I think that's a good reason to put this in for now.


Bugfix/server connection release

Fixing https://github.com/Yakifo/amqtt/pull/101

I'm a little confused about the general exception handling in this block. I'm wondering if it wouldn't make more sense to change the base class to AMQTTException of  NoDataException, MQTTException and CodecException here https://github.com/Yakifo/amqtt/blob/master/amqtt/errors.py
This would allow to catch them all at once. But I saw that the writer was not closed here and I'm wondering what the reason was and if the writer needs to be closed in the added exception handling of NoDataException as well. But that can be tested/treated in another MR.

LGTM


config(tikv): remove required contexts on integration tests

tikv: remove required contexts on integration tests.
All integration test will be triggered after pr  merged

/ok-to-test

/merge

/cc @nolouch