Treasury - [Target price $800eth purchase x30 with dai total coat $24000 dai]

The amount requested to transfer: $24000
Whilst we have no farmr/trader. I would like to propose the following future trade if the target price is achieved!
Target price $800
Purchase 30 eth at $800 with dai costing $24000
Not putting a stop loss price we have held eth in the wallet before
Sell price $1600
Sell only 15 eth at $1600 and convert back to dai for $24000
Leave the other 15 Eth in the treasury as ETH.
If this trade makes entry price and sell price the treasury will end up with 15 ETH profit.
Out of the 15th Eth profit I would like a 2 5eth buyback this gives total treasury increase of 12.5 ETH. And a little incentive for the HOLDERS if this trade is successful
Many thanks
Buzz
The recipient of the amount. Each additional recipient will receive the specified amount in the proposal:
The purpose of the transfer. This can include the allocation of the funds to delegated traders/farmers, to conduct purchases of specific assets, to perform token buybacks, or to pay external

Very good proposal, I agree 100%

Good proposal! IMO we wont see $800 for eth

I changed the title as I was made aware of a spelling mistake.

How long does the proposal suggest it should be valid for?  If the Proposal passes, but an $800 ETH price point doesn’t ever come…how long before the Proposal is voided?  Please update.

I have taken the advice into consideration and therefor I when amended the proposal to be valid for 90 days from day of a successful vote .

Amended the proposal information for clarity and to define the actions more clearly. Moving this to snapshot for vote as the timelock treasury does not need to release any funds to execute this.

Proposal opened on Snapshot:
https://snapshot.org/#/aggregatedfinance.eth/proposal/0x72bb8df7f20a5d9e782c9f473115c55e4a4f1f64c5a2743f35eaf6f1c908d64c

Vote closed with a majority FOR outcome. Market will be monitored for the next 90 days to determine if ETH target entry price is met.


Cannot get  element to display

I'm unable to reproduce the material select example at http://krescruz.github.io/angular-materialize/#select
See http://jsbin.com/vanuxunise for minimal example taken from github.io site.
When inspecting the github.io page, I see that "select-wrapper" element is created in the DOM. However, it does not appear to be created in the JSBin example or in other attempts I have made to work with it.
Adding the "browser-default" element class to the select element does cause the element to render.
Can anyone see what example I'm missing here? I'm probably overlooking something, but I haven't been able to find anything in the documentation or source that differs from the JSBin example.
Thanks.

Yep, you forgot to include jQuery.
It says that you need to include jQuery in the "About angular-materialize" section in http://krescruz.github.io/angular-materialize/.
This is because this isn't a angular rewrite of Materialize, this is just directives that interact with the Materialize code. So since Materialize requires jQuery, so do we.

Yes, I realize jQuery is a requirement.
If you look at the JSBin I posted, you will see that the CDN for jQuery was included.
Thanks for the response, but unfortunately this doesn't address my question.

I just looked at the console output, so i didn't spot the exact error.
What happened is that you had jQuery after AngularJS, in which case AngularJS doesn't use the full jQuery. And we use the jQuery from AngularJS, so we require that jQuery is before AngularJS.
You've changed the page, so I don't get the same error, but your includes are still not in order.
Have them like this, and then it works.
<script src="https://code.jquery.com/jquery-2.1.1.js"></script>
<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.3.5/angular.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/materialize/0.97.0/js/materialize.min.js"></script>

Going back to look at the JSBin to make the dependencies were in the correct order allow me to the see that the source of the error was having jQuery listed twice, once before angular and once before materialize. I figure it would be a dumb error, but not that dumb...
Thanks so much for your help.


Version 2.7.5 - Various improvements

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.2 out of 3 committers have signed the CLA.:white_check_mark: ClaudeROSSI:white_check_mark: Ramzay:x: lmargaronYou have signed the CLA already but the status is still pending? Let us recheck it.


CB-15357- Creating a custom cluster definition via cdp cli fails with NPE

@gregito why do you requested review from raven team?

usually you do not need to add raven team to PRs on master, we already aware of every master PRs which is approved and green (as @lnardai mentioned in the email and mentioned in the wiki), so my only question is that do you want to address issues mentioned by @lajosrodek?

pls fix checkstyle and integration test

horadla23 commented 20 days ago
"pls fix checkstyle and integration test"
we are going to close the PR tomorrow if there is no activity on this PR.

@gregito I am waiting for this PR to land in mow-dev. Please do the needful.

retest this please


Deployment Support on Kubernetes

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
i need to deploy solution on Kubernetes hosted on my environment
Describe the solution you'd like
A clear and concise description of what you want to happen.
i need to deploy solution on Kubernetes hosted on my environment
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Hi @ahmedhkhalil, deployment process described in README: https://github.com/hystax/optscale/blob/integration/README.md If you have any problems with Optscale deployment please create issue and describe them. Thank you.

requested feature is how to deploy application on kuberentes directly , what current exist in provided document is how to deploy application on single virtual machine using ansible and use kuberentes on deployment
for example we need to have helm charts that used to deploy application on kuberentes or eks


Fix transpiler failure with circuits containing conditions

Summary
Fix #4672
Details and comments
When using optimization level 3, the run method of qiskit/transpiler/passes/optimization/consolidate_blocks.py would cause an UnboundLocalError in qiskit/converters/circuit_to_instruction.py if the circuit contained a conditional statement. The QuantumCircuit call in consolidate_blocks did not include any cregs which would cause the conversion of the condition to fail. This fix adds cregs to the QuantumCircuit call if there is a condition in the DAG node.

@kdk @ewinston Here's where this stands. I copied the failing circuit from the Travis job above and ran it alone and got the 'expected 2 wires, got 7' error. I tried the following,

Return consolidate_blocks to original and make change to circuit_to_instruction.py as mentioned by ewinston above. Still get same error.
Don't add cargs and add condition to unitary. Get 'local variable 'c' referenced before assignment'.
Add cargs and add condition to unitary. Get 'expected 2 wires, got 7' error.

So at this point, I'm stuck on this circuit. It almost feels as if this error is unrelated, but I don't know. I ran the standard tests and many runs of test_randomized and did not get this error on any of those runs.

@enavarro51 , thanks for investigating. You're right that this wasn't related to the changes on this branch (I was able to replicate this on master). I opened https://github.com/Qiskit/qiskit-terra/issues/4727 to track it.

Thanks, @kdk. Good to know that's what it was.


Setting the Vagrant environment

As a Developer,
I need a vagrant environment setup
So that I can push code faster
Details & Assumptions:

Environment details TBD

Acceptance Criteria:
Given x members of the team
When we run vagrant up
Then the same environment should be set up for everyone without errors


[23.11] expat: 2.5.0 -> 2.6.2

Description of changes
Original PRs: #287040, #289294, #290448, #289734, #292430.
Changes:

https://github.com/libexpat/libexpat/blob/R_2_6_0/expat/Changes
https://github.com/libexpat/libexpat/blob/R_2_6_1/expat/Changes
https://github.com/libexpat/libexpat/blob/R_2_6_2/expat/Changes

Fixes CVE-2023-52425, CVE-2023-52426, CVE-2024-28757.
Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[x] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Are we really unable to patch? 2.5.0 -> 2.6.2 suggests some significant changes.

I do not see any breaking changes in changelogs and chose an easy path of just cherry-picking everything that is done on master. If this is not acceptable for backport this time, I may check if bringing separate patches is a viable solution.

I have successfully built expat and its package tests for x86_64-linux, aarch64-linux, aarch64-darwin, ran its binary (xmlwf).

I also have successfully built expat and its package tests for x86_64-darwin, ran its binary (xmlwf), everything looks good.

So.. CVE-2024-28757's patch looks trivial.
CVE-2023-52426's patch looks slightly less trivial but I'd guess probably backportable
CVE-2023-52425's patch looks more significant.
Debian have left these three unfixed for now, so it's possible a backport isn't feasible. Though in the meantime they've clearly weighed that the risk from these vulnerabilities (just DoS after all) doesn't outweigh the risks in bumping.
The issue is that "breaking changes" are not always obvious from the changelog. We've had single-patchversion bumps of expat cause breakage in the past.

I believe we've already had even a buggy security-only patch from expat upstream.

For CVE-2024-28757 it is indeed trivial to backport, see https://gist.github.com/LeSuisse/7e4372e2be8e76dbecdcc70fe07be34f
For CVE-2023-52426 we do not build with -DEXPAT_DTD=OFF so we should be fine.
The fix CVE-2023-52425 is not trivial at all to backport and bunch of things have changed since 2.5.0 (including the tests).
We could consider that patching CVE-2024-28757 is good enough for now but it looks like it is not unlikely we will be forced
to do the upgrade anyway before the end of life of 23.11 https://github.com/libexpat/libexpat/blob/R_2_6_2/expat/Changes#L14

