deactivated functions are activated again after reboot

Microsoft PowerToys version
0.53.1
Running as admin

[X] Yes

Area(s) with issue?
General
Steps to reproduce
i have deactivated awake, fancyzones and mousetools.
after restart of powertoys they are activated again.
✔ Expected Behavior
No response
❌ Actual Behavior
No response
Other Software
No response

I tried to repro and didn't fail.
/reportbug to see if we can't see something in the logs.

@adam1book too

PowerToysReport_2022-01-12-07-55-58.zip
@crutkas Zip file uploaded. I disabled all tools except for FancyZones, File Explorer add-ons, and Mouse utilities; restarted PowerToys; and created the zip. All disabled tools were re-enabled after the restart.

ok here is my zip file
PowerToysReport_2022-01-12-16-20-55.zip

P.S. on an other system i have the same behavior

Tried replicating by copying in the settings from the bug report to my local settings folder, but PowerToys reacts to it as expected on my machine.
This might have something to do with access, has suggested by @adam1book .
Could we please try something to get more info?
In file explorer, navigate to %LOCALAPPDATA%\Microsoft\PowerToys and check the settings.json file properties, like security to check if you'd have access. Check for weird flags as well, like read-only, hidden, etc...
Also check if after enabling/disabling PowerToys that file gets changed or its date gets modified.
When editing settings for a specific PowerToy, try to see if the *-settings.json file inside each PowerToy folder gets edited as well.

PowerToysReport_2022-01-12-16-16-52.zip
But I will move conversation into that other thread.
Originally posted by @t-makaro in https://github.com/microsoft/PowerToys/issues/15491#issuecomment-1011569605
@t-makaro Please check what @jaimecbernardo requested in the previous comment too.

This occurs still after I did a fresh install of Powertoys. If the computer reboots with powertoys open, and powertoys launches on startup this does not occur. This occurs if I manually exit powertoys from the system tray and reopen it; just to be clear.
The settings.json file is not read-only, and I do have permission to edit it. Yes, that file is changing if I make a setting change in powertoys. When I closed powertoys from the system tray, the settings.json file also changed, but I'm not sure what. When I launch powertoys. I notice that the settings.json file changes to contain:
"enabled":{}

which if I then open the powertoys settings the settings.json file repopulates with all of the toys enabled set to true.

So, PowerToys is populating the "enabled":{} field when you open it and then reverting it to "enabled":{} when you close it?
Could you please give some more details about what's happening to the "enabled":{} field? That's where the enabled/disabled settings of PowerToys get saved.

i have morfe information:
when i start powertoys from whith its autorun option form task sheduler (at logon) the error does not occur,
only if i start it from startmenu or from my batchfile.
the error occurs not with te videotools options.

@jaimecbernardo Powertoys is deleting the entries inside "enabled":{} when I start Powertoys from the start menu. The toys that I disabled don't know that they should be disabled, so they must be using some default. When I load the settings UI then the entry inside of settings.json gets repopulated with the defaults.
@Matzeeee is right. If I click "Run as Administrator" on Powertoys in the start menu. Then this does not happen. This only happens if I run powertoys but just hitting "Open" (or an equivalent) even though Powertoys does give a UAC prompt when opening this way.

Interesting. I'm not aware of a reason why PowerToys would be unable to read the file properly but then would be able to save it.
It might be something else, like a general load fail where we end up going to a code path that resets that main file. Are settings that are unique to each PowerToy getting reset as well?
Would you mind creating a new bug report and sending it? We might be able to pick up a pattern with the added entries in the logs from repetition.

powertoys started "normal" (no admin) with error reenable some tools
PowerToysReport_2022-01-14-14-44-19.zip
:

powertoys started as admin with no error
PowerToysReport_2022-01-14-14-46-02.zip
:

@jaimecbernardo No, settings that are unique to each powertoy do not appear to be reset, nor do the other general settings such "startup":. It's just the "enabled": section.

Having this exact same issue. See attached for my bug reportfile
PowerToysReport_2022-01-21-10-00-45.zip

now i have activated the option "run as admin" in the properties of the powertoys.exe file ...

Having the same issue, had to set my settings.json to read only to stop it getting reverted.

https://github.com/microsoft/PowerToys/blob/main/src/runner/main.cpp#L410
Here settings are saved before modules() have been loaded, which is propably a cause of this issue.

The was fixed in in 0.55. Head over to https://aka.ms/installpowertoys to try it out

Tried the new version, issue still present.

I am still encountering this on 0.55 as well.

The issue still persists, because #15818 changed nothing in terms of how modules are saved.

As I can't reproduce this, could someone try this test build and let me know if something has changed?
installer .exe can be found here:
https://github.com/stefansjfw/PowerToys/releases/tag/v0.0.1

I can't reproduce this

This is completely impossible. Are you sure you are testing it on PowerToys v0.55.0 and are following the following instruction:

Make sure your PowerToys is not running as administrator.
Tick Always run as administrator
Disable Awake module (or any other)
Close PowerToys
Enable it again and make sure it's now running in administrator mode.
Enabled modules should be reset to defaults by now

I can't reproduce this

This is completely impossible. Are you sure you are testing it on PowerToys v0.55.0 and are following the following instruction:

Make sure your PowerToys is not running as administrator.
Tick Always run as administrator
Disable Awake module (or any other)
Close PowerToys
Launch it again and make sure it's now running in administrator mode.
Enabled modules should be reset to defaults by now

1 and 2 is not possible in regular PT usage, only when PT is started by installer after installing/updating (see https://github.com/microsoft/PowerToys/issues/15487).
So this only happens for you right after installing/updating PT ? Or you can reproduce it somehow when manually starting PT ?
Did you try test build ? Could you try and and reattach /bugreport?
Thanks in advance

@stefansjfw Sorry, I wasn't aware of this behavior, so I gave you incorrect instructions. I've already corrected them. The issue happens when PowerToys is restarting to open in administrator mode, here the settings are saved before modules() have been initialized.

@stefansjfw Sorry, I wasn't aware of this behavior, so I gave you incorrect instructions. I've already corrected them. The issue happens when PowerToys is restarting to open in administrator mode, here the settings are saved before modules() have been initialized.

This is exactly what I'm trying to solve :) So, I just need confirmation that test build works. Could you try it please ? :)
https://github.com/stefansjfw/PowerToys/releases/tag/v0.0.1

@Gieted Thanks for your help! I believe this is now (properly) solved

I can confirm. That this appears resolved now.

Shipped with 0.55.1 release.

This should be fixed with 0.55, we're closing this out with the 0.56 release


People Collection - View as Role

Now that we're experimenting with affiliations modeling first-class roles, it could be helpful to have a view that slices just one role

I think this covers it


Scan QR code using front camera

I want to implement scan QR code using front camera. Before adding this library to my application I want to confirm if this works. I tried using this module: https://github.com/moaazsidat/react-native-qrcode-scanner
But this works for only back camera. I need to implement from front camera instead.

I don't know if QR code scanning will work for the front camera, sorry. Try it out and please let me know if it does (as I suspect it may not).


Show how many votes are present/missing

In today's refinement meeting, @LiTe1991 had the idea that it would be useful for a Scrum master to know how many people are in the current session, and how many of those have voted on the active item, already. This way, they would not have to count the people/votes manually to know when the estimation for the item is complete.

@hangy thanks, good suggestion. We'll triage and I'll come back with an update later this week.


Add property for generating standalone binary

This PR adds three items to <PropertyGroup> so that using dotnet publish Source/Boogie.sln -r <RID> can generate standalone binary of boogie.

https://github.com/dotnet/sdk/issues/10053
Looks like there is a conflict between PackAsTool and self-contained app.

dotnet/sdk#10053
Looks like there is a conflict between PackAsTool and self-contained app.

Interesting... I tried dotnet publish  Source/Boogie.sln  -r osx-x64 -c release and it works. Perhaps because I am using publish instead of build?

For publishing Boogie online I'm guessing we don't want the options that this PR configured. How about you add a .sh file that invoces dotnet publish with the arguments you require? That way rest of Boogie is unaffected.


Hosting using wrong backend enviroment (since web compute migration)

Before opening, please confirm:

[X] I have checked to see if my question is addressed in the FAQ.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting questions.
[X] I have removed any sensitive information from my code snippets and submission.

App Id
deu8uyp1wcls7
AWS Region
eu-west-1
Amplify Hosting feature
Backend builds, Build settings
Question
Hi all!
I've migrated to Web Compute Next 12 SSR yesterday evening. Since then all builds use the dev environment. I've tried creating new branches and coupling them with the main environment, but no cigar; all use the dev environment.
The master environment is still live, and can be accessed locally when checking out that env.
I honestly have no idea at the moment how to fix this issue. Should I revert the migration?
Is it because there might be cache stuck somewhere?
Posted this under questions, I'm not sure if this is a bug or a mistake at my end.
Update. Reverted back to WEB_DYNAMIC but amplify url is now throwing 500 errors.
I'm sorry I don't have any more info at the moment.

For reference. It was a combination of

migrating from SSG to SSR
migrating from WEB_DYNAMIC to WEB_COMPUTE
Redirects/rewrites
yarn workspace monorepo setup, but not in the way amplify recommends.

Adding     outputFileTracingRoot: path.join(__dirname, "../..") to nextConfig.experimental fixed the issue of 500 errors being returned. The underlying problem was Error: Cannot find module 'next/dist/server/next-server' which seems to be because of a hoisting problem. More in this thread: https://github.com/vercel/next.js/discussions/39432
It's definitely worth checking the cloudwatch logs 👍


the setup.py  file need to fix.

Make sure these boxes are checked before submitting your issue - thank you!

[ ] I have checked the superset logs for python stacktraces and included it here as text if any
[ ] I have reproduced the issue with at least the latest released version of superset
[ ] I have checked the issue tracker for the same issue and I haven't found one similar

Superset version
0.18.5
it is a litle problem,i find someone change the path static/assets,but the path in setup.py is also using.so,i think you need to fix it.
in the setup.py :
PACKAGE_DIR = os.path.join(BASE_DIR, 'superset', 'static', 'assets')
need to change as:
PACKAGE_DIR = os.path.join(BASE_DIR, 'superset', 'assets')

static/assets is a link to assets. Are you on windows?

i am on ubuntu14.04,the link can not work

im wrong,when i delete the static,i can compile it. but ,superset can not running . some file depend on it


Generating negative samples

Hi may i know how to go about doing so? i want to resolve some issues regarding the model mistaking other markings for lanes

@nathannzw Then you need to modified the code to change the model from binary classification into multi class classification:)


