text:
OLH-1896-cache-our-frontends-static-assets-in-cloudfront

Proposed changes
OLH-1896 Cloud front static caching on /assets/* and /public/*
What changed
Addition of cache behaviours, enabling of caching static content in /assets/* and /public/*
Why did it change
Improve performance of front end content loading
Related links
N/A
Checklists
N/A
Environment variables or secrets

[x] No environment variables or secrets were added or changed

Testing

Validated deployment in dev successfully updates cloud front config

It might be worth waiting until this PR is merged https://github.com/govuk-one-login/di-account-management-backend/pull/260 which changes the flag we're using

@latifcabinetoffice It might be worth waiting until this PR is merged govuk-one-login/di-account-management-backend#260 which changes the flag from IsNotDevelopment to IsNotDevelopmentOrDemo

@aenciso Do you know if that change will be happening in the front end as well?

authors: aenciso latifcabinetoffice


text:
hostname is showing IP instead of real hostname

Hi,
Thanks for the cool theme. I found one issue with status bar: when I do ssh, the status bar shows IP address of remote server instead of its hostname. Anything I missed? Also I didn't find any definition of hostname function in your config file. Why? Thanks.

I figured out why. It is all about my .ssh/config. I put ip address over there, not hostname. Thanks.

Hello @spivoler,
You figured it out yourself. The reason is that I'm asking ssh the values for user and hostname and if you put ip addresses into your ~/.ssh/config file that's what you get back.

@spivoler I was wondering if it is possible to retrieve real hostname from the server.  My servers share the same ip address, and I differentiate them by port number.

source: gharchive/issue

authors: gpakosz matthew-z spivoler

license: MIT

license_type: permissive

license_source: github-api


text:
Custom ISO serializer for DateTime

Hi, we're currently trying to parse a date time in ISO format.
On the server the scalar name is DateTime
build.yaml
targets:
  $default:
    builders:
      ferry_generator|graphql_builder:
        enabled: true
        options:
          schema: package:my_app|lib/schema.graphql
          type_overrides:
            EmailAddress:
              name: String
            DateTime:
              name: DateTime
          custom_serializers:
            - import: "package:my_app|lib/utils/date_time_deserializer.dart"
              name: DateTimeSerializer

      ferry_generator|serializer_builder:
        enabled: true
        options:
          schema: driver_app|lib/schema.graphql
          type_overrides:
            DateTime:
              name: DateTime
              import: package:my_app|lib/utils/date_time_forward.dart

Unfortunately our date_time_serializer never gets used, could anyone lend some support?

here's an example of your use case:
https://ferrygraphql.com/docs/custom-scalars

@knaeckeKami That isn't working for us.
We don't want to override the type and still want to use DateTime from dart:core.
We just want to serialize it differently.
Am I missing something?

no worries, glad i could help

authors: Inlustra knaeckeKami

repo: gql-dart/ferry


text:
Potential memory issues caused by large cache size in CachingPatternSpecFactory

Context
After upgrading AGP to 3.6.0-beta-01 we got memory issues and failures in santaTrackerAndroidBuild performance test:
Expiring Daemon because JVM heap space is exhausted
Daemon will be stopped at the end of the build after running out of JVM memory
Expiring Daemon because JVM heap space is exhausted

It turns out to be Android OssLicensesPlugin incorrectly using fileTree searching large directories:

Each pattern searches large transforms cache directory (which has nearly 30k files in my computer) - these 30k file paths will be cached in CachingPatternSpecFactory $CachingSpec.resultCache. 30+ such patterns can result in OOM in Gradle daemon.
@oehme Can we reduce the cache size? It seems like previously the overall result cache size is 1200K, then you changed "per pattern cache size" to 100K: https://github.com/gradle/gradle/commit/e3f5bac15364722cb55a46f9d896e6f748f9c20e
. This seems still a little large in this situation.
CC @wolfs @big-guy

Branch: https://github.com/gradle/gradle/compare/blindpirate/decrease-cache-size
I'm wondering if we need to clean the cache in CachingPatternSpecFactory  or make them weak references.

Yeah, 10K results sounds like a more reasonable baseline. Also, supporting 30K instances seems totally overblown. How many patterns do we expect people to create? 100 maybe?

We should reuse the CrossBuildInMemoryCache infrastructure to take care of caching the patterns, rather than reimplement another cross-build cache that behaves differently to the others. Then we have a centralized place to improve the strategies for cache sizing and cleaning up unused values and so on.

For 6.0, could we reduce the size of the cache and put a proper fix in for 6.1?

Absolutely.

Per discussion in the dependency management planing today, I move this to 6.1. The PR shows that there is an impact on performance of our own scenarios and we have to investigate this deeper if we want to change something here.
@blindpirate will suggest to use another API in the licensing plugin so that the cache directory does not need to be scanned anymore. See: https://docs.gradle.org/5.6.2/userguide/working_with_dependencies.html#accessing_a_modules_metadata_file

authors: adammurdoch big-guy blindpirate jjohannes oehme

repo: gradle/gradle


text:
Repo libs-releases-local outdated, not containing artifacts after 6.1.1

Looks the last updated date for https://repo.gradle.org/gradle/libs-releases-local/org/gradle/ is 24-Jan-2020 for 6.1.1 release. After that, nothing has been pushed there. Plugin developers depending on APIs of Gradle subprojects (e.g., protobuf-gradle-plugin using kotlin-dsl's extension APIs) are not able to upgrade.
There is an API change for kotlin-dsl made in 6.8, NamedDomainObjectContainer<T>.invoke(kotlin.Function1). But protobuf-gradle-plugin is not able to migrate away from it, as no artifact containing the changed API definition can be found.
(#15508 reverted the API deletion, but I guess Gradle is still suggesting to migrate.)
Expected Behavior

Be able to find the latest version of Gradle subproject artifacts (e.g., org.gradle:gradle-kotlin-dsl:6.8.3).
Current Behavior

Third-party plugins are not able to migrate usages of APIs from Gradle subprojects.
Context

NA
Steps to Reproduce

NA
Your Environment

NA
Build scan URL:

Gradle API should be consumed by adding the embedded dependency to gradleApi() in dependency declaration.
There is no immediate plan to publish these binaries as they expose way more than the public API.
Can you be more specific as why there is a use case where gradleApi() is not enough?

Specifically, the protobuf-gradle-plugin has an API for users to configure NamedDomainObjectContainer, something like
protobuf {
   plugins {  // <== NamedDomainObjectContainer<PluginOptions>
      id("grpc") {
        artifact = "io.grpc:protoc-gen-grpc-java:1.37.0"
      }
   }
}

In Groovy, this is just delegated by ConfigureUtil.configure(Closure, T). In Kotlin DSL, it uses <T : Any, C : NamedDomainObjectContainer<T>> C.invoke(configuration: NamedDomainObjectContainerScope<T>.() -> Unit).
However, Gradle is changing the Kotlin DSL API to <T : Any, C : NamedDomainObjectContainer<T>> C.invoke(configuration: Action<NamedDomainObjectContainerScope<T>>) as in https://github.com/gradle/gradle/commit/593001e74f21a67ecc8d6f6c6174818f02eab007. Although #15508 added the T.() -> Unit overloading back, I guess in the long term Gradle is still suggesting plugins to migrate.
So, protobuf-gradle-plugin would need compile-time access to the <T : Any, C : NamedDomainObjectContainer<T>> C.invoke(configuration: Action<NamedDomainObjectContainerScope<T>>) API, which is provided by org.gradle:gradle-kotlin-dsl.  gradleApi() doesn't seem to provide this.

This issue looks like Gradle 8.0 will break all builds which use protobuf-gradle-plugin but does not provide any means for plugin authors to migrate to the recommended API. I assume that "do not upgrade to Gradle 8" will be the official answer of the Gradle team? Or is there a way for a community to resolve this issue? Either here or in protobuf-gradle-plugin repo?

The specific issues around protobuf-gradle-plugin have been addressed by https://github.com/google/protobuf-gradle-plugin/pull/577 (a part of v0.9.0).
The "official" Gradle API is the one produced by gradleApi() and not the published libraries on repo.gradle.org.

authors: big-guy iNikem ljacomet voidzcy


text:
Configuration cache in Gradle's own build has false-hit

Current Behavior
CC entry is reused even though it should not
Expected Behavior
CC entry discarded and new one calculated
Context (optional)
No response
Steps to Reproduce

Execute gw :architecture-test:checkBinaryCompatibility on a Windows machine
See that the build is failing due to bad URI construction
Try to fix it by editing build-logic/binary-compatibility/src/main/groovy/gradlebuild/binarycompatibility/ExtractGradleApiInfoTask.java
Run the build again

=> Build fails with the same error

Now run again with --no-configuration-cache

=> Build succeeds or gives error matching the new code

Now run again without --no-configuration-cache

=> Build fails with the original error
Gradle version
master
Build scan URL (optional)
No response
Your Environment (optional)
No response

Thank you for providing a valid report.
The issue is in the backlog of the relevant team and is prioritized by them.

Let's try to figure out what is actually broken as a first step.

authors: Vampire cobexer mlopatkin


text:
Upgrade to Groovy 2.5.4

Groovy 2.5.4 was just released and we should upgrade to the latest version to benefit from bug fixes.

I won't have the time to do the upgrade, but published groovy-all-1.0-2.5.4 so anyone ready to babysit the build can bump the version number.

FYI https://discuss.gradle.org/t/gradle-5-0-rc-2-is-now-available-for-testing/29447/8

Hi guys, looks like there was a critical bug fixed for groovy 2.5.4 - https://issues.apache.org/jira/browse/GROOVY-8871. I stumbled across this as one of my home brewed plugins stopped working due to the same exception

Done in https://github.com/gradle/gradle/commit/16d1b2af48ac6b45bbe96ad83a97cd07caf7b4ed

authors: embee1981 eskatos lptr marcphilipp


text:
projectsEvaluated task dependencies ignored with configure-on-demand

When using --configure-on-demand, task dependencies configured inside a project.gradle.projectsEvaluated block are silently ignored.
This even happens with a single project:
task task1
task task2

gradle.projectsEvaluated {
  task1.dependsOn task2
}

Behaviour tested by running ./gradlew -m task1.
Expected Behavior
Task dependencies should work if set up in projectsEvaluated, and only afterwards should the task graph be initialized.
This is the output when running without configure-on-demand:
tarting a Gradle Daemon (subsequent builds will be faster)
:task2 SKIPPED
:task1 SKIPPED

BUILD SUCCESSFUL in 3s

Current Behavior
Task dependencies are silently ignored.
gw -m task1 --configure-on-demand
Configuration on demand is an incubating feature.
:task1 SKIPPED

BUILD SUCCESSFUL in 0s

Context
This is a bit more involved than the basic issue explained above, but just for the sake of completeness I'll outline what I'm trying to do.
I want to set up some task dependencies based on inter-project dependencies.
These dependencies aren't guaranteed to be ready for a given project until its parent projects have also been evaluated, hence I'm using projectsEvaluated. I think I can separately set up task dependencies in such a way that the parent projects will be evaluated, even if configure-on-demand is enabled.
For example, say I have two projects, :foo and :foo:objects. A plugin applied to :foo configures :foo:objects.
I start with a task that triggers a configuration resolution, and that configuration depends on project(':foo:objects').
In order to ensure the plugin gets set up and configures the subproject, I am adding a task dependency which would cause the inclusion of :foo:objects in the configured projects list to also trigger :foo to be configured.
Steps to Reproduce
As above
Your Environment

Build scan URL:

Could you describe what you mean by

These dependencies aren't guaranteed to be ready for a given project until its parent projects have also been evaluated

This might be interesting for the dependency management team /cc @ljacomet

I mean simply that we have a plugin which, when applied onto a project :foo, configures some subprojects of that project (e.g. :foo:foo-objects) with additional dependencies, and naturally this happens as part of evaluating :foo.
Therefore, it's imperative that when resolving a dependency on :foo:foo-objects from some other project, we must ensure that :foo is also resolved.
On top of that, we have another plugin, gradle-consistent-versions, that needs to copy all java configurations from all projects at some point (during evaluation time).
It follows that, unless we require adding a bunch of well placed evaluationDependsOn statements, which is error-prone, the only safe time to do this and guarantee the result is what you want is after all projects have been evaluated.
Of course, in the context of gradle-consistent-versions, this copying implies that we need to evaluate all projects. However, this only needs to happen when a task is run, and we can configure that task to depend on all projects such that they'd all be evaluated, so that is a bit off topic regarding the issue described here.
The relevant bit is that

we need to configure task dependencies / create configurations inside projectsEvaluated
it's fine if this configuration only happens on projects selected by configure-on-demand
configure-on-demand makes the above configurations not happen / happen too late

@ljacomet could I get you to have a look at this if you've got the chance?
This is blocking us from properly supporting configure-on-demand in our gradle-consistent-versions plugin.
Main thing we'd like to do is
gradle.projectsEvaluated {
    rootProject.subprojects { p ->
	    if (!p.state.executed) return
	    // Configure some extra task dependencies, add some extra configurations
	}
}

I'm having similar issue of that dependencies added using dependsOn inside gradle.projectsEvaluated are ignored after all when org.gradle.configureondemand is turned on.

I was in the same situation ,I create a  simple demo：
Demo.zip
when I execute command ：gradle rootTask --no-configure-on-demand ,the execute result is:

but when I execute command :gradle rootTask --configure-on-demand,the execute result is:

Can confirm this is still an issue with Gradle 7.4.2.

Still an issue in Gradle 7.6. Our use case is to build jar files of dependencies, because they must be present when javaCompile.doLast runs, I don't know if there's a better place to do this than projectsEvaluated.

Is there a suggested workaround for this issue? Having to disableorg.gradle.configureondemand is disappointing.

authors: Pei116 YaoWang0515 big-guy bondolo chylek-qr dansanduleac phase


text:
Finer grained incremental compiler

This pull request improves the incremental Java compiler by making it smarter about constants. It uses a better strategy to recognize when a file should be recompiled, by storing the constants defined by each class, and storing the literals found in method bodies. It will also avoid recompiling if a change in a class that contains constants is irrelevant to constant values.

Stage 3 build passed: https://builds.gradle.org/viewLog.html?buildId=1992791&tab=buildResultsDiv&buildTypeId=Gradle_Branches_Checkpoints_Stage3LinuxWindowsBasicCoverageBasicCompatibility

Looks great. It's in master now

source: gharchive/pull-request

authors: adammurdoch melix


text:
Also test shadow plugin version 7.0

Fixes gradle/gradle-private#3316

@bot-gradle test and merge

OK, I've already triggered a build for you.

Pre-tested commit build failed.

@bot-gradle test and merge

Your PR is queued because #16987 is being built.

OK, I've already triggered a build for you.

Pre-tested commit build failed.

@bot-gradle test and merge

OK, I've already triggered a build for you.

OK, I've already triggered a build for you.

authors: bot-gradle wolfs


text:
Polish configuration-cache

A few minor changes after a code review.

@bot-gradle test and merge


text:
Publish 8.3-20230720232937+0000

Publish 8.3-20230720232937+0000

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

I've triggered a build for you. Click here to see all failures if there's any.


text:
Add support for TestNG's threadPoolFactoryClass launch parameter

Supersedes #25760

@bot-gradle test this

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

PullRequestFeedback build

@bot-gradle test this

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

PullRequestFeedback build

@bot-gradle test and merge

WARN: This is a feature pull request but no changes to release note found.

Sorry some internal error occurs, please contact the administrator @blindpirate

@bot-gradle test and merge

WARN: This is a feature pull request but no changes to release note found.

The merge queue build has started. Click here to see all failures if any.

The merge queue build has started. Click here to see all failures if any.

authors: bot-gradle ghale


text:
De-incubate dependency insight report

Context
This PR adds release notes for the dependency insight report improvements, and, probably as important, de-incubates it!

@melix Should we also add to the release notes?

Also, I've filed an issue for us to tweet about this after 4.9

@eriwen the PR actually includes release notes.

Indeed it does :) I didn't read the file name. I saw so much content I foolishly assumed this was in some user manual chapter. Ignore me then. This looks very good 👍

authors: eriwen melix


text:
add buffer to promise like channel

PR Description
add buffer to promise like channel so main goroutine loop doesn't block
Which issue(s) this PR fixes
no issue, just performance improvement
Notes to the Reviewer
hey @mattdurham, I was reviewing usage of go-actor and just noticed this so I wanted to share it with you.
in DoWork caller is being notified  after config gets updated. because this channel is not buffered this goroutine will get blocked because caller is also blocked at this point (it's waiting on response from done channel). main loop will remain blocked until goroutine that made this request is resumed again (which can take time theoretically speaking).
probably the best approach when implementing logic of DoWork (aka workers) is to never have it's code blocked unless it is blocked on reading data from inbound mailboxes - in other words blocked because it's waiting on work.
in this case, this can be easily achieved by making done, promise like channel, to have buffer of size 1. this will ensure that DoWork can write to it without waiting on this goroutine to be ready.

defer close(done) was removed because it is unnecessary, after data transmission, this channel is no longer used so no one will care if this channel is closed or not - eventually it will be garbage collected.
PR Checklist

[ ] CHANGELOG.md updated
[ ] Documentation added
[ ] Tests updated
[ ] Config converters updated

Since your here :) having an issue on where I don't know the number of callers, so if I close call and still have work coming in I get a panic which is not ideal. My idea is for actors that behave as a channel to not call close and not set the panic send handler. Thoughts?

You mean mailboxes? To me it sound like you are using mailbox and sometimes you stop mailbox but there is more work coming in? If this is true then just just have to additional logic that will not send data to mailbox is something is sopped.
Or there is different issue, were you are stopping in different order. Inbound routine, that sends work, should be stopped first, before mailbox.

authors: mattdurham vladopajic

repo: grafana/alloy


text:
pull build/ from upstream

Description of your changes

Fixes #
I have:

[ ] Read and followed Crossplane's contribution process.
[ ] Run make reviewable test to ensure this PR is ready for review.

How has this code been tested

I used my personal account now, as the controller-amd64 repo on the grafana org is broken (filed a support requests).
Also $(SPACE) didn't render properly from common.mk, added a fix for that locally.

repo: grafana/crossplane-provider-grafana


text:
Remove relative path info from executable field

Related to https://github.com/grafana/grafana-zabbix/issues/1785
A change in the plugin SDK allows us now to not require the nested datasource executable to live in the parent root directory.

@wbrowne I'm trying this out but it is not working for me. It tries to get the executable from the datasource folder. am I missing something?
I deleted the dist folder. run mage -v and then yarn build

@zoltanbedi could you take it for a spin now and let me know if it's okay for you? 🙏 Can you also confirm the directory structure of the built plugin looks like the following:

Plugin dist
./go_plugin_build_manifest
./datasource
./datasource/query_help.md
./datasource/gpx_zabbix-datasource_windows_amd64.exe
./datasource/gpx_zabbix-datasource_darwin_amd64
./datasource/gpx_zabbix-datasource_linux_arm64
./datasource/module.js.map
./datasource/plugin.json
./datasource/img
./datasource/img/icn-zabbix-datasource.svg
./datasource/module.js
./datasource/dashboards
./datasource/dashboards/template_linux_server.json
./datasource/dashboards/zabbix_system_status.json
./datasource/dashboards/zabbix_server_dashboard.json
./datasource/gpx_zabbix-datasource_linux_arm
./datasource/gpx_zabbix-datasource_linux_amd64
./datasource/gpx_zabbix-datasource_darwin_arm64
./LICENSE
./panel-triggers
./panel-triggers/module.js.LICENSE.txt
./panel-triggers/module.js.map
./panel-triggers/plugin.json
./panel-triggers/img
./panel-triggers/img/icn-zabbix-problems-panel.svg
./panel-triggers/module.js
./CHANGELOG.md
./module.js.map
./plugin.json
./README.md
./img
./img/screenshot-annotations.png
./img/screenshot-dashboard01.png
./img/icn-zabbix-app.svg
./img/screenshot-triggers.png
./img/screenshot-showcase.png
./img/screenshot-metric_editor.png
./styles
./styles/dark.css
./styles/light.css
./module.js

authors: wbrowne zoltanbedi

repo: grafana/grafana-zabbix


text:
feat: add support for forwarding cluster events as json logs

Summary
Add support for forwarding cluster events as json logs by adding a logs.cluster_events.logFormat input value.
Notes

This change is not breaking as it respects the current default log format (logfmt).
log_format is a field already supported by the kubernetes_events component.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

I like the improvements! A few comments to get the tests to pass:

In the top-level directory, run helm-docs (https://github.com/norwoodj/helm-docs) That will regenerate the README.md to document the new field in values.yaml
Then, run make regenerate-example-outputs, which is used to build the example files.

When the changes that is made there looks good, update your PR and it should pass the tests.
See https://github.com/grafana/k8s-monitoring-helm?tab=readme-ov-file#contributing for some more details.

authors: CLAassistant claudioscalzo petewall


text:
Incorrect regions added in v1.1.2

In v1.1.2, the regions supported by the plugin were updated to reflect where Timestream is available.
However, the available West Coast region is us-west-2, and not us-west-1: https://github.com/grafana/timestream-datasource/blob/master/src/common/regions.ts
This is confirmed in the pricing page which shows available regions: https://aws.amazon.com/timestream/pricing/. Note: "US West (Oregon)" is us-west-2
This causes the Grafana UI to not allow us-west-2 to be configured as a Timestream data source. It allows us-west-1, where Timestream is not currently supported.

HI,
I faced the same issue : which is a GUI deign error more than an issue : you can fill in whatever value you need, even if not listed !
It is not natural for a dropdown menu, nothing tells you you can, it requires a "usability fix".
Remove entirely the dropdown would be better than this.
see #19
(that's where I found the idea to 'type in', no-one can guess that)

HI,
I faced the same issue : which is a GUI deign error more than an issue : you can fill in whatever value you need, even if not listed !
It is not natural for a dropdown menu, nothing tells you you can, it requires a "usability fix".
Remove entirely the dropdown would be better than this.
see #19
(that's where I found the idea to 'type in', no-one can guess that)

Same with the pre-defined eu-west-2 region, which is actually supposed to be eu-west-1.

resolved in v1.2.0

authors: agranig lewalt000 ryantxu squalou

repo: grafana/timestream-datasource


text:
🛑 Employment is down

In 72fd70c, Employment (https://www.schooljobs.com/careers/gram) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Employment is back up in 995b9ee after 15 minutes.

repo: gramblingstatewebmaster/upptime


text:
Update to Bot API 6.0

Updates grammY to Bot API 6.0.
https://core.telegram.org/bots/api#april-16-2022
Blocked by https://github.com/grammyjs/types/pull/6

For some reason, skypack fails to build @grammyjs/types@v2.7.0 but it succeeds for @grammyjs/types@v2.6.0. I could not figure out what broke it, so we're using https://esm.sh instead now.

repo: grammyjs/grammY


text:
feat: add has and readAll methods to StorageAdapter interface

These methods will be used mainly by the chat-members and the broadcast
plugins

Codecov Report
Base: 36.70% // Head: 36.68% // Decreases project coverage by -0.03% :warning:

Coverage data is based on head (8e5154f) compared to base (6441e25).
Patch coverage: 25.00% of modified lines in pull request are covered.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #366      +/-   ##
==========================================
- Coverage   36.70%   36.68%   -0.03%
==========================================
  Files          18       18
  Lines        4588     4591       +3
  Branches      166      166
==========================================
  Hits         1684     1684
- Misses       2902     2905       +3
  Partials        2        2

Impacted Files
Coverage Δ

src/convenience/session.ts
99.12% <25.00%> (-0.88%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

@Satont I'm very curious what your opinion is on this

@Satont I'm very curious what your opinion is on this

I'll wait for this before I move on

I'm wondering about implementation of something like that. Already expect to "crutches".
I'm interested about use case such methods, can you explain a little more about what this is for??

Initially, for the broadcast plugin.
The chat-members stores information about users in the storage, and the broadcast plugin will need to list all those members in order to send messages to them.
chat-members need has to check wether a member has already been saved, and broadcast need readAll / readEntries

So, should I go ahead with this?
@KnorpelSenf @Satont

I'm interested about use case such methods, can you explain a little more about what this is for??

Initially, for the chat-members and the broadcast plugins.
The chat-members plugin stores information about users in the storage, and the broadcast plugin will need to list all those members in order to send messages to them.
chat-members need has to check wether a member has already been saved, and broadcast need readAll / readEntries

Ok. Do you plan implement all those methods in storages?

Ok. Do you plan implement all those methods in storages?

I can try to, yes. But the idea of havin the optional properties is so we don't necessarily have to do that.

I can try to, yes. But the idea of havin the optional properties is so we don't necessarily have to do that.

Ok, then go on.

One last question. When using the new storage adapter, do we ever need to differentiate between sync and async iterables?

We shouldn't need to, because sync iterables can be consumed with await the same way async ones can.

Awesome, that's what I was hoping for!

authors: KnorpelSenf Satont codecov-commenter roziscoding


text:
Updated the api

get and set handler now receives code, res
on handler now receives path, update
ready to be published, need the go ahead.

Forgot to override the event emitter class to add regex based event emitting feature (just the way we are doing in arduino). I will push it through a new commit.

Forgot to override the event emitter class to add regex based event emitting feature (just the way we are doing in arduino). I will push it through a new commit.

With the next PR? Or should I wait for the commit?

Forgot to override the event emitter class to add regex based event emitting feature (just the way we are doing in arduino). I will push it through a new commit.

With the next PR? Or should I wait for the commit?

I have added a new commit.

authors: abdullahmahboob moizhusnain

repo: grandeurtech/py-sdk


text:
Use custom ids

projects should be able opt-out of automatic id-generation

Closed as duplicate of #365

repo: graphcool/graphcool


text:
Version string in Electron app setting is wrong

This issue pertains to the following package(s):

[x] GraphQL Playground - Electron App

What is the expected behavior?
It prints the right version string.
What is the actual behavior?

This is not a bug, because electron version is different from react one. Elecron app wraps react app what is version bottom. And why is that? If we have one version of package version would increase so fast because when you want to fix something in electron playground you would need to release all packages and vice versa :)

authors: Huvik marktani

repo: graphcool/graphql-playground


text:
Support multiple profiles if pt enabled

Currently we support public transit (pt) or road network based FlagEncoder like car. It should be possible to specify graph.flag_encoders=pt,car and being able to route through car or pt. And for the other encoders all speed up algorithms should be available, so nothing complex like multi modal. Just reusing the graph data structure.
As a start we should throw an exception telling that "pt,car" is not yet supported.

what is the status of the problem, I need the feature for a project. could you please solve the problem.

Meanwhile, this works.
Enable PT by gtfs.file=.... (Currently) don't mention pt anywhere in flag_encoders or profiles, it'll just work.

Ah, this is great, thanks!

any updates on this? I want to know if multi modal plans can be generated by graph hopper latest version(s)?

authors: amrshah constantin42 karussell michaz

repo: graphhopper/graphhopper

license_source: bigquery


text:
Feature Request: handleTransaction

Do you want to request a feature or report a bug?
Feature request.
Currently, there is handleBlock, which allows us to trigger on all incoming blocks in subgraphs, but is it possible to add a trigger for all transactions? (like handleTransaction) In this way, all blocks, transactions and addresses on the network can be indexed, so it will be possible to create explorers (like etherscan) on evm-based chains (if it is not possible to add them as a cli command as mentioned in #297). In addition, if the feature mentioned in #1211 is added, transaction information can be retrieved from the block and this feature may not be needed.

Hi! Yes this is a good request - transaction information is non trivial to fetch from the RPC, but with the addition of an Ethereum Firehose as a data source, this should become much more immediately feasible @maoueh

@azf20  is there any update on this Feature-handleTransaction , so that all transactions can be indexed, if not is there a workaround we can do in subgraph to acheive this?

hey @kumar8317 - we have made significant progress with the Firehose integration, but this data is also available directly using https://substreams.streamingfast.io/. What is your use case?

@azf20  Our use case is to index all transactions (including native coin transfers) on the chain and then do further processing. If this can be done, could you direct me to a doc/tutorial on how to achieve this

repo: graphprotocol/graph-node


text:
docker: Allow custom ethereum poll interval

This PR will allow to optionally specify ethereum poll interval when using graph-node's docker image

@lutter clould you please re-run the following CI job : Run tests (stable) ?
It looks like previous run has failed due to a lack of space on the github action runner.

@lutter clould you please re-run the following CI job : Run tests (stable) ?
It looks like previous run has failed due to a lack of space on the github action runner.

@lutter clould you please re-run the following CI job : Run tests (stable) ?
It looks like previous run has failed due to a lack of space on the github action runner.

I just kicked off another run - we are still in the process of migrating to GH actions, and for now the thing I pay attention to is the Travis result. Let's see whether the additional run will fix it, if not, I'll merge since Travis had already passed.

@lutter clould you please re-run the following CI job : Run tests (stable) ?
It looks like previous run has failed due to a lack of space on the github action runner.

I just kicked off another run - we are still in the process of migrating to GH actions, and for now the thing I pay attention to is the Travis result. Let's see whether the additional run will fix it, if not, I'll merge since Travis had already passed.

authors: cyrilledec lutter


text:
Add BlockDetailLevel

Firehose block detail level introduced a source of non deterministic behavior. This PR ensures that if Call or block handlers are used, the incoming blocks are required to use Extended Block Details, this essentially means rpc poller based chains will not be allowed as they currently introduce some behaviors for which the graph-node cannot ensure deterministic subgraph data.

Expose the existing DetailLevel information to graph-node's protobuf
Enforce a minimum value based on the handler type
Add env var to disable this behavior, in some changes extended block types are not yet available, so for those chains the new env var needs to be used.

Optimism at the time of writing is still a WIP. Arbitrum has a mix of block detail level and may require the env var to be used to bypass validation.

@sduchesneau could you please confirm if there are any additional chains that also should have the block detail validation disabled by default?

FWIW I could (and have) run rpc-poller on chains that support full blocks. (We have a few today we're converting to full blocks, but initially were set up with RPC poller blocks because full firehose support was not available).
Shouldn't this better be a property in the graph-node config file about what attributes the provider supports? (Like we have traces=true on and RPC node and other properties today)
Any OP-STACK or Polygon-ZK type chain does not support full blocks currently.

IMO kinda hidden environment variables that change graph-node behaviour for specific chains are hard to understand when a node operator is setting up new chains.  Forcing them to think about it is better than trying to debug why things go wrong mysteriously.
Or alternatively, what is the maintenance plan to keep this ENV up-to-date as studio keeps adding new chains?  Recently they are adding 4 chains per week or so.

This is still being discussed internally, we probably will need to sync with the chains in test and enable the full block requirement once they go live. Ideally for operators this should be mostly transparent if the sync works well, they exist in case it doesn't

Asside: As I brought up during recent off-site, I would ideally like to get away from forcing graph-node restart to add/remove/change a chain configuration.  There are 100s of new chains launching in the next year or so....  Forcing a graph-node restart is annoying.   So not adding new environment variables would be nice.  (During the discussion Adam/David mentioned this would not be easy lift to accomplish).

Asside: As I brought up during recent off-site, I would ideally like to get away from forcing graph-node restart to add/remove/change a chain configuration. There are 100s of new chains launching in the next year or so.... Forcing a graph-node restart is annoying. So not adding new environment variables would be nice. (During the discussion Adam/David mentioned this would not be easy lift to accomplish).

I don't really see that as related to this situation, that overall seems to be like a low return investment. The extra complexity to avoid restarts is a lot of code that needs to be written for a low impact achievement (no restart) but that's just my opinion and not really related to this PR

authors: mangas matthewdarwin


text:
test: more snapshots

instead of writing out big string by hand we should utilize more snapshots testing since that is what we are trying to achieve with these compares for generated code anyways.

I am not sure why I didn't merge this but goal was this makes test runner more stable.

Yeah I've re-implemented it in #1824

authors: YaroShkvorets saihaj

repo: graphprotocol/graph-tooling


text:
feat: Add FielNameRewriter

Supersedes #14.

@Sytten @chanind Can this please get merged?

Yeah I didnt spend much time in the last months on rewriter. I will try to give it a spin soon.

authors: ChrisLahaye Sytten

repo: graphql-query-rewriter/core


text:
The hint dom nodes lives outside the codemirror dom tree currently.

Submitting another PR because I missed two cases in my earlier PR https://github.com/graphql/graphiql/pull/791.

@acao can you please review? Thanks!

@codeStryke yeah for sure!

Deploy preview looks good - thanks

Thanks!

authors: acao codeStryke orta

repo: graphql/graphiql


text:
ValueError: can't find checkpoint

I've run the step1, but when it gets to step2 it shows that "Can't find a valid checkpoint at checkpoints/glue_sst2_roberta-large_targeted_prompt/t5.p0.10/checkpoint". I viewed my documents and found the right checkpoint at this path but it is not accessible by the algorithm.

Please train a poisoned checkpoint.

repo: grasses/PoisonPrompt


text:
Configure logging initialization such that it can be readily initiali…

…zed by a programmatic execution of aspen. Fixes #540.
Feel free to reject and develop an alternative, accept and tweak, or accept as-is.

Picking up from #540 ...

Okay, upon looking at this again, the current code is correct because: init_logging initializes handlers and formats and such, which a module should NOT do.  This is why it's done in __main__.

@pjz The way I read this PR, init_logging initializes handlers, yes, and it's defined in __init__ ... but it's not called except during python -m aspen via __main__ (notice the functools.partial at https://github.com/jaraco/aspen/blob/6c920a68ac7912188e23ca19a743edba22a540ff/aspen/init.py#L104). No?

In other words, I think @pjz's concerns are misplaced, and I'm :+1: here.
Am I missing something, @pjz?

That's the intention - expose the functionality so another caller might be able to re-use it, but still call it by default only in __main__.

Looking at the __main__ code now, I think that serve() should NOT have been refactored into __init__.py for similar reasons as I think init_logging() shouldn't be:  The goal of python -m aspen is to serve as 1: a test/dev toy server and also 2: example code.  Literally nothing else ever in the aspen module will call or use serve() and init_logging().  Production deploys shouldn't use them either - they should use uwsgi or the like to call a minimal wrapper around the WSGI entry point.  I much prefer to not add an extra support/documentation burden to the module by instead encouraging people to copy the __main__ as a starting point.

I'd prefer the solution embodied by #545.

Closing per https://github.com/gratipay/aspen.py/issues/540#issuecomment-176803859.

authors: jaraco pjz whit537

license: mit


text:
🛑 GrauNeko.com is down

In 9b74327, GrauNeko.com (https://graueneko.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: GrauNeko.com is back up in 5d34dee.

repo: graueneko/status-page


text:
Add gravity CLI commands to work with operations

Adding view (dumping the JSON object f.ex.) and delete (to deal with stuck operations) to remove the need for operators to drop down into etcd to resolve problems.

Having this right now and this would be helpful.
Cluster name:           stable4
Cluster status:         shrinking
Application:            core-paas, version 0.0.15
Join token:             08406613fa564c86317e04ca0dcc026a
Periodic updates:       OFF
Remote support:
    opscenter: ON
Active operations:
    * operation_shrink (31595672-cbca-4054-b48d-cb4ad91b435d)
      started:  Tue Feb 11 21:24 UTC (27 minutes ago)
      initializing the operation, 0% complete

gravity version
Edition:        enterprise
Version:        6.2.5
Git Commit:     5794ad618bd19b32652bfc1223b16b2d27498466
Helm Version:   v2.12

authors: anandkumarpatel helgi

repo: gravitational/gravity


text:
Home page creation

I wan to work on the home page

@Glory135 Kindly work on the what we offer section and Ready to try different work experience section also make it responsive.
Kindly acknowledge you have seen this message @Glory135.

Okay

Solved #16

repo: gray-adeyi/orderlie-fe-react


text:
[FEAT] A parent tree item should remain expanded if there is an active/selected tree item within it

:bulb: Feature request
Feature Name
A parent tree item should remain expanded if there is an active/selected tree item within it
The Desired Behavior

Your Use Case

Prior Work

Environment

Daffodil version: X.Y.Z
Angular version: X.Y.Z

For Tooling issues:
- Node version: XX
- Platform:

Others:

@xelaint is this permanently open? Or only open upon initial render?

I think it should be permanent. If a user is on next.daff.io/docs/packages/cart/extension, and I refresh the page, the @daffodil/cart tree item should remain expanded so the user knows what page they're on and are able to find the related pages easily. Currently, if I navigate to Extension and refresh the page, the @daffodil/cart tree item is closed.

Ok. If I'm on that page and I click:

What should happen?
Should the click do nothing?

I disagree. I think the feature should only cover what happens on initial render. I also think that it should scroll the active item into view.

What I expect in a sidebar navigation where items are hidden:

User can collapse or expand a tree item, but the state resets upon refresh.
The selected tree item should be visible at all times.

Based on this UI, how does a user easily know where they are in the nav sidebar?

So if you're on the "Extension" page and decide to refresh to page, you wouldn't want to see that the Extension page is still the selected item in the sidebar?

refreshing the page is an "initial render"
the way I interpret "remain open" is that the accordion cannot be closed, even by user interaction.

my proposed UX:

upon initial render (page load) the accordion that holds the active nested item (if the active one is nested) is expanded
upon initial render the active nav item is scrolled into view

Gotcha. I interpreted "initial render" as literally the first initial render and nothing after that. I think we're on the same page then.

authors: damienwebdev griest024 xelaint

repo: graycoreio/daffodil


text:
Support iframe autoconnect

This adds support for the iframe to autoconnect when it detects it's in an iframe whose parent is running Cosmiframe.

memorializing discord convo:
we want autoconnect by default because the app has to specify which origins it trusts, and they may not want to add the iframe wallet to a wallet connection modal as it might not make much sense to the user. thus, let's just make autoConnect a boolean that defaults enabled, and attempt auto-connection to all chains provided to GrazProvider

repo: graz-sh/graz


text:
graph selection info table text overflow problem

'log2_fold_change' overlaps with value:

closed by #76

authors: vincerubinetti yhao-compbio

repo: greenelab/hetmech-frontend


text:
Issue with loading SVG sprite

I'm trying to load an SVG file as a React component. I found a PR https://github.com/facebookincubator/create-react-app/pull/3718 by @iansu that solves the problem.
However there is an issue with reading the SVG file contents.
Issue
I have the following SVG file (it was generated by [svg-sprite]):(https://www.npmjs.com/package/svg-sprite)
<?xml version="1.0" encoding="UTF-8"?>
<svg width="0" height="0" style="position:absolute">
  <symbol xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" id="filter">
    <path d="M10 18h4v-2h-4v2zM3 6v2h18V6H3zm3 7h12v-2H6v2z" />
    <path d="M0 0h24v24H0z" fill="none" />
  </symbol>
</svg>

which is being imported as:

As you see the <svg /> element is empty.
Workaround
I was able to find a workaround to the above. All works fine if I add <defs /> element that includes <style /> element:
<?xml version="1.0" encoding="UTF-8"?>
<svg width="0" height="0" style="position:absolute">
  <defs><style></style></defs>
  <symbol xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" id="filter">
    <path d="M10 18h4v-2h-4v2zM3 6v2h18V6H3zm3 7h12v-2H6v2z" />
    <path d="M0 0h24v24H0z" fill="none" />
  </symbol>
</svg>

which returns a proper <svg /> element and its contents:

Expected scenario
The SVG example from Issue section should be loaded correctly (with its contents) without adding some extra tags.

Hey @neoziro, I think I have the same issue now with @svgr/webpack loader. When I load single svg icon, it works fine, however, once I try to load a sprite it injects <svg></svg>.
I define an SVG loader as following rule for webpack:
{
    test: /\.svg$/,
    use: [{
      loader: '@svgr/webpack',
      options: {
        keepUselessDefs: true
      }
    }, 'url-loader'],
  }

I'm not sure if keepUselessDefs is still there in the current lib version, though.

Same error loading sprite:
<svg version="1.1" xmlns="http://www.w3.org/2000/svg"> <symbol id="ah_icon_alert" viewBox="0 0 983 1024"> <path d="M493.556 205.519l331.457 591.956h-662.913l331.457-591.956zM529.293 143.589c-15.639-27.931-55.837-27.931-71.475 0l-366.397 654.353c-15.288 27.304 4.447 60.973 35.739 60.973h732.792c31.293 0 51.028-33.669 35.738-60.973l-366.395-654.353z"/> <path d="M522.482 408.365v185.874c0 16.966-13.754 30.72-30.72 30.72-16.97 0-30.72-13.754-30.72-30.72v-185.874c0-16.966 13.75-30.72 30.72-30.72 16.966 0 30.72 13.754 30.72 30.72z"/> <path d="M456.95 701.223c0-19.227 15.585-34.816 34.816-34.816 19.227 0 34.816 15.589 34.816 34.816 0 19.231-15.589 34.816-34.816 34.816-19.231 0-34.816-15.585-34.816-34.816z"/> </symbol> </svg>
getting :
<svg xmlns="http://www.w3.org/2000/svg"></svg>
here is config:
webpack(config) {
// Grab the existing rule that handles SVG imports
const fileLoaderRule = config.module.rules.find((rule) => rule.test?.test?.('.svg'))
config.module.rules.push(
  // Reapply the existing rule, but only for svg imports ending in ?url
  {
    ...fileLoaderRule,
    test: /\.svg$/i,
    resourceQuery: /url/ // *.svg?url
  },
  // Convert all other *.svg imports to React components
  {
    test: /\.svg$/i,
    issuer: fileLoaderRule.issuer,
    resourceQuery: { not: [...fileLoaderRule.resourceQuery.not, /url/] }, // exclude if *.svg?url
    use: ['@svgr/webpack']
  }
)

// Modify the file loader rule to ignore *.svg, since we have it handled now.
fileLoaderRule.exclude = /\.svg$/i

return config

},

Same error loading sprite:
<svg version="1.1" xmlns="http://www.w3.org/2000/svg">
<symbol id="ah_icon_alert" viewBox="0 0 983 1024">
<path d="M493.556 205.519l331.457 591.956h-662.913l331.457-591.956zM529.293 143.589c-15.639-27.931-55.837-27.931-71.475 0l-366.397 654.353c-15.288 27.304 4.447 60.973 35.739 60.973h732.792c31.293 0 51.028-33.669 35.738-60.973l-366.395-654.353z"/>
<path d="M522.482 408.365v185.874c0 16.966-13.754 30.72-30.72 30.72-16.97 0-30.72-13.754-30.72-30.72v-185.874c0-16.966 13.75-30.72 30.72-30.72 16.966 0 30.72 13.754 30.72 30.72z"/>
<path d="M456.95 701.223c0-19.227 15.585-34.816 34.816-34.816 19.227 0 34.816 15.589 34.816 34.816 0 19.231-15.589 34.816-34.816 34.816-19.231 0-34.816-15.585-34.816-34.816z"/>
</symbol>
</svg>

result:
<svg xmlns="http://www.w3.org/2000/svg"></svg>

here is config:
  webpack(config) {
    // Grab the existing rule that handles SVG imports
    const fileLoaderRule = config.module.rules.find((rule) => rule.test?.test?.('.svg'))

    config.module.rules.push(
      // Reapply the existing rule, but only for svg imports ending in ?url
      {
        ...fileLoaderRule,
        test: /\.svg$/i,
        resourceQuery: /url/ // *.svg?url
      },
      // Convert all other *.svg imports to React components
      {
        test: /\.svg$/i,
        issuer: fileLoaderRule.issuer,
        resourceQuery: { not: [...fileLoaderRule.resourceQuery.not, /url/] }, // exclude if *.svg?url
        use: ['@svgr/webpack']
      }
    )

    // Modify the file loader rule to ignore *.svg, since we have it handled now.
    fileLoaderRule.exclude = /\.svg$/i

    return config
  }

Also tri load simple svg, all working correct

authors: kopacki tk-o wawezz

repo: gregberge/svgr


text:
[TypeScript] Typing issue when spreading props on html element (.e.g. div)

🐛 Bug Report
I get typing error for basic html attributes when spreading props on x.* elements. Honestly I don't know if I'm using it wrong or there is an internal problem, so any suggestion is welcome.
To Reproduce
There is a sample repository to inspect the issue down below.
Notice that there is a typing error for color prop (`Type 'number & {}' is not assignable to type 'string'.)
Expected behavior
It should be okay to spread props
Link to repl or repo (highly encouraged)
https://codesandbox.io/s/aged-darkness-pgirn

Hello @NKBelousov, your typing was wrong. You should use React.ComponentProps helper: https://codesandbox.io/s/sparkling-field-hg6ec

@gregberge I see, thanks a lot :)

@gregberge actually I think it would be cool to add this information to the docs, do you mind if I open PR for that?

@gregberge actually I think it would be cool to add this information to the docs, do you mind if I open PR for that?

Yeah feel free to complete it!

Hi,
After using this helper types are valid but autocompletion isn't working like usually with x.*
@gregberge do u have a suggestion about that ?
ty

@vincent-vade no sorry, as I said, I am not a real TypeScript user. I write library in TypeScript but does not use it in my real project (waste of time 🤗).

authors: NKBelousov gregberge vincent-vade

repo: gregberge/xstyled