Created #299306 to backport the patch for CVE-2024-28757.
The Ubuntu team has backport the fix for CVE-2023-52425 (see https://git.launchpad.net/ubuntu/+source/expat/commit/?id=2ec8b79e7283ce97b32bd722ef9799e9444b4ff5), I tried to apply the patch but it breaks the tests (test_return_ns_triplet, test_column_number_after_parse and test_default_current).

Since we applied a patch for CVE-2023-52425 in #300500 I'm closing this.


Allow Configuration Cache for TAPI requests without Isolated Projects

Gradle currently disables CC when Tooling models are requested (which is part of the IDE sync process) unless Isolated Projects are enabled.
Supporting CC for TAPI requests benefits TAPI clients in general, but it can also benefit the IDE sync.
Larger builds tend to have custom tooling that allows loading only part of the full build to reduce overall sync times. In such setups, switching between those views is common. It might be possible in the future to improve CC hit rate in such cases. Today, it's problematic and having CC for TAPI is not enough: the sync process is mainly the same TAPI request, but the build configuration changes in between the invocations leading to an invalidation of an existing cache entry instead of a creation of a new one.
Overall, supporting CC for TAPI requests is aligned with an eventual goal of making CC mode the preferred mode of Gradle execution.

Another use case that might be rather common is simply reopening a project in the IDE.
Right now, it will always result in a full sync. However, if no configuration was actually changed, it can be a CC hit.
Reopening of a project in the IDE is possibly much more common than doing a resync without closing it:

Closing the IDE in the evening, and reopening it the next day
Restarting the IDE after some IDE plugins got updated (but not necessarily the IDE itself)
Opening another git worktree checkout

larger builds tend to have custom tooling that allows loading only part of the full build to reduce overall sync times

Implementations I've seen of this involve changing the contents of settings.gradle (or similar). That'd invalidate the CC anyway, no?

Implementations I've seen of this involve changing the contents of settings.gradle (or similar). That'd invalidate the CC anyway, no?

@DSteve595, there can be more than one entry in the configuration cache. When you modify CC inputs (e.g. by changing the settings file), it causes CC to compute another key for the cache. And that can result in a cache hit.
Imagine a use-case of switching back-and-forth between two branches in your project. As long as you don't change anything about the build configuration, in the ideal case, you should be getting CC hits.

Imagine a use-case of switching back-and-forth between two branches in your project. As long as you don't change anything about the build configuration, in the ideal case, you should be getting CC hits.

Further discovery uncovered that invalidation of CC entries is almost inevitable in the current implementation, and enabling CC for TAPI requests is not enough to get cache hits for, say, git branch switching and IDE sync. Additional work would be required to improve those use cases.
Having said that, the overall ability to run with CC for TAPI requests is still a prerequisite.


:wrench: allow to specify cocoadpods acknowledgment through ENV

in multi projects folder of iOS projects, it looks like the cocoapods plugin is unable
to find the proper Pods-...-acknowledgments.plist file. As it takes only the 1st item of the dir,
We should be able to also specify the one we want trought an environment variable ACKNOWLEDGEMENT_PATH
just like what it is done in the SPM plugin where we do need to specify the environment variables for
DerivedDatas & Package.resolved files.

@etiennecadicidean Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@etiennecadicidean Thank you for signing the Contributor License Agreement!

Not sure why the bundle install step fails for some jruby tests on
concourse-ci/ruby-jruby-<IP_ADDRESS>
it has nothing to do with my minor changes and I guess it fails on the main branch as well.

Hi @etiennecadicidean , the PR looks good overall.  The only change I would suggest is expose this new environment variable, either though the README, or through a raise error (similar to spm), or both. We want to make sure everyone is aware of this new feature.
Do not worry about jruby as that is not a blocking test as we have not had the bandwidth yet to investigate the failing tests.

Hi @etiennecadicidean , the PR looks good overall. The only change I would suggest is expose this new environment variable, either though the README, or through a raise error (similar to spm), or both. We want to make sure everyone is aware of this new feature.

@xtreme-jason-smith as the variable is completely optional and can help in very specific situations I only added additional informations in the README.md ! Thank you for your cutting comments on all my PRs 👍

Hey @etiennecadicidean ! Dont worry about the jruby stuff. It has been failing for a while and we will be removing it from our pipelines soon. We are just fixing up our CI and will merge this in. Thanks again!!


can now add multiple approvers, and any of them can approve

Adds support for multiple possible approvers for a page, partially addresses #21.

Fixed a merge conflict, made page list look prettier.


littlewhitecloud's advices for jou syntax

1
I have look at the examples/primes.jou and I noticed the for loop.
I think the for loop requires "(" and ")" to make the for loop more read able
from "stdlib/io.jou" import printf

def is_prime(n: int) -> bool:
    if n < 2:
        return False

    for (divisor = 2; divisor < n; divisor++): #here add "(" ")"
        if n % divisor == 0:
            return False
    return True

def main() -> int:
    for (n = 0; n < 10; n++): #here add "(" ")"
        if is_prime(n):
            printf("%d\n", n)
    return 0

2
I hope the arguments can support this syntax:
[typename] [variable]
def is_prime(int n) -> bool: # here changed
    if n < 2:
        return False
    for (divisor = 2; divisor < n; divisor++): #here add "(" ")"
        if n % divisor == 0:
            return False
    return True

Because I often use C/C++ coding......
bool isprime(int n) { // typename variable
	if n < 2:
		return false
	// and more
}

This is just a suggest...

Thanks for sharing your thoughts :)
Suggestion 1 would be inconsistent with if and while: they don't have parentheses in Jou or Python, but they have parentheses in C.
Suggestion 2: I don't want to add two ways to do the same thing (it would only be confusing), so I would delete the variable: typename syntax as well. But then variable: typename = value (e.g. x: int = 'a') is inconsistent with how arguments work, and should also be changed to int x = a. This isn't great because int x = a is difficult to distinguish from x = a when parsing, and I want Jou to be super simple to parse.

okay, thx for your reply


Upgrade fastapi & starlette dependencies

Managed to find the breaking upgrade: fastapi 0.69.0 uses starlette 0.15. Using those versions or newer results in database errors


how to prevent to add "/?post=1&action=edit" to url

hi @SofiaSousa
how to prevent to add /?post=1&action=edit to url when add data to local storage like https://demo.gutenbergcloud.org/

Hi @amirrahimi71
We used to override add_query_args (from @wordpress/url package) https://github.com/WordPress/gutenberg/blob/master/packages/url/src/add-query-args.js, which is the method responsible for appending arguments as querystring to URLs. But that's something we don't do anymore.


tracing: apply tracer provider configuration defined as part of http_connection_manager filter

Description: apply tracer provider configuration defined as part of http_connection_manager filter
Risk Level: Low
Testing: unit tests
Docs Changes: N/A
Release Notes: N/A
Context:

part of #9998

@mattklein123
I need your advice on how to better handle OpenCensus case.
Right now, I've documented why OpenCensus is different from other tracing providers.
Do you think we need something better than a warning in the docs ?
E.g., we could prohibit configuring *envoy.tracers.opencensus* via http_connection_manager and only allow it in the bootstrap config.
Also, current implementation of HttpTracerManager as a Singleton leaves a room for an error in case of OpenCensus. Since Singletons might be removed when no longer in use (no more Listeners left), it is possible that  OpenCensus will be configured more than 1 time even if it's a part of bootstrap config. Unfortunately, OpenCensus will not handle gracefully double configuration (it will not crash Envoy, but its behaviour will be wrong, e.g. reporting a Span multiple times).
WDYT ?

E.g., we could prohibit configuring envoy.tracers.opencensus via http_connection_manager and only allow it in the bootstrap config.

If our goal is to get rid of tracing config in bootstrap (which I think it is) I don't think this is a viable long term option.

Unfortunately, OpenCensus will not handle gracefully double configuration (it will not crash Envoy, but its behaviour will be wrong, e.g. reporting a Span multiple times).

This seems like a pretty big bug in the OpenCensus implementation. Can we get this tracked somehow and someone working on an upstream fix? I would be inclined to just ignore this for now and let this be tracked as a known bug. IMO we should not go out of our way to work around broken extensions in Envoy. cc @g-easy @rnburn @objectiser

@mattklein123
I don't want to leave any room for an error.
Because if it can happen, it will happen eventually, and it will cost somebody a few hours/days of troubleshooting.
So, I propose to update OpenCensusTracerFactory::createHttpTracer():

On first successful invocation, memorize the proto_config argument and a created Tracer instance
On subsequent invocations, compare proto_config argument against the first-time value; if they match, return previously created Tracer, otherwise throw an error

This way, HttpTracerManager can remain a Singleton and get deleted when it's necessary.
WDYT?

WDYT?

Yup sounds like a great plan.

@mattklein123
Should I do it in this PR or a separate one ?

@mattklein123
I've made a few changes:

rephrased warnings about OpenCensus (in the light of #10519)
added a deprecation notice for Bootrstrap.tracing field

I was unable to add [deprecated = true] annotation, though:

if I add it to v2.Bootrstrap, then tracing field gets completely removed from v3.Bootrstrap
if I add it to v3.Bootrstrap, then it gets stripped off by automation on git push

How should I proceed ?

How should I proceed ?

cc @htuch you can still access the hidden smuggled field in the v3 object (see the generated API protos that are checked in). However, technically we can't make breaking changes to v3 like this. We are likely going to lock v2 very soon (next ~1 week) and then we will be working on v3 and v4alpha. So what I would probably do is deprecate this field from v2 and get the hidden smuggled field approach working. Then when we move to v3/v4alpha it should be straightforward to move this change over.

Yeah, I'm actively working on moving the v2->v3 API migration tooling to go v3->v4alpha, ETA < 1 week.

@mattklein123
After adding [deprecated = true] to v2.Bootstrap.tracing field, //test/config_test:example_configs_test was failing in CI builds with --define deprecated_features=disabled option.
To fix that, I updated all "example_configs" to define tracing provider as part of HCM.
The only example left that is still using v2.Bootstrap.tracing field is configs/using_deprecated_config.v2.yaml.
Let met know if it's not what you expected.

Please merge master to pick up https://github.com/envoyproxy/envoy/pull/10672. We no longer accept changes to v2 (without explicit exception), so any API modifications should happen in v3. If this PR is adding a new proto, please follow the updated instructions in https://github.com/envoyproxy/envoy/blob/master/api/STYLE.md#adding-an-extension-configuration-to-the-api.

@mattklein123
When I refer to v3 apis in deprecated.rst and  version_history.rst, CI build for docs fails with
/source/generated/rst/intro/deprecated.rst:15: WARNING: undefined label: envoy_api_field_config.bootstrap.v3.bootstrap.tracing (if the link has no caption the label must precede a section header)
/source/generated/rst/intro/deprecated.rst:15: WARNING: undefined label: envoy_api_field_extensions.filters.network.http_connection_manager.v3.httpconnectionmanager.tracing.provider (if the link has no caption the label must precede a section header)
/source/generated/rst/intro/version_history.rst:6: WARNING: undefined label: envoy_api_field_config.bootstrap.v3.bootstrap.tracing (if the link has no caption the label must precede a section header)
/source/generated/rst/intro/version_history.rst:6: WARNING: undefined label: envoy_api_field_extensions.filters.network.http_connection_manager.v3.httpconnectionmanager.tracing.provider (if the link has no caption the label must precede a section header)

How should I fix that ?

@htuch see question about doc failure above?

@yskopets try using envoy_v3_api... prefix for the v3 protos, e.g. envoy_v3_api_field_config.bootstrap.v3.Bootstrap.tracing

@htuch thanks! it helped

Apologies needs a master merge. We moved version history files around (see master).
/wait


requirements.txt - make experience more fluid

Problem
When a user clones a repo, the tools have their own requirements.txt, this requirements.txt may contain things that are not currently installed. Right now the mbed-cli tool spits out a warning, but its not easy to understand or to use.
The warning looks like this:
[mbed] Couldn't find build tools in your program. Downloading the mbed 2.0 SDK tools...
[mbed] WARNING: -----------------------------------------------------------------
[mbed] WARNING: The mbed build tools in this program require Python modules that are not installed.
[mbed] WARNING: This might prevent compiling code or exporting to IDEs and other toolchains.
[mbed] WARNING: The missing Python modules are: pyserial, intelhex, project-generator, project-generator-definitions, junit-xml, pyyaml, requests, mbe
d-ls, mbed-host-tests, mbed-greentea
[mbed] WARNING: You can install all missing modules by running "pip install -r requirements.txt" in "C:\Users\ARM\scratch\.temp\tools"
---

which then requires thew user to manually type the following
> pip install -r C:\Users\ARM\scratch\.temp\tools

Solution
This experience is not as easy as it should be. There are many ways we could solve this. From best to worst here they are
Best Solution
mbed cli detects the tools need additional packages and automatically installs them for the user. Everything is transparent to the end user.
Best Solution: Considerations
I understand that this may violate some peoples idea of what a tool should, but I dont care, mbed-cli needs to be the easiest, best way to do the thing. To appease these pedants we can enable / disable this auto-installation process via a global config flag, which will be turned on by default, thus ensuring the best experience for the majority of users while permitting corner cases to have their cake and eat it too.
Reasonable Solution
mbed-cli detects the tools need additional packages and asks the user if they want to install them. This would look like this:
[mbed] WARNING: -----------------------------------------------------------------
[mbed] WARNING: The mbed build tools in this program require Python modules that are not installed.
[mbed] WARNING: This might prevent compiling code or exporting to IDEs and other toolchains.
[mbed] WARNING: The missing Python modules are: pyserial, intelhex, project-generator, project-generator-definitions, junit-xml, pyyaml, requests, mbe
d-ls, mbed-host-tests, mbed-greentea
[mbed] WARNING: Would you like mbed-cli to install the missing packages? [Y/n] :

> Y

[mbed] Installing packages now ........
......
[mbed] Packages ........ were installed succesfully!

This is an acceptable compromise that I think we can get out the door before release. I reccomend doing this for now and the best solution later.
Acceptable Solution
mbed-cli detects missing packages, and spits out the command for the user to copy/paste.
This is the lazyest way to do this, it interrupts the work flow, but at least it is considerably better than the current solution.
[mbed] WARNING: -----------------------------------------------------------------
[mbed] WARNING: The mbed build tools in this program require Python modules that are not installed
....
....
[mbed] WARNING: You can install all missing modules by running "pip install -r C:\Users\ARM\scratch\.temp\tools\requirements.txt"

At the bare minimum we should make the command easy to assemble to copy/paste for the end user.

@sg- @theotherjimmy

These mbed 2 and mbed OS 5 are de-facto the same tools, except that the mbed 2.0 are delivered separately and also that they support compatibility/legacy compile flags for both ARMCC and GCC. Once the automatic handling of mbed OS 5 tools requirements is resolved, this will be propagated to mbed 2 as well.

Introduced in PR #310

Now part of mbed CLI 0.9.1 release


Module additions for *nix agents

Added two modules for *nix based targets. One spawns an SSL encrypted TTY shell to a remote listener and the other enables arbitrary renaming of the Empire process (/usr/bin/python) to anything within a 15 character limit.

My first pull ever but I think I screwed something up

Thanks dchrastil! I'm not sure how I did it, but it looks like somehow managed to tangle my commits up with xorrior's. I'll try creating a new pull request and see if it comes through correctly this time.


Fixes circular importation problem.

This fixes the circular importation problem discussed here:
https://groups.google.com/group/django-shop/browse_thread/thread/3738b2cd8303db3c
and here:
https://groups.google.com/group/django-shop/browse_thread/thread/3936063131aec679
Regards,
Eduardo

OK after staring at it for half an hour, this is my understanding:

if the user wants to override one of the models, his model path MUST look like this: "someappname.models.Modelname"

That means, if a user wants to seperate his model classes into further files, this workaround will not work because of the check for length == 3.
i.e. myshop.models.cartmodel.Cart and myshop.models.ordermodels.Oder
We would restrict people here.
I think it would be better if we check like this:
IF class_path.startswith('shop.models') THEN do our usual load_class thing
ELSE return '%s.%s' % (parts[0], parts[-1])

Hello-
I agree with mbrochh in that my solution is not ideal, but I would suggest that the change required is a bit more substantial than I have done here and what mbrochh describes.
The problem in both cases is that the values that we need--app_label and model name--can only be taken from the class_path in the most basic default case.  It is possible, I think, to reassign a model to a completely different app, arbitrarily, using Meta.app_label.  In such a case, even under my modified implementation, it is possible for a model found at "someapp.models.ModelName" to have an app_label of "otherapp", and therefore be registered inside Django at a completely different location, breaking get_model_string.  An added problem with mbrochh's suggestion is that some models may be loadable only with the class path "projectname.appname.models.submodule.ModelName" or something of the form, whereby any workable parsing would be very complex if not impossible.
A more permanent solution would be to modify the kind of data found in SHOP_x_MODEL settings.  Instead of being class paths, I think that they should instead be ("app_label", "ModelName") pairs, or strings of the form "app_label.ModelName".  This would dramatically simplify get_model_string, and would require a very simple change to the importation of custom models inside shop.models.  Instead of using load_class, use get_model, as described here:
http://stackoverflow.com/questions/5542753/how-to-import-a-model-in-django-given-the-name/5543163#5543163
Other than get_model_string and shop.models, I am unsure of where SHOP_x_MODEL settings are used, which is why I did not include this more comprehensive change in my pull request; also, any such change would render any production settings files backwards incompatible (albeit, in a manner trivial to correct), so I hesitated for that reason as well.
Regards,
Eduardo

duh. Using ('appname', 'modelname') pairs in conjunction with get_model is so simple and elegant. Why didn't we do that right away?
+1

Actually, thinking about this a bit more, it occurs to me that the "comprehensive solution" that I suggested in my last comment may not work in the default case where no custom models are defined by outside apps.  Furthermore, my suggestion mandates that any custom apps be listed before shop inside INSTALLED_APPS.
The reason, I think, is that for get_model to work, the model has to already be loaded into memory, and because it is shop.models that causes the default shop models to be loaded into memory (in the default case), get_model cannot be used there in order to perform the load.  Also, if 'shop' is listed in INSTALLED_APPS ahead of the app containing the custom model, I don't think that the app will be available via get_model.
So, it seems to me that there are a couple of solutions.
(a) The most basic is to define the SHOP_x_MODEL settings in the form ("path.to.model.Class", "app_label"), rather than ("app_label", "Class") or "path.to.model.Class", accepting that we actually need both values.  The problem with this may be that many django users do not know about the "app_label" concept being distinct from the name of their app; however, the fact that this is an advanced feature anyway should mitigate this problem.
(b) The other solution is to still use get_model in shop.models, but only in the case where SHOP_x_MODEL is defined.  The problem with this is that "shop" would, if I am correct, still need to be listed in INSTALLED_APPS after the app containing the custom models.  This is a little annoying and may require users to separate their model implementations from the rest of their shop code in order to have other things like template loading work.
I would go with option (a), which requires probably the minimum number of changes.
If you all agree, I'll code something up and modify this pull request.

+1 to (a) as well!

I'm not sure about (a). This requires all existing shops to change their settings... In (b)'s case this is not the case. And I think that an advanced user should be able to remember to load his custom models before the shop app.
Also, we need can failfast (or at least log) the fact that a model is being "overwritten", so we can can warn the user with a friendly message ("you seem to be trying to override X - is your app before 'shop' in installed_apps?")
Finally, I think we need a test for this :)