WIne detection step in install script sees v9.10 as less than v9.8 and forces user to install wine again.

Describe the bug
As the title says.
To Reproduce
Steps to reproduce the behavior:

Install a version of wine-staging that is still in the 9 series and has a dot-release of greater than or equal to 10.
Run the install script.

Expected behavior
The install script is happy with the version of Wine installed.
Additional context
The issue is that the math comparison of version numbers only works while the dot-release of wine hasn't gone into double digits. After that is stops behaving like a decimal number and can no longer be compared as one.

Resolved with #427.


Update Visual Studio 2019 to install "Blend for Visual Studio" option

Tool information

Tool name: Visual Studio 2019 - Blend for Visual Studio option
Tool license:
Update
Desired version: Latest
Approximate size:

Area for Triage:
Visual Studio
Question, Bug, or Feature?:
"Feature"
Virtual environments affected

[ ] macOS 10.15
[ ] Ubuntu 16.04 LTS
[ ] Ubuntu 18.04 LTS
[ ] Ubuntu 20.04 LTS
[ ] Windows Server 2016 R2
[X] Windows Server 2019

Can this tool be installed during the build?
I don't know
Tool installation time in runtime
Minimal
Are you willing to submit a PR?
No, beyond my experience with the environment generation.

Hi @pculver,
There is a component Microsoft.ComponentGroup.Blend for VS2019 that can be installed in runtime (takes about 20 seconds) with the following code:
steps:
  - name: Install Blend component
    run: |
       Start-Process -FilePath "C:\Program Files (x86)\Microsoft Visual Studio\Installer\vs_installer.exe" -ArgumentList "--add Microsoft.ComponentGroup.Blend --passive --norestart --wait --installpath ""C:\Program Files (x86)\Microsoft Visual
 Studio\2019\Enterprise""" -Wait -PassThru
    shell: pwsh

Does installation in runtime work for you?

I am a bit new to Azure pipelines.  It might work.   What task would I add to the build process?  I tried both a command line and powershell tasks and neither produce YAML that exactly matches what you put above?

oh, you are using Azure DevOps, I provided step for GitHub Actions.
For Azure DevOps you can use the following code for YAML or use PowerShell V2 task:
steps:
- powershell: 'Start-Process -FilePath "C:\Program Files (x86)\Microsoft Visual Studio\Installer\vs_installer.exe" -ArgumentList "--add Microsoft.ComponentGroup.Blend --passive --norestart --wait --installpath ""C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise""" -Wait -PassThru'
  displayName: Install Blend Component

Hi @pculver, I am going to close this issue.
Please, feel free to reopen or file a new one if any help needed.
Thank you!


Unexpected keyword argument 'hf' when downloading CSV dataset from S3

