[aavegotchi-agip] fix missing gotchi data with other endpoint

Fixes issue with missing gotchi data, we are aware of open proposals and still request the update be made. thanks

Hey @candoizo i get this error with latest snapshot
    Errors found in subgraphRequest: https://api.thegraph.com/subgraphs/name/aavegotchi/aavegotchi-core-matic[{"locations":[{"column":6,"line":1}],"message":"Unexpected `end of input`\nExpected `{`, `Name`, `(`, `$`, `:`, `=` or `)`"}]

oh, the filter for Object.entries(res).length > 0 on that query which seemed to fix it in my tests even when using the more flag but I will try another way. now it will succeed, thanks @ChaituVR

@candoizo Just waiting for one more PR to be merged before this going live, will update you once this change go live ;)

@candoizo Changes should be live now, Thanks for waiting :)


ROX-15780: Add unit tests for diagnostic bundle

Description
Add unit tests that require mocked global db
Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.
Testing Performed
TODO(replace-me)
Use this space to explain how you tested your PR, or, if you didn't test it, why
you did not do so. Valid reasons include, for example, "CI is sufficient",
"No testable changes". Feel free to attach JSON snippets, curl commands,
screenshots.
In addition to reviewing your code, reviewers must also review your testing
instructions and make sure they are sufficient.

Current dependencies on/for this PR:

master

PR #5231

PR #5426

PR #5454   👈

This comment was auto-generated by Graphite.

/retest

@janisz queued this pull request to merge with Graphite.


Added dbt-azuresynapse

Description & motivation
Added a reference to dbt-azuresynapse a community contributed adapter for Azure Synapse DW an azure big-data-warehouse offering.
Edited

website/docs/docs/supported-databases.md

Added

website/docs/reference/warehouse-profiles/azuresynapse-profile.md

@jtcohen6 Good catch above. I have committed your suggestion.

@mattberns Last thing: could you add the new file reference/warehouse-profiles/azuresynapse-profile to this list, so that it will show up on the sidebar?

@jtcohen6 Jeremy when is the next release of the docs to the production site? It would be good to have a reference for future PRs if I add to docs here. Is there an update cadence for current branch?

The production site is continuously deployed from the current branch. Check it out: https://docs.getdbt.com/reference/warehouse-profiles/azuresynapse-profile

@mattberns The production site is continuously deployed from the current branch. Check it out: https://docs.getdbt.com/reference/warehouse-profiles/azuresynapse-profile

Ah! Had to clear my cache!


Handle multiple requester clients

Bugfix to handle multiple work order requester for Ethereum
This commit handles multiple work order requests from multiple requesters
but not simultaneously. The 'nonce' field in any transaction needs to be
unique and equal to one more than the number of transactions submitted
with the account being used. This needs a synchronization between the
requesters by some means. In a future implementation, some central counter
generator service could be used which would also hold multiple signing
accounts and return counter for account requested. Refer https://github.com/ethereum/wiki/wiki/Glossary to
look for Account nonce.
But with the current implementation only a single account is being considered.

Signed-off-by: Rajeev Ranjan<EMAIL_ADDRESS>

Raise another PR with separate commit.


update build constraints with Go 1.17

Codecov Report

Merging #1216 (a942542) into main (37edbaf) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #1216   +/-   ##
=======================================
  Coverage   57.57%   57.58%
=======================================
  Files         127      127
  Lines       21326    21326
=======================================
+ Hits        12279    12280    +1
+ Misses       7556     7555    -1
  Partials     1491     1491

Impacted Files
Coverage Δ

cmd/mount_unix.go
49.12% <ø> (ø)

pkg/chunk/utils_unix.go
73.33% <ø> (ø)

pkg/meta/redis.go
71.69% <ø> (ø)

pkg/meta/redis_lock.go
75.00% <ø> (ø)

pkg/meta/sql.go
68.34% <ø> (+0.66%)
:arrow_up:

pkg/meta/sql_lock.go
72.84% <ø> (ø)

pkg/meta/sql_mysql.go
100.00% <ø> (ø)

pkg/meta/sql_pg.go
100.00% <ø> (ø)

pkg/meta/sql_sqlite.go
100.00% <ø> (ø)

pkg/meta/tkv_mem.go
86.75% <ø> (ø)

... and 42 more

Continue to review full report at Codecov.

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


Add Alias function to data-admin in Django

Overview
We need to add the alias function to data admin user in Django so users can update it.
Action Items

[ ] Add the functionality for data-admin to be able to update the alias function in django

Resources/Instructions

@cnk or @emecas when you have the chance, could you please add the above functionality so we can start populating the org tags and any aliases we find? Thank you!

I have added the ability to manage aliases to the data-admin user on https://test-civictechindexadmin.herokuapp.com/admin/


Make translation works

Minor update for config flow translation file
Fix states sensor translation.
Add french translation

Remove integration name in error message string during config flow to ease usage in a cookiecutter template.

Obsolete since #45


TypeError: the JSON object must be str, not 'bytes'

Hi,
I am trying to build my sphinx documentation with your builder. Unfortunately it fails, which is my motivation for posting this issue.
Issue Details
I called the builder using
sphinx-build -E -b confluence -d documentation/doctrees doc_source documentation/confluence
The corresponding error log contains the following data:
# Sphinx version: 1.6.2
# Python version: 3.5.2 (CPython)
# Docutils version: 0.13.1 release
# Jinja2 version: 2.9.6
# Last messages:

# Loaded extensions:
Traceback (most recent call last):
  File "[...]/sphinx/cmdline.py", line 305, in main
    opts.warningiserror, opts.tags, opts.verbosity, opts.jobs)
  File "[...]/sphinx/application.py", line 234, in __init__
    self._init_builder()
  File "[...]/sphinx/application.py", line 311, in _init_builder
    self.builder.init()
  File "[...]/sphinxcontrib/confluencebuilder/builder.py", line 102, in init
    self.publisher.connect()
  File [...]/sphinxcontrib/confluencebuilder/publisher.py", line 62, in connect
    'limit': 1
  File "[...]/sphinxcontrib/confluencebuilder/rest.py", line 54, in get
    json_data = json.loads(rsp.content)
  File "/usr/local/Cellar/python3/3.5.2_1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/json/__init__.py", line 312, in loads
    s.__class__.__name__))
TypeError: the JSON object must be str, not 'bytes'

Personal Fix
In order to fix the issue, I modified

[...]/sphinxcontrib/confluencebuilder/rest.py:54

and updated it to
            json_data = json.loads(rsp.content.decode("utf-8"))

@T-002, thanks for the information.
This should already be fixed on master (see #32; and also fa206b18982ad7765fd23e57b47718c6795df5ac). Once #53 is merged into master after a review, we'll close up all the active issues in milestone 0.7 and push out a release.

Thanks a lot. :)
I just installed it via pip ;)


subtitle-encoding option - how to use

I'm seeing issues with missing special characters in auto-downloaded danish subtitles - It seems like I need to use the subtitle-encoding option to fix this. This option isn't documented though - any quick pointers on what it'll take as input?
Thanks for your work on this script - I use it tons.

Turns out it was a broken subtitle on the provider side - sorry about the confusion.


Single access token mode - token expiry and refresh

When OAUTH_SINGLE_ACCESS_TOKEN is set to True then instead of always creating a new token we check whether one with the same client user and scope already exists and we return that instead:
def get_access_token(self, request, user, scope, client):
    try:
        # Attempt to fetch an existing access token.
        at = AccessToken.objects.get(user=user, client=client, scope=scope)
    except AccessToken.DoesNotExist:
        # None found... make a new one!
        at = self.create_access_token(request, user, scope, client)
        self.create_refresh_token(request, user, scope, at, client)
    return at

Note that this does not check for token expiry when fetching the access token.
If OAUTH_DELETE_EXPIRED is set to False (default) then if we hit the access_token endpoint with grant_type=refresh_token and pass the refresh token from a previous access token then the refresh process will just create a second access token:
def refresh_token(self, request, data, client):
    """
    Handle ``grant_type=refresh_token`` requests as defined in :rfc:`6`.
    """
    rt = self.get_refresh_token_grant(request, data, client)

    # this must be called first in case we need to purge expired tokens
    self.invalidate_refresh_token(rt)
    self.invalidate_access_token(rt.access_token)

    at = self.create_access_token(request, rt.user, rt.access_token.scope,
            client)
    rt = self.create_refresh_token(request, at.user, at.scope, at, client)

    return self.access_token_response(at)

The invalidate_access_token function will just set the expiry date and we end up with 2 access tokens in our db with the same client, user and scope.
This results in get_access_token above bombing out at
 AccessToken.objects.get(user=user, client=client, scope=scope)
with a multiple objects returned error.
I think that OAUTH_SINGLE_ACCESS_TOKEN should either automatically enable  OAUTH_DELETE_EXPIRED or at a minimum I think the old access token should be deleted on refresh.
I'm happy to reopen this as a pull request if the above solution sounds good.

Hi , how could I achieve this using Oauth Tool Kit?


Added scope field to checks

Closes #150
Closes #157
Closes #161
Added a scope field to the checks for single-field, multi-field or register.  Right now pulled out during the df_to_json formatter only.  I thought about putting logic there to add the field only to the json, but that adds looking for 'E3000' to be treated differently so decided to put the scope at the source check.
Also added a check if the validation id isn't in more_than_2_fields = ["E2014", "E2015", "W2035", "W2036", "W2037", "W2038", "W2039"] to call reversed(tuple(rec_df.groupby(by='field_name', sort=False))) to flip any of the 2-field multifield check outputs so that the ordering aligns with the FIG.

Adding fig_link to json for #161

rolled into #165


Need for Sequential Consistency in Contract Upgrade Proposals to Prevent Potential Concurrency Issues

I believe that contract upgrades are critical operations, and we should prevent potential concurrency issues. For instance, Proposal 1 suggests upgrading the implementation to version 1.1, while Proposal 2 suggests upgrading the implementation to version 1.2. If the approval sequence turns out to be Proposal 2 followed by Proposal 1, the contract will actually be upgraded to version 1.1. From an implementation perspective, we should leverage the incremental nature of proposal IDs for protection. If a later upgrade proposal passes, earlier proposals should not be executable, even if they are passed.

Currently, contract upgrades are serialized, so there are no two upgrade proposals for the same contract at the same time.
When an upgrade proposal is being voted on, it is not allowed to initiate a second upgrade proposal.
This is due to the design of UUPS, when upgrading a contract, you can use an _authorizeUpgrade() function to judge whether the upgrade can be passed, but when judging, the only information you can get is the agent address of the contract and the address of the new implementation.


Update e3dc-rscp to 1.2.1