Good point, Chris, I forgot about the backwards incompatibility :(

I think that I could write option (a) in such a way as to be backwards compatible, so that SHOP_x_MODEL could accept either ('path.to.model.Class', 'app_label') or 'path.to.model.Class'.  Users would only have to use the former if the latter is failing.
A message could be added to that as well.  How should the message be output, with "print" or something else?

So, I think that what I just committed is an improved, more generic approach that is similar to my initial approach and mbrochh's suggestion, for the purpose of backwards compatibility, but with an error message that indicates the "preferred" method if anything goes wrong.
I also added a small change to the cart view.  As you can see, in the PUT (i.e. update) case, I changed the view to look at the REQUEST dictionary (which is a combo of GET and POST dictionaries), instead of the POST dictionary.
I know that it is not REST, but neither is the approach already taken, really (i.e. a hard-coded PUT method looking inside the POST dictionary).  This change makes it much easier to implement finer-grain control of the cart in the UI.  Specifically, it allows for line-items to be deleted with a single click, without deleting the entire cart.

I have to think it through when I have more time. Can you try to write some tests for this as well?

Why are you adding unrelated code to this pull request?

Well, to a certain extent this is unintentional.  As I update my repository, this pull request changes without my doing anything.  If I recall, that's not how bitbucket works, for instance, where I believe you have to explicitly update the pull request after updating your repo.
That being said, these changes are not all completely unrelated, even if it was not my explicit intention to group them all together here.
The most recent change is also a fix to the general problem I am trying to address here: the problem of "custom model implementations not working at all".  I think that you and I discussed this in irc, that the models that are defined directly inside of /models/ordermodel.py break when Order is re-implemented.  The reason is this: the migration that exists inside of django-shop for these objects creates a foreign-key relationship with models.defaults.ordermodel.Order and ignores (because it must) any custom Order you define.  Furthermore, it is not sufficient to create your own custom order-extras models and your own migrations, because these objects are referenced from inside django-shop at a variety of locations.  The changes that I made are the only solution to this problem, as far as I can tell.
The "INVALID" order status is unrelated, yes.  Again, this is something that I added to my repo that I did not explicitly decide to include here.  Normally, I would put this in a separate pull request, but I haven't had the time to create a separate repository for that purpose to place this change in it.
The explanation for this change is as follows: there is a use case for orders to enter into a status that is not "CANCELLED", which implies a human decision being made, but that instead indicates an automated decision being made as to the status of the order.  For instance, if there is an irreconcilable failure inside of the payment or checkout procedure prior to settlement that requires the order to be segregated, it's status would be set to "INVALID".  It's purpose is to allow for orders to be automatically segregated by the software when a fatal error occurs.

You should create feature branches in your fork, develop the patch, send it as a pull request and then wait for us to accept the merge.
Further commits into your branch of course get added to the pull request - this is convenient because you can add changes as we discuss the problem and point out problems.
Now things are a bit messy... :(
I won't have time to dive into all these open pull requests until after my marriage / family is back in Germany (10th of November). Maybe we need a small one night hackathon to gather the active devs and punch away all those open pull requests. Really sorry that it all takes so long :(

As I said, unfortunately you have polluted the patch with lots of unrelated stuff. I have to review it again to see if we need all the additional stuff you added but honestly, I would like it more if you could create a new branch based off master, then send a pull request from this feature branch and then DON'T add anything unrelated to that feature to that branch.

I'm closing this pull request, but I opened a new (clean) one with only your relevant commits here: https://github.com/divio/django-shop/pull/118
Please use 118 to continue discussion. Maybe if you need to update it in the future, could you make a branch for your further changes? I'll merge your future branch with the current pull request branch.
Best regards,

Chris


Create a new pipeline to support auto prod deployment

A pipeline to move our code into content repo automatically.
AB#5622

[x] #1604
[x] #1521
[x] #1522
[ ] #1523

@thewahome what's the block on this?

@ddyett  this work requires moving the source code to ADO


Migrate to GitHub Actions

Removes dependency on another platform (Travis) which recently silently broke.

Branch protection rule added for the master branch requiring approving review and CI checks to pass in order to merge.

Validated that binding to environment secret in a job w/o the environment set cannot access the secret:
https://github.com/auvsi-suas/interop/actions/runs/690058838
Validated that setting the environment on a non-protected branch is not allowed:
https://github.com/auvsi-suas/interop/actions/runs/690088975

Validated that the master branch can leverage the environment & seret:
https://github.com/auvsi-suas/interop/actions/runs/690104583
Removed environment review requirements so that it happens automatically, and because there isn't an admin override and we don't have additional reviewers at this time.

Successful push to Dockerhub. Revoked the Travis access token.

Uninstalled Travis app.

Deploy successful, migration complete.


Persistence refactor

persistence store now has a manager with an interface and a persistence store.
the manager provides

the translation for protobuf (protobuf is not used at the store level)
the error handling and translation
an interface for mocking an test (providing in-memory testing etc.)

The store abstract will allow for working with zk, but other impls may be created later.
I also refactored the logic for deadnode tracking out... It was just a separate need.
This code has been tested on DCOS

@elingg @adam-mesos looking for reviews to merge on this.  Removing tech debt.

Thanks @kensipe, will look ASAP. This will take some time, as it's a pretty big PR. It would be good if you could try to kill a few nodes to test out the failure handling of the deadnodes. You could kill the executor processes, for example.

Review in progress

@kensipe while you are working on zk have you thought about using curator to ease the load on zookeeper?

@elingg My day was crazy busy today... thanks for the review... I hit this in the morning.  I can agree with the naming changes you prefer.
@nicgrayson I think most of the zk stuff is simplified through the ZooKeeperState for us.  I would be pro curator if it help us... but I don't think it does here.  Are you seeing something?

No worries, @kensipe. My review is still in progress. My day was also crazy busy so I plan to continue the review tomorrow!

@kensipe I don't see any issues currently. It was something that I thought about when I was writing that part originally.

A bit more progress on this review, will continue with it ASAP

Ok finished initial review, @kensipe!

@elingg I think this is done save 1 thing.   I resolved all comments.  However it appears you have something in mind for a Utility class which I can't make sense of.

Finished the second pass at the review, and this is looking great, @kensipe!  Mainly minor points now. My current concern is over engineering using Guice as mentioned above. I'd rather use a simple constructor as we did before.

I did some investigation, we are now injecting into Scheduler but not into ConfigServer. We probably should be consistent with this as well and either inject in both places or use the constructor in both places.

We discussed in person

Fix the issues with adding extra lines
Add documentation of Guice
Use Guice consistently in ConfigServer and HdfsScheduler in order to pass PersistentStateStore

Feel free to merge once this is tested, rebased, and these changes are done @kensipe!

@elingg all things on the todo are complete.  I've tested out on dcos.   I'll wait for Travis to build... then it's merge time.


ocamlPackages.{zed,lambdaTerm,utop}: update

Motivation for this change
Update; improved compatibility with OCaml 4.08; remove unused legacy version 1.6 of the lambda-term library.
Things done

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

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

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

@GrahamcOfBorg build ocamlPackages.utop


instruction

hi, I followed your instructions and I don't understand what the problem is... it doesn't translate anything, can you correct me?
public OnPlayerText(playpublic OnPlayerText(playerid, const text[])
{
if(text[0] == '+')
{
DeepL_SetAuthKey("cbae67e8-63cd-4f7f-a0c9-a2a32905679d:fx");
DeepL_Translate(text[1], "RO", "DE", #DeepL_OnTranslationDone);
}
return 0;
}
public bool:DeepL_OnTranslationDone(bool:success, result[], from[], cookie)
{
if(success == true){
SendClientMessageToAllf(0x00FF00FF, result);
}else SendClientMessageToAllf(0x00FF00FF, "the translation does not work");
return true;
}

Hello, is DeepL_OnTranslationDone called at all? If there is an error, result will contain the error message - what is the content?

yes is called DeepL_OnTranslationDone
bool:success is:  false
result is:   unexpected end of input

Well, then it might be caused by DeepL_SetAuthKey("cbae67e8-63cd-4f7f-a0c9-a2a32905679d:fx");. First of all, that should be called in OnGameModeInit (or similar), not before each request.

I changed, but the same problem without change

Did you obtain your DeepL API key, or do you actually use cbae67e8-63cd-4f7f-a0c9-a2a32905679d:fx?

cbae67e8-63cd-4f7f-a0c9-a2a32905679d:fx yes I updated in OnGameModeInit, and same error send me...

See the readme:

To use the plugin, you have to provide your DeepL authentication key.

DeepL_SetAuthKey("cbae67e8-63cd-4f7f-a0c9-a2a32905679d:fx"); // example key

You will need your own API key.


Tasks: show task log action should take terminal into account

Refs: #34953
We have a Tasks: show task log which always opens the output. However this can be wrong if my tasks are running in the terminal.
We should either remove this action and only use "Show running tasks", or make this action smarter that it opens the terminal if no task is appending output to the output channel

Actually they both serve a purpose and I didn't remove the "Show Task Log" since even in the terminal case the task parse write interesting error messages into the task output channel. Considering that terminal is the default for the future I still think that keeping both does makes sense.
I will close the issue. Please ping if you disagree.

Not sure if renaming the action would make it more clear
"Show Task Output"
"Show Task Output Log"
This way there shuold be some connection between name and output pane.
Just a suggestion


Update gpu direct mch test : GPU only test, use mpi

test will fail if not compiled with OpenACC support
replace depreciated include "mpif.h" with use mpi
added a loop reduction to test openacc

Can I test this patch?

yes

Ok to test


Channels2

This branch uses channels2.
TODO:

[x] fix restricted_data_cache by adding change_id cache
[x] fix notify
[x] fix tests
[x] unskip tests

@normanjaeckel I don't understand way isort fails on travis. It works fine on my computer. Can you check?

Hi, I'm testing this branch. When I add a plugin (in my case openslides-voting) I get this error at the end of the migrations: https://pastebin.com/TFNaenUw
However I do not understand where the connection between the plugin and the creation of the default workflows is. This needs further investigation also with different plugins.

I changed the signatur of the method get_startup_elements(), https://github.com/OpenSlides/OpenSlides/pull/3784/files#diff-a5a428ba9327cc39ed3b6a6037e6d58cR48-R54
Now, the method has to return Cachables (for example RestModelMixins). Before the PR, it had to return Collection objects. This change was necessary but also helps to fix #2468.
I will fix this by making the Collection a Cachable. Then it is possible for plugins to return the Collection objects. On the long run, the plugins should be changed.

Ok, I see. The "fix" is easy, but we should think about older plugins; What do you think about checking the returned type by get_startup_elements and if it's an collection, get the model of the collection and use it?

I changed the Collection to a Cachable.
I don't see the problem with older plugins. What could happen? They return a Collection and a Collection is a Cachable now.

Note to change the merge target to the OpenSlides3 branch.

I opened another PR for the OpenSlides-3 branch #3796
I close this one


Azure virtual network limits clarification

[Enter feedback here]
Hello team,
I need to understand what this limits means "Private IP addresses per virtual network = 65,536"  , also I need to know if there are limits for number of address spaces that can be added per virtual network

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

ID: 36f49a06-90b1-cbe1-3853-2c38277b79f8
Version Independent ID: 02ff6f6c-3ef6-b48f-060d-b290419e0aba
Content: Azure subscription limits and quotas - Azure Resource Manager
Content Source: articles/azure-resource-manager/management/azure-subscription-service-limits.md
Service: azure-resource-manager
Sub-service: management
GitHub Login: @mumian
Microsoft Alias: tomfitz

@TarekNabeel
Thanks for your feedback! We will investigate and update as appropriate.

@asudbring - Hi Allen, do you have any insights?

@TarekNabeel
The "Private IP addresses per virtual network = 65,536" limit means that you can't have a more than 65,536 assigned private IP addresses in a virtual network for devices, services, etc.
You can only have one address space per virtual network with a maxiumum of 3,000 subnets.
Thanks!

@TarekNabeel - I will close the issue for now.  We can reopen if you have any additional questions.
#please-close


Get-FailedContentIndexDocuments Documentation not clear

[Enter feedback here]
The existing documentation is not clear regarding the support of the cmdlet Get-FailedContentIndexDocuments in Exchange Online. While is says that the document applies to Exchange Online, it also wrongly states that the cmdlet is only available in on-premises environment.

It's not true. The cmdlet is also available in Exchange Online despite it's implementation is somehow different from on-premises environment and ending always with the same error. Always existing with the "The component operation has failed".

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

ID: d543b7d1-e33b-a9f8-3c07-9355cb515054
Version Independent ID: 6ebdf127-8c1a-42ca-3a85-534bae6300ed
Content: Get-FailedContentIndexDocuments (exchange)
Content Source: exchange/exchange-ps/exchange/Get-FailedContentIndexDocuments.md
Service: exchange-powershell
GitHub Login: @chrisda
Microsoft Alias: chrisda

@mnegrinho, this appears to be a case where the cmdlet is available in the cloud, but it doesn't work. Also, I get the same error in Exchange 2019, but it runs without error in Exchange 2010 to Exchange 2016. I updated the introduction sentence accordingly.
Thanks for the feedback.
Closing


allow admin to change user email address

Am I correct in understanding that there's currently no way for an admin user to change the email address of a particular user (and thereby send them a confirmation email)?
I've asked a related question on #53, about whether the email address of an impersonated user can be changed.
Thanks!

Well, it really depends on what you want to do exactly. Let’s check if what you want might already be there:

If a user didn’t get their confirmation email, you can just use the – usually public – interface for requesting another email, which the user themself would use as well. Just enter their email address there. Of course, to do that, you must have implemented this feature.
If a user can’t or doesn’t want to log in to their account in order to change their email address, you can impersonate them, which means that you skip the password check as an admin and just log in as the user directly. Then, again, you can use the normal interface that the user themself would use to change their email address. Again, you must obviously have implemented that feature. If changing one’s email address causes a confirmation email to be sent with your service (which it should), the email will be sent in this case as well. So the user receives a link at their new address which they can use to complete the address change.

Does this include what you need? Or is it something else?

@ocram Thanks! I've implemented solution 1, for circumstances where the user didn't receive their confirmation. The situation here is that (for whatever reason) the user doesn't want to log in to change their email address. I will use solution 2 (and thanks for your answer over in #53).
It's up to you, but I might suggest leaving this issue open as a feature request, i.e. that an admin user have the ability to directly modify a particular user's email address (targeting the user via ID or current email address).

You’re right, we should leave this open and implement this as another feature in the Administration interface in the future.
The advantage will be that you will no longer have to switch from the admin context to the user context by impersonating the user, requiring that you switch back to the admin context afterwards. With the new feature, you could stay in the admin context. Furthermore, we could allow admins to change email addresses without any confirmation as well.
Thanks!

@ocram Great, thanks!


Error in console if attributionController is undefined

In my application the attributionController is undefined. That results in a console error (but no other issues I am aware of). Do you think it makes sense to add
if (!attributionController) return;

inside the _setAttribution method?

Resolved by #2


Address breaking changes in Quarto (works in 1.4.176, broken in 1.4.528)

[ ] natbib breaks (related to https://github.com/pat-alt/quarto-juliacon-proceedings/issues/28 and https://github.com/quarto-dev/quarto-cli/issues/6938)

Works locally by altering the template to not use natbib, but the official template renders outside of Quarto without issue

! Package natbib Error: Bibliography not compatible with author-year citations.
(natbib)                Press  to continue in numerical citation style

[ ] Can no longer use table* environments with Quarto in raw LaTeX

Quarto now wraps raw latex table in a table environment and moves the captions. Unclear where/why this would be changed.

LaTeX Error: Not in outer par mode.

table* issue fixed in Quarto 1.4.529, see https://github.com/quarto-dev/quarto-cli/issues/7937

To future self: needed biblio-config: false, like the Springer Nature fix. (Perhaps default to this off in all templates?)


[RFC]: improve README examples of number/float32/base/assert namespace

Description
This RFC proposes to improve the README examples of the number/float32/base/assert namespace package. Currently, namespace package READMEs only include minimal examples which are not particularly informative and do not showcase namespace functionality.
Historically, namespace examples were not given much effort due to the rapidly changing nature of the project; however, now that development and organization has settled, it would be good to revisit these packages and add proper examples to better communicate to users how to use namespace contents.
For those wanting to contribute to this issue, you can use the following steps:

Browse through the contents of the number/float32/base/assert namespace and identify interesting functions and packages to showcase.
Update the example code block in the "Examples" section of the README for the number/float32/base/assert namespace and open a PR.
When updating the README, examples should follow existing project conventions (e.g., ES5).
Examples may require functionality from other packages to help make examples more interesting.

Related Issues
None.
Questions
No.
Other
No.
Checklist

[X] I have read and understood the Code of Conduct.
[X] Searched for existing issues and pull requests.
[X] The issue name begins with RFC:.

i want to work on this issue @Planeshifter


chore: Release v1.9.5

Promotion v1.9.5

/ok-to-test sha=1503384

/ok-to-test sha=1503384

/ok-to-test sha=85675e9


Expose async-attributes macros behind feature flag

For applications it's generally useful to have access to the attributes as defined in async-attributes. Being able to install a single dependency seems quite desirable.
Implementation
I propose we expose these attributes from the root of the crate, relying on a feature flag. As for the flag name, there's a few options. But the one I think I prefer is "bin" to indicate this should be used for binaries only.
#[cfg(feature = "bin")]
pub use async_attributes::*;

Should this also be behind the unstable feature flag? Or is the bin flag itself suppose to be unstable?
If the motivation for another feature flag is reducing compilation times, I wonder if we should just embrace sync and quote dependencies to simplify things...

@stjepang For me "unstable" means: "we want to eventually find a way to stabilize this, or remove it if we don't think it's useful. To me "bin" means: this is behind a feature flag forever because we're polyfilling the language.

I wonder if we should just embrace sync and quote dependencies to simplify things...

It would certainly make things easier; in particular #225 could greatly be simplified. And our ideas around random delays / tracing would be furthered by it. So not sure; we could consider it? But that feels like a larger discussion than what we're talking about here. And even then having this live behind a flag may still be desirable.

And even then having this live behind a flag may still be desirable.

Actually thinking more about it; I don't think people care about splitting lang polyfills out into separate features. If anything feature flags are kind of annoying. I think you're right, and this flag should only exist to guard pulling in the syn + quote dependencies.

I'm not convinced of exposing these features through the async-std library. I don't quite see the argument for just deploying one single library with multiple features. While it's desirable to ship e.g. an official test macro, it also leads to the jarring situation where alternative test frameworks need to deactivate such a feature.

it also leads to the jarring situation where alternative test frameworks need to deactivate such a feature.

Can you share more about this? This is the first time I'm hearing of it.

@skade Could you expand on the problem? It'd be nice to have this behind the attributes feature flag (or something similar).

The docs of async-attributes currently say:

We want to make sure async-std's surface area is stable, and only includes things that would make sense to be part of "an async version of std". Language level support is really important, but not part of the standard library.
This has some distinct benefits: in particular it allows us to version both crates at a different pace. And as features are added to the language (or we decide they weren't a great idea after all), we can incrementally shrink the surface area of this crate.
The other big benefit is that it allows libraries to depend on async-std without needing to pull in the rather heavy syn, quote, and proc-macro2 crates. This should help keep compilation times snappy for everyone.

I understand the second point but the first one is no longer true with the re-export, is it? Even with the feature-flag, the attributes are now part of the public API of async-std and hence it would be a breaking change to remove them in favor of language features, right?
It feels like we could just merge those macros into async-std now to remove this indirection (and also remove the circular dependency: async-attributes has a devDependency on async-std).


Elepot color panel does not work

Exception occurs when elepot color panel is shown for molsurf renderer.

Fixed [6b37c7b017182e190aec84bf585c389be963aeb4]


bip_util: Create Trait To Abstract Handle/RemoteHandle

Many of our crates try to be agnostic over the execution mechanism for their futures. However, currently we hardcode against Handle to spin off asynchronous tasks.
It would be nice if our crates depended instead on some trait in bip_util that exposed a function to pass a future to, which would be executed when some event loop/other mechanism, starts up.

Tracking https://github.com/alexcrichton/futures-rs/pull/455 for this.

This should also extend to some trait that allows clients to configure whether we use sync channels, or unsync channels, depending on how they will be composing the library in their own application so that they can get performance benefits if they are really using a single thread.


Don't produce swagger for http-in nodes without a corresponding http-out node

Scenario -
1) add HTTP In (say /path1) to canvas
2) add a function node but never add an HTTP Out node
3) in swagger ui, you'll see we generate swagger for the /path1 resource, but if you test it, it'll never return

Need to add a check to only include http-in nodes if they have an http-out node as well.

It isn't trivial to determine this - and wouldn't be fool-proof. Any flaw in the implementation logic, for example, could prevent a message reaching its http-out node even if was present.
What about ignoring nodes that don't have swagger-doc added? That at least adds that additional step to knowingly add it to the doc.

Hey Nick,
I've done some testing surrounding this and wrote a recursive function that traverses the wires to determine if there is at least one http-out node in the tree. It occurs when the swagger is being generated, so it shouldn't have any effect on ongoing messages. There's additional questions being brought up around nodes without swagger-doc, but i'll open a separate issue for that to discuss and bring back to scrum on Monday (since I know you're out all week).
Here's what I've implemented for a check of the wires:
function checkWiresForHttpResponse (node) {
    var wires = node.wires[0];
    for(var i in wires){
        var newNode = RED.nodes.getNode(wires[i]);
        if(newNode.type == "http response"){
            return true;
        } else if(checkWiresForHttpResponse(newNode)){
            return true;
        }
    }
    return false;
}

That function will be called when we do the check to determine if the node is an http-in node for the generation of swagger:
RED.nodes.eachNode(function(node) {
        if (node.type === "http in" && checkWiresForHttpResponse (node)) { ...

That's a simple test of my filtering code. Although the flows aren't realistic, it shows that /test and /test3 are filtered out as they do not have an http-out node in along any of the wires.

Additionally, I think we would essentially be implementing a check in the same spot to exclude nodes without swagger doc, wouldn't we? Just checking for an attached config instead of traversing the corresponding wires.

+1


falkon: enable qtwayland

Motivation for this change
Enable wayland support in falkon.
Things done

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

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

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

@GrahamcOfBorg build falkon

Success on x86_64-linux (full log)
Attempted: falkon
Partial log (click to expand)
shrinking /nix/store/s95i0n1zrpgbi1vvw7glryjp720wkzds-falkon-3.0.1/lib/qt-5.11/plugins/falkon/KWalletPasswords.so
shrinking /nix/store/s95i0n1zrpgbi1vvw7glryjp720wkzds-falkon-3.0.1/lib/qt-5.11/plugins/falkon/ImageFinder.so
shrinking /nix/store/s95i0n1zrpgbi1vvw7glryjp720wkzds-falkon-3.0.1/lib/libFalkonPrivate.so.3.0.1
shrinking /nix/store/s95i0n1zrpgbi1vvw7glryjp720wkzds-falkon-3.0.1/bin/falkon
strip is /nix/store/vcc4svb8gy29g4pam2zja6llkbcwsyiq-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/s95i0n1zrpgbi1vvw7glryjp720wkzds-falkon-3.0.1/lib  /nix/store/s95i0n1zrpgbi1vvw7glryjp720wkzds-falkon-3.0.1/bin
patching script interpreter paths in /nix/store/s95i0n1zrpgbi1vvw7glryjp720wkzds-falkon-3.0.1
checking for references to /build in /nix/store/s95i0n1zrpgbi1vvw7glryjp720wkzds-falkon-3.0.1...
postPatchMkspecs
postPatchMkspecs

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: falkon
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Failure on aarch64-linux (full log)
Attempted: falkon
Partial log (click to expand)
make[3]: *** [Makefile.gn_run:336: run_ninja] Error 1
make[3]: Leaving directory '/build/qtwebengine-everywhere-src-5.11.1/src/core'
make[2]: *** [Makefile:80: sub-gn_run-pro-make_first] Error 2
make[2]: Leaving directory '/build/qtwebengine-everywhere-src-5.11.1/src/core'
make[1]: *** [Makefile:79: sub-core-make_first] Error 2
make[1]: Leaving directory '/build/qtwebengine-everywhere-src-5.11.1/src'
make: *** [Makefile:47: sub-src-make_first] Error 2
builder for '/nix/store/ls9pcq6m945qkqy417sh79ynix1d9q57-qtwebengine-5.11.1.drv' failed with exit code 2
cannot build derivation '/nix/store/iz27aagagsnl9v5j6aaryqc8i4mspscn-falkon-3.0.1.drv': 1 dependencies couldn't be built
error: build of '/nix/store/iz27aagagsnl9v5j6aaryqc8i4mspscn-falkon-3.0.1.drv' failed

[23:39:34]  It would be nice to ask ofborg to build the current version of a package. I have a PR and it doesn't build for aarch64, and I don't know if it's because of my change or because it has never built for aarch64.

builder for '/nix/store/ls9pcq6m945qkqy417sh79ynix1d9q57-qtwebengine-5.11.1.drv' failed with exit code 2
cannot build derivation '/nix/store/iz27aagagsnl9v5j6aaryqc8i4mspscn-falkon-3.0.1.drv': 1 dependencies couldn't be built
error: build of '/nix/store/iz27aagagsnl9v5j6aaryqc8i4mspscn-falkon-3.0.1.drv' failed

Looks like there's no issues with falkon right now. The issue seems to be with qtwebengine. Not sure what the actual issue is though. What follows is not relevant to your PR.
ninja: build stopped: subcommand failed.

and earlier
[14012/16390] CXX obj/third_party/WebKit/Source/bindings/core/v8/bindings_core_impl/bindings_core_impl_jumbo_19.o
FAILED: obj/third_party/WebKit/Source/bindings/core/v8/bindings_core_impl/bindings_core_impl_jumbo_19.o
/nix/store/klgxdd526njckk7cq8j1pxakb2p6wv70-gcc-wrapper-7.3.0/bin/g++ -MMD -MF obj/third_party/WebKit/Source/bindings/core/v8/bindings_core_impl/bindings_core_impl_jumbo_19.o.d -DV8_DEPRECATION_WARNINGS -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DNO_TCMALLOC -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -DFIELDTRIAL_TESTING_ENABLED -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DBLINK_CORE_IMPLEMENTATION=1 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_32 -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_26 -DGL_GLEXT_PROTOTYPES -DUSE_GLX -DUSE_EGL -DBLINK_IMPLEMENTATION=1 -DINSIDE_BLINK -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DU_STATIC_IMPLEMENTATION -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -DUCHAR_TYPE=uint16_t -DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DHAVE_PTHREAD -DSK_IGNORE_LINEONLY_AA_CONVEX_PATH_OPTS -DSK_HAS_PNG_LIBRARY -DSK_HAS_WEBP_LIBRARY -DSK_HAS_JPEG_LIBRARY -DSK_SUPPORT_GPU=1 -DWTF_USE_WEBAUDIO_FFMPEG=1 -DWTF_USE_DEFAULT_RENDER_THEME=1 -DLEVELDB_PLATFORM_CHROMIUM=1 -DUSE_SYSTEM_LIBJPEG -DLIBXSLT_STATIC -DUSE_SYSTEM_ZLIB=1 -I. -Igen -I../../3rdparty/chromium -I../../3rdparty/chromium/third_party/WebKit/Source -I../../3rdparty/chromium/third_party/WebKit -Igen/blink -Igen/third_party/WebKit -I/nix/store/lfqn0va9pcmj3ga25ifsnwk6zhb2czdd-glib-2.56.0-dev/include/glib-2.0 -I/nix/store/hqq3pvy2jgsf11s6dp7h6zsgri6q9723-glib-2.56.0/lib/glib-2.0/include -Igen -Igen -Igen -I../../3rdparty/chromium/third_party/khronos -I../../3rdparty/chromium/gpu -I../../3rdparty/chromium/third_party/libyuv/include -Igen -Igen -Igen -Igen -Igen -Igen -I../../3rdparty/chromium/third_party/WebKit/Source -Igen/blink -I../../3rdparty/chromium/third_party/ced/src -I../../3rdparty/chromium/third_party/icu/source/common -I../../3rdparty/chromium/third_party/icu/source/i18n -I../../3rdparty/chromium/third_party/protobuf/src -I../../3rdparty/chromium/third_party/protobuf/src -Igen/protoc_out -I../../3rdparty/chromium/third_party/boringssl/src/include -I/nix/store/97dcvq0b2dnvxhy857csw1fp4m533m8d-nss-3.39-dev/include/nss -I/nix/store/lhsbi2vhfayl3lbnyy3yn74w2jdnmc0g-nspr-4.20-dev/include -I../../3rdparty/chromium/skia/config -I../../3rdparty/chromium/skia/ext -I../../3rdparty/chromium/third_party/skia/include/c -I../../3rdparty/chromium/third_party/skia/include/config -I../../3rdparty/chromium/third_party/skia/include/core -I../../3rdparty/chromium/third_party/skia/include/effects -I../../3rdparty/chromium/third_party/skia/include/encode -I../../3rdparty/chromium/third_party/skia/include/gpu -I../../3rdparty/chromium/third_party/skia/include/images -I../../3rdparty/chromium/third_party/skia/include/lazy -I../../3rdparty/chromium/third_party/skia/include/pathops -I../../3rdparty/chromium/third_party/skia/include/pdf -I../../3rdparty/chromium/third_party/skia/include/pipe -I../../3rdparty/chromium/third_party/skia/include/ports -I../../3rdparty/chromium/third_party/skia/include/utils -I../../3rdparty/chromium/third_party/vulkan/include -I../../3rdparty/chromium/third_party/skia/src/gpu -I../../3rdparty/chromium/third_party/skia/src/sksl -I../../3rdparty/chromium/third_party/libwebm/source -I../../3rdparty/chromium/third_party/leveldatabase -I../../3rdparty/chromium/third_party/leveldatabase/src -I../../3rdparty/chromium/third_party/leveldatabase/src/include -I../../3rdparty/chromium/third_party/WebKit -Igen/third_party/WebKit -I../../3rdparty/chromium/v8/include -Igen/v8/include -I../../3rdparty/chromium/third_party/iccjpeg -I/nix/store/8ic96xw2pv5bld24wzck7iw8a7cg7l7x-zlib-1.2.11-dev/include -I/nix/store/70s80dpzbng51rlc4wbzl14sgwiwsx37-libpng-apng-1.6.34-dev/include/libpng16 -I/nix/store/szvmhyrca143i7svz1l3j9h8v3797211-libwebp-1.0.0/include -I../../3rdparty/chromium/third_party/ots/include -I../../3rdparty/chromium/v8/include -Igen/v8/include -I../../3rdparty/chromium/third_party/angle/include -I../../3rdparty/chromium/third_party/angle/src/common/third_party/base -Igen/angle -I../../3rdparty/chromium/third_party/libxml/src/include -I../../3rdparty/chromium/third_party/libxml/linux/include -I../../3rdparty/chromium/third_party/libxslt/src -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -funwind-tables -fPIC -pipe -pthread -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-deprecated-declarations -fno-delete-null-pointer-checks -Wno-missing-field-initializers -Wno-unused-parameter -O2 -fno-ident -fdata-sections -ffunction-sections -fno-omit-frame-pointer -fvisibility=hidden -g0 -DLIBXML_STATIC= -std=gnu++14 -fno-delete-null-pointer-checks -Wno-narrowing -fno-exceptions -fno-rtti -fvisibility-inlines-hidden -c gen/gen/blink/bindings/core/v8/bindings_core_impl_jumbo_19.cc -o obj/third_party/WebKit/Source/bindings/core/v8/bindings_core_impl/bindings_core_impl_jumbo_19.o
{standard input}: Assembler messages:
{standard input}:377303: Warning: end of file not at end of a line; newline inserted
{standard input}:377361: Error: operand 1 must be an integer register -- `str'
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,

@GrahamcOfBorg build falkon
Hopefully, a bit fewer dependencies to build, and better luck in the qtwebengine build, if it was some bad luck that caused the failure.

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: falkon
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Attempted: falkon
Partial log (click to expand)
shrinking /nix/store/086ddlblh7b05mfxvprv9b2ss29ycgln-falkon-3.0.1/lib/qt-5.11/plugins/falkon/StatusBarIcons.so
shrinking /nix/store/086ddlblh7b05mfxvprv9b2ss29ycgln-falkon-3.0.1/lib/qt-5.11/plugins/falkon/AutoScroll.so
shrinking /nix/store/086ddlblh7b05mfxvprv9b2ss29ycgln-falkon-3.0.1/lib/qt-5.11/plugins/falkon/TabManager.so
shrinking /nix/store/086ddlblh7b05mfxvprv9b2ss29ycgln-falkon-3.0.1/lib/qt-5.11/plugins/falkon/KWalletPasswords.so
strip is /nix/store/vcc4svb8gy29g4pam2zja6llkbcwsyiq-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/086ddlblh7b05mfxvprv9b2ss29ycgln-falkon-3.0.1/lib  /nix/store/086ddlblh7b05mfxvprv9b2ss29ycgln-falkon-3.0.1/bin
patching script interpreter paths in /nix/store/086ddlblh7b05mfxvprv9b2ss29ycgln-falkon-3.0.1
checking for references to /build in /nix/store/086ddlblh7b05mfxvprv9b2ss29ycgln-falkon-3.0.1...
postPatchMkspecs
postPatchMkspecs

Success on aarch64-linux (full log)
Attempted: falkon
Partial log (click to expand)
shrinking /nix/store/f39gwg6ysh3kdc7iv4mgvp1mb36lzqkk-falkon-3.0.1/lib/qt-5.11/plugins/falkon/FlashCookieManager.so
shrinking /nix/store/f39gwg6ysh3kdc7iv4mgvp1mb36lzqkk-falkon-3.0.1/lib/qt-5.11/plugins/falkon/AutoScroll.so
shrinking /nix/store/f39gwg6ysh3kdc7iv4mgvp1mb36lzqkk-falkon-3.0.1/lib/libFalkonPrivate.so.3.0.1
strip is /nix/store/p9akxn2sfy4wkhqdqa3li97pc6jaz3r1-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/f39gwg6ysh3kdc7iv4mgvp1mb36lzqkk-falkon-3.0.1/lib  /nix/store/f39gwg6ysh3kdc7iv4mgvp1mb36lzqkk-falkon-3.0.1/bin
patching script interpreter paths in /nix/store/f39gwg6ysh3kdc7iv4mgvp1mb36lzqkk-falkon-3.0.1
checking for references to /build in /nix/store/f39gwg6ysh3kdc7iv4mgvp1mb36lzqkk-falkon-3.0.1...
postPatchMkspecs
postPatchMkspecs
/nix/store/f39gwg6ysh3kdc7iv4mgvp1mb36lzqkk-falkon-3.0.1

Thanks for the info and nudging the bot, @samueldr !


Add InsecureSecrets section to external-mqtt-trigger profile for testing purpose

🐞 Bug Report
Description and Minimal Reproduction [REQUIRED]
Based on the request of edgex-taf #848, set the authmode of external MQTT to usernamepassword. Add InsecureSecrets to the external-mqtt-trigger profile to connect secure MQTT.

@cherrycl , @cloudxxx8 , do you agree this bug is a medium and the work around is to make the changes in #579 manually for 3.0.0? i.e. don't need a patch release for Minnesota?

yes, I agree.  It's quite minor.
Also, the default AuthMode is none.  This change is for TAF to easily config the tests.


Ability to swap of RowMajor to ColMajor layout at runtime

Most ML frameworks are RowMajor, but FL is ColMajor, so we should wrap that to just expose both.

This should be possible to change throughout the program (sm.enableRowMajor() etc)
This should have minimal perf impact in either layout

done here: https://github.com/facebookresearch/shumai/commit/0f8660bef38827b308f53e05272697207db30640


Does not run in Xcode 7

Hey, nice library.
I'm getting 9 build errors on Xcode 7 (some of them are fixed automatically by Xcode, others are not):
Attached are pictures of the errors I am getting. As a beginner iOS developer, I can only fix so many errors :S

Beginner iOS dev here too....but the fix is easy
Edit > Convert > To Latest Swift Syntax
Explanation of fixes:

All of the "Missing..." errors -- caused by missing "amount" parameter name in front of second parameter (your last picture is caused by a weird bug in Xcode where it inserts the correct parameter name in the wrong position)
"Cannot invoke..." error -- caused because the call for boundingRectWithSize does not take an attributes parameter of String:AnyObject? but instead String:AnyObject (optional vs. forced unwrap) so fixed by adding "!" to the end of the textAttr definition
Both the "overload" and "ambiguous" errors are caused by the nil value for the options parameter -- fixed by changing nil to an empty array

for the boundingRectWithSize error in Xcode 7, beta version 7A192o i couldnt get it to downcast at that line so i had to downcast at the declaration of textAttr, line 189:
let textAttr = [NSFontAttributeName:textView.font as! AnyObject]

Try my pull request to resolve this issue : https://github.com/stakes/JSSAlertView/pull/21

Fixed by #26


fix(c8yscrn): Fix highlighting elements with parents having 0 bounding rect

When elements have parents that for example have display: contents set, the parents are actually not visible and have a 0 bounding rect. This could break calculation of highlight rect if selector matches multiple DOM elements. Now parents with 0 bounding rect are ignored.

Approved


Timesheet - 10/04/2021 - Truyen Hoang

Task 1

Init project structure
Setup AWS network + postgresql 12 by terraform
Test new script

Proof of Work

https://github.com/thenewboston-developers/iac/commit/0904723a540ba98691d031c031c83df9440a90f1
AWS resources

Time Spent
5,5  hours
Total Time Spent
5,5 hours
Account Number
5d52e2bb5acf296a120dc2a16efd46f6803c9a4f55cda44d6b1b6dd42d9f1a6d

Approved

Closed. This was practice, we will officially begin timesheet reports Monday, April 12, 2021


Allow setters to return

Search Terms
Setters cannot return a value
decorators

Suggestion
By default JavaScript does nothing with the return value of a setter, but it isn't an error.
Allow setters to return as the default behaviour and add flag to turn errors on.

Use Cases

Decorators that override the setter and use the original setters return value.
Methods that directly call the setter function and expect a return.

Examples
A live example would be @computed from ember-decorators, which matches the old behaviour from ember.
Code example using legacy decorators (same would be possible with stage 2 decorators):
function saved (target: {}, key: string | symbol, descriptor: PropertyDescriptor) {
  const savedStore = new WeakMap();

  const oldSet = descriptor.set;
  if (!oldSet) {
    throw new Error('Must be used on setter only');
  }
  const oldGet = descriptor.get;
  return {
    ...descriptor,
    get () {
      let response = savedStore.get(this);
      if (!response && oldGet) {
        response = oldGet.call(this);
      }
      return response;
    },
    set (value: any) {
      const result = oldSet.call(this, value);
      savedStore.set(this, result);
    }
  };
}

class Foo {
  @saved
  get square () {
    // default value of 1 if none is saved
    return 1;
  }
  set square (value: number) {
    return value * value;
  }
}

Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript / JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. new expression-level syntax)

I'd love to see property decorators allowed to return PropertyDescriptor<T> and in turn the decorated property would be of type T.
Currently I have decorator code which returns a property descriptor, but I have to also express the type of the property.
e.g.
class {
@mydecorator(arg)
myprop: string
}

If mydecorator returns PropertyDescriptor I wish TSC would infer the type of myprop to be string

I will vote for this. A return statement in a function which used as "setter" is not an error in the specification. And it is just ignored silently in most browsers.
Another use case:
class A {
  @AutoImplemented
  set name(value: string) {
    if (value === this.name) return;
    this.name = value;
    console.log('set name to: ' + value);
    return true; // Use return value to indicate that if the assignment action is performed.
  }
}

I made a "AutoImplemented" decorator, which will create a backing field with _ prefix for the property, add the getter function, and replace the assignment to the it automatically.
It will also generate $getName and $setName helpers in the prototype, to allow overriding of accessors, which is still a problem when targeting ES5. (338, 4465)
class B extends A {
  @AutoImplemented
  set name(value: string) {
    // super.name = value; <-- this will not work.
    if (!super.$setName(value)) return;
    this.updateWhenValueIsDirty();
    return true;
  }
}

updateWhenValueIsDirty should only be invoked when value is actually changed, but the super.name = value statement cannot tell me if the assignment is performed(and even it can't compile in ES5). Invoking the setter method as a instance method and checking its return value is the only way to make this work.

hum, we need a flag to omît or bypass this kind of error !
Inside a good design pattern we maybe want use return to break condition.
just as example
	set value(v: string) {
		if (this._deriveTargetValue) return (this._deriveTargetValue = v);  // apply
		this._value = v;
	}

instead of
	set value(v: string) {
		if (this._deriveTargetValue){
			this._deriveTargetValue = v
		} else {
			this._value = v;
		}
	}

A lot of people are not fan of elseif design, so using batch if return  is also valid for break thing !
thanks
So to be more abstrac in concept
this is a good design in setters
	set foo(v: string) {
		if (this._disableLocalFoo) return;
		if (this._derivedFoo) return this.deriveFoo(v);
		this._foo= v;
	}


ISPN-15882 fixed command name in documentation for RESP endpoint

ISPN-15882

@kazuhira-r hey thanks@ would you mind adding the ISPN-15882 to the commit message plz ?

@karesti Sorry, I forgot the rules for commit messages.
I fixed it to include the JIRA issue key in the commit message and Pull Request title.


New schedules are not executed

resque-scheduler (4.0.0)
New  schedules added to resque_schedule.yml are not executed.
They are shown OK in UI - look attached schedule

When starting, the new schedule appears in log as "Scheduling cbki_conversion_reader":
studnev@leadads:/var/www/leadada-tracker/current$ bundle exec rake resque:scheduler RAILS_ENV=production
resque-scheduler: [INFO] 2015-09-07T10:15:33+03:00: Starting
resque-scheduler: [INFO] 2015-09-07T10:15:33+03:00: Loading Schedule
resque-scheduler: [INFO] 2015-09-07T10:15:33+03:00: Scheduling cbki_conversion_reader
resque-scheduler: [INFO] 2015-09-07T10:15:33+03:00: Scheduling leads_conversion_reader
resque-scheduler: [INFO] 2015-09-07T10:15:33+03:00: Scheduling publisher_postback_sender
resque-scheduler: [INFO] 2015-09-07T10:15:33+03:00: Scheduling etl_log_writer
resque-scheduler: [INFO] 2015-09-07T10:15:33+03:00: Scheduling cpahub_conversion_reader
resque-scheduler: [INFO] 2015-09-07T10:15:33+03:00: Scheduling etl_log_reader
resque-scheduler: [INFO] 2015-09-07T10:15:33+03:00: Scheduling leadada_monitor_unprocessed_worker
resque-scheduler: [INFO] 2015-09-07T10:15:34+03:00: Scheduling leadada_info_update_job
resque-scheduler: [INFO] 2015-09-07T10:15:34+03:00: Schedules Loaded
but then in never executes.
Manually executing it works OK.
Configuration is:
require "resque"
require "resque/failure/multiple"
require "resque/failure/redis"
Resque.redis = "localhost:6379:1"
Rake task is:
require "resque/tasks"
require 'resque/scheduler/tasks'
task "resque:setup" => :environment do
ENV['QUEUE'] = '*'
Resque.schedule = YAML.load_file('config/resque_schedule.yml')
end
After i manually cleared all resque database in Redis, it started executing.  But again, adding new schedules are not run

This is repeating issue, which is very annoying
None of added schedules are executed, however they are correctly displayed in console and log

Issue appears due to multiple processes ran on one host
I am closing this issue, however it will be very helpfull if scheduler warns abotut this situation


Fix Issue #6650: Enable Azure Active Directory token-based auth access for AzureChatOpenAI

When using AzureChatOpenAI the openai_api_type defaults to "azure". The utils' get_from_dict_or_env() function triggered by the root validator does not look for user provided values from environment variables OPENAI_API_TYPE, so other values like "azure_ad" are replaced with "azure". This does not allow the use of token-based auth.
By removing the "default" value, this allows environment variables to be pulled at runtime for the openai_api_type and thus enables the other api_types which are expected to work.
This fixes #6650

maintainers: @baskaryan

thanks @vmansolas!


Add support for DLL exports in Win32 platforms

Add config.h header with define OPENXLSX_EXPORT with __declspec directive
for support export symbols in build and import in client code.
Also move some default constructors and assignament operators
to .cpp file by avoid incomplete type issues with exported inline
methods.

Changes includes in other pull request


rancher-catalog-service unsafe interface conversion of config.yml values

Rancher Versions:
rancher-catalog-service: v0.15.0
Steps to Reproduce:

Create a catalog entry with a values.yml that includes a value that can be interpreted as an int/float. For example:

name: Zammad
description: |
  Zammad is a web based open source helpdesk/customer support system
version: 1.2
category: Ticketsystems
maintainer: "Zammad Project<EMAIL_ADDRESS>projectURL: https://github.com/zammad/zammad
license: AGPL-3.0

Launch rancher-catalog-service with the repository configured to serve the newly created catalog entry: ./rancher-catalog-service -catalogUrl library=https://github.com/monotek/community-catalog
Make an API call to get the template details: http://localhost:8088/v1-catalog/templates/library:zammad

Results: The non-string value version appears as an empty string in the API. This is due to unsafe interface conversion: https://github.com/rancher/rancher-catalog-service/blob/master/manager/catalog.go#L261-L281
Expected: The yaml parser is given an out object that contains typed fields so interface conversion logic is not necessary
This bug was caught by our community-catalog CI system which performs some basic validation of template objects served from rancher-catalog-service API:
https://github.com/rancher/community-catalog/pull/411

Version - master 2/21
Verified fixed


[feat] ScriptConfig includes ARGS field

I would like to manage scripts with ScriptConfig. As some of my scripts are not args-empty, I have to handle them specifically. Why does ScriptConfig exclude ARGS and is it possible to include ARGS? ARGS is part of a script, I think it is useful for developers that support managing these scripts with non-empty args.
https://github.com/nervosnetwork/lumos/blob/bba6b4db382638250910a3d7224ac1b56527ad0b/packages/config-manager/src/types.ts#L2-L10

The ScriptConfig is designed for managing needed scripts' deployed info in a dApp

CODE_HASH + HASH_TYPE for determined which deployed code should be used for a script in a cell
TX_HASH + INDEX + DEP_TYPE for determined which OutPoint should be used for CellDeps

These configs are usually static constants, whereas args are generally not constants
const tx = {
  cellDeps: [
    {
      tx_hash: CONFIG.SECP256K1_BLAKE160.TX_HASH,
      index: CONFIG.SECP256K1_BLAKE160.INDEX,
      dep_type: CONFIG.SECP256K1_BLAKE160.DEP_TYPE
    }
  ],
  outputs: [
    {
      code_hash: CONFIG.SECP256K1_BLAKE160.HASH_TYPE,
      hash_type: CONFIG.SECP256K1_BLAKE160.HASH_TYPE,
      args: "0xMY_PUBLIC_KEY_HASH" // args is not a static constant
    }
  ]
  ...
}

There may be scenarios where args is a constant, but we don't recommend hard coding it directly in ScriptConfig either, as it's not easy to understand, maybe write it as a named constant in the application and then use it

// we assume that deposit and withdrawal implemented in a contract
const DEPOSIT_LOCK_ARGS = '0x...'
const WITHDRAW_LOCK_ARGS = '0x...'

const depositTx = {
  outputs: [
    {
      args: CHARGE_LOCK_ARGS
    }
  ],
  ...
}

const withdrawTx = {
  outputs: [
    {
      args: WITHDRAW_LOCK_ARGS
    }
  ]
}

The ScriptConfig is designed for managing needed scripts' deployed info in a dApp
CODE_HASH + HASH_TYPE for determined which deployed code should be used for a script in a cell
TX_HASH + INDEX + DEP_TYPE for determined which OutPoint should be used for CellDeps

Thank you for such a detailed reply.
I understand the design principles. But the above design principles sound like it is more like "script code config" than "script config".

A common deployment is like:

Deploy a cell that cell.data is the script code
Construct scripts using the above script code, Script { code_hash: <referenced to the above script code>, args: <self-defined args> }

The current ScriptConfig is for script code only.

Close this issue since I understand the purpose of this module, https://github.com/nervosnetwork/lumos/issues/344#issuecomment-1122103168, it is a good principle.


Task/add initial files

Should the namespace be more specific, e.g. "saas_client" or "saas_api_python"?

Should the namespace be more specific, e.g. "saas_client" or "saas_api_python"?

"Python" I think is clear from the context, as it is a python namespace and not a java one.
Imagining using the API, I assume a developer would prefer writing something like saas.connect() rather than saas_client.connect().
But maybe, later on, we might create a class Client in saas.client, which is not prevented by the initial repository layout.

I agree that the word "python" is not needed. Longer names in the import are usually not a problem as you can use short aliases. I just thought it would be good to distinguish between the backend and the client namespaces. But I guess exasol.saas.client will work just as well.


Run tests with Django 1.11

I guess you're going to need a release, right?
Please ping me tomorrow morning ;o)


⚠ Bofrost.at has degraded performance

In 7c5da67, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1636 ms

Resolved: Bofrost.at performance has improved in 02a6ea7 after 13 minutes.


Sample notebook addition - molecular modeling blog

Community Note

Please use a 👍 reaction to provide a +1/vote. This helps the community and maintainers prioritize this request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Graph Notebook Version (and Graph Database and Version used if applicable)
Is your feature request related to a problem? Please describe.
Submitting a request to add my sample notebook on molecular modeling to the repository of sample applications
Describe the solution you'd like
Approval and addition of the notebook file I have created to be added to the repository. Will be attached to upcoming blog publish
Additional context
Add any other context or screenshots about the feature request here. Describe any alternatives you've considered.

Hi @gkutchekAWS ,
Thank you for the heads up. We greatly appreciate your interest in contributing to graph-notebook, and are looking forward to your sample notebook and blog post!
Please feel free to submit a pull request for the new notebook whenever you are ready for a review.

Closing in favor of #472.


What are the requirements for the script to work?

Hey!
I found your script and got my hopes up! 😄 However, I've tried a bunch of SVG files and haven't managed to get any to work reliably. What would you say the requirements are for this script to work well as-is?
For example, this SVG ended up like this:

Thanks and nice work!

Unfortunately, since Godot does not have a proper "path"-node, the script is not intended to import complex paths.
However, I opened and re-saved the svg-file in Inkscape and got the following result (after rearranging some of the resulting shapes):

You can also try out setting var use_path2d = true to get propper paths via Path2D node. However, those are only visible in the editor:

Ah, nice! Thanks for the pointers 😊


Generate PGF to verbalise s(CASP) answers from L4 code

This is the final piece needed for the expert system pipeline.
Now the command l4 yaml creates the PGF file AnswerTop.pgf, which will be copied to the Docassemble server.
(It also includes the questions, which are not currently used. TODO improve them and maybe use later.)

hello @inariksit, I’ve looked through the changes, and tried running the updates. I am not entirely sure what (if any) feedback you are looking for, or how it fits into the expert systems pipeline. From what I’ve seen, the output pgf file would need to be uploaded (together with the lexsis and scasp files) to the docassemble server, where it would help sCASP generate better answers? Is the pgf file ingested by the gf-python package?
The arity thing is very interesting though, and could possibly help with the lexsis generation as well.

@alfredats Sorry for being unclear! This PR doesn't contain anything that uploads the generated file to the docassemble server, it just constructs the PGF.
And yes, the PGF that this update generates (AnswerTop.pgf) is the one that gf-python uses. Before this PR, we have just been using a manually crafted PGF, which is currently committed in the gf-python repository.

@alfredats Let us (the NLG team) know if there's anything more you need from us to integrate things better into the expert system. I will merge this now in any case.


Look at the seasonal cycle

It would be interesting to carry out the skill score analysis month-by-month or season-by-season.

Agreed.
Just a note: the FAR output is currently just decadal means, so we'll have to exclude them for the seasonal analysis for now. The seasonal data exists but I haven't processed those binary files just yet.


fix(grid-and-flex): Eager conversion of flex and grid related props

Felxbox and grid support flow-neutral authoring out of the box, so
properties related to them should not be transformed into physical
directions.
Similarly, content is about content, so thould not be
transformed either.

Codecov Report

Merging #2 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master     #2   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           1      1
  Lines          44     47    +3
  Branches       17     18    +1
=====================================
+ Hits           44     47    +3

Impacted Files
Coverage Δ

src/index.js
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Drop IsForeign from onInput

IsForeign here is a bit misleading, as the value is always a string for this event. I've been tripped up several times trying to use IsForeign to cast the value to a number for me, but it won't ever do that as IsForeign reading only succeeds for prim values with the right runtime tag.
The same might be true for onValueChanged, but I'm not 100% certain.

:+1: I hate foreign. :smiling_imp:

The same might be true for onValueChanged, but I'm not 100% certain.

How can a value ever be a non-string

I was thinking in the case of <select> - I'll do a test to see you get values or indices, I suspect it is values though.


tile grid to solid

https://github.com/adonaac/fuccboiGDX/blob/master/fuccboi/world/Tilemap.lua#L28

Should be implemented at a game level because it depends on GameObject creation. So it's out of scope for this


Unable to use the send button message in Electron.

I tried using the send button message in Electron, but it couldn't send it correctly

I use preload to load wa.js in Electron
window.WPP = require('@wppconnect/wa-js')
This is my code
if(!id.endsWith("@c.us")){
<EMAIL_ADDRESS>}
const data = "data:" + mime + ";base64,"+ base64
const msg = await window.WPP.chat.sendFileMessage(id,data,{
type:mime,
caption:text,
buttons: [{
id: 'your custom id 1',
text: 'Some text'
}]
})
This is the returned result
{"id":"true_xxxx@c.us_xxxx_out","ack":-1,"sendMsgResult":{"_flags":269,"_value":"ERROR_UNKNOWN","_resolveLevel":2,"_thenableParent":null,"_parent":{"_flags":13,"_value":"ERROR_UNKNOWN","_resolveLevel":2,"_thenableParent":null}}}

I have solved this problem