Describe the bug
I receive this error message when using load_dataset with "csv" path and dataset_files=s3://...:

        Parameters
        ----------
        refresh : bool
            Whether to create new session/client, even if a previous one with
            the same parameters already exists. If False (default), an
            existing one will be used if possible
        """
        if refresh is False:
            # back compat: we store whole FS instance now
            return self.s3
        anon, key, secret, kwargs, ckwargs, token, ssl = (
            self.anon, self.key, self.secret, self.kwargs,
            self.client_kwargs, self.token, self.use_ssl)

        if not self.passed_in_session:
>           self.session = botocore.session.Session(**self.kwargs)
E           TypeError: Session.__init__() got an unexpected keyword argument 'hf'

Steps to reproduce the bug

Assuming a valid CSV file located at s3://bucket/data.csv
Run the below code:

storage_options = {
    "key": "...",
    "secret": "...",
    "client_kwargs": {
        "endpoint_url": "...",
    }
}
load_dataset("csv", data_files="s3://bucket/data.csv", storage_options=storage_options)

Encountered in version 2.16.1 but also reproduced in 2.16.0 and 2.15.0.
Note: I encountered this in a unit test using a moto mock for S3, however since the error occurs before the session is instantiated, it should not be the issue.
Expected behavior
No exception is raised, the boto3 session is created successfully, and the CSV file is downloaded successfully and returned as a dataset.
===
After some research I found that DownloadConfig has a __post_init__ method that always forces this value to be set in its storage_options, even though in case of an S3 location the storage options get passed on to the S3 Session which does not expect this parameter. I assume this parameter is needed when reading from the huggingface hub and should not be set in this context.
Unfortunately there is nothing the user can do to work around it. Even if you manually do something like:
download_config = DownloadConfig()
del download_config.storage_options["hf"]
load_dataset("csv", data_files="s3://bucket/data.csv", download_config=download_config)

the library will still reinsert this parameter when download_config = self.download_config.copy() in line 418 of download_manager.py (DownloadManager.download).
Therefore load_dataset currently cannot be used to read a dataset in CSV format from an S3 location.
Environment info

datasets version: 2.16.1
Platform: macOS-14.2.1-arm64-arm-64bit
Python version: 3.11.7
huggingface_hub version: 0.20.2
PyArrow version: 14.0.2
Pandas version: 2.1.4
fsspec version: 2023.10.0

I am facing similar issue while reading a csv file from s3. Wondering if somebody has found a workaround.

same thing happened to other formats like parquet

I am facing similar issue while reading a parquet file from s3.
i try with every version between 2.14 to 2.16.1 but it dosen't  work

Re-define the DownloadConfig might work:
`    class ReviseDownloadConfig(DownloadConfig):
def post_init(self, use_auth_token):
if use_auth_token != "deprecated":
warnings.warn(
"'use_auth_token' was deprecated in favor of 'token' in version 2.14.0 and will be removed in 3.0.0.\n"
f"You can remove this warning by passing 'token={use_auth_token}' instead.",
FutureWarning,
)
self.token = use_auth_token
    def copy(self) -> "DownloadConfig":
        return self.__class__(**{k: copy.deepcopy(v) for k, v in self.__dict__.items()})

downloadconfig = ReviseDownloadConfig()`

Same here, can be easily reproduced with ds = load_dataset("parquet", data_files={"train": ["s3://..."}, ...) for any files in s3. Using the current version of datasets from pip, transformers 4.38.0.dev0, aiobotocore==2.7.0, boto3==1.28.64, botocore==1.31.64.

Re-define the DownloadConfig might work:
class ReviseDownloadConfig(DownloadConfig):
    def __post_init__(self, use_auth_token):
        if use_auth_token != "deprecated":
            warnings.warn(
                "'use_auth_token' was deprecated in favor of 'token' in version 2.14.0 and will be removed in 3.0.0.\n"
                f"You can remove this warning by passing 'token={use_auth_token}' instead.",
                FutureWarning,
            )
            self.token = use_auth_token

This seemed to work for me.

use pandas and then convert to Dataset

I am currently facing the same issue while using a custom loading script with files located in a remote S3 instance. I was using the download_custom functionality but now it is deprecated mentioning that I should use the native S3 loading, which is not working.
As stated before, the library forces the existence of a hf key in the storage_options variable, which is not accepted by  s3fs : TypeError: __init__() got an unexpected keyword argument 'hf'.
Meanwhile, if my storage_options var stays like:
{'key': '...',
 'secret': '...',
 'client_kwargs': {'endpoint_url': '...'}}

it works alright.


social network feed

hi. thanks for your great works.
is it possible to get social account (such as twitter) with picoFeed?

Picofeed used to handle Twitter just fine when they provided an RSS feed. Then they locked down their api and made it very hard to use: you need to get a token for your library and one for every Twitter user that accesses the api. The website for getting both tokens is ridiculously hard to use so asking your users to get a token is out of question. To make matters worse both tokens are limited to a small amount of queries per day.
If you ask me, all social networks and especially Twitter try to keep their information locked in to keep views and interaction on their page as much as possible (ads!), that's why they are all rolling out very hard to use apis.
Those APIs also work fundamentally different than RSS/atom feeds so you're better off using a dedicated library, see https://dev.twitter.com/overview/api/twitter-libraries

Tldr: social media APIs make it hard to impossible to use their feed like content in a feed reader properly.


Add UTs for AdjustResources

What would you like to be cleaned:
#1197 added a dedicated helper method to adjust resources from LimitRanges, RuntimeClass and limits.
They need some tests. I have a WIP in https://github.com/kubernetes-sigs/kueue/commit/7af676bc42aeef82e98d98930f0b04f67e483ffc
Why is this needed:
Increase coverage

/kind help
/assign @B1F030


test: Support upgrade test from the current version

closes: #3592

OK, I think I have a simplification of this that will work. @YanniHu1996 let me address the comments so far in my next PR.

/ok-to-merge


[Feature Request] TriggerSourceXmlTest

Checklist

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

Describe the feature
TriggerSourceXmlTest
Additional context
No response

u2a_DTS_Transfer_request_Table.xlsx

u2c_DTS_Transfer_request_Table.xlsx

u2c_sDMAC_Transfer_request_Table.xlsx

TestSpec_API_HeaderComment_RH850F1KH-D8.xlsx

TestSpec_General_RH850F1KH-D8.xlsx

u2b_sDMAC_Transfer_request_Table.xlsx


App page-business logic

please also update release notes

please also update release notes

this is already updated


Check calendar access

Check if that's possible to get user's calendar feed from API

find a tool to read incoming emails at account
match accept/decline events and make some job

find api to exchange ical


add FLIP for cadence mutability restrictions

Adds FLIP for improvements to Cadence's handling of public fields in structures. See discussion in https://github.com/onflow/cadence/issues/1260 for more discussion of this issue. An implementation of the FLIP can be found in https://github.com/onflow/cadence/pull/1267.

For contributor use:

[X] Targeted PR against master branch
[X] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[X] Updated relevant documentation
[X] Re-reviewed Files changed in the Github PR explorer
[X] Added appropriate labels

First of all, thank you very much for taking time for the detailed FLIP.
I have a question about:

Another approach would be to make let a true constant declaration, and forbid writing or mutating it in any context,
while allowing var to be mutated in all the contexts it can be written. This, however, is likely too restrictive;
a complex initialization for a dictionary or array value may benefit from the ability to iteratively mutate its contents,
up to the point at which its value is finalized, and can thus be exported. As such we would like to still allow users
to perform mutations in an limited context.

This part confused me a little, I see following scenarios in general: ( if we try to limit to pub scope)
owner can change, public can change: pub(set) var
owner can change, public cannot: pub var
owner and public cannot change: pub let
if I would like to let's say iteratively change the content, it feels like I should choose pub var

This is a good question, and the semantics you propose would also solve the issue in question. Coming from a functional background myself, I actually personally prefer the behavior you describe in general. However, given the existing programming paradigm used by Cadence, I am not sure that having pub let denote a purely immutable value by default is the right solution. There is a pretty big difference between overwriting a value entirely (like var lets you do), and adding or removing a value from an array or dictionary. Requiring that users make their fields writable in order to mutate them does not seem like the right approach to me for this reason.
Additionally, there are existing contracts that we have to consider, and it is likely that restricting pub let fields from being mutated in any context, even inside the contract or structure where they are defined, would break a much larger proportion of existing code. Mutating a field privately is not inherently a bad behavior, and is thus much more likely to occur in valid code than the field being mutated in a public context, which is a security issue.
This FLIP proposes a minimally invasive solution to the existing problem in the interest of presenting an easy migration path for users who were relying on the old, bad behavior by only restricting exactly the bad behavior we wish to prevent. That said, if the community overall prefers the behavior you are describing, it is certainly also worth considering since it does address the problem at hand.

Considering Cadence dictionaries are value types, I think let + value type to be mutable will be little unexpected.
But rest of the part I agree, it is a bit bigger change for backward compatibility. (I just checked contracts, lots of let)

I think it would be also very nice if we can get immutability as a concept in cadence.
It can save a lot of code in contracts (especially query part of some contracts)
I am thinking something like a flag in composite or resource, that will make the composite reference immutable.
Basically you can access all fields and call all methods as long as it doesn't mutate the object. (Ofc you cannot move resources)

This is exciting! I'm looking forward to having this in the language. 😃

As mentioned above, I feel like the "pub let mutability problem" won't be solved completely after this change, so it would be nice to also think about how these proposed mutation rules can be applied to composite values.

This proposal uses the same behavior that Cadence currently has for reassignments, which is that the access modifier of the "lowest" field in a nested composite determines whether or not something can be reassigned. Consider:
pub struct Foo {
    pub let x: Integer
    pub(set) var y: Integer
    init() {
        self.x = 3
        self.y = 3
    }
}

pub struct Bar {
    pub(set) var f: Foo
    pub let g: Foo
    init() {
        self.f = Foo()
        self.g = Foo()
    }
}

pub fun main() {
    let b = Bar()
    b.f.x = 2 // this is an error
    b.g.y = 1 // this is fine
}

One possible change that might address your concern would be to consider the access modifiers of every field in the nested access; i.e. require that in order to modify a.b.c, both b and c have a pub(set) var modifier. In this scenario, b.f.x and b.g.y would both not be writeable, since one of the two fields in the access has a pub let modifier, but b.f.y would be valid to write to from outside of both Bar and Foo.

+1. It is too easy to by accident make something mutable.


docker.io: "we now block all IP addresses that are located in Cuba, Iran, North Korea, Republic of Crimea, Sudan, and Syria"

Before proceeding

[X] I didn't find a similar issue

Version
2.2.0
How to reproduce

Have an IP from Cuba, Iran, North Korea, Russia, Sudan, and Syria.

# werf.yaml:
image: main
from: alpine

Run werf build

Result
Error: phase build on image main stage from handler failed: unable to fetch base image "alpine:3.17.3" for stage main/from: unable to pull image alpine:3.17.3: Error response from daemon: error parsing HTTP 403 response body: invalid character '<' looking for beginning of value: "
403 Forbidden
\nSince Docker is a US company, we must comply with US export control regulations. In an effort to comply with these, we now block all IP addresses that are located in Cuba, Iran, North Korea, Republic of Crimea, Sudan, and Syria. If you are not in one of these cities, countries, or regions and are blocked, please reach out to https://hub.docker.com/support/contact/\n\n"

Expected result
Build succeeded.
Additional information
No response

Reason
docker.io blocks requests from IPs from certain countries.
Mitigation
If you use Docker backend for building images, then add a registry mirror, following these instructions:
https://docs.docker.com/docker-hub/mirror/#configure-the-docker-daemon
If you use Buildah backend or is using our registry.werf.io/werf/werf images, then set an environment variable WERF_CONTAINER_REGISTRY_MIRROR_<any-key>, e. g. WERF_CONTAINER_REGISTRY_MIRROR_1=mirror.gcr.io


[Migrated] Fix handling of gzip-encoded text response

Originally from: https://github.com/Miserlou/Zappa/issues/2141 by suriya
When Zappa receives a compressed text/plain response from the
application, it tries to process it as a text response. Instead, Zappa
should treat the response as if it were a binary one and base-64 encode
the response body.
See issue #2080 binary_support logic in handler.py (0.51.0) broke compressed text response
https://github.com/Miserlou/Zappa/issues/2080

Description

GitHub Issues

duplicate
https://github.com/zappa/Zappa/issues/908
closing


Zf mvc auth can not identifier request type. Collection or Entity

https://github.com/zfcampus/zf-mvc-auth/blob/25dca76fbe9017165dbe2c2dc7ac51146ea6149d/src/Authorization/DefaultResourceResolverListener.php#L126
This method can not identifier request type for authorization check.
I have REST service
/path/to/url[/:identifier_name]

Allowed methods is
COLLECTION -> GET
ENTIITY-> PUT
for authorization  I have this configs
'collection' => [
	'GET' => true,
	'POST' => false,
	'PUT' => false,
	'PATCH' => false,
	'DELETE' => false,
],
'entity' => [
	'GET' => false,
	'POST' => false,
	'PUT' => true,
	'PATCH' => false,
	'DELETE' => false,
],

but when I'm sending request like this
/path/to/url?identifier_name=some_value

zf auth think that this is ENTITY-> GET.
because of on line 137 you are checking also if identifier exist in query parameters

@weierophinney  what you think about it.
is it ok?

It's not interpreting the request as a GET request; it's instead matching a query string argument (which can occur with ANY URI, not just those sent via GET).
I'm not sure why we check for the identifier in the query string arguments, to be honest; we likely shouldn't. However, to change that at this time would break backwards compatibility.
Can you answer a couple questions for me, please, so we can better evaluate your concerns?

Why are you sending the identifier using a query string argument in the first place?
What problems are you observing due to the current behavior, exactly?

This repository has been closed and moved to laminas-api-tools/api-tools-mvc-auth; a new issue has been opened at https://github.com/laminas-api-tools/api-tools-mvc-auth/issues/1.


feat: support visitor write comment after read atricle

There is a comment area at the bottom of the article details page.
Visitors can comment on the article content after logging in to Github Oauth.
New comment can send notification to administrator by email.

Database Required! Maybe mysql 8.0？Use Gorm or sqlx?


Iterate over all fields in the named JSON array.

Some json files have an object with multiple named entries, each containing the same structure, instead of an array.
Provide an option to have each field treated as a separate element in an array.
But we have to still support users who want to name the SINGLE object to be processed.

Object.values will work on an object too.
So we only need a switch to prevent doing topobj = [ topobj]

Implemented in 0.27.0
If the new field is selected then the named toplevel field in the JSON file will have a separate note created for each subfield.
The name of the subfield can be accessed using {{SourceIndex}}


Expose region and zone task info in API

JIRA Issues: MARATHON_EE-1849

@timcharper can someone please re-review the whole thing including the pods and then merge?


create_with_config_of now calls a virtual function

create_with_config_of now calls a virtual (protected) function to allow proper creation of derived classes without unnecessary copy instructions.

@nbeams I actually only wanted to test it on my system to be sure it is properly fixed, but I actually wanted to leave the old fix in in case someone has still the old version of CUDA 10.1.
Thanks for finding it!


luci-mod-status: improve channel_analysis and firewall page

Many user complained problem with using pool with wifi scan.
This comes from the limitation that some wifi driver have problems with scanning
nearby wifi and keeping traffic.
Fix this by doing the wifi scan only one time on page load and provide a button
to refresh the channels manually.
The original implementation is preserved as the user can simply reenable the poll
referesh from the ui.
While at it also sort the table by channel instead of by signal quality to better
track the most used channels in the table.
This also try to improve the firewall page that is currently bugged.
2 new css class are introduced called cbi-title-section and cbi-title-field.
With these new class it's possible to put buttons on the same line of the title
view and we can use flex instead of using right class + hardcoded margin.
Signed-off-by: Ansuel Smith<EMAIL_ADDRESS>@jow- only concern I have it the use of style in the h2 div... Any idea how to
improve? An old pr [1] still open added the ability to add buttons at the end of
the h2... Would be handy here and also in the firewall status page that is
currently broken...
Current implementation by this pr

Broken implementation by using strange div and right class

[1] https://github.com/openwrt/luci/pull/5224

The visual glitch above looks like a problem of the material theme. It should look okay on bootstrap.

@jow- yes it does but from the code it looks like an hack than a correct implementation with flex and putting them in a div.
Also IMHO it would be better to put them on the line of the h2 instead of the tabmenu div. (they are relevant to the global view not specific to the current tab)

(ignore the extra space... material theme have the entire firewall page broken but honestly part of the problem is also the code)

Please test bootstrap as this is the default theme, I don't really care how it looks in material

What do you think? IMHO it looks better

I think the simplest solution is moving the right class div after the <ul>, then removing the extra margin style.
That'll push the content a bit away from the tabs but I think this is okay.

What i don't like is the extra white space on the left, i mean the button on the right of the h2 seems to be the perfect place for this kind of thing... but I understand this kind of change would require a tweak to the themes to be correctly implemented...

@jow- ok I tested the firewall page with all the different themes (material, bootstrap, openwrt and openwrt2020)
On the mobile page, bootstrap and openwrt have the button behind the tabs and are not selectable. Openwrt2020 works correct and material works correctly.
I fixed all of these problems and now the buttons are more or less the same with all the 4 theme. In a normal screen, they are all correctly placed on the right on the same line of the h2.
What do you think?

Any news with this?

@jow- any chance for this?

I merged the channel analysis commit. The firewall change is too invasive for my taste.


only parse time once

This code will potentially parse time twice.  We should parse it once,
when it is input, and parse it with respect to utc.  This cleans the
code a little and makes it compatible with Rails 4 by removing some
to_time warnings

parsing time after time?

The only reason I can see a reason for this code is to pass across a queue.
I can't see that happening though.
:+1: LGTM

parsing time after time?

lol.  I was thinking the same thing!


Include HTML (Content-Type: text/html) in email destination.

 Issue by Sampathreddygopireddy118
Thursday Dec 10, 2020 at 14:42 GMT
Originally opened as https://github.com/opendistro-for-elasticsearch/alerting/issues/324

Is your feature request related to a problem? Please describe.
currently email destination only supports (plain/text).
Describe the solution you'd like
It is really good to have the (Content-Type: text/html)  in email destination.
Describe alternatives you've considered
Currently I using custom webhook destination for email notification.

 Comment by Sampathreddygopireddy118
Tuesday Mar 09, 2021 at 15:45 GMT

I was able to do the HTML format for email using custom webhook (destination as jenkins (generic-webhook-trigger)). Below are the steps if someone wants to do it.
Steps:
Message info in opendistro alerting write your message including painless script and include html tags.
create a free-style jenkins job -> enable the generic webhook trigger-> provide the variable to receive text format from kibana (custom webhook).
enable/create execute shell in Build, and write the incoming text (variable assigned in generic webhook) to a file with html extention (echo $variable > email.html).
enable editable email notification in your post build. Follow the steps from the document below.
https://dzone.com/articles/jenkins-convert-excel-data-to-tabular-format-and-s
Hope this helps. Let me know if you need any other details. My email<EMAIL_ADDRESS>

 Comment by anjanaasok
Monday Mar 08, 2021 at 09:36 GMT

@Sampathreddygopireddy118 can you share the custom webhook that you created, How did you pass the context over to webhoook. DO we pass the ctx object in the URL of webhook

Closing as solved.


Machine-built files are in version control

Describe the bug
Any machine-built files should be ignored by version control to avoid confusion and merge conflicts. Currently src/assets/css/main.css and src/data/contributors.json are there and can be ignored without too much hassle.
To Reproduce
Steps to reproduce the behavior:

Check out current version of develop
run npm run build
See changed files in git status

Expected behavior
All machine-build files should be ignored when possible. Running npm run build (or develop) shouldn't result in modified files in version control unless a user has changed the source files.
My suggestion:

delete main.css and add it to gitignore
delete contributors.json and add it to gitignore

I may be missing something here but I think this should be pretty straightforward.

Can I tackle this issue?


chore: release v4.5.5

PR-Codex overview
This PR updates the Biconomy SDK to version 4.4.6, introducing changes related to session storage, token payment, and smart accounts.
Detailed summary

Updated SDK version to 4.4.6
Moved SessionStorageClient to a separate package
Added nonce options for transactions
Enhanced session support and token payment
Improved helper functions for translations and session leaf retrieval

The following files were skipped due to too many changes: tests/paymaster/write.test.ts, tests/playground/write.test.ts, src/modules/sessions/sessionSmartAccountClient.ts, examples/CREATE_AND_USE_A_SESSION.md, src/modules/sessions/batch.ts, src/modules/sessions/abi.ts, src/modules/utils/Helper.ts, tests/modules/write.test.ts, tests/account/write.test.ts

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

Just one small thing, PR title says 4.5.5 release but it should be 4.4.6


Clean up error handling

couchbackup/couchrestore version(s) that are affected by this issue.

1.4.0

Node.js version.

N/A

A sample of the code or command line statement that demonstrates the issue.

N/A

Refactor the error handling so that the API and internal functions only emit error events and do not write to stderr. This will avoid suppressing errors from being handled by API callers and also give API users complete control over the output.
The command line tooling (effectively an API user) should write to stderr when receiving the events. <-- I think this part was handled by #52 (but whoever picks this up should check)
We should also check for whether something calls the callback(err) or emits an error event and document the expected behaviour.

Closely related to #103. I'll pick this one up too.

After some discussion,

an event emitter error will represent a non-fatal error
(will be printed to stderr in the CLI)
a callback error will represent a fatal error
(will terminate the CLI with a suitable exit code)


Update README.md

Why this change?

This depends on how you installed postgres, AFAIK it is not recommended to run psql with sudo


Copy for an 'About Glow' Section

What is Glow?
Glow is a blockchain native single methodology pay-it-forward carbon credit
standard focused on photovoltaic solar that uses emissionality to measure
marginal carbon impact and uses forward productivity to establish
additionality.
What does that mean?
Glow is a standard for certifying carbon credits. A carbon credit is a
metaphorical object that represents one ton of carbon dioxide that was
eliminated from the atmosphere. There are many carbon credit standards today,
and some reputable examples include the American Carbon Registry and Gold
Standard.
Glow appraises projects that reduce carbon dioxide emissions, and creates one
Glow Carbon Credit for each ton of carbon dioxide emissions that was prevented
by the project. The Glow Protocol takes responsibility for the accurate
appraisal of emissions reductions and uses its own reputation to vouch for the
quality of the carbon credits that are created by Glow projects.
Most carbon credit standards operate by giving carbon credits to projects that
reduce emissions or sequester carbon. Under this model, carbon credit buyers
are retroactively paying for activity that already happened, giving buyers
little guarantee that their money is actually going to drive future change.
Glow uses a pay-it-forward financing structure that ensures all money spent on
carbon credits gets used to drive future carbon credit production. Carbon
credit producers receive rewards in tokens that have value based on carbon
credits that were sold previously.
Glow is a blockchain-native protocol, which means all of the governance and
carbon credit issuance happens on the Ethereum blockchain. Glow does offer ways
to transfer carbon credits off of the blockchain and onto more traditional
carbon credit marketplaces, which means that users can acquire Glow carbon
credits without needing to use a blockchain, however all Glow carbon credits
start their life as ERC20 tokens.
Glow is a single methodology carbon credit standard, which means that Glow only
certifies exactly one type of carbon credit.  A
photovoltaic solar panel is the blueish-purple-panel-with-white-lines style of
solar panel - it's what most people think of when they think "solar".
Glow measures carbon impact using emissionality, a strategy for counting carbon
emissions reductions by observing all of the power plants that are operating on
a power grid, understanding which power plants are shutting down in response to
solar power becoming available, and then measuring the total emissions that
would have happened if those power plants had not shut down.
Measuring emissionality is only possible on power grids that have considerable
public data available about which power plants are operating at what
capacities, and what emissions are associated with each power plant. Glow
therefore can only certify solar farms operating on compliant power grids.
Thankfully, modern regulations in most of the US, most of Europe, most of Asia,
most of Australia, and many more places aside from those require this data to
be made readily available. Glow can therefore operate in many emissions
intensive parts of the world.
One of Glow's major innovations is forward productivity, which requires solar
farms to contribute 100% of their gross electricity revenue towards the
incentive pool that funds the installation of more solar farms.
Forward productivity creates a massive multiple on the money that is
contributed by carbon credit buyers. $1 spent on carbon credits turns into $1
that gets spent on solar panels. Those solar panels may then produce $0.95
worth of electricity, which can then be used to buy $0.95 of new solar panels.
And then those solar panels may produce $0.91 of electricity, and so on. In
total, forward productivity allows the Glow Protocol to turn $1 of carbon
credit purchases into $10-$20 of future solar panels, maximizing the overall
additionality of the Glow protocol.
Additionality is a complicated subject, but the core concern behind
additionality is "how much of a difference did my dollar actually make?". For
example, if you pay someone not to cut down trees in a forest, so they respond
by cutting down trees in a different forest, your dollar is actually not
reducing the total amount of deforestation and therefore has very low
additionality.
Many varieties of solar based carbon credits struggle with additionality. The
evidence is in the math that companies use to drive their solar decisions. In
most cases today, a solar company will decide to install a solar farm first,
and then check how many carbon credits they get later. Because the carbon
credits are not a core part of the decision, the carbon credits have low
additionality.
With Glow, solar farms must agree to give up all sources of revenue to
participate. That revenue is then used to fund the creation of even more solar
farms. This ensures that Glow's economics are a fundamental part of the
decision process when setting up a new solar farm for Glow, and that every
dollar spent on carbon credits is driving as much real change as possible -
change that would be happening without the dollar.

What is Glow?
The Glow Protocol is a blockchain native single methodology pay-it-forward
carbon credit standard focused on photovoltaic solar that uses emissionality to
measure marginal carbon impact and uses forward productivity to establish
additionality.
What does that mean?
The Glow Protocol is a standard for certifying carbon credits. A carbon credit
is a metaphorical object that represents one ton of carbon dioxide that would
otherwise be in the atmosphere. There are many carbon credit standards today,
and some reputable examples include the American Carbon Registry and Gold
Standard.
The Glow Protocol appraises projects that reduce carbon dioxide emissions, and
creates one Glow Carbon Credit for each ton of carbon dioxide that was
successfully prevented from being released into the atmosphere. The Glow
Protocol takes responsibility for the accurate appraisal of emissions
reductions and uses its own reputation to vouch for the quality of the carbon
credits that are created by Glow projects.
Most carbon credit standards operate by giving carbon credits to projects that
reduce emissions or sequester carbon. Under this model, carbon credit buyers
are retroactively paying for activity that already happened, giving buyers
little guarantee that their money will result in additional future change.
The Glow Protocol uses a pay-it-forward financing structure that ensures all
money spent on carbon credits gets used to drive future carbon credit
production. Carbon credits that get sold today increase the value of the
rewards pool for producers that create carbon credits tomorrow.
Glow is a blockchain-native protocol, which means all of the governance and
carbon credit issuance happens on the Ethereum blockchain. Blockchain
technology is a good match for the carbon credit industry, as it can give
strong guarantees about who owns the carbon credits, how many carbon credits
are in existance, and what the current state of each carbon credit is.
Blockchain based carbon credit platforms have previously struggled, because
most carbon credits are created using legacy technology that does not mesh well
with Blockchain. As a fully blockchain native carbon credit, Glow is a powerful
ally to other blockchain protocols such as Flowcarbon and Toucan.
For carbon credit buyers that do not want to interact with the blockchain, Glow
features mechanisms for moving carbon credits off-chain and into the legacy
carbon credit system. This reduces the security and guarantees of the off-chain
credits to that of the legacy carbon credit system, and increases convenience
for carbon credit buyers that are not yet ready to make the transition to
blockchain.
The Glow Protocol is a single methodology carbon credit standard, which means
that Glow only certifies exactly one type of carbon credit. Specifically, the
Glow Protocol certifies carbon credits when newly constructed photovoltaic
solar panels displace unclean energy from modern power grids. Dirty energy on
modern power grids is responsible for more than 30% of global carbon dioxide
emissions. A photovoltaic solar panel is the thing that most people picture
when they think of solar power: it's a blueish-purle panel with a grid of while
lines.
The Glow protocol measures carbon dioxide emissions reduction using a strategy
called emissionality. Modern grids publish a large amount of data about the
composition of the grid, including auction data that determines which power
plants are operational at which times of the day. By observing the auction, it
is possible to measure which power plants are being pushed out by the presence
of solar farms. Modern grids also have published data on the carbon dioxide
emissions of each power plant, making it possible to measure the exact carbon
impact of a solar farm.
Emissionality can only be measured on grids that have a sufficient amount of
public data about the electricity auctions and about the carbon dioxide
emissions of each power plant. For this reason, Glow is only able to certify
carbon credits from solar farms that are placed on modern electrical grids.
Thankfully, this covers almost the entire United States, most of Europe, much
of Asia, and more regions are supported every year.
The Glow protocol features a novel requirement called forward productivity.
Under forward productivity, solar farms must contribute 100% of their gross
electricity revenue towards the incentive pool that funds the installation of
more solar farms.
By enforcing this requirement, the Glow protocol is in a sense buying the solar
farm with carbon credit incentives. Because the solar farm produces valuable
resources, the Glow protocol takes ownership of these resources and uses them
to incentivize the construction of even more solar farms.
In a practical sense, forward productivity means that every dollar spent on
carbon credits drives significantly more impact than it would without forward
productivity. It allows each dollar spent on Glow Carbon Credits to create as
much as $10 of solar panels that would not otherwise exist, making Glow one of
the most cost effective carbon credit programs on the planet.
Why only solar? What about wind?
There are many sources of renewable energy, and all of them contribute to a
cleaner climate. On a philosophical level, the Glow community is aligned with
all renewable energy sources such as wind, geothermal, hydro, and others. The
Glow community is also philosophically aligned with other carbon related
efforts such as sealing oil wells and direct-air-capture.
However, one of the major challenges facing the carbon credit industry today is
that there are a very large number of methodologies for reducing carbon
emissions: more than can be easily appraised by experts. Historically, this has
created a large amount of buyer confusion, and is more recently creating large
beauracratic overheads as incumbent carbon credit standards attempt to ensure
that every type of project meets appropriate quality standards.
Rather than try to create a beauracratic standard that generalizes well across
many carbon methodologies, Glow is choosing to focus on exactly one methodology
to improve buyer confidence, to improve quality, and to reduce overall
beauracratic overhead.
Out of all the options for carbon methodologies, solar seemed like the best
pick due to a number of features. The first is that solar can be scaled until
it is single-handedly offsetting more than 30% of today's global carbon
emissions. The second is that solar has been getting cheaper at a very
encouraging rate, and is expected to be highly cost effective in the near
future. Finally, solar works well at low scales as well as at large scales,
meaning nearly any homeowner can participate in the Glow protocol, and as a
side benefit the homeowner can reduce their dependency on the grid.

What is Glow?
The Glow Protocol is a blockchain native single methodology pay-it-forward
carbon credit standard focused on photovoltaic solar that uses emissionality to
measure marginal carbon impact and uses forward productivity to establish
additionality.
What does that mean?
The Glow Protocol is a standard for certifying carbon credits. A carbon credit
is a metaphorical object that represents one ton of carbon dioxide that would
otherwise be in the atmosphere. There are many carbon credit standards today,
and some reputable examples include the American Carbon Registry and Gold
Standard.
The Glow Protocol appraises projects that reduce carbon dioxide emissions, and
creates one Glow Carbon Credit for each ton of carbon dioxide that was
successfully prevented from being released into the atmosphere. The Glow
Protocol takes responsibility for the accurate appraisal of emissions
reductions and uses its own reputation to vouch for the quality of the carbon
credits that are created by Glow projects.
Most carbon credit standards operate by giving carbon credits to projects that
reduce emissions or sequester carbon. Under this model, carbon credit buyers
are retroactively paying for activity that already happened, giving buyers
little guarantee that their money will result in additional future change.
The Glow Protocol uses a pay-it-forward financing structure that ensures all
money spent on carbon credits gets used to drive future carbon credit
production. Carbon credits that get sold today increase the value of the
rewards pool for producers that create carbon credits tomorrow.
Glow is a blockchain-native protocol, which means all of the governance and
carbon credit issuance happens on the Ethereum blockchain. Blockchain
technology is a good match for the carbon credit industry, as it can give
strong guarantees about who owns the carbon credits, how many carbon credits
are in existance, and what the current state of each carbon credit is.
Blockchain based carbon credit platforms have previously struggled, because
most carbon credits are created using legacy technology that does not mesh well
with Blockchain. As a fully blockchain native carbon credit, Glow is a powerful
ally to other blockchain protocols such as Flowcarbon and Toucan.
For carbon credit buyers that do not want to interact with the blockchain, Glow
features mechanisms for moving carbon credits off-chain and into the legacy
carbon credit system. This reduces the security and guarantees of the off-chain
credits to that of the legacy carbon credit system, and increases convenience
for carbon credit buyers that are not yet ready to make the transition to
blockchain.
The Glow Protocol is a single methodology carbon credit standard, which means
that Glow only certifies exactly one type of carbon credit. Specifically, the
Glow Protocol certifies carbon credits when newly constructed photovoltaic
solar panels displace unclean energy from modern power grids. Dirty energy on
modern power grids is responsible for more than 30% of global carbon dioxide
emissions. A photovoltaic solar panel is the thing that most people picture
when they think of solar power: it's a blueish-purle panel with a grid of while
lines.
The Glow protocol measures carbon dioxide emissions reduction using a strategy
called emissionality. Modern grids publish a large amount of data about the
composition of the grid, including auction data that determines which power
plants are operational at which times of the day. By observing the auction, it
is possible to measure which power plants are being pushed out by the presence
of solar farms. Modern grids also have published data on the carbon dioxide
emissions of each power plant, making it possible to measure the exact carbon
impact of a solar farm.
Emissionality can only be measured on grids that have a sufficient amount of
public data about the electricity auctions and about the carbon dioxide
emissions of each power plant. For this reason, Glow is only able to certify
carbon credits from solar farms that are placed on modern electrical grids.
Thankfully, this covers almost the entire United States, most of Europe, much
of Asia, and more regions are supported every year.
The Glow protocol features a novel requirement called forward productivity.
Under forward productivity, solar farms must contribute 100% of their gross
electricity revenue towards the incentive pool that funds the installation of
more solar farms.
By enforcing this requirement, the Glow protocol is in a sense buying the solar
farm with carbon credit incentives. Because the solar farm produces valuable
resources, the Glow protocol takes ownership of these resources and uses them
to incentivize the construction of even more solar farms.
In a practical sense, forward productivity means that every dollar spent on
carbon credits drives significantly more impact than it would without forward
productivity. It allows each dollar spent on Glow Carbon Credits to create as
much as $10 of solar panels that would not otherwise exist, making Glow one of
the most cost effective carbon credit programs on the planet.
In summary, the Glow Protocol is a blockchain native single methodology pay-it-forward
carbon credit standard focused on photovoltaic solar that uses emissionality to
measure marginal carbon impact and uses forward productivity to establish
additionality.
Why only solar? What about wind?
There are many sources of renewable energy, and all of them contribute to a
cleaner climate. On a philosophical level, the Glow community is aligned with
all renewable energy sources such as wind, geothermal, hydro, and others. The
Glow community is also philosophically aligned with other carbon related
efforts such as sealing oil wells and direct-air-capture.
However, one of the major challenges facing the carbon credit industry today is
that there are a very large number of methodologies for reducing carbon
emissions: more than can be easily appraised by experts. Historically, this has
created a large amount of buyer confusion, and is more recently creating large
beauracratic overheads as incumbent carbon credit standards attempt to ensure
that every type of project meets appropriate quality standards.
Rather than try to create a beauracratic standard that generalizes well across
many carbon methodologies, Glow is choosing to focus on exactly one methodology
to improve buyer confidence, to improve quality, and to reduce overall
beauracratic overhead.
Out of all the options for carbon methodologies, solar seemed like the best
pick due to a number of features. The first is that solar can be scaled until
it is single-handedly offsetting more than 30% of today's global carbon
emissions. The second is that solar has been getting cheaper at a very
encouraging rate, and is expected to be highly cost effective in the near
future. Finally, solar works well at low scales as well as at large scales,
meaning nearly any homeowner can participate in the Glow protocol, and as a
side benefit the homeowner can reduce their dependency on the grid.

What is Glow?
The Glow Protocol is a blockchain native single methodology pay-it-forward
carbon credit standard focused on solar that uses emissionality to measure
marginal carbon impact and uses forward productivity and competition to
establish additionality.
What does that mean?
The Glow Protocol is a standard for certifying carbon credits. A carbon credit
is a metaphorical object that represents one ton of carbon dioxide that would
otherwise be in the atmosphere. There are many carbon credit standards today,
and some reputable examples include the American Carbon Registry and CORSIA.
The Glow Protocol appraises projects that reduce carbon dioxide emissions, and
issues one Glow Carbon Credit for each metric ton of carbon dioxide that is
successfully prevented from being released into the atmosphere. The Glow
Protocol takes responsibility for the accurate appraisal of emissions
reductions and uses its own reputation to vouch for the quality of the carbon
credits that are created by Glow projects.
Glow is a blockchain-native protocol, which means all of the governance and
carbon credit issuance happens on the Ethereum blockchain. Blockchain
technology is a good match for the carbon credit industry, as it can give
strong guarantees about who owns the carbon credits, how many carbon credits
are in existance, and the current state of each carbon credit.
Many previously existing blockchain based carbon credit platforms struggled
because it is difficult to migrate legacy carbon credits to the blockchain, and
as a result many platforms either had few carbon credits or carbon credits of
very low quality. Glow supports the rest of the carbon credit blockchain
ecosystem by providing a source of scalable, high quality carbon credits that
permissionlessly interact with the rest of the crypto ecosystem.
Furthermore, it is much easier to migrate a blockchain based carbon credit into
the legacy carbon credit ecosystem than it is to go the other way. Carbon
credit buyers that are not yet ready to make the leap into Blockchain have the
ability to buy and retire Glow carbon credits using traditional payment flows.
Most carbon credit standards operate by giving carbon credits to projects that
reduce emissions or sequester carbon. Carbon credit buyers then purchase the
credits, effectively paying retroactively for change that has already occurred
and receiving little to no assurance that their money will be used to
incentivize future change.
The Glow Protocol uses a pay-it-forward financing structure that ensures all
money spent on carbon credits gets used to drive future carbon credit
production. As carbon credits are sold, the money is used to fuel the incentive
pool that pays out to future carbon projects.
This means that Glow is structured differently than traditional carbon credit
standards. Projects on Glow directly receive cash and tokens for producing
carbon credits instead of receiving carbon credits. The carbon credits, once
produced, are sold by the Glow protocol to fund future projects.
The Glow Protocol is a single methodology carbon credit standard, which means
that Glow only certifies exactly one type of carbon credit. Specifically, the
Glow Protocol certifies carbon credits when newly constructed solar farms
displace dirty energy from modern power grids. Dirty energy makes up more than
30% of all global emissions, giving Glow the opportunity to scale to producing
tens of billions of carbon credits per year even though Glow only uses a single
methodology to produce carbon credits.
The choice to use a single methodolgy is intentional. The carbon credit
ecosystem today features over one hundred different methodolgies, each with
their own controversies and criticisms. Most buyers of carbon credits have
little hope of understanding what exactly they are purchasing, and education is
difficult because every carbon credit has its own story, and its own drawbacks.
By focusing on a single methodology, the Glow protocol is better able to scale
up, better able to address shortcomings and criticisms, and is better able to
give carbon credit buyers confidence in the credits they are purchasing.
The Glow protocol measures carbon dioxide emissions reductions using a strategy
called emissionality. Emissionality uses the rich, regulated data feeds of
modern power grids to observe which power plants reduce their output in
response to new solar farms joining the power grid. This allows Glow to measure
the precise emissions impact of a single solar farm, and also means that each
solar farm will produce different amounts of carbon credits based on where they
are in the world.
Emissionality can only be measured on grids that publish high quality data
about which power plants are active and how many emissions are associated with
each power plant. Thankfully, modern regulations require this data to be
available, and thus Glow is able to certify solar in the entire continential
US, most of Europe, much of Asia, and significant portions of the rest of the
world, with more regions being supported every year. Glow sources most of its
data through a non-profit provider called WattTime.
The Glow protocol features a novel requirement called forward productivity,
which requires solar farms to contribute 100% of their gross electricity
revenue towards the incentive pool that rewards solar farms for producing
carbon credits.
Though forward productivity sounds unusual at first, it solves a very important
incentive alignment problem that exists in much of the carbon credit space.
Carbon credit buyers are spending money on carbon credits because they want to
change the world. This means that their money needs to inspire changes that
would not happen otherwise.
If solar farms are allowed to keep their electricity revenue, it becomes
difficult to measure whether the solar farm even required carbon incentives in
the first place. Many solar farms are highly profitable even without carbon
based incentives, and therefore allocating carbon credit money to them is a
waste.
Even if the solar farm can demonstrate that they would not be profitable
without carbon incentives, it is still difficult to validate that the solar
farm is receiving just enough carbon incentives.
By requiring solar farms to give up 100% of their electricity revenue to other
solar farms, Glow creates a competitive rewards system which favors solar farms
that are as cost-efficient as possible in producing carbon credits. Solar farms
receive cash rewards from other solar farms proportional to the number of
carbon credits that they produce, and solar farms receive token rewards from
the Glow protocol proportional to the amount of cash they contribute to other
solar farms.
The net effect of this incentive structure strongly favors solar farms that are
just a hair's breadth away from profitability. Solar farms that are profitable
without carbon incentives will prefer not to participate in Glow, because they
will want to keep all of their valuable electricity revenue. And solar farms
that produce very little revenue will not receive enough Glow tokens to remain
competitive.
In summary, the Glow Protocol is a blockchain native single methodology
pay-it-forward carbon credit standard focused on solar that uses emissionality
to measure marginal carbon impact and uses forward productivity and competition
to establish additionality.

What is Glow?
The Glow Protocol is a blockchain native single methodology pay-it-forward
carbon credit standard focused on solar that uses emissionality to measure
marginal carbon impact and uses forward productivity and competition to
establish additionality.
What does that mean?
The Glow Protocol is a standard for certifying carbon credits. A carbon credit
is a metaphorical object that represents one ton of carbon dioxide that would
otherwise be in the atmosphere. There are many carbon credit standards today,
and some reputable examples include the American Carbon Registry and CORSIA.
The Glow Protocol appraises projects that reduce carbon dioxide emissions, and
issues one Glow Carbon Credit for each metric ton of carbon dioxide that is
successfully prevented from being released into the atmosphere. The Glow
Protocol takes responsibility for the accurate appraisal of emissions
reductions and uses its own reputation to vouch for the quality of the carbon
credits that are created by Glow projects.
Glow is a blockchain-native protocol, which means all of the governance and
carbon credit issuance happens on the Ethereum blockchain. Blockchain
technology is a good match for the carbon credit industry, as it can give
strong guarantees about who owns the carbon credits, how many carbon credits
are in existence, and the current state of each carbon credit.
Many previously existing blockchain based carbon credit platforms struggled
because it is difficult to migrate legacy carbon credits to the blockchain, and
as a result many platforms either had few carbon credits or carbon credits of
very low quality. Glow supports the rest of the carbon credit blockchain
ecosystem by providing a source of scalable, high quality carbon credits that
permissionlessly interact with the rest of the crypto ecosystem.
Furthermore, it is much easier to migrate a blockchain based carbon credit into
the legacy carbon credit ecosystem than it is to go the other way. Carbon
credit buyers that are not yet ready to make the leap into Blockchain have the
ability to buy and retire Glow carbon credits using traditional payment flows.
Most carbon credit standards operate by giving carbon credits to projects that
reduce emissions or sequester carbon. Carbon credit buyers then purchase the
credits, effectively paying retroactively for change that has already occurred
and receiving little to no assurance that their money will be used to
incentivize future change.
The Glow Protocol uses a pay-it-forward financing structure that ensures all
money spent on carbon credits gets used to drive future carbon credit
production. As carbon credits are sold, the money is used to fuel the incentive
pool that pays out to future carbon projects.
This means that Glow is structured differently than traditional carbon credit
standards. Projects on Glow directly receive cash and tokens for producing
carbon credits instead of receiving carbon credits. The carbon credits, once
produced, are sold by the Glow protocol to fund future projects.
The Glow Protocol is a single methodology carbon credit standard, which means
that Glow only certifies exactly one type of carbon credit. Specifically, the
Glow Protocol certifies carbon credits when newly constructed solar farms
displace dirty energy from modern power grids. Dirty energy makes up more than
30% of all global emissions, giving Glow the opportunity to scale to producing
tens of billions of carbon credits per year even though Glow only uses a single
methodology to produce carbon credits.
The choice to use a single methodology is intentional. The carbon credit
ecosystem today features over one hundred different methodologies, each with
their own controversies and criticisms. Most buyers of carbon credits have
little hope of understanding what exactly they are purchasing, and education is
difficult because every carbon credit has its own story, and its own drawbacks.
By focusing on a single methodology, the Glow protocol is better able to scale
up, better able to address shortcomings and criticisms, and is better able to
give carbon credit buyers confidence in the credits they are purchasing.
The Glow protocol measures carbon dioxide emissions reductions using a strategy
called emissionality. Emissionality uses the rich, regulated data feeds of
modern power grids to observe which power plants reduce their output in
response to new solar farms joining the power grid. This allows Glow to measure
the precise emissions impact of a single solar farm, and also means that each
solar farm will produce different amounts of carbon credits based on where they
are in the world.
Emissionality can only be measured on grids that publish high quality data
about which power plants are active and how many emissions are associated with
each power plant. Thankfully, modern regulations require this data to be
available, and thus Glow is able to certify solar in the entire continental US,
most of Europe, much of Asia, and significant portions of the rest of the
world, with more regions being supported every year. Glow sources most of its
data through a non-profit provider called WattTime.
The Glow protocol features a novel requirement called forward productivity,
which requires solar farms to contribute 100% of their gross electricity
revenue towards the incentive pool that rewards solar farms for producing
carbon credits.
Though forward productivity sounds unusual at first, it solves an important
incentive alignment problem that exists in much of the carbon credit space.
Carbon credit buyers are spending money because they want to change the world.
This means that their money needs to enable projects that would not exist
otherwise.
If solar farms are allowed to keep their electricity revenue, it becomes
difficult to measure whether the solar farm required carbon incentives at all.
Many solar farms are highly profitable even without carbon based incentives,
and allocating incentives to those farms is a waste.
Even if a solar farm can demonstrate that it would not be profitable without
carbon incentives, it can be difficult to determine the exact amount of
incentives that are required to make the project viable.
By requiring solar farms to give up 100% of their electricity revenue to other
solar farms, Glow creates a competitive rewards system which favors solar farms
that are as cost-efficient as possible in producing carbon credits. Solar farms
receive cash rewards from other solar farms proportional to the number of
carbon credits that they produce, and solar farms receive Glow token rewards
proportional to the amount of cash they contribute to other solar farms.
This incentive structure most strongly favors solar farms that are just a
hair's breadth away from profitability. Solar farms that are profitable without
incentives will not participate in Glow, because they will prefer to keep their
valuable electricity revenue. And solar farms that produce very little revenue
overall will be unable to participate, because they won't receive enough Glow
tokens to be competitive with higher revenue solar farms.
In summary, the Glow Protocol is a blockchain native single methodology
pay-it-forward carbon credit standard focused on solar that uses emissionality
to measure marginal carbon impact and uses forward productivity and competition
to establish additionality.


Copy OP execution outcome tests

Describe the feature
Copy all tests that have an optimism feature gate inside, into optimism evm crate. For the copies, remove the optimism feature gate. For the originals, remove the optimism feature gated code completely.
https://github.com/paradigmxyz/reth/blob/6a1ec0d1a20436a79aee612c68749abc3411ec6b/crates/evm/execution-types/src/execution_outcome.rs#L365-L891
Additional context
No response

hi @emhane, assign me please

hi @emhane, assign me


Remove dependency on Resque

There are several different Resque forks, with different names (for example mongo-resque and resque-mongo).
Luckily, resque-pool is compatible with almost all of them.
Can the dependency on Resque be removed (or made optional somehow)?
That way, all Resque-compatible forks can be used.
(BTW: Thanks for the great work on resque-pool! It's awesome!)

I can create a pull request if needed.


Streaming plugin

@zazabe please review

doc: {int} seems not a valid type, {number} should be used instead
I would rather put the createAnswer (startMediaStreaming) inside the watch request, because connect could execute a switch, which has no jsep in response i suppose.
Maybe startMediaStreaming could even be "private".

doc: {int} seems not a valid type, {number} should be used instead

I wanted to emphasise the fact that this id should be natural number.

I would rather put the createAnswer (startMediaStreaming) inside the watch request, because connect could execute a switch, which has no jsep in response i suppose.

ok

Maybe startMediaStreaming could even be "private".

Why? It is a shortcut to the main logic of this plugin.

@zazabe please look


Communication troubles after several seconds

I'm making "split simulations" with OM: one OM instance doing part of the simulation, the other the second part.
This is part of a project to realise Hardware-in-the-loop simulation taking advantage of OM. The two instances can work on the same PC, or on different PCs belonging to the same LAN.
The enclosed SplitSim.mo works without changes in two OM instances on the same PC
These split simulations are somehow frontier usages of OM, and if they work would enlarge OM capabilities significantly.
Everything works, except that on the instance running UDP.Slave, the simulation stops at t=135.2 with the following message:
The code has encountered trouble from which it cannot recover.
can't continue. time = 135.200000
### STATISTICS ###
MDDUDPSocket.h: Receiving not possible, socket not valid.
DASKR-- TOUT (=R1) TOO CLOSE TO T (=R2) TO START INTEGRATION
      In above,  R1 =   1.3520000000000E+02   R2 =   1.3520000000000E+02
Simulation process failed. Exited with code 0xffffffffffffffde.

Steps to Reproduce
The issue can be reproduced in a simplified way just running UDP.Slave::  the simulation stops at 135.2s with the error message above.
NOTES:

if one wants to see split simulation at work, they can run Slave while Master is already running (or vice versa).
Strangely, if I put Slave outside UDP folder, its simulation does not start.

FIle (change extension into "mo" before using):
SplitSim.txt
Tested with OpenModelica 1.18.0

On first sight this seems rather an OM issue.
I've just tested with Dymola 2022 on Windows and it worked as expected.
However, for the Master model in Dymola I get following warnings:
Integration started at T = 0 using integration method DASSL
(DAE multi-step solver (dassl/dasslrt of Petzold modified by Dassault Systemes))
MDDRealtimeSynchronize.h: WARNING simTime=0.015916 < lastSimTime=0.025500 (possibly due to solver step-size adaption)
MDDRealtimeSynchronize.h: WARNING simTime=0.015916 < lastSimTime=0.025500 (possibly due to solver step-size adaption)
...

However, those go away if one uses the sampled option in the realtimeSynchronization block (which is already used in the Slave model).
For split simulation another option is to use the TCP/IP blocks. This allows the model with the TCP/IP server to control the step size progress of the model with a client. I have not experimented very much with this, but it seems to work rather nicely. In the tcpipserverconfig use useNonBlockingMode=false, in the tcpipSend block use blockUntilConnected=false and in the tcpipReceive block use blockUntilConnected=true and showAdvancedOutputs=true. When the server can be connected like this:

This gives you  control on the execution sequence of the input/output readings. So maybe an interesting alternative for using UDP, though the mutual blocking might be more costly in terms of (real-time) performance.

This opens new opportunities... and new issues.
To simulate Modelica models I use Dymola and OpenModelica. I prefer OpenModelica, for several reasons, the most important of which is that I prefer OpenSource software, also for my classroom teaching.
I tried your recommendation in the last comment, even though I'm not familiar with TCP/IP at all (but I can learn). Unfortunately, immediately I came across a new issue. I discussed it in this ticket:
https://github.com/OpenModelica/OpenModelica/issues/8172

Yes, I know this is an longstanding issue with OM and it is very nice if it gets fixed as indicated in your linked issue.
In hindsight to my previous post, I think I should comment a bit more about the caveats of using the advocated TCP/IP option. The example above would actually run the two models in serial. So it's not suitable for getting a speed-up for real-time applications.
For a speed-up in real-time simulation we probably would like to use UDP or shared memory. In addition it would be nice to have some sort of "director" or "master" to control the simulation federates, particularly if one tries to use more than two simulations. Some GUI for controlling the federates would be nice, too.
However, for the moment being, simply using UDP or shared memory and rely on the real-time clock for synchronization is probably the best one can do. More dedicated support for distributed real-time simulations would be cool, but would need some time to spare for implementing it properly...


Not compatible with Pale Moon?

https://addons.mozilla.org/en-US/firefox/addon/h264ify/ says "Not available for Firefox 24.9" and same for 24.7.2.  Is it really not compatible or it just says it isn't?

Wrong repo - you should report this here: https://github.com/erkserkserks/h264ify-firefox/issues


Unable to resolve module AccessbilityInfo ReactNative with Expo

Platform

Android
Expo

Target Application
Android React Native with Expo
Version of SDK
react: 17.0.1
react-native: 0.64.3
expo: 44.0.0
Issue
I tried to create an example app like the following example https://github.com/BigThinkcode/AdaptiveCards/tree/master/source/community/reactnative#databinding. After building and starting the app using Expo and the Expo Sandbox I got the error message that a module cannot be resolved. I even followed the steps that were mentioned in the error.
Unable to resolve module AccessibilityInfo from D:\dev\someproject\node_modules\adaptivecards-reactnative\node_modules\react-native\Libraries\react-native\react-native-implementation.js: AccessibilityInfo could not be found within the project or in these directories:
  node_modules\adaptivecards-reactnative\node_modules
  node_modules

If you are sure the module exists, try these steps:
 1. Clear watchman watches: watchman watch-del-all
 2. Delete node_modules and run yarn install
 3. Reset Metro's cache: yarn start --reset-cache
 4. Remove the cache: rm -rf /tmp/metro-*
  19 | const ReactNative = {
  20 |   // Components
> 21 |   get AccessibilityInfo() {
     |       ^
  22 |     return require('AccessibilityInfo');
  23 |   },
  24 |   get ActivityIndicator() {

Please file this issue over in the BigThinkcode/AdaptiveCards repo. Thanks!


Triggered Modals (reveals) on Mobile load at Top of Page when scrolled down within the content

If you have a page, where the user can scroll down some, then interact with an element to reveal a modal, the modal always reveals at the top of the page, sometimes leaving the use unable to even scroll up to the modal since the reveal background prevents scrolling.
Any ideas?

Looks like this was fixed on the master branch https://github.com/zurb/foundation/commit/0dfb33664b3547fa359ad475b67f7deaf2f5ea71
It will be out in the next release next week.


Moving the codebase into typescript

It will  be nice to move the entire codebase from javascript to typescript we can start by moving from component to componeent

I don't see why is this relevant. Definitely not needed from my point of view. @akshatnema imho we should close this one unless you had different vision for the future


Inspect all binary operations regardless within or without if/else statements

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

13 of 19 (68.42%)  changed or added relevant lines in 5 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-2.7%) to 75.0%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/voku/PHPStan/Rules/IfConditionBooleanNotRule.php
0
1
0.0%

src/voku/PHPStan/Rules/IfConditionBooleanOrRule.php
0
5
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
-2.7%

Covered Lines:
90

Relevant Lines:
120

💛  - Coveralls


specify version for CI actions

This PR adds a specific version for some actions. This was triggered by some breaking changes introduced to the typos action.

Codecov Report

Merging #760 (99e59f3) into main (7423eb7) will increase coverage by 1.62%.
Report is 2 commits behind head on main.
The diff coverage is n/a.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #760      +/-   ##
==========================================
+ Coverage   63.15%   64.78%   +1.62%
==========================================
  Files          44        1      -43
  Lines        5607      389    -5218
  Branches       93       81      -12
==========================================
- Hits         3541      252    -3289
+ Misses       2066      137    -1929

Components
Coverage Δ

apel_plugin
64.78% <ø> (-10.03%)
:arrow_down:

auditor
∅ <ø> (∅)

slurm_collector
∅ <ø> (∅)

slurm_epilog_collector
∅ <ø> (∅)

htcondor_collector
∅ <ø> (∅)

priority_plugin
∅ <ø> (∅)


Change base site url to t3hmun.com

I've setup the CNAME with GitHub pages, now all the links generate HTTP 301 page moved responses, a waste of time and a bit silly.

This will be done as part of #26


Throw from .register() instead of DispatcherInstance.get()

In hindsight its useful to be able to get even if it isn't set.

fixed as of 72b4508e0cb63402695124c0fa20017fa3a0f9bb


Step8: Type mismatch with generated FlowStepArgument class

On Step 8, the code
val safeArgs = FlowStepFragmentArgs.fromBundle(arguments)
produces a type mismatch error: inferred type is Bundle? but Bundle was expected

Ran into this as well.

Thanks for reporting this and the feedback!
This had to do with breaking changes in one of the alpha releases that came out after the last publishing of the codelab code. I'm pushing an update to the codelab soon that will fix this -- sorry for the confusion. The proper way to get args in Kotlin is now:
val safeArgs: FlowStepFragmentArgs by navArgs()

@ceruleanotter Just as a heads up, your Udacity course still uses the old method which throws this type mismatch error. While I was fortunately able to find this post eventually, it was a bit of a pain having an officially supported tutorial giving you broken, outdated methods. I am only about 50% through the "App Navigation" tutorial which would mean if this one single thread didn't exist, it'd make the entire back half of the course unusable...
Would be great to see some edits/updates to the text portions of the course outlining any changes that may affect the outcomes of the tutorials.


Hugging Face demo

Summary
This PR adds a link to the demo of Hugging Face.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 93.56%. Comparing base (b8da718) to head (32116ca).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #282   +/-   ##
=======================================
  Coverage   93.56%   93.56%
=======================================
  Files          47       47
  Lines        5799     5799
=======================================
  Hits         5426     5426
  Misses        373      373

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


New version: GRUtils v0.3.0

Registering package: GRUtils
Repository: https://github.com/heliosdrm/GRUtils.jl
Created by: @heliosdrm
Version: v0.3.0
Commit: 1e652c135c09b7a3521af4ea6d9eb88a7a8c03f8
Reviewed by: @heliosdrm
Reference: https://github.com/heliosdrm/GRUtils.jl/commit/1e652c135c09b7a3521af4ea6d9eb88a7a8c03f8#commitcomment-35574652

Your new version pull request met all of the guidelines for automatic merging.
I will automatically merge this pull request during the next cron job.
If you want to prevent this pull request from being auto-merged, simply leave a comment.
(If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment.)

On a separate note, I see that you are registering a release with a version number of the form v0.X.Y.
Does your package have a stable public API? If so, then it's time for you to register version v1.0.0 of your package. (This is not a requirement. It's just a recommendation.)
If your package does not yet have a stable public API, then of course you are not yet ready to release version v1.0.0.

[noblock]


[Task]: Replace confluent-kafka-go Kafka emulator with emulator based on Apache Kafka in Playground

What needs to happen?
confluent-kafka-go built-in emulator is an experimental product with various compatibility issues, e.g. it is not working with current version of Java Kafka client used in Beam (2.4.1)
Replace usage of this emulator with one based on real Apache Kafka server in Playground
Issue Priority
Priority: 2 (default / most normal work should be filed as P2)
Issue Components

[ ] Component: Python SDK
[ ] Component: Java SDK
[ ] Component: Go SDK
[ ] Component: Typescript SDK
[ ] Component: IO connector
[ ] Component: Beam examples
[X] Component: Beam playground
[ ] Component: Beam katas
[ ] Component: Website
[ ] Component: Spark Runner
[ ] Component: Flink Runner
[ ] Component: Samza Runner
[ ] Component: Twister2 Runner
[ ] Component: Hazelcast Jet Runner
[ ] Component: Google Cloud Dataflow Runner

.take-issue