Please update my adapter ioBroker.e3dc-rscp to version 1.2.1.
This pull request was created by https://www.iobroker.dev c0726ff.

RE-CHECK!

Automated adapter checker
ioBroker.e3dc-rscp

:thumbsup: No errors found

[ ] :eyes: [W171] "common.title" is deprecated in io-package.json
[ ] :eyes: [W105] "common.titleLang" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W109] "common.desc" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W156] Adapter should support admin 5 UI (jsonConfig) if you do not use a React based UI
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W513] "gulpfile.js" found in repo! Think about migrating to @iobroker/adapter-dev package

Add comment "RE-CHECK!" to start check anew


Naming Convention: Import from Historical Data Success Message

As an ECMPS user, I want the success message for 'Import from Historical Data' to be updated so that it is easier for the user to understand
Acceptance Criteria:
Given I am an ECMPS user importing QA data from historical QA data
When the import is successful and I see a success message
Then it says MP Configuration Name Test Data has been Successfully Imported'
Reference Screenshot from Import from File:

Test Case: TC4813
Test Passed


Don't open Palette when settings is open

This PR:

adds an editor kind to each editor view
adds the editor kind to check_condition
adds a condition to the palette actions to disallow opening behind the settings window
removes unused code

I'm not entirely certain what happened to the keymaps, but I think they should be using \n now consistently. Maybe.

I think it's probably easier to check if settings is active in the palette open code.

I would like to avoid special-casing more things. The palette should not assume anything about settings. We might introduce other dialogs in the future that should also disable palette opening, and we might also introduce new palette-style controls as well. This way, we don't need to touch the code except to introduce new editor types when needed.

What if the focus is not on the settings editor when the settings is open, and the key press was captured by the catch all?
I think the setting, palette, file picker, context menu, code actions etc should be popups, and only one popup can be active at a time.


corrected mistake

fixed issue #119
Corrected typo error in reducer @pradeeban please review

@Rahuljagwani, can you please review this?
I am not a Javascript expert. I only test for functionality most of the time.
Please feel free to constructively review each other's (and other people's) code contributions. It is an open-source project, after all. We appreciate both of your contributions.

@Rahuljagwani, can you please review this?
I am not a Javascript expert. I only test for functionality most of the time.
Please feel free to constructively review each other's (and other people's) code contributions. It is an open-source project, after all. We appreciate both of your contributions.

Sure @pradeeban, I will review it in sometime.

@pradeeban thanks for your comment and @Rahuljagwani for reviewing this PR

Yeah the team work is great , In the future also we both will try to improve Concore-editor functionality and make it  more robust

Yeah the team work is great , In the future also we both will try to improve Concore-editor functionality and make it  more robust


version of kombu needs to be updated for newer python

python 2.7.11 does not work with the version of kombu in requriements.txt.

Update kombu to at least 3.0.30 in requirements/dev.txt
kombu==3.0.30

Just to add a bit of useful context (hopefully), this appears to be the backtrace you get at kombu=3.0.24 which goes away after following @seanfcarroll's advice, above:
$ python app.py
Traceback (most recent call last):
  File "app.py", line 7, in <module>
    from celery import Celery
  File "/Users/kernst/devel/MLU/GrosseLab/flask-celery-example/venv/lib/python2.7/site-packages/celery/__init__.py", line 130, in <module>
    from celery import five
  File "/Users/kernst/devel/MLU/GrosseLab/flask-celery-example/venv/lib/python2.7/site-packages/celery/five.py", line 149, in <module>
    from kombu.utils.compat import OrderedDict  # noqa
  File "/Users/kernst/devel/MLU/GrosseLab/flask-celery-example/venv/lib/python2.7/site-packages/kombu/utils/__init__.py", line 19, in <module>
    from uuid import UUID, uuid4 as _uuid4, _uuid_generate_random
ImportError: cannot import name _uuid_generate_random

It might be helpful to change the issue title to be/include the error message ImportError: cannot import name _uuid_generate_random.


Decoding Error when running Ganache 2.7.0 on linux

Basically I am trying to see the content from a contract that does not have anything special besides that it saves the addresses from other two contracts that are being deployed first.
The migration of the contract looks like this:
var Oracle = artifacts.require("Oracle");
var SubsOracle = artifacts.require("SubsOracle");
var MyContract = artifacts.require("Customer1");
module.exports = function(deployer, network, accounts) {
deployer.deploy(MyContract, Oracle.address, SubsOracle.address);
};
And it is done after the deployment of the other 2 contracts.
The error comes when I try to access the contract from the Ganache GUI.
I guess not, but could it be because in that contract I am using low-level calls to the other two?
Thanks for your time. If more specific information is needed I will provide it.
PLATFORM: linux
GANACHE VERSION: 2.7.0
EXCEPTION:
UnknownBaseContractIdError: Cannot locate base contract ID 246$ of contract$ Customer1 (ID 132)
    at /tmp/.mount_ganachejPEvH/resources/static/node/node_modules/@truffle/decoder/lib/allocate/storage.ts:181:13
    at Array.map (<anonymous>)
    at allocateContract (/tmp/.mount_ganachejPEvH/resources/static/node/node_modules/@truffle/decoder/lib/allocate/storage.ts:178:59)
    at Object.getStorageAllocations (/tmp/.mount_ganachejPEvH/resources/static/node/node_modules/@truffle/decoder/lib/allocate/storage.ts:23:19)
    at TruffleContractDecoder.<anonymous> (/tmp/.mount_ganachejPEvH/resources/static/node/node_modules/@truffle/decoder/lib/interface/contract-decoder.ts:237:39)
    at Generator.next (<anonymous>)
    at fulfilled (/tmp/.mount_ganachejPEvH/resources/static/node/node_modules/@truffle/decoder/dist/interface/contract-decoder.js:5:58)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)

Having said that, it also has inheritance from an interface which is from my own code. In case it could cause any trouble.


Set System.version via Makefile-generated src/runtime/version.js module.

LGTM. I like yours better.

We should remove setCompilerVersion now.

done


Add TreeUpdateBuilder to support git_tree_create_updated

git_tree_create_updated requires a length and a contiguous array of
git_tree_update structures, each of which has a pointer to a C string.
Create a builder, TreeUpdateBuilder, to wrap that safely without
excessive copies.

@ehuss Fixed.


Unable to consume odata from on-prem S/4 system in this project - Getting destination not found error when deployed

Thanks for this tutorial. I have successfully followed and created this application as per the tutorial. However, I wanted to experiment and use an odata service from my on-prem S/4 system connected via cloud connector with basic authentication for the destination in BTP instead of public S/4 system. I added the Connectivity service in the resource section and also included it as a dependency in the service module in mta.yaml as per CAP documentation
capire-connectivity.
I am getting the following error, the error logs I pulled from CloudFoundry for the deployed app:

I am not sure why it's not able to find the destination , it works perfectly fine when I am using S/4HANA system in cloud as a backend. The only difference is the connectivity service which I need for on-prem.
Here's my full mta.yaml file in numbered screenshots:

I had to manually bind the Destination service to the Service application and restart the application for it to work.


test: support background_ddl_rate in recovery test

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?

Materialized views without backfill leaf nodes will not run in the background after this PR. e.g. StreamValues, DeltaJoin.
This is because backfill facilitates the recovery process of mviews.
This PR also supports background mviews in deterministic test framework. It will wait for the background ddl to complete by inserting a WAIT, and making sure it is created by querying the mview catalog.
This PR also supports randomly running mviews in background for recovery test by setting BACKGROUND_DDL variable.

Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

Passed. Now cleaning up this PR.

Hi, PTAL @BugenZhao @yezizp2012

The functionality LGTM, but I'm not sure if it's a good practice to change the create way of every mview in each slt by chance. Previously adding kill-rate in recovery test was to reduce the total test time in CI test, it's more like a operation action for recovery test. The background_ddl_rate somehow changes the test cases I think, what if user want to run some tests in foreground on purpose? I think maybe background_ddl tests is enough and already involved in recovery test to see if it's recoverable. And we can add some more tests under background_ddl and integration tests. 🤔

I agree that user may want to run some tests in foreground on purpose, and test recovery for it.
What about if I disable it by default for the original recovery test? And rerun these tests in a separate workflow (background recovery tests) in main-cron?
This test managed to catch several bugs and I would prefer to keep it since it includes more coverage, that would take a long time to add manually.


Use master for the source code for personal/organization webpages

This PR is for https://github.com/alshedivat/al-folio/issues/342 and makes the following changes:

Always push the generated website code to gh-pages.
Update the documentation for the personal/organization webpages.

Thank you for the PR! I'm 100% in favor of simplifying deployment.
Can you please somehow confirm that deploying user and organization pages to gh-pages actually works? A while back, it used to be the case that user and organization pages had to be deployed to master. Did something change recently?

@alshedivat Yes, even I remember this restriction. There is an option to configure a publishing source:

https://docs.github.com/en/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site#choosing-a-publishing-source

I am not sure if this was always there or recently introduced. I have set up my page using the same method - https://github.com/neerajgangwar/neerajgangwar.github.io


Early exit for corrupted PE images resources?

When experimenting with my own version of createdump on x86, the number of resource entries were unreasonably large (over thousands) but we were unable to detect this error.
https://github.com/microsoft/clrmd/blob/69db395bbcc3db1fbdb7bfa0bad31cafebbe72ea/src/Microsoft.Diagnostics.Runtime/src/Utilities/PEImage/ResourceEntry.cs#L130
A known problem is that we didn't check if PEImage.Read<T> returned a valid result.
https://github.com/microsoft/clrmd/blob/69db395bbcc3db1fbdb7bfa0bad31cafebbe72ea/src/Microsoft.Diagnostics.Runtime/src/Utilities/PEImage/PEImage.cs#L382

I also have this issue on my machine (Tizen armel). Printing a simple stack trace of an application (which normally has 40+ dlls loaded in memory) took 1m43.092s for a minidump and 0m13.167s for a minidump with heap.
count = 18328 + 63042
count = 0 + 0
count = 37500 + 58526
count = 0 + 1
count = 0 + 1
...

I have also noticed a problem like this in dotnet-dump's lm command. A huge perf problem that affects the first command run because the modules are enumerated to find the runtime module. Getting the Version for each PE image in the Linux core dump was taking way too long and failing.
The problem is the "layout" of managed PE modules. Some PE's are "file" layout and some are "loaded" layout. The "isVirtual" flag in the PEImage constructor needs to be set based on the layout, but there is no way to determine that in the core dump data reader. If the layout/isVirtual flag is set incorrectly, PEImage doesn't enumerate through the resources correctly, takes a long time because it is reading really long garbage strings, etc.
The solution I've been working (for release/1.1 for now since that is what dotnet-dump needs), is to skip all the PE's in the ELF reader module list.  IDataReader.EnumerateModules() is meant to return just native modules (like libcoreclr.so, etc) but the PE's show up because it uses the NT_FILE entries in the coredump and because the PE's are memory mapped by the runtime as shared named memory,
I think the best fix is too skip all the PE's (modules that ELFLoadedImage.Open can't open).  The managed assemblies can be enumerated at a higher level (ClrRuntime.Modules) without any problems.  dotnet-dump has a "clrmodules" command to do that.  The only thing that needs to be added to that is displaying the module Version a customer requested feature that caused all the problems in the native IDataReader.EnumerateModules implementation.
/cc: @leculver

I've fixed this in PR #620.
@swift-kim It would be interesting to take a look at why the those dlls don't correctly read PE image headers/resources.  #620 gives early outs so we won't spend as long failing to look up modules, but it feels like there's still an underlying bug here where we shouldn't be reading those huge counts.
If you have time to debug your scenario and take a look that'd help a lot.  If not no worries.

This version (and later) contains the fix:  https://www.nuget.org/packages/Microsoft.Diagnostics.Runtime/2.0.0-beta.20222.5

Ah the problem you are running into is possibly https://github.com/microsoft/clrmd/issues/475 where we are misinterpreting the layout.  I haven't tackled that issue yet.

@leculver Okay. I'll go through it after finishing some my jobs. Just note that I currently see this error with the recent changes. Maybe ReadSections() should return ImmutableArray<SectionHeader>.Empty instead of default.
sh-3.2$ dotnet stacktrace/PrintStackTrace.dll coredump-6424
Unhandled exception. System.NullReferenceException: Object reference not set to an instance of an object.
   at Microsoft.Diagnostics.Runtime.Utilities.PEImage.RvaToOffset(Int32 virtualAddress) in E:\public\clrmd2.0\src\Microsoft.Diagnostics.Runtime\src\Utilities\PEImage\PEImage.cs:line 191
   at Microsoft.Diagnostics.Runtime.Utilities.PEImage.CreateResourceRoot() in E:\public\clrmd2.0\src\Microsoft.Diagnostics.Runtime\src\Utilities\PEImage\PEImage.cs:line 249
   at Microsoft.Diagnostics.Runtime.Utilities.PEImage.get_Resources() in E:\public\clrmd2.0\src\Microsoft.Diagnostics.Runtime\src\Utilities\PEImage\PEImage.cs:line 107
   at Microsoft.Diagnostics.Runtime.Utilities.PEImage.GetFileVersionInfo() in E:\public\clrmd2.0\src\Microsoft.Diagnostics.Runtime\src\Utilities\PEImage\PEImage.cs:line 223
   at Microsoft.Diagnostics.Runtime.CoreDumpReader.CreateModuleInfo(ElfLoadedImage image) in E:\public\clrmd2.0\src\Microsoft.Diagnostics.Runtime\src\DataReaders\Core\CoreDumpReader.cs:line 114

@swift-kim Sorry about that, should be fixed as part of: https://github.com/microsoft/clrmd/pull/622.
I'll push a nuget package after it's built and signed.

Published here, should be usable in about an hour:  https://www.nuget.org/packages/Microsoft.Diagnostics.Runtime/2.0.0-beta.20222.8

@leculver It worked. Thanks!


Update 1_client_credentials.rst

What issue does this PR address?
Removing sentence about AddIdentityServerAuthentication in docs. Not actually used in Startup code sample. Unless I am misunderstanding and this is foreshadowing something later in the quickstart?
Does this PR introduce a breaking change?
No.
Please check if the PR fulfills these requirements

[X] The commit follows our guidelines
[ ] Unit Tests for the changes have been added (for bug fixes / features)

Other information:

thanks!


SerenityJS and Is.condition (ex. Is.clickable) timeout

Hi Jan,
Sometime knowing what timeout using SerenityJS can be challenging. Is it mocha, is it protractor, is it selenium, is it within serenity's code itself -> I think it may be good documentation material to sum-up what can be customized where, when it comes to timeout.
This said here is my question.
I need to be able to wait for a button to be clickable more than 5000ms. How can I custom the timeout in a expression such as Wait.until(Account.logout, Is.clickable()) ?
Wait.until(myButton, Is.clickable()),
Click.on(myButton),

I found out within protractor > built > expectedCondition.js
@example
 * var EC = protractor.ExpectedConditions;
 * var button = $('#xyz');
 * var isClickable = EC.elementToBeClickable(button);
 *
 * browser.get(URL);
 * browser.wait(isClickable, 5000); //wait for an element to become clickable
 * button.click();

Could you advise me on a way to express that wait within my scenario, but with a different timeout?
And is there a way, not to change the timeout wait by wait but globally (for every wait.until I use for ex.)?

I should add that my error is:
TimeoutError: The "myButton" button did not become clickable within 5000ms
[e2e] Wait timed out after 7831ms
In case mocha was not the right culprit :).

So thanks to an example of yours (this one) I realized, I could probably use Wait.upTo(...).until(...). And it looks like it does what I wanted. So I guess this issue can be closed.
Sorry for this long post and thanks again for all your work !
San.

 Although to be fair, this area deserves some better documentation so I'll look into that.


Use __dirname in tests so that cwd doesn't matter

Update relative paths in tests to use __dirname when constructing the path. This allows running the tests without changing the cwd to ./tests

But tests are run using npm test from tests folder? How would anyone run tests from another folder?

They can be run with mocha directly as well. I just configured vscode to run them and if you don't set the cwd, they fail


Basic badge not rendered in preview

Regression of a previous issue. Basic badges without parameters fail to render in preview. Example:

Now handles bare badges properly:

Confirmed in 2.0.9


Secrets rotation and Secrets semantics

It would be nice to be able to rotate secrets while the pod is still running.  This issue is to discuss how that might work.
Some things to think about:

Can we attach a new volume to a running container?  I don't think so.
Is the content of a secret mutable after creation?
What happens if you delete a secret that is in use by running pods?  I guess they keep running, but then new instances can't be created from the same template?
What happens if you modify the data in a pod (if that is allowed) or if you delete a secret and then create a new one with the same name?   Does kubelet notice that and update the volume of a running pod?
Given that the tmpfs is readonly bind mounted, if the kubelet could modify the data, how consistently would the pod see the changes?
If the kubelet does modify volume contents, should it do so in a way that is atomic (that is, make a second file tree, and then flip a hard link over once the change is complete?  Does that require a minimum number of path components to separate the bind mount root from the flippable hard link?
If the above, then we should document that clients need to not keep secrets files open indefinitely.
If containers keep files open after files on the tmpfs are deleted, the memory charges should migrate to the container (@vmarmol or @dchen1107 or @thockin might know better)
Is the behavior different for different secrets types?

Relevant to #4672

@pmorie

@bgrant0607

I'm really hoping to avoid having the kubelet be dynamically updating magic
volumes (run your own side-car), but I am not sure we can escape it with
secrets since there is info there that is meaningful to the kubelet itself..
On Fri, Feb 20, 2015 at 9:43 AM, Eric Tune<EMAIL_ADDRESS>wrote:

@bgrant0607 https://github.com/bgrant0607
--
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/4673#issuecomment-75285192
.

I think we should support dynamic updates. That makes the feature vastly more useful and reduces the complexity for clients tremendously. Immutable secret objects would induce cascading complexity: automatic name generation, automatic garbage collection of secrets not in use, etc. Plus, I doubt we could prevent users from updating the volume source to point to a new secret, which seems to have about the same complexity. In general, making things not updatable greatly complicates our user-facing configuration solution. We could potentially restart/recreate containers upon these kinds of updates for now, if that would simplify the implementation.
Additionally, we're going to want the same behavior for a dynamic config solution for our own components.

Also, I vote for atomic update. A lifecycle event can notify the containers that they should reopen the file(s).

Dynamic updates can be achieved by running a secret-syncer sidecar.  I'm
just trying to convince myself that this is not a viable answer.
As for atomic updates, easier said than done.  The only atomic op is
rename() and that is singular AND only works for directories iff the
destination does not already exist.
We could do something like put secrets into a subdir of the volume and then
flip a symlink with rename.
e.g.
mkdir /path/to/volume/.update_in_progress
write secrets to /path/to/volume/.update_in_progress
mv /path/to/volume/.update_in_progress /path/to/volume/new_timestamp
ln -s new_timestamp /path/to/volume/.updated_link
rename /path/to/volume/.updated_link /path/to/volume/current
It's ugly and we still have to deal with cleanup, but it's the only way I
know.
On Fri, Feb 20, 2015 at 10:48 PM, Brian Grant<EMAIL_ADDRESS>wrote:

Also, I vote for atomic update. A lifecycle event can notify the
containers that they should reopen the file(s).
--
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/4673#issuecomment-75359254
.

@erictune @thockin @bgrant0607 I am torn on this one personally.  One thing I want to point out while I gather my thoughts is that I think we have a similar problem in this use-case to other ones that have been mentioned:

Expose labels to containers (#560)
Dynamic configuration (#1553)
Exposing secrets as env vars (#4710)

I now think we probably don't need to prioritize automated rotation at this time.
Most pods are going to have a way that they can be updated to have a new image or new flags.  Updating the secret can use that same workflow, assuming secret changes are infrequent.
There are two cases where secrets might change frequently, but I don't think these are that important right now:
First, short lived tokens.  We've talked about having a way to hold something like an OAuth Refresh Token in the apiserver, and then have it generate access tokens periodically, and "rotate" them for clients.  While this has the nice property of protecting the long lived secret, clients are probably not going to expect to have the access token changing underneath them, and it has the drawback of giving the client the access token even when it doesn't need it (if it has time-varying behavior).
Second would be a server that stores multiple changing secrets, like username/password combinations for a website.  This case doesn't match the current secrets implementation: secret modifications made by the pod won't be remembered.

TL;DR
I don't think we should work on secret rotation right now.
And we should make secrets immutable.  I'll file a narrower issue for that.

I'm fine closing this for now - it's a much larger design issue and not priortiy


Silex 2.x support

Update code so it becomes compatible with Silex 2.x series.

Sorry for the late reply. I will check the PR soon and thank you for your contribution!


Contribute To this Project

I wish to contribute to this project

I wish to contribute to this project

feel free to contribute! The development branch is dev :)


Fix/issue-1000 Updated mark call related changes

Fix/Issue-1000
Remove Assignment if statement which throws Assignment when not found, instead send the Assignment object with no condition details. This way, the user can mark this Assignment.
Fix/Issue-999
Remove unnecessary experimentType property from Assign & Mark call of V5

v4 and v5 look like they should have payload removed as a parameter in data.assignedCondition object, it causes an error in v4 library mark calls but the mark call in the controllers doesn't even utilize this property as far as I can tell.


Improve logging to help isolate a bug

{"level":"debug","ts":"2023-03-20T21:24:01Z","logger":"controller.VpcEndpoint","msg":"Found infrastructure name:","controller":"vpcendpoint","controllerGroup":"avo.openshift.io","controllerKind":"VpcEndpoint","VpcEndpoint":{"name":"service-cluster-endpoint","namespace":"openshift-aws-vpce-operator"},"namespace":"openshift-aws-vpce-operator","name":"service-cluster-endpoint","reconcileID":"46cc7b16-4208-40d6-aa36-47e17d4187d2","name":"hs-sc-ge77jaj60-cw28q"}
{"level":"debug","ts":"2023-03-20T21:24:01Z","logger":"controller.VpcEndpoint","msg":"Found cluster tag:","controller":"vpcendpoint","controllerGroup":"avo.openshift.io","controllerKind":"VpcEndpoint","VpcEndpoint":{"name":"service-cluster-endpoint","namespace":"openshift-aws-vpce-operator"},"namespace":"openshift-aws-vpce-operator","name":"service-cluster-endpoint","reconcileID":"46cc7b16-4208-40d6-aa36-47e17d4187d2","clusterTag":"kubernetes.io/cluster/hs-sc-ge77jaj60-cw28q"}
{"level":"debug","ts":"2023-03-20T21:24:01Z","logger":"controller.VpcEndpoint","msg":"Parsed region from infrastructure","controller":"vpcendpoint","controllerGroup":"avo.openshift.io","controllerKind":"VpcEndpoint","VpcEndpoint":{"name":"service-cluster-endpoint","namespace":"openshift-aws-vpce-operator"},"namespace":"openshift-aws-vpce-operator","name":"service-cluster-endpoint","reconcileID":"46cc7b16-4208-40d6-aa36-47e17d4187d2","region":"us-east-1"}
{"level":"debug","ts":"2023-03-20T21:24:02Z","logger":"controller.VpcEndpoint","msg":"Selecting vpc id","controller":"vpcendpoint","controllerGroup":"avo.openshift.io","controllerKind":"VpcEndpoint","VpcEndpoint":{"name":"service-cluster-endpoint","namespace":"openshift-aws-vpce-operator"},"namespace":"openshift-aws-vpce-operator","name":"service-cluster-endpoint","reconcileID":"46cc7b16-4208-40d6-aa36-47e17d4187d2","vpcId":""}

For reasons that aren't entirely clear yet, somehow we are selecting a vpcId: "", which shouldn't be possible. This PR just adds some additional logging to help isolate how this is happening.
OSD-15465

/lgtm

Codecov Report

Merging #150 (3f49ed7) into main (c312ced) will decrease coverage by 0.08%.
The diff coverage is 0.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #150      +/-   ##
==========================================
- Coverage   41.82%   41.75%   -0.08%
==========================================
  Files          29       29
  Lines        1585     1588       +3
==========================================
  Hits          663      663
- Misses        843      846       +3
  Partials       79       79

Impacted Files
Coverage Δ

controllers/vpcendpoint/helpers.go
36.36% <0.00%> (-0.08%)
:arrow_down:

pkg/aws_client/vpc_endpoint.go
40.62% <0.00%> (-0.87%)
:arrow_down:


Refactoring Enso_File to be path based

Pull Request Description

Closes #9289
Ensures that we can refer through Enso_File to files that do not yet exist - preparing us for implementing the Write functionalities for Enso_File (#9291).

Important Notes

Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[x] The documentation has been updated, if necessary.
[ ] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[x] All code follows the
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
All code has been tested:

[x] Unit tests have been written where possible.
[ ] If GUI codebase was changed, the GUI was tested when built using ./run ide build.

Marking as ready for review.
I thought I'd consider some caching solution, but honestly we are not accessing the service more than in case of e.g. S3 files.
There is some opportunity for caching (i.e. we can cache some asset information from directory listing, currently we get that info, drop it and if asked about the file - re-fetch it), but it feels like a separate feature - so if we want to implement it - that should be done as a separate PR.


Remove custom decomposition for MHLO decomposition lowering

LLVM patch adds custom support for the math log1p and expm1 operations for the SPIRV backends. Remove the MHLO
to MHLO lowerings as they are no longer needed.
https://reviews.llvm.org/D118081

Even if not needed for this particular case anymore, are these legalizations still useful?

Not really? This should be corrected at a lower level if they  were. How to decompose is very backend specific.


Added Portuguese layout

Description
Added Portuguese layout
Checks

[Yes ] Tests ( npm run test ) are passing

For Portuguese we need two layouts ptBR and ptPT, so closing it


Permalink icon is not

Not sure why it's not, but we should make it not not.

arguably worse here :joy:


how to deploy LangGraph

How to deploy LangGraph locally, can you provide detailed instructions? I have downloaded LangGraph Studio and want to deploy it locally. I’m not sure what to do next.

If you have LangGraph studio downloaded locally, you can follow these instructions to get up and running: https://github.com/langchain-ai/langgraph-studio/blob/main/README.md
Ensure you have docker running. The langgraph.json config file is in the root of this repository.
Then once the app is running, in the bottom left of the screen you'll see a localhost URL. Copy that, and replace the current localhost URL of LANGGRAPH_API_URL in src/constants.ts.
Also ensure you have all the necessary environment variables set.


Access tokens get logged

Shouldn't these be removed from the logs?

Absolutely, yes.
We should implement https://github.com/vector-im/riot-ios/issues/2071 to avoid accident.

Closed with #2071 as the leak seems to be in the logs for http request errors.


[Broken CI] latest release modified build location

v1.5.0 modified the location of built binaries which breaks ci and therefore the pipeline. as such, 1.5.0 isn't actually live yet 😞
I'll try to resolve this ASAP (hopefully in the next few hours)

ah - the deeper issue here seems to be vcpkg has moved to a bin directory of msbuild.<arch>.<configuration> - we should probably migrate our build to those folders, and at minimum we'll need to update the Nuget.vcxproj that copies things into place for building our nupkg

Sorry for the trouble!
Is there a way that you can just use ./bootstrap-vcpkg.bat instead of calling MSBuild? In the future, we may move to using CMake on windows, but ./bootstrap-vcpkg.bat will definitely continue to work (and continue to place the executable in the root).

No worries @ras0219-msft - that's a great idea, I've opened #29 to track


Fail Install Mxnet Windows 10

Fail of install
I use this guide https://gist.github.com/thirdwing/89aa9bfc588ade138496e6932072152c
Fail on command
R CMD INSTALL --no-multiarch R-package
C:\GPU\mxnet>R CMD INSTALL --no-multiarch R-package

installing to library 'C:/Users/Statislove/Documents/R/win-library/3.4'
installing source package 'mxnet' ...
** libs
make: Nothing to be done for `all'.
installing to C:/Users/Statislove/Documents/R/win-library/3.4/mxnet/libs/x64
** R
** demo
** inst
** preparing package for lazy loading
** help
No man pages found in package  'mxnet'
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded
Error: package or namespace load failed for 'mxnet':
.onLoad failed in loadNamespace() for 'mxnet', details:
call: inDL(x, as.logical(local), as.logical(now), ...)
error: не могу загрузить разделяемый объект 'C:/Users/Statislove/Documents/R/win-library/3.4/mxnet/libs/x64/libmxnet.dll':
LoadLibrary failure:  Не найден указанный модуль.

Ошибка: загрузка не удалась
Выполнение остановлено
ERROR: loading failed

removing 'C:/Users/Statislove/Documents/R/win-library/3.4/mxnet'

What is mistake?

It seems R can't load the shared lib.
I am sorry I can't figure out where is the error from the log you provided.
Can you try to install the prebuilt pkg to see if it works?
cran <- getOption("repos")
cran["dmlc"] <- "https://s3.amazonaws.com/mxnet-r/GPU"
options(repos = cran)
install.packages("mxnet")

Thank, i setup mxnet. Really, i think it's not possible. To install, i make magic steps with UBUNTU.
But now i'm really happy 👍

I am closing this now. Feel free to reopen if necessary.


Fixed self referencing datatypes bug

Well detailed description of the change :

updated listToString and dictToString functions inorder to skip segfault
// for list
var x = [1,2,3];
x.push(x);
print(x);// [1,2,3,[...]

// for dict
var a ={1:2};
a[2]=a;
print(a);// {2: {...}, 1: 2}

Resolves: #
Self referencing datatypes #354

Type of change:

[x] Bug fix

[ ] New feature

[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Housekeeping

[ ] Tests have been updated to reflect the changes done within this PR (if applicable).

[ ] Documentation has been updated to reflect the changes done within this PR (if applicable).

Preview (Screenshots) :

Thanks for this! I'll leave the issue open as there are a couple of other places still affected.


Added puppet 4 to test matrix

We'd like to ensure modern puppet users can still use our modules

Makes sense to me :+1:


When I use loco, the following error is too common. what reason?

#![allow(clippy::unused_async)]
use loco_rs::prelude::*;
use sea_orm::DeleteResult;
use crate::models::_entities::recipes;
use crate::models::_entities::recipes::{ActiveModel};
use serde::Deserialize;
use axum::response::Json;
use axum::extract::Query;
use axum::extract::Path;
use serde::Serialize;
#[derive(Clone, Debug, Serialize, Deserialize)]
pub struct RecipeSearchParams {
pub limit: i32,
}
#[derive(Clone, Debug, Serialize, Deserialize)]
pub struct RecipeCreate {
pub label: Option,
pub source:Option,
pub url: Option,
}
impl RecipeCreate {
fn update(&self, item: &mut ActiveModel) {
item.label = Set(self.label.clone());
item.source = Set(self.source.clone());
item.url = Set(self.url.clone());
}
}
pub async fn fetch_receipe(Path(id): Path, State(ctx): State) -> Result{
let result = recipes::Entity::find_by_id(id).one(&ctx.db).await?;
Ok(format::json(result)?)

}
pub async fn remove_recipe(Path(id): Path, State(ctx): State) -> Result {
// Delete the recipe from the database
let res: DeleteResult = recipes::Entity::delete_by_id(id).exec(&ctx.db).await?;
// Check if any rows were affected by the delete operation
if res.rows_affected == 0 {
    // No rows were affected, so the recipe was not found in the database
    return Err(eyre::eyre!("Recipe not found").into());
}

format::empty()

}
pub async fn search_recipes(Query(params): Query, State(ctx): State) -> Result {
let all_results = recipes::Entity::find().all(&ctx.db).await?;
let result :Vecrecipes::Model= all_results.into_iter().take(params.limit as usize).collect();
Ok(format::json(result)?)
}
pub async fn create_recipe(Json(params): Json, State(ctx): State) ->Result{
let mut active_model = ActiveModel {
    ..Default::default()
};
params.update(&mut active_model);
let res = active_model.insert(&ctx.db).await?;
Ok(format::json(res)?)

}
pub fn routes() -> Routes {
Routes::new()
.prefix("recipes")
.add("/:id", get(fetch_receipe))
.add("/remove_recipe/:id", get(remove_recipe))
.add("/search_recipes", get(search_recipes))
.add("/create_recipe", post(create_recipe))
}
---------------------------------------------------------error
root@T14P:~/fastapi-project/fastapi-learn/loco-learn/myapp# cargo loco doctor
Compiling myapp v0.1.0 (/root/fastapi-project/fastapi-learn/loco-learn/myapp)
error[E0277]: the trait bound fn(axum::Json<RecipeCreate>, loco_rs::prelude::State<loco_rs::prelude::AppContext>) -> impl std::future::Future<Output = std::result::Result<axum::http::Response<Body>, loco_rs::Error>> {create_recipe}: Handler<_, _> is not satisfied
--> src/controllers/recipes.rs:82:37
|
82  |         .add("/create_recipe", post(create_recipe))
|                                ---- ^^^^^^^^^^^^^ the trait Handler<_, _> is not implemented for fn item fn(Json<RecipeCreate>, State<AppContext>) -> impl Future<Output = Result<Response<Body>, Error>> {create_recipe}
|                                |
|                                required by a bound introduced by this call
|
= help: the following other types implement trait Handler<T, S>:
<axum_extra::handler::or::Or<L, R, Lt, Rt, S> as Handler<(M, Lt, Rt), S>>
<axum_extra::handler::IntoHandler<H, T, S> as Handler<T, S>>
<Layered<L, H, T, S> as Handler<T, S>>
<MethodRouter as Handler<(), S>>
note: required by a bound in loco_rs::prelude::post
--> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/axum-0.7.5/src/routing/method_routing.rs:389:1
|
389 | top_level_handler_fn!(post, POST);
| ^^^^^^^^^^^^^^^^^^^^^^----^^^^^^^
| |                     |
| |                     required by a bound in this function
| required by this bound in post
= note: this error originates in the macro top_level_handler_fn (in Nightly builds, run with -Z macro-backtrace for more info)
For more information about this error, try rustc --explain E0277.
error: could not compile myapp (lib) due to 1 previous error
root@T14P:~/fastapi-project/fastapi-learn/loco-learn/myapp#

root@T14P:~/fastapi-project/fastapi-learn/loco-learn/myapp# cargo loco doctor
Compiling myapp v0.1.0 (/root/fastapi-project/fastapi-learn/loco-learn/myapp)
error[E0277]: the trait bound fn(axum::Json<RecipeCreate>, loco_rs::prelude::State<loco_rs::prelude::AppContext>) -> impl std::future::Future<Output = std::result::Result<axum::http::Response<Body>, loco_rs::Error>> {create_recipe}: Handler<_, _> is not satisfied
--> src/controllers/recipes.rs:82:37
|
82  |         .add("/create_recipe", post(create_recipe))
|                                ---- ^^^^^^^^^^^^^ the trait Handler<_, _> is not implemented for fn item fn(Json<RecipeCreate>, State<AppContext>) -> impl Future<Output = Result<Response<Body>, Error>> {create_recipe}
|                                |
|                                required by a bound introduced by this call
|
= help: the following other types implement trait Handler<T, S>:
<axum_extra::handler::or::Or<L, R, Lt, Rt, S> as Handler<(M, Lt, Rt), S>>
<axum_extra::handler::IntoHandler<H, T, S> as Handler<T, S>>
<Layered<L, H, T, S> as Handler<T, S>>
<MethodRouter as Handler<(), S>>
note: required by a bound in loco_rs::prelude::post
--> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/axum-0.7.5/src/routing/method_routing.rs:389:1
|
389 | top_level_handler_fn!(post, POST);
| ^^^^^^^^^^^^^^^^^^^^^^----^^^^^^^
| |                     |
| |                     required by a bound in this function
| required by this bound in post
= note: this error originates in the macro top_level_handler_fn (in Nightly builds, run with -Z macro-backtrace for more info)
For more information about this error, try rustc --explain E0277.
error: could not compile myapp (lib) due to 1 previous error
root@T14P:~/fastapi-project/fastapi-learn/loco-learn/myapp#

correct  pub async fn create_recipe(State(ctx): State,Json(params): Json) ->Result
error  pub async fn create_recipe(Json(params): Json,State(ctx): State) ->Result
This error is unbelievable！！！！！！！！

I had the same error and it caused me a lot of confusion I made this pull request to solve it and make the errors more readable.
import this:  use axum::debug_handler;
and add this macro to your handler that is causing the issue like so.
#[debug_handler]
pub async fn echo(req_body: String) -> String {
req_body
}
l

documents   :  Building a CRUD API
pub async fn update( Path(id): Path,State(ctx): State,Json(params): Json) -> Result {
let item = load_item(&ctx, id).await?;
let mut item = item.into_active_model();
params.update(&mut item);
let item = item.update(&ctx.db).await?;
format::json(item)
}
An error is reported when changing the order of function parameters.
pub async fn update( Path(id): Path,Json(params): Json,State(ctx): State) -> Result {
let item = load_item(&ctx, id).await?;
let mut item = item.into_active_model();
params.update(&mut item);
let item = item.update(&ctx.db).await?;
format::json(item)
}
error[E0277]: the trait bound is not satisfied
--> src/controllers/recipes.rs:82:37
|
82 | .add("/create_recipe", post(create_recipe))
| ---- ^^^^^^^^^^^^^ the trait is not implemented for fn item
| |
| required by a bound introduced by this call
|
= help: the following other types implement trait :
<axum_extra::handler::or::Or<L, R, Lt, Rt, S> as Handler<(M, Lt, Rt), S>>
<axum_extra::handler::IntoHandler<H, T, S> as Handler<T, S>>
<Layered<L, H, T, S> as Handler<T, S>>
<MethodRouter as Handler<(), S>>
note: required by a bound in loco_rs::prelude::post
--> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/axum-0.7.5/src/routing/method_routing.rs:389:1

Yes, the order matters for the parameters. If you add this macro #[debug_handler] to your function you will get better error messages.
#[debug_handler]
pub async fn update( Path(id): Path,Json(params): Json,State(ctx): State) -> Result {
let item = load_item(&ctx, id).await?;
let mut item = item.into_active_model();
params.update(&mut item);
let item = item.update(&ctx.db).await?;
format::json(item)
}
Like this but do not forget to import the following.
use axum::debug_handler;

This design is very unreasonable.Is it possible to make the order of function parameters not affected?
1.documents : Building a CRUD API . function (list ,add,update,remove,get_one)  .The order of arguments for these functions in the official documentation is confused.
2.The second is that the misinformation is outrageous.
3. #[debug_handler]  I only found out about this plan after talking to you.

pub async fn fetch_receipe(Path(id): Path, State(ctx): State)   correct
pub async fn fetch_receipe(State(ctx): State，Path(id): Path)  correct
but
async fn create_recipe(State(ctx): State,Json(params): Json)    correct
async fn create_recipe(Json(params): Json,State(ctx): State)    error
That's why it's puzzling.

Something subtle that is mentioned in the docs I linked above is the disclaimer that extractors who implement the FromRequest trait HAVE to be last in order, and ones that implement the FromRequestParts trait can be anywhere but last. Another thing mentioned is that no type can implement both FromRequest and FromRequestParts. Since the Json extractor needs to read the body of the request, it can't have any extractor go after it (can only read the body stream once). This means it must implement FromRequest, requiring it to be put last in the order. The State and Path extractors do not read from the body stream and therefore implement the FromRequestParts trait, meaning the order can be switched around as long as none are put after an extractor that implements FromRequest.
In your first example, both State and Path implement FromRequestParts and have no extractors that implement FromRequest, so the order of them can be changed around. But in the second example, Json implements FromRequest (meaning it reads the http request body stream) so it HAS to go last, that's why there is an error when it is not put last.


Change opened selector for Date Picker

The focused state has been removed in newer versions of Pickadate. This changes the CSS to target only the opened state. Fixes #336.

To be clear, this will not stop it from working with the version of Pickadate we currently bundle with Fabric.

Makes sense. Looks good--approved.

Cool beans!  Approved with gusto. :fireworks:


Link DNS RRs to IPAM data

This is probably more a long-term project than something that can be implemented in a singe PR.
In the IPAM module there are lots of IP address data, together with an optional DNS name. This is exactly the information that is maintained in the DNS module as well with a different focus. It would be very useful to provide some kind of link between the two in some way that probably needs to be discussed further.
Some ideas:

Make it possible to select the DNS hostname in IPAM from the data in the DNS zones
Provide links to IP Addresses (IPAM) to DNS names (DNS) and vice versa, potentially with some kind of referential integrity (when the IPAM address is removed, offer to remove the DNS name as well)
Create the DNS record for an IP Address when the "DNS name" field is filled in

I did not dig into the Netbox code base too deeply yet, so I'm not sure whether a plugin can change the behaviour of a core module (which would be necessary for some of the functionality sketched above), or if a cross-referece to data from a core module is possible at all from a plugin, but it would be really nice to have.
Another issue is that IP addresses are not necessarily in a 1-1 relation to DNS records if different VRFs or different DNS views (BIND jargon) are in use, so that one IPAM IP address might be present in different zones/views. This is something that probably needs some discussion.

This netbox webhook project  uses the IPAM database to push updates to the DNS servers.  Syncing this DNS plugin to IPAM with the dnsupdate webhook would be the holy grail for one-step DNS/IPAM management.

This netbox webhook project  uses the IPAM database to push updates to the DNS servers. Syncing this DNS plugin to IPAM with the dnsupdate webhook would be the holy grail for one-step DNS/IPAM management.

This is another interesting approach, but less to this issue than to the one addressed in #8.
I'll have to have a look when I find the time, but currently I see some issues that need to be resolved (see also discussion #182):

Priming the DNS server from the current state of the data in NetBox DNS does not seem to be addressed
Since NetBox DNS creates many record updates (some records are created and updated automatically) there needs to be a way to execute updates in batch, so the DNS servers don't get flooded with update requests
If views need to be supported that needs to be addressed on the DNS server side as it's not possible to send dynamic DNS updates with view information
The webhook server needs to be extended to support all DNS records, not only A/AAAA

... and probably some more "interesting" issues.
Perheps it will be the shorter route to look at octodns and the provider created by @jcollie, but the webhook architecture can also be a good start for other specific solutions.

After a long hiatus, here's a quick update.
As of today (NetBox 3.3.x) there are not too many documented and supported ways to interact with core NetBox models from a plugin.
This will change to some extent in NetBox 3.4. With the upcoming version there will be an option to create plugin specific panels in core views, which I'm currently playing around with. Functionality is currently limited to an informational aspect such as showing the related DNS records for an IP address, but I can imagine going on from there to more involved scenarios, as far as the plugin interface allows.
My current idea is to implement the integration feature as an optional feature in NetBox DNS, which needs to be enabled in the plugin configuration to work so it doesn't interfere with the NetBox core interface in case anything does not work as planned.


Unnecessary mirrored recipe

Minecraft can handle recipe mirroring all by itself.

Doesn't matter, the code didn't have enough Flamingo!


MacOS error: Library not loaded: /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib

Hi, I would love help getting ObjectiveGit running on macOS.
I'm on Catalina 10.15.1 and Xcode Version 11.1.
I'm building using Carthage, following all the steps.
iOS seems to work fine.
MacOS does not:
dyld: Library not loaded: /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib
  Referenced from: /Users/.../Build/Products/Debug/.../Contents/Frameworks/ObjectiveGit.framework/Versions/A/ObjectiveGit
  Reason: image not found

Looking in /usr/local/opt/openssl/lib/ I see libcrypto.1.1.dylib, but not libcrypto.1.0.0.dylib.
(If relevant at all, I was able to get https://www.github.com/SwiftGit2/SwiftGit2 to run on macOS)
Any pointers would be super, super appreciated!
Thanks

I finally got ObjectiveGit working on macOS 10.15.1 Catalina and Xcode 11! Here's a quick recap of the problems I ran into and the eventual solution - hopefully useful for anyone running into similar issues dow: the road.
Problem & Solution:
First I tried installing the latest release (0.14.2) with carthage, using Cartfile entry:
github "libgit2/objective-git"
But then macOS fails with error:
dyld:
  Library not loaded: /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib
  Referenced from: ...
  Reason: image not found

After many different attempts, I finally managed to get everything working by forking the repository, creating a branch off of the latest release, and using that as my Cartfile dependency:
github.com "marcuswestin/objective-git" "0.14.2-fork-for-catalina-xcode11"
I had to jump through a few additional hoops to get everything finally working, not necessarily related to this library, but worth noting:

Enable "Curl: could not resolve

In {Project file} > {Target} > Signing & Capabilities > App Sandbox > Network >
Check: Outgoing Connections (Client)

Fix CodeSign errors

In {Project file} > {Target} > Signing & Capabilities > Hardened Runtime >
Check: Disable Library Validation

ObjectiveGit.framework could not be found

Create an Objective-C bridging header with File > New File... > macOS: Objective-C File> {Any name, Empty File}
When prompted to configure an Objective-C bridging header: Create Bridging Header
Finally, either:

import ObjectiveGit in any swift file you want to use it in, or
#import <ObjectiveGit/ObjectiveGit.h> in your ...-Bridging-Header.h file for access from any swift file in your project.

This makes it work! Why? I'm not certain, but my guess is that because the latest libgit2/objective-git release has binary builds, Carthage downloads and uses those, but they don't work with Catalina. However, when using the branch build, Carthage has to build from source - and then it works!

I faced the exact same problem (Library not loaded: /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib) and solved it by building Objective Git like so:
carthage update --platform macOS --no-use-binaries

This was just using @marcuswestin's intuition that the solution was to force Carthage to build from source, and finding the --no-use-binaries flag to do that explicitly.


Bump version 2.3.1

@amazingalek @misternebula @TAImatem approve please? Just a patch release with a tiny fix from @salomj


Updating some of the wording

There was a technical inaccuracy

@stgeorgi : Thanks for your contribution! The author(s) have been notified to review your proposed change. @ChJenk

#sign-off

@daveba: I'm sorry - only the author of this article, @ChJenk, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

@rjagiewich Please approve.


LightController's ValidateInput method should be pure

This method should do what its name tells us: validate input data. Instead, it stores the validation result within a backing field:
https://github.com/Avanade/Liquid-Application-Framework/blob/8f03b94252db859c61992662bc7c84fced8fee64/src/Liquid.Activation/Controller/LightController.cs#L89-L115
This method is not idempotent as it has side effects.
Let's take this view model as an example:
public class TestVM : LightViewModel<TestVM>
{
	public string Id { get; set; }

	public override void Validate()
	{
		RuleFor(i => i.Id).NotEmpty().WithErrorCode("ERR_ID_REQUIRED");
	}
}

If we'd mistakenly call ValidateInput twice, we'd end up with THREE error messages. Why is that? The method calls the view model's Validate method:
https://github.com/Avanade/Liquid-Application-Framework/blob/8f03b94252db859c61992662bc7c84fced8fee64/src/Liquid.Activation/Controller/LightController.cs#L103-L106
which builds validators for the view model itself. By calling it multiple times, each RuleFor would also be applied multiple times. So, calling twice is the same as doing this:
public override void Validate()
{
	RuleFor(i => i.Id).NotEmpty().WithErrorCode("ERR_ID_REQUIRED");
	RuleFor(i => i.Id).NotEmpty().WithErrorCode("ERR_ID_REQUIRED");
}

Combine this with the fact that we reuse the list of errors, and now we have three error messages.
And this problem grows exponentially. ValidateInput should be a pure function.
Also, the method Factory<T> throws the InvalidInputException but, in my opinion, this is the responsability of the ValidateInput method.

One thing that I find worth mentioning and that is a corollary of the non-pure aspect of Validate(), is that the validators created by the call to Validate() aren't cached. This means that we are creating instances of Validators multiple times, on the hotpath, which can be a waste of resources (for instance, the implied reflection call to obtain the name of the property).


tests(acl) reading the response body

I don't think we should remove this.
The http client requires the body to be read iirc, to be able to make a next request. Hence to prevent future nasty issues due to reuse of the client or by copy-pasta of code I think it should remain as it is.

@Tieske sorry - remove what?

@thefosk the read_body() call this PR is about

This PR is actually adding the call, as I pointed out to @thefosk yesterday.

lol, sorry for the noise.


(fix) Fix main path

To use this repository instead of an NPM package, we need main within package.json to correspond to the actual source entry. For example:
yarn add https://github.com/xBacked-DAO/algorand-wallet-selector.git

See https://docs.npmjs.com/cli/v7/configuring-npm/package-json#main for more information
Resolves #2

Closed #2 - we can close this PR too.


surfer library error (gablab neuroimaging)

Hello all,
I'm getting this error that seems to be part of the surfer library. Any thoughts on how to troubleshoot? Thanks!!
////////////    task001: zstat01    ////////////
Traceback (most recent call last):
File "l2_screenshots.py", line 91, in
take_screenshots(tasks ,contrasts, l2_path, model)
File "l2_screenshots.py", line 17, in take_screenshots
contrast_lh=project_volume_data(zstat,"lh",subject_id=template,smooth_fwhm=0.3)
File "/om/project/ran/env/ran_py/lib/python2.7/site-packages/surfer/io.py", line 179, in project_volume_data
env = dict(line.split('=', 1) for line in envout.split('\n') if line)
ValueError: dictionary update sequence element #73 has length 1; 2 is required
X Error of failed request:  GLXBadContextTag
Major opcode of failed request:  150 (GLX)
Minor opcode of failed request:  5 (X_GLXMakeCurrent)
Serial number of failed request:  458
Current serial number in output stream:  458

This seems to be a consequence of #132. Can you give the branch in #149 a try?
Sorry about the slow response.


v1.10 backports 2022-04-26

#19153 -- metrics: Add go_* metrics (@chancez)
#19528 -- make: check that Go major/minor version matches required version (@tklauser)

Makefile conflicts, I think we just need to add the new target & hook it in like I've done here.

#19452 -- Limit the number of active FQDNs beyond the TTL to --tofqdns-endpoint-max-ip-per-hostname (@joestringer)

Minor conflicts in pkg/endpoint/endpoint.go, pkg/fqdn/cache.go.

#19563 -- docs: fix version warning URL to point to docs.cilium.io (@aanm)

Once this PR is merged, you can update the PR labels via:
$ for pr in 19153 19528 19452 19563; do contrib/backporting/set-labels.py $pr done 1.10; done

@chancez does this look familiar to you? It seems most likely that PR #19153 is the one introducing new grpc dependencies (perhaps via prometheus vendor update?)
github.com/cilium/cilium/pkg/kvstore imports
	go.etcd.io/etcd/clientv3 tested by
	go.etcd.io/etcd/clientv3.test imports
	go.etcd.io/etcd/integration imports
	go.etcd.io/etcd/proxy/grpcproxy imports
	google.golang.org/grpc/naming: module google.golang.org/grpc@latest found (v1.46.0), but does not contain package google.golang.org/grpc/naming

/test-backport-1.10

CI Triage:

Code scanning results / CodeQL

Not marked as required; I think these are known to be failing for the latest CodeQL checks against v1.10 branch. Ignoring.

Conformance AWS-CNI

Failed due to agents not getting ready, agents crashing with level=fatal msg="Error when enabling sysctl parameters" error="could not open the sysctl file /proc/sys/net/ipv4/ip_forward: open /proc/sys/net/ipv4/ip_forward: read-only file system" subsys=daemon. Looks similar to https://github.com/cilium/cilium/issues/19526, which is reported as fixed in https://github.com/cilium/cilium/pull/18898. This is likely a regression introduced by that logic, potentially fixed by #19555.

CI-3.0 workflows were apparently broken due to master changes, likely fixed by #19582:

ConformanceEKS
ConformanceGKE
External workloads
Multicluster / Cluster mesh

k8s-1.20-kernel-4.19

Provisioning error at 25m, will re-run

ConformanceAKS (ci-aks-1.10)

Did not run; not marked as required. Ignoring.

/test-1.20-4.19

/ci-eks-1.10

/ci-awscni-1.10

/ci-gke-1.10

/ci-external-workloads-v1.10


🐛 [Bug report]:

Describe the bug
Inconsistent horizontal margin on the navbar
To Reproduce
Steps to reproduce the behavior:

Go to 'The reactplay site'
Scroll to the ''hero page"
See error

Expected behavior
Same space between the edge of screen and the elements on both sides of the navbar
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

Browser  [chrome]

Additional context
Nothing else

Hey @Deevyn9
Thanks for reporting it. Could you please post a screenshot of the issue?

The places the arrows are pointing to are the ones in question

Thanks @Deevyn9 for the clarity. Do you want to fix it?

Hello,
can I fix it ?

Hello,
can I fix it ?
@atapas @Deevyn9

Go ahead


nukies can have the same name

Description

Reproduction

Screenshots

Additional context

Resources/Prototypes/GameRules/roundstart.yml Line 131
Resources/Prototypes/Datasets/Names/syndicate.yml Line 9
For anyone who wants to fix this.
I looked into it and It's doomed.

full house


Partition Key Isolation

Is your feature request related to a problem? Please describe.
I have several dynamic (they go up, new ones get made, old ones destroyed) development environments. It would be advantageous from a provisioning time stand point and (more importantly) a cost standpoint if I could run multiple environments backed by the same containers.
Describe the solution you'd like
An obvious solution to this problem would be to prefix all our partition keys with an environment specific prefix and ensure that prefix is always applied to partition keys passed to the SDK. A comparative approach is the stackexchange redis client's WithKeyPrefix method on IDatabase.
https://github.com/StackExchange/StackExchange.Redis/pull/92
This approach is awesome because I can configure it in DI and the rest of my application doesn't need to know its happening. It also results in no breaking changes.
Describe alternatives you've considered
Currently my approach is to define this in my DI:
For<CreatePartitionKey>()
    .Use(x =>
    {
        var prefix = Configuration.Get(x => x.CosmosPrefix);
        return (string name, out string fullName) =>
        {
            fullName = $"{prefix}_{name}";
            return new PartitionKey(fullName);
        };
    });

public delegate PartitionKey CreatePartitionKey(string name, out string fullName);

And then i inject and use that delegate anywhere i need a PartitionKey instance. Mostly this works but it's not the bullet proof solution i have in my redis client. A dev is still free to make whatever partition key they like and break it.
A little side query, I have the out string fullName so I can get the partition key's name as a string. I do this so I can set it on TModel.PartitionKey (if upserting). PartitionKey.ToString() returns some json form of the value so I can't get the key from that (simply). Am I able to change the type of TModel.PartitionKey from string to PartitionKey? That would solve the need for a string representation of the key. Still think I should be able to get the plain name from a PartitionKey instance.
Additional context
var partitionKey =<EMAIL_ADDRESS>                out string partitionKeyString);

//...

var viewModel = new UserDocumentListViewModel
{
    Id = documentRef.Key,
    Title = documentEntity.Title,
    Owner = ownerEntity.ToString(),
    Role = documentRef.Value,
    PartitionKey = partitionKeyString
};

using (var ms = new MemoryStream())
{
    await JsonSerializer.SerializeAsync(ms, viewModel,
        new JsonSerializerOptions() { PropertyNamingPolicy = JsonNamingPolicy.CamelCase },
        cancellationToken);
    tasks.Add(_container.UpsertItemStreamAsync(ms, partitionKey, cancellationToken: cancellationToken));
}

Have you look at shared throughput on databases? I'm not sure if it is a concern, but there is a restriction of 25 containers per a database.

Hi @j82w, I had not considered that. Topologically it seems more complex an approach then a string prefix. I would need to make container names configurable and differ per env. Small complaints but... we programmers are fickle :D
I suppose that is one way to solve this. Personally I would prefer to use a prefix to the key. As a concept its simple, doesn't grow the surface area of my topology and, afaik won't run into any artificial caps on usage.


Added authToken feature to views, updated react to send authToken in api

New file auth.py has the authToken code. Recommended to change my_secret to a strong private key.
Generates authToken on login and sends it back in the response.
The authToken is stored in localStorage on login from frontend.
React requests send token for user related api in the axios headers:
headers: {
Authorization: localStorage.getItem("authToken")
}
Views decode the token and use the decoded username to do tasks.
How to test:
Make sure nothing has broken. (I checked on my end but we should double check)

I can see the auth token in local storage


Include ess-julia-mode in the list of major modes

Hi
I'm using ess to deal with julia code: ess-julia-mode is the major mode of the buffer, so in order to enable lsp-julia it is necessary to include it along with julia-mode in the list of major modes.
Thanks

does this mean julia-mode.el should have a transitive dependency on ess-julia-mode or the other way around.

Well, ess-julia.el requires julia-mode.el. But you may use julia-mode.el without ess-julia.
In case you decide to go with ess-julia, the major mode will be ess-julia-mode, and so this issue.


Doesn't @Controller/@JsonController work with factory functions for classes?

I want to use factoryFunction to create my controllers with some type and then extend them, i'm doing this:
export function createLocationController<T extends ClassTypedInterface<LocationInterface>>(locationClass: T) {
  console.log("Creating class");

  @JsonController(`/locations/${locationService.get(locationClass).name}`)
  class LocationController {
    @Inject()
    protected locationService: LocationService;
    protected location;

    constructor() {
      this.location = this.locationService.get(locationClass);
    }
  }

  return LocationController;
}

and then I extend created class like this:
export default class IntroLocationController extends createLocationController(IntroLocation) {
  @Inject()
  private playerService: PlayerService;

  @Get("/something")
  getSomething() {
    return true;
  }

// omitting...

In the end - there is not routes for this

ahhh I really recommend you to keep it simple. You should mark your IntroLocationController as @JsonController to make it to work.

Yeah, I'm kinda feeling that I'm abusing this comfortability of using decorators :D
But it would've been nice possibility to do something like this. I'm having like 30> controllers in future that are based on same functionality and bootstrap code like service.getItemForThisExactController()
Anyway I'll keep it simple for now. Maybe in the future I'll find some nice solution like controllers as services (with abstract service controller as parent) or something like this. Hm.
Thanks!

First try to keep your controllers as simple and small as possible. Second, prefer composition over such inheritance. Extract logic into repositories/managers/services/utils. I have hundreds controllers in my projects and always following these patterns.

Yes, of course, I'm using composition and services much, because their behavior and functions should be separated. But sometimes you may use inheritance, it's not obsolete and can provide generating-code like behavior. In this example locations are classes for erm game like thing, with their behavior, and it would've been nice touch to generate some actions based on location methods but wrapped in action logic (http errors instead of location inner errors etc)
I mean generating code with factory functions and inheritance is nice.
Thanks for advices!


standardjs (triggered from git commit) fails on quote-actions.js

git -c user.useConfigOnly=true commit --quiet --allow-empty-message --file -
standard: Use JavaScript Standard Style (https://standardjs.com)

/home/ricfio/projects/platformatic/tutorial-movie-quotes-app/apps/movie-quotes-frontend/src/scripts/quote-actions.js
4:7  error  'confirm' is not defined  no-undef
✖ 1 problem
pre-commit:
pre-commit: We've failed to pass the specified git pre-commit hooks as the test
pre-commit: hook returned an exit code (1). If you're feeling adventurous you can
pre-commit: skip the git pre-commit hooks by adding the following flags to your commit:
pre-commit:
pre-commit:   git commit -n (or --no-verify)
pre-commit:
pre-commit: This is ill-advised since the commit is broken.
pre-commit:

Thanks for reporting! Would you like to send a Pull Request to address this issue?

Sorry, but I don't know how fix it:

'confirm' is not defined. (no-undef)

This is the snippet of souce code in apps/movie-quotes-frontend/src/scripts/quote-actions.js:
import { quotesApi, gql } from '../lib/quotes-api.js'

export function confirmDeleteQuote (form) {
  if (confirm('Are you sure want to delete this quote?')) {
    form.submit()
  }
}
...


[eas-cli] print better error message when uploading the project archive tarball fails

Why
https://exponent-internal.slack.com/archives/C017N0N99RA/p1687487381876689
How
Improve error message
Test Plan
Test locally

/changelog-entry chore Print better error message when uploading project archive tarball fails


fix(pattern): CTA and button default - no icon

Related Ticket(s)
https://github.com/carbon-design-system/ibm-dotcom-library/issues/2356
Description
CTA section - default button without Icon
added default state to CTA, button group components.
Changelog
Changed

Added default button type

@greeshmareddyg can you fix the merge conflicts?

@greeshmareddyg switching CTA to type default renders this:

@jeffchew I will fix it Jeff.

@greeshmareddyg one minor thing, I know that we're missing defaultProps for a bunch of these components, can you add those? Let's have default be the default for type.

@greeshmareddyg one minor thing, I know that we're missing defaultProps for a bunch of these components, can you add those? Let's have default be the default for type.

sure, I will add that @jeffchew


Adding DotImaging

DotImaging - .NET array as imaging object
The framework sets focus on .NET native array as primary imaging object, offers extensibility support via extensions, and provides unified platform-abstract imaging IO API.

LGTM, but it seems does not have enough test.

OK, if you are referring to the Test folder it does not include them. The library is mature enough judging by the number of package downloads: https://www.nuget.org/packages?q=dotimaging
Should I add unit tests and then notify you or (this may take a while)... ?

@dajuric Fine, it could be better if you add the unit tests, thanks.

Thank you.


Make context of Icinga alert pages clearer

The pages in the "Icinga alerts" section like this one  are linked from the Icinga UI:

However, when you visit the page the context isn't really made clear.

This PR adds a block to 1) communicate that this is a page that deals with a specific alert, 2) links back to govuk-puppet, so that the user can find out what triggered the alert. See these search results for example.

cc @nickcolley @fofr because I'm randomly adding a new UI element here, what do you think?

A list of our content call out patterns are towards the bottom here:
http://govuk-component-guide.herokuapp.com/components/govspeak
Though I quite like what you've done. We also know that those patterns aren't doing their job well.

I'd prefer to have consistency in the callouts but we don't have consistency with the current callouts yet anyway so this seems fine.

Thanks @nickcolley @fofr !


[Addition]: All of these hotspots asserted location approximately the same time

Hotspot b58 Addresses
11gDW6TkcTXpGf2WpXJFPcQVtxGAmDA2oQCA365YuMD7CVT9o1c
11rmdV94NDGeiF7svmBMDEEcZFUDRZNokirQo3ea5GXb21jX2Gp
112LWbasV169wrdS3YxZn1XDdy1N1CoBBcBApqSb2zbjJGxHW83f
112B4kf33JyGoRsJfyTipgn2UGKYdNZ8d3Pm2V6TAtpsvD1k32Bh
11ZAgPpazaSJWRdM6XmPB52MzBjRrkSU1NrEQeLhZFhJyDbkVXV
11fA8QLJuuKdCgTip3e5uxprNBuLK6VtyypGhLtvzrnN4hMvWCz
11aLgaq4MsPx3x2MMqGPSYuLFY5Lab5WAWfX5VWfsm6CeBgEexQ
112K638Fj9nthJDQ4BFN8UhXuXDE9vWiKuVUmjreQUC9DYoWf1zm
11H5xYP2w3edMN9x4HiUeNpcAkgojXrBs8mbnKmzrPYRJYBsLQi
Discord Handle
No response
Reason(s)
I think they are cheating because all of these hotspots reasserted location approximately the same time. They are all belonging to a same wallet. Before they reasserted, they were getting a lot of invalid witnesses.

I would like to add more info. These hotspots are only witnessing each other, despite there are other hotspots in the area too. Also a lot of the witnesses are showing as invalid.

@CTH-Red-Team-Mapping-Service-P1 Hi. I submitted this request for more than a month ago. Would you be able to take a look at it? I’m sure the owner has other hotspots which I haven’t listed spoofing in other areas too.
Please check! Thank you

Cluster seems inactive


[BUG] Indecipherable error during first query and no registered doc

Hey Roman. :)
Describe the bug
If you have a large project and forget to include a model in the connection / registration, the error message is super weird.
To Reproduce
Try to do a query without passing a document to the models value in the connection, for example:
await BackgroundJob.find(BackgroundJob.processing_status == JobStatus.awaiting).to_list()

if BackgroundJob wasn't registered, the error is:
AttributeError: processing_status
What? There is a processing_status on the class, but the class wasn't registered.
Expected behavior
A message like "Cannot query against BackgroundJob, it has not been registered with Beanie"

Hi @mikeckennedy ,
Thank you for the catch! I'll pick this up next wee during the next bug-fixing session.

Thanks Roman. :)


(WIP) Feat: introduce e2e tests using furyctl and KFDDistribution

As per title, this PR aims to add e2e tests that are using furyctl with the new providers.
This way we can test that everything will be installed correctly, and we can also test migrations with a multi step furyctl config files execution.

This CI step is passed! https://ci.sighup.io/sighupio/fury-distribution/1435/2/3 🚀


⚠ Turnos 24x7 has degraded performance

In 5692949, Turnos 24x7 (https://reservas-dev.alternativasinteligentes.com/) experienced degraded performance:

HTTP code: 200
Response time: 898 ms

Resolved: Turnos 24x7 performance has improved in 9ab6ae5.


Admin UI Facelift

This is a UI Facelift centered around removing the sidebar and replacing it with a navbar
This PR also addresses a few other issues:

Reduces the docker image size size by 22mb (a 25% reduction in compressed image size)
Handles redirects for admins/staff who are not also students
Handles the unwieldy list of courses for admins by creating a route that lists courses
Makes the deploy script not use git tag for images with - (which indicates a staging deployment)
Hides the grading menu option if there are no grading tasks pending

Resolves #1071
Screenshots from local environment (with fake data)

For context - this was what it looked like before:

It's also deployed to staging if you want to try it out.

I agree that a course dashboard is a good idea - we can scope a course dashboard into this PR

There's now a course dashboard - about 13 months after the route was created in v3 :)

Screenshot of the dashboard:

I'm pretty happy with this. I'm going to put off the Vue.js action bar (the search bar in the navbar) because the enrollment search should be good enough for now.

Nice, looks awesome :)


[PAPI-103] Api versioning

Requires prepending version to all API routes, so for example we can call /v1/status
Returns api-supported-versions header for all API calls, so consumers can see they can potentially upgrade
Returns 400 with error message if an unsupported version is used

Wondering if we should include v1 in the opdex configuration ApiUrl, or if we should add v1/... to Transaction callback endpoint and auth callback endpoints in configuration.
Will need to apply changes to the frontend to match this.
Also wondering if we should add v1 to the socket hub.

Just those things to figure out and implement along with conflicts.

Wondering if we should include v1 in the opdex configuration ApiUrl, or if we should add v1/... to Transaction callback endpoint and auth callback endpoints in configuration.

Probably individual is more flexible, although I can't see a need to update these separately. Can stick with the /v1 on the ApiUrl and then we can always change config without disruption, if the need arises

Also wondering if we should add v1 to the socket hub.

I think we should, just in case


[image_picker] Add support for Android 13's photo picker

Currently the system file picker is opened.
See https://developer.android.com/about/versions/13/features/photopicker.

Android 13 is still in beta and is yet to be available officially and Flutter is no exception as it doesn't yet support new OS.
Keeping it open and labeling as proposal.

cc @GaryQian

Any updates with this?

I want to add a fix for this task. Is anyone already doing this task?
cc: @GaryQian @blasten

any news? maybe change priority?

@blasten @darshankawar I've submitted a PR implementing this. Can you assign this to me when you get time, please?

@FXschwartz Done :)


Feature/mobile devices

Let's try automated Travis tests in github. I will do the same on iOS SDK.


New Release

The addition of AWS signing would warrant (in my opinion) a new release of the package, most likely 0.1.1, though that's obviously not my decision.
I can update the wiki to include instructions on adding AWS signing information to the JSON configuration, but do not think it would be wise to do so until #10 that @llvtt merged in becomes part of the latest released package.

Thanks @sha1sum and @ReedD! We released version 0.2.0 which includes your AWS request signing enhancement. It would be great if you could update the Usage with Elasticsearch wiki so others know about this feature. Thanks again, this release is largely you two.

@ShaneHarvey it seems that I cannot edit the wiki pages, but I've gladly typed out the Markdown for the bottom of the page if you'd like to simply paste it in:
### Signing Requests to AWS Elasticsearch Service

Both Elasticsearch 1.5.2 and 2.3 versions that—at the time of this writing—are provided by Amazon Elasticsearch Service through AWS are suported by [elastic-doc-manager](https://github.com/mongodb-labs/elastic-doc-manager) (for version 1.x) and [elastic2-doc-manager](https://github.com/mongodb-labs/elastic2-doc-manager) (for 2.x), respectively. The `args` for the proper doc manager in configuration file will accept an `aws` configuration object with a required `region` key and—optionally—an `access_id` and `secret_key` corresponding to your AWS credentials.

_**Note:**_ If `access_id` and `secret_key` are unspecified, the credentials found in the `~/.aws/credentials` file (if any) for the user running mongo-connector will be used instead, which may be the behavior that you want, particularly if you've already used [AWS CLI](https://aws.amazon.com/cli/).

#### Example AWS Usage

The following is an example of using AWS Elasticsearch service running Elasticsearch 1.5.2 using [elastic-doc-manager](https://github.com/mongodb-labs/elastic-doc-manager). The same `args` apply to both `elastic-doc-manager` and [`elastic2-doc-manager`](https://github.com/mongodb-labs/elastic2-doc-manager).

\```json
...
  "docManagers": [
    {
      "docManager": "elastic_doc_manager",
      "targetURL": "https://search-my-domain-29tg824978g24924t42.us-east-1.es.amazonaws.com/",
      "args": {
        "aws": {
        	"region": "us-east-1",
        	"access_id": "ACCESS_ID",
        	"secret_key": "SECRET_KEY"
        }
      }
    }
  ]
  ...
\```

As stated above, the `access_id` and `secret_key` arguments are optional if you are using credentials stored in `~/.aws/credentials` **for the user running** the `mongo-connector` instance.

Note that I had to "escape" the triple backticks to make this comment work with preformatted text :)

Ah the wiki is only open to those with push access, sorry for the misinformation. I added your instructions to the wiki: https://github.com/mongodb-labs/mongo-connector/wiki/Usage-with-ElasticSearch#signing-requests-to-aws-elasticsearch-service. Thanks!


Build error because of new flate2 version

flate2 recently updated to  "0.2.0" and uses the new std::io.
Wheter the Cargo.toml could be updated to use version 0.1.8 of flate2
or rs-tiled has to be changed to use the new std::io.
Also the flate2 module reader has been renamed to read.
See: https://travis-ci.org/mattyhall/rs-tiled/builds/50744832

Thanks for the report! I've updated the code to use the new std::io. Unfortunately it got rid of the read_u32_le methods so I've had to roll that myself.
Travis still says the build is failing because the latest cargo in rust nightly is broken. It works on my machine though.
Cheers!

Thanks for fixing it so fast!
Compiles and works as expected.
Cheers!


Replace map reduce with anyMatch operation

@hasithaa Thanks for the great feedback and I have incooperated the requested changes


portal: Do not fail when writing repeatedly

I will go ahead and merge this, we could land more docs improvements in the future.


Add meta details to dask Array, fix #8759

[x] Closes #8759
[ ] Tests added / passed
[x] Passes pre-commit run --all-files

Can one of the admins verify this patch?
Admins can comment ok to test to allow this one PR to run or add to allowlist to allow all future PRs from the same author to run.

ok to test

@jsignell Updated as per your suggestion, can you verify once

This looks good @jayeshmanani thanks for reminding me to merge.


Merge a "main" branch into a separate branch of a model or versioned folder

Description
At the moment, you can only merge changes from a model/versioned folder from a new branch back into the "main" branch (draft) model/versioned folder, but you cannot do this the other way around. For example, in this scenario:

You can select the "Merge" option to merge branch "CR8000" to "main"
You currently cannot merge "main" to "CR8000"

The second case is important too because changes may have been made to "main" whilst the other branch has been idle or worked on, so the latest "main" changes should be able to be committed back to the other branch for consistency.

Not a ui change, actually a security change see Pr: https://github.com/MauroDataMapper/mdm-core/pull/460

Reopened for a question, I can now merge a main Version Folder into other branches, Do I want to also be able to merge individual models inside? Security policies seems to indicate folder only but task is a tad ambigious on this

@OButlerOcc I would say it only really makes sense to merge whole VFs at a time - if you were to merge single models within a VF you'd likely end up with dangling links - references to things that didn't exist.

@OButlerOcc and @jamesrwelch - I think if I remember correctly, a merge diff is allowed on a standalone model so long as it is not inside a versioned folder - the VF takes precedence over sub-models within it. So a merge, either as main -> branch, or branch -> main, should apply to:

Models (Data Model, Terminology, Code Sets etc) not inside a VF
Versioned Folders
But not models inside a Versioned Folder


Sync GRT HEAD?

I am under the impression that we take a snapshot of GRT and use it for most of the development.
However, given the PR and other changes that has been made in GRT, should we consider syncing our GRT?
Also this might be helpful if we are hosting the workshop together (avoid different GRT APIs).
The argument for not syncing with the master is that we are using GRT 0.0.1 release.
I've seen a couple significant changes in HEAD:

There are some type changes that we will need to address if we sync. E.g. MatrixDouble is no longer available and it's now MatrixFloat. If you dig more about what's the float, you will see typedef double Float.

VectorFloat is different from vector<double> so it's not directly cast-able.

I think it's probably a good idea. Any thoughts on how we should go about it?

I think it would be helpful to still use your forks: syncing that to the master and then update our submodule. Then fix any compilation and API changes (this could take a while...).


Update install instructions to use virtual environment

Inspired by #29.

Sorry took too long to look into this.