text:
New Jersey Vaccine Numbers Repeated Last 3 Days

The Vaccine Dose figures for New Jersey have been the same since 5/3. The numbers match what is currently in the hourly file as well.
New Jersey,2021-05-03,All,34.0,US,40.2989,-74.521,,8769895.0,7430120.0,4634016.0,3005463.0,"New Jersey, US"
New Jersey,2021-05-04,All,34.0,US,40.2989,-74.521,,8769895.0,7430120.0,4634016.0,3005463.0,"New Jersey, US"
New Jersey,2021-05-05,All,34.0,US,40.2989,-74.521,,9006975.0,7430120.0,4634016.0,3005463.0,"New Jersey, US"

The JHU dashboard is showing updated figures (https://coronavirus.jhu.edu/vaccines/us-states). When will the bot update the figures in the hourly table?

Thank you for flagging this issue! We investigated and corrected the data.


text:
Ato 1009/identity for authorize endpoint

Add identity to authorize

check for identity
check return code

I've overwritten this to get rid of the return code - we should not be making return codes public

Think it would be good to have a chat about how return codes work in this ticket, as I've been doing some thinking about it today 🙂

#https://github.com/govuk-one-login/simulator/pull/111

The checking of return codes should be done in https://github.com/govuk-one-login/simulator/pull/111 . Since the only check for identity is the check for the flag itself and that it has no effect on the auth code, closing down this PR. All the validation for claims is already done and checking for identity should be done before returning the return codes.

source: gharchive/pull-request

repo: govuk-one-login/simulator

license: MIT

license_type: permissive

license_source: github-api


text:
如果我直接想让他把我读出的中文语音直接翻译成英文读出来 应该调整那个参数或者方法 就是同声传译 应该怎么设置一下？

我运行后发现我读中文他可以理解 并调用大模型 直接把英文的答案 读出来
如果我想让他直接把我读的中文  直接用英文读出来 应该怎么设置
就是里面提到的同声传译 应该修改那些参数

hi, 我们的训练数据中没有翻译相关的数据，也没有测试是否能支持同声传译，可以试试“please translate: 我是谁”。不过，不保证成功。理论上加一些翻译类的数据可以有效实现此类功能。

好的，我试试
---- 回复的原邮件 ----
| 发件人 | @.> |
| 日期 | 2024年09月07日 18:08 |
| 收件人 | @.> |
| 抄送至 | @.>@.> |
| 主题 | Re: [gpt-omni/mini-omni] 如果我直接想让他把我读出的中文语音直接翻译成英文读出来 应该调整那个参数或者方法 就是同声传译 应该怎么设置一下？ (Issue #38) |
hi, 我们的训练数据中没有翻译相关的数据，也没有测试是否能支持同声传译，可以试试“please translate: 我是谁”。不过，不保证成功。理论上加一些翻译类的数据可以有效实现此类功能。
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

I'll close it for now, please feel free to re-open.

source: gharchive/issue

authors: anstonjie mini-omni

repo: gpt-omni/mini-omni


text:
Timeout

How can I add time out to the GraphQL requests?

You can use Dio client as ferry client and set timeout there,
 final dio = Dio(BaseOptions(
        baseUrl: dotenv.env['BASE_URL']!,
        receiveTimeout: 60000,
        connectTimeout: 60000,
        responseType: ResponseType.json,
        headers: <String, dynamic>{
          'Accept': 'application/json',
          'Content-Type': 'application/json',
        },
      ));
return Client(
      link: Link.from([DioLink(dotenv.env['GRAPHQL_ENDPOINT']!, client: dio)]),
    );

@ebsangam What do you think about that adding timeout to request controller layer..?
There are different type of transport link (eg. websocket) to handle timeout directly..

you can write a TimeoutLink in front of your terminating link which would work regardless of the transport type. RequestControllerTypedLink is the wrong place for that, since is also handles requests for cached content, which for which timeouts do not make sense.

authors: dehypnosis ebsangam knaeckeKami yasaman93

repo: gql-dart/ferry


text:
All dependencies are assigned to the settings.gradle.kts file

Looking at the self-test results, all of the dependencies are being bound to the settings.gradle.kts file instead of binding the dependencies to the respective subproject's build.gradle.kts file.
https://github.com/gradle/github-dependency-graph-gradle-plugin/network/dependencies
For example, search for junit: https://github.com/gradle/github-dependency-graph-gradle-plugin/network/dependencies?q=junit
This dependency could be traced to either of these two locations:

https://github.com/gradle/github-dependency-graph-gradle-plugin/blob/03dc2f16f686aca915f878f0b66360da3db303d9/plugin/build.gradle.kts#L44
https://github.com/gradle/github-dependency-graph-gradle-plugin/blob/03dc2f16f686aca915f878f0b66360da3db303d9/gradle/libs.versions.toml#L19-L20

However, neither of these files are linked to in the GitHub UI

FYI here's the commit that flattened the model to a single "manifest" for the entire build invocation.
Ideally, each resolved dependency version could be traced to the one (or several) places where it is declared. Unfortunately Gradle makes this very difficult to determine, and simply linking to the subproject that resolves a dependency (the previous behaviour) wasn't particular helpful if the version is defined elsewhere, like in a plugin or a .toml file.
BUT, linking the dependency to each subproject has the major downside of creating many more dependabot alerts for the project when this version needed upgrading. When working with real-world projects this made the Dependency Graph support much less useful, since the 100s of alerts generated led to users not trusting the tool.
So until we can reliably link a dependency version to the source file where it is defined, I'd prefer to point to the entire Gradle build (either settings.gradle or the root build.gradle), rather than try to guess a more specific location which might be incorrect.

BUT, linking the dependency to each subproject has the major downside of creating many more dependabot alerts for the project when this version needed upgrading. When working with real-world projects this made the Dependency Graph support much less useful, since the 100s of alerts generated led to users not trusting the tool.

To clarify this: imaging a Gradle build with 100 Java subprojects, and each subproject applies a convention plugin to configure the version of Junit used. In this case, we should be linking the junit dependency to the plugin sources as the single location where the version is defined.
But since we don't have a mechanism to do this, I don't think we should link this junit version to each of the subprojects that applies that plugin. Instead, we simply link the junit version to the entire Gradle build, relying on the users to determine which exact source file needs to be updated.

BUT, linking the dependency to each subproject has the major downside of creating many more dependabot alerts for the project when this version needed upgrading. When working with real-world projects this made the Dependency Graph support much less useful, since the 100s of alerts generated led to users not trusting the tool.

Friendly ping to @jhutchings1 This seems like a bug, and/or a bad user experience for this feature.

Ideally, each resolved dependency version could be traced to the one (or several) places where it is declared. Unfortunately Gradle makes this very difficult to determine, and simply linking to the subproject that resolves a dependency (the previous behaviour) wasn't particular helpful if the version is defined elsewhere, like in a plugin or a .toml file.

This seems like something that could be tracked if the .toml file generated a richer Dependency object that included this information regarding declaring file, and this information was exposed all the way through the resolution event API.

Instead, we simply link the junit version to the entire Gradle build, relying on the users to determine which exact source file needs to be updated.

This seems like a reasonable "guess" could be made for a majority of cases, rather than always being incorrect by just using the settings.gradle file. This would be the principle of least surprise IMHO.

So until we can reliably link a dependency version to the source file where it is defined, I'd prefer to point to the entire Gradle build (either settings.gradle or the root build.gradle), rather than try to guess a more specific location which might be incorrect.

🤔 I see your rationale, but I don't entirely agree. The dependency is tied to a specific subproject, and each subproject has a dedicated build.gradle file. Even if the dependency isn't declared in the build.gradle, it's still the file where that particular dependency is "managed" because it's the build.gradle for that project.

BUT, linking the dependency to each subproject has the major downside of creating many more dependabot alerts for the project when this version needed upgrading. When working with real-world projects this made the Dependency Graph support much less useful, since the 100s of alerts generated led to users not trusting the tool.

Friendly ping to @jhutchings1 This seems like a bug, and/or a bad user experience for this feature.

Understood that this isn't ideal behavior, but we're not anticipating making any changes to the behavior of the API at this time.

adding to the discussion here - medium sized Gradle build, 49 modules, 1 extra included build. Dependency analysis is cool, but I have no clue where the deps are coming from as all of them say settings.gradle.kts. I would much rather have a bunch of dupes I can actually chase down.

Thanks for your comment. Were you aware of any of the additional documentation regarding "resolving dependency vulnerabilities"? (I'm wondering if there's a way to make these more prominent)

https://github.com/gradle/github-dependency-graph-gradle-plugin?tab=readme-ov-file#using-the-plugin-to-generate-dependency-reports
https://github.com/gradle/actions/blob/main/docs/dependency-submission.md#resolving-a-dependency-vulnerability
https://github.com/gradle/github-dependency-submission-demo?tab=readme-ov-file#detecting-and-resolving-dependency-vulnerabilities-in-gradle-projects
https://github.com/gradle/actions/blob/main/docs/dependency-submission-faq.md#why-arent-dependencies-be-linked-to-the-source-file-where-they-are-declared

Although I don't think it's practical to make it easy to attribute dependencies directly in the GitHub UI, we could also generate an extra, detailed report with full dependency-path information. Or we could possibly add the full dependency-path information as metadata in the GitHub Dependency Graph file.

Nope, I wasn't aware of those docs. I did manage to solve all of my issues by manually invoking the GitHub variant of the plugin locally though. I think the most ergonomic way for solving this would be perhaps exporting the generated .json file from GitHub Actions?

Thanks @madisp.
I've raised https://github.com/gradle/actions/issues/195 to make this process easier in general.

We use renovate and was attempting to use the gradle dependency graph to auto-create PRs. The config passed to renovate come directly from this plugin. Therefore it is telling renovate to look in settings.gradle.kts for a specific dependency in order to substitute the string with an acceptable version.
I'm not a java developer, but best I can tell you can't declare dependencies inside of settings.gradle.kts short of maybe a catalog.
Would it be possible to make this file configurable? We don't have any subprojects so setting it to build.gradle.kts would give us an avenue to automate vuln fixing.


text:
Failed to calculate the value of task ':lib-common:compileDebugJavaWithJavac' property 'options.generatedSourceOutputDirectory'.

Expected Behavior
Let the task execute successfully
Current Behavior
Failed
Steps to Reproduce
https://github.com/wangdaqi77/P2M/tree/adapt_AGP7.0/example
./gradlew clean assembleDebug -s -i
Execution failed for task ':lib-common:compileDebugJavaWithJavac'.Failed to calculate the value of task ':lib-common:compileDebugJavaWithJavac' property 'options.generatedSourceOutputDirectory'. > Querying the mapped value of map(java.io.File property(org.gradle.api.file.Directory, fixed(class org.gradle.api.internal.file.DefaultFilePropertyFactory$FixedDirectory, /Users/wongki/AndroidStudioProjects/P2M/example/lib-common/build/generated/ap_generated_sources/debug/out)) org.gradle.api.internal.file.DefaultFilePropertyFactory$ToFileTransformer@7d9cb9cf) before task ':lib-common:compileDebugJavaWithJavac' has completed is not supported

not actively fetching options.generatedSourceOutputDirectory in place，but running the task is failing
Your Environment
Gradle 7.4,Android Gradle plugin 7.1.2,Kotlin 1.5.21,macOS 10.14.6 (18G87)
Build scan URL:https://scans.gradle.com/s/f7bcx5rnry2ws

@wangdaqi77 Can you tell me how to fix it?

repo: gradle/gradle


text:
Project.files enters into an infinite loop when passing a nio Path instance

When calling Project.files with a java.nio.file.Path instance, resolving with the returned FileCollection will loop forever. The cause is that java.nio.file.Path implements Iterable<Path> and Gradle will try to resolve this infinitely nested collection.
I will create pull request in a minute solving this bug (including tests).

This is a duplicate of https://github.com/gradle/gradle/issues/1973 which already has a PR https://github.com/gradle/gradle/issues/2144

Sorry, didn't notice the other report.


text:
Missing 'archiveName' attribute in eclipse wtp

Expected Behavior
When generating the .settings/org.eclipse.wst.common.component file with the eclipse plugin, project dependencies should include an attribute named 'archiveName' and generated war from Eclipse should include the dependency.
<dependent-module archiveName="lib.jar" deploy-path="/WEB-INF/lib" handle="module:/resource/lib/lib">
    <dependency-type>uses</dependency-type>
</dependent-module>

$ unzip -l out.war | grep "lib.jar"
1308484  2022-12-13 10:36   WEB-INF/lib/lib.jar

Current Behavior
The 'archiveName' attribute is not generated leading Eclipse to print a warning and the generated war to miss the library.
<dependent-module deploy-path="/WEB-INF/lib" handle="module:/resource/lib/lib">
    <dependency-type>uses</dependency-type>
</dependent-module>

$ unzip -l out.war | grep "lib.jar"
<no result>

Context
Trying to generate a WAR with eclipse to deploy in JBoss
Steps to Reproduce
Run ./gradlew eclipse on https://github.com/Tiller/gradle-eclipse-issue. Import project, and check 'Deployment Assembly' or export war from Eclipse.
Your Environment
Gradle 7.6, Linux, Java 11

If you are interested in contributing to Gradle, this issue is actionable and ready for contribution but might be challenging for first time contributors.
See CONTRIBUTING.md for more information.

@xaviarias I have tried to fix this issue in this PR.

I have quickly reviewed the PR and looks OK.
@donat do you want to take a looks? Thanks!

authors: Chaoba Tiller xaviarias


text:
Support @Option with ListProperty

Expected Behavior
It is possible to annotation a JavaBean property of type List<String> with @Option and supply it with values from the command-line. We should have feature parity for properties of type ListProperty<String> etc.
Current Behavior (optional)
Currently an error is thrown if @Option is used on ListProperty<String>:
Caused by: org.gradle.cli.CommandLineArgumentException: Command-line option '--serial' does not take an argument.
	at app//org.gradle.cli.CommandLineParser$KnownOptionParserState.onArgument(CommandLineParser.java:423)
	at app//org.gradle.cli.CommandLineParser.parse(CommandLineParser.java:93)
	at app//org.gradle.execution.commandline.CommandLineTaskConfigurer.configureTasksNow(CommandLineTaskConfigurer.java:67)
	... 123 more

Context
When migrating eager multi-valued properties from List<T> to lazy ListProperty<T> types we need to keep @Option working for them.

Duplicate of https://github.com/gradle/gradle/issues/10517.


text:
fileTree unexpected behavior when used as task output

Current Behavior
When task defines output as filtered via include/exclude filters  fileTree the root directory of fileTree is considered as output.
Expected Behavior
If task output uses a filtered fileTree, the root directory of the fileTree should not be considered as output, only files/directories matching the exclude/include patterns should be considered as outputs.
Context (optional)
No response
Steps to Reproduce
This dummy build.gradle.kts showcases the issue:
plugins {
    base
}

// This mocks the task that takes `.graphqls` files in `src` directory and generates `.go` files from them in the same directory.
// The files are partly generated and supposed to be edited manually after generation, to implement actual resolver logic, thats
// why they sit in the `src` directory
tasks.register<Exec>("generate") {
    commandLine("echo", "Generating..")
    inputs.files(layout.projectDirectory.dir("src").asFileTree.matching{ include("*.graphqls") })
    outputs.files(layout.projectDirectory.dir("src").asFileTree.matching{ include("*.go") })
    doLast{
        println("Generation complete.")
    }
}

// This mocks the task that validates the `.graphqls` files in the `src` directory
// This have no dependency on `generate`, as it only validates the `.graphqls` files that are not generated by the `generate` task
tasks.register<Exec>("validate") {
    commandLine("echo", "Validating...")
    inputs.files(layout.projectDirectory.dir("src").asFileTree.matching { include("*.graphqls") })
    doLast {
        println("Validation complete.")
    }
}

tasks.named("build") {
    dependsOn("validate", "generate")
}

Executing gradle's build task results in the following error:
A problem was found with the configuration of task ':validate' (type 'Exec').
  - Gradle detected a problem with the following location: '/tmp/gradle_tasks/src'.

    Reason: Task ':validate' uses this output of task ':generate' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.

As a workaround for this i am calling .elements on the fileTree and passing the result as task output:
    outputs.files(layout.projectDirectory.dir("src").asFileTree.matching{ include("*.go") }.elements)

Gradle version
8.9
Build scan URL (optional)
No response
Your Environment (optional)
No response

The issue is in the backlog of the relevant team, but the existence of a workaround means it might take a while before a fix is made.

Related:

https://github.com/gradle/gradle/issues/9131

@ov7a
I feel like i am lacking understanding of the root cause of the issue.
I end up using the .elements workaround by chance without having clear understanding on why it resolves the issue for me.
At first i was using the .files method, but noticed that it returns a Set<File>, when .elements returns lazy Provider, which is today's preferable approach for working with files in gradle (afaik).
Using the .elements have some risks / downsides?
Maybe some explanation on difference between fileTree and fileTree.elemets can shed some light and give me confidence in the solution i come up with.
And thanks for attention!

Using the .elements have some risks / downsides?

I'm not aware of any, but as you said, it should be the preferable approach.

Maybe some explanation on difference between fileTree and fileTree.elemets can shed some light and give me confidence in the solution i come up with.

Unfortunately, it not documented very well and I don't have a good response for this, sorry.


text:
Document dependency verification udpate process

Follow up on #18769

@bot-gradle test this

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

@bot-gradle test this

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

@bot-gradle test this

@bot-gradle test and merge

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

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

authors: bot-gradle ljacomet


text:
Publish 8.1-20230329050757+0000

Publish 8.1-20230329050757+0000

@bot-gradle test and merge

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

I've triggered a build for you.


text:
DefaultGradleEnterprisePluginAdapter is not a service

The adapter carries state and is referenced by the manager. It is not a service in the sense that it can be re-created in a stateless way when firing up the remaining services.
The configuration cache would not use serialization to restore a service, but use the existing service since it assumes the service is stateless.
This change allows to annotate all the Gradle enterprise services with the correct service scope.

@bot-gradle test and merge

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

authors: bot-gradle wolfs


text:
Disambiguate overloads with/without lambdas based on call site lambda presence

Fixes https://github.com/gradle/gradle-private/issues/4116

@bot-gradle test and merge

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


text:
Remove Groovy compiler bug workaround

Since we've upgraded to Groovy 2.5.2, we don't need to prefix fields with _ to avoid hitting https://issues.apache.org/jira/browse/GROOVY-8732
This reverts parts of https://github.com/gradle/gradle/pull/6218

I think we should remove those as well. I mean, they are private fields, so why would user code be able to access them (save for the compiler bug that was just fixed)? I've added a commit to change them back to non-surprising names.

@wolfs PTAL.


text:
Update-otel-packages

Why
Upgrade Otel packages
What

Upgrade Otel packages
Fix test because data types for startTimeUnixNano and endTimeUnixNano have changed to IFixed64.

Checklist

[x] Tests added
[ ] Changelog updated
[ ] Documentation updated

To many problems with --latest upgrade.
Updating minor and patch versions for now

repo: grafana/faro-web-sdk


text:
Setting basicAuthPassword in provisioned datasource.yaml doesn't work

What happened:
I'm trying to configure a datasource for opensource from the provisioning folder in the same way, I did before with the Elasticsearch provider. In the datasources.yaml I have the following configuration
- name: BU-ELK
  type: grafana-opensearch-datasource
  access: proxy
  url: "https:/....."
  basicAuth: true
  basicAuthUser: "grafana"
  basicAuthPassword: "mypassword"
  jsonData:
    database: "[bu-k8s-logs-]YYYY.MM.DD"
    interval: Daily
    timeField: "@timestamp"
    version: "1.0.0"
    flavor: "opensearch"

The datasource with all fields will be read correctly except basicAuthPassword. This field will be shown empty in the configuration editor and that's why the connection test fails. Since the connection was created automatically, I can not change the password. When I configure a datasource manually with a password, the connection works fine.
What you expected to happen: The predefined password should be used and the connection should work.
Anything else we need to know?:
I also tried to move the basicAuthPassword to the jsonData but with the same result.
Environment:

Grafana version: 9.5.15
OpenSearch version: 2.11.1
Plugin version: 2.14.3

I found the configuration hint here: https://grafana.com/docs/grafana/latest/administration/provisioning/
The basicAuthPassword has to be configured in the secureJsonData section.

repo: grafana/opensearch-datasource


text:
Cannot build: failed to verify certificate

When running the documented command:
docker run --rm -it -u "$(id -u):$(id -g)" -v "${PWD}:/xk6" grafana/xk6 build v0.43.1 \
  --with github.com/mostafa/xk6-kafka@v0.17.0 \
  --with github.com/grafana/xk6-output-influxdb@v0.3.0

It fails because of SSL validation.
2024/05/06 17:31:07 [INFO] Temporary folder: /tmp/buildenv_2024-05-06-1731.563602991
2024/05/06 17:31:07 [INFO] Initializing Go module
2024/05/06 17:31:07 [INFO] exec (timeout=10s): /usr/local/go/bin/go mod init k6
go: creating new go.mod: module k6
2024/05/06 17:31:07 [INFO] Pinning versions
2024/05/06 17:31:07 [INFO] exec (timeout=0s): /usr/local/go/bin/go mod edit -require github.com/mostafa/xk6-kafka@v0.17.0
2024/05/06 17:31:07 [INFO] exec (timeout=0s): /usr/local/go/bin/go mod tidy -compat=1.17
go: downloading github.com/mostafa/xk6-kafka v0.17.0
go: k6 imports
	github.com/mostafa/xk6-kafka: github.com/mostafa/xk6-kafka@v0.17.0: verifying module: github.com/mostafa/xk6-kafka@v0.17.0: Get "https://sum.golang.org/lookup/github.com/mostafa/xk6-kafka@v0.17.0": tls: failed to verify certificate: x509: certificate signed by unknown authority
2024/05/06 17:31:08 [INFO] Cleaning up temporary folder: /tmp/buildenv_2024-05-06-1731.563602991
2024/05/06 17:31:08 [FATAL] exit status 1

It appears the images CA certificates are out of date.

False alarm. Cisco Umbrella is being a man in the middle https://stackoverflow.com/a/68333945/185316


text:
Upgrade tag ?

Hello  @grainrigi ;) could it be possible to create a tag 1.1.0 & publish on npm (https://github.com/grainrigi/async-singleton/issues/2) ? Thanks a lot

Sorry, I've forgot to do that.
Please use 1.1.1. (I accidentally published old build for 1.1.0)

Thanks a lot

authors: Alahel grainrigi

repo: grainrigi/async-singleton


text:
Transform/OffsetToZero function

Would it be possible to offer/implement Transform/OffsetToZero http://graphite.readthedocs.io/en/latest/functions.html#graphite.render.functions.offsetToZero?
https://github.com/grafana/grafana/issues/5230

I assume you mean in the 0.9.x branch. In that case, no. If you need it I encourage you to try running from the master branch instead. It's actually quite stable and our current focus is preparing a 1.0 release.

Ahh, thanks for the information! It confuses me that when I follow the link to the documentation
http://graphite.readthedocs.io/
that per default the documentation of an unreleased version is displayed. Usually such a link redirects to the latest stable release version instead.
Another idea would be to note the version number next to the descriptions of the funktions under /functions.html (e.g. "since 0.10.0 – UNDER DEVELOPMENT", "since 0.9.15")

authors: klaffke obfuscurity

repo: graphite-project/graphite-web

license_source: bigquery


text:
Implement uniqueNames() for issue #1779

I guess the code for issue 1779 would look something like this. :)

Current coverage is 66.55% (diff: 100%)

Merging #1780 into master will increase coverage by 0.04%

@@             master      #1780   diff @@
==========================================
  Files            55         55
  Lines          6276       6285     +9
  Methods           0          0
  Messages          0          0
  Branches       1247       1250     +3
==========================================
+ Hits           4174       4183     +9
  Misses         1878       1878
  Partials        224        224

Powered by Codecov. Last update 73bc058...61ca12e

I like this in general, but I would prefer to call it uniqueSeries or simply unique.
Should the function attempt to do any reconciliation of series with different contents (or determine preference)?

refs #1779

Hello @yati-sagade,
Would you mind to rename your function to unique? It will have nice match with grep, exclude etc.

Closing in favor of #2063

authors: DanCech TvdW codecov-io deniszh obfuscurity


text:
Should be able to sort by multiple fields

Do you want to request a feature or report a bug?
feature
What is the current behavior?
Ordering is possible just by one field.
What is the expected behavior?
Should be able to sort by multiple fields just like SQL's ORDER BY clause.

See also https://dba.stackexchange.com/q/271601/5061 on the implementation (also in issue #1809).

repo: graphprotocol/graph-node


text:
runtime: big_int_to_hex prints in big endian and trims zeros

Resolves #481

@Jannis I believe we store BigInts as decimal strings, so I don't think this would apply.


text:
Incompatibility with CxxWrap 0.15.0+

Code generated with WraptIt! is not compatible with CxxWrap 0.15.0 due to the new support of default value and name for function argument, that changes how constructor must be declared: call to constructor<...>(false/true) must be replaced by constructor<...>(jlcxx::finalize_policy::no/jlcxx::finalize_policy::yes). In addition, the build system used in test/ can examples can lead to inconsistency between CxxWrap version used to build the shared library and the one used to run the test or the example, the two being updated independently: the code build processes uses the  buildtools project directory.

Fixed in releases v1.3.0 and above.

repo: grasph/wrapit


text:
run Gratipay 147

146

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/10037521-run-gratipay-147?utm_campaign=plugin&utm_content=tracker%2F85909&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F85909&utm_medium=issues&utm_source=github).

Reviewed 49 (45) accounts.

Backup taken and verified.

Droplet spun up and updated.

Script started.

Script ran for 14 minutes (0:14:10.521195).

Pinned https://twitter.com/Gratipay/status/581075525235580930.

Log downloaded and droplet destroyed.

MassPay done for 87 users.

Logs uploaded in https://github.com/gratipay/logs/commit/10be449d2ba217ed6eea9d834b7c30281075e5be.

MassPay posted back.

Escrow shuffled.

license: mit


text:
fix: multi oauth plan selection

Issue
https://github.com/gravitee-io/issues/issues/8460

🚀 CI was able to deploy the build of this PR, so you can now try it directly here
Notes: The deployed app is linked to the management API of APIM master. (Same login and password as APIM master)

📚  View the storybook of this branch here

⚠ Wait before merging this PR

authors: gaetanmaisse jhaeyaert

repo: gravitee-io/gravitee-api-management


text:
feat(elasticsearch) add rest support

Use rest API to call Elasticsearch

Replaced by https://github.com/gravitee-io/gravitee-repository-elasticsearch/pull/23

authors: GuillaumeWaignier brasseld


text:
Barracuda Kit

LGTM

repo: gravwell/kits


text:
Remove duplicate entries in banned API list

The obstack_object_size() and va_start() calls were listed twice as banned functions for seemingly no reason.

I just noticed you have a PR here. We should merge gpos to orca as early as possible. It was almost forgotten by people.

Agreed, gpos should be merged into orca as soon as possible. Closing this since #35 kills the need for this PR.

authors: danielgustafsson hsyuan

repo: greenplum-db/gpos


text:
Version 3.0 is not published on Maven

It seems like the latest published version is 3.0.0-beta1 instead of 3.0.0.  Could you please release it on maven?
Thanks.
http://mvnrepository.com/artifact/de.greenrobot/eventbus/3.0.0-beta1

Awesome! Thanks.

repo: greenrobot/EventBus


text:
EventBus posts to a subscriber which is removed during post process.

Stackoverflow question
While using EventBus, I have faced an unexpected situation that a subscription method of a Fragment is called one time even after the Fragment is unregistered.
Scenario is like this. I have an Activity containing a layout which any Fragment can be put. The Activity starts with a certain Fragment.
The Activity and the Fragment register themselves on their onResume() and unregister on onPause(). They have their own handlers for each for an event of same type.
By a dispatched event, the Activity replaces the Fragment with another by some condition. Then, the Fragment's onPause() gets called during removal process and EventBus.getDefault().unregister(this) is also executed.
Here, then, I expect the Fragment's handler not to be called from now. BUT it is called one time right after the Fragment is unregistered.
It seems like that EventBus doesn't handle the case of any subscriber is unregistered while event posting process.

As the event was submitted on the main thread before the unregister call, and is to be received on the same (main) thread, the event will be posted to all subscribers that exist at the moment, yes.
If you do not want the event to be handled if your fragment is paused, you might check for !isResumed() before handling the event.
Or post the event on a thread different from the main thread and change to @Subscribe(threadMode = ThreadMode.MAIN). Because if the posting and receiving thread are different, the subscription will be checked again before invoking the subscriber method.
The relevant code is at EventBus.postSingleEventForEventType(). @greenrobot Can this be allowed?

Tracking this further with #307 which has a potential fix.

authors: greenrobot-team neokim


text:
#147 On zoom out and zoom in there is a flicker of white space.

Fixes #147
video
https://github.com/greensopinion/flutter-vector-map-tiles/assets/16399272/d82903f0-94dd-4077-9977-09c833f9c37f

thanks for the PR. Can you describe the issue and how this PR fixes it? It's not clear to me from the video what is happening or from the code how it's related. Thanks!

No problem, I've been on vacation too.
What are the memory and CPU implications of this change? I ask because including more tiles means doing more computations on the UI thread, which can introduce jank.

Indeed it increases Jank. I Guess I'll have to find another solution to improve rendering time.

authors: greensopinion sikandernoori

repo: greensopinion/flutter-vector-map-tiles


text:
fix(schedules): Fix update scenario schedule method

Fix the update scenario schedule method as described in api documentation : https://app.gremlin.com/api#/schedules/updateScenarioSchedule
Method signature is PUT

Closing, as this has been pulled in elsewhere.

authors: sewhyte xdumas-so

repo: gremlin/gremlin-python


text:
FeatureRequest

感谢分享项目！想请教一下，直接把这些文件夹拷到新机器的话，能确保消息记录迁移到新机器么？

感谢分享项目！想请教一下，直接把这些文件夹拷到新机器的话，能确保消息记录迁移到新机器么？

你指的新机器是手机还是电脑？

感谢分享项目！想请教一下，直接把这些文件夹拷到新机器的话，能确保消息记录迁移到新机器么？

你指的新机器是手机还是电脑？

华为harmonyOS或者安卓手机，拷贝覆盖com.tecent.mm，会不会跟imei起啥问题？

感谢分享项目！想请教一下，直接把这些文件夹拷到新机器的话，能确保消息记录迁移到新机器么？

你指的新机器是手机还是电脑？

华为harmonyOS或者安卓手机，拷贝覆盖com.tecent.mm，会不会跟imei起啥问题？

转移不了的，微信数据库不同手机加密密钥都是不一样的

多谢，那这个加密目前是会随时更改么？还是说可以按照对应版本进行加密然后注入？

authors: greycodee shouldsee

repo: greycodee/wechat-backup


text:
GhotBypasser [OSS Project Appication]

You are applying for OSS program

[X] Yes my project is OSS licensed and open to public.

Repository URL to your project
https://github.com/megz15/ghotbypasser/
URL to your website
https://megz15.github.io/ghotbypasser/ (it's not up yet)
Expected Quota of usage
Hmm, probably around 2000 per day max
Details
- Category: Education
- License: MIT
- Date of release: 15/01/2023

Anything else?

This project will be really helpful for me and my friends, we are in uni and the prescribed books have difficult problems. Some of the solutions are on Chegg and similar sites but they are unfortunately behind paywalls.

Hi @megz15 . Thank you for your application.
I have a good feeling about your project!
Please email me with subject "cors.sh OSS - #" to universe@grida.co.
I'll send you an api key on that thread.
Thank you and happy hacking


text:
Dynamic g-image tags are not lazy loaded

Description
Fetching data from Contentful and dynamically creating <g-image /> tags in a for loop disables lazy loading. All images created this way are loaded immediately on page load, whether they are in the viewport or not.
Steps to reproduce
Here is a repo demonstrating this bug. There are 2 pages, on the home page its demonstrating the <g-image> bug, and on the on the /about page I added a different image lazy loader and these images are lazy loaded correctly. This may help to solve the issue with <g-image>
Expected result
What should happen?
I expect the images to not load with the page unless they are in the viewport. The images should lazy load, just like they do if you create a <g-image> tag with a static image
Actual result
What happened.
The images created from the fetched Contentful data are not lazy loaded. They are loaded with the inital page load, heavily impacting performance and SEO scores (in case there are a lot of images it can get really bad)
Environment
Paste the information here as shown by gridsome info
System:
OS: Linux 5.4 Ubuntu 18.04.4 LTS (Bionic Beaver)
CPU: (8) x64 Intel(R) Core(TM) i7-4700HQ CPU @ 2.40GHz
Binaries:
Node: 10.19.0 - ~/.nvm/versions/node/v10.19.0/bin/node
Yarn: 1.22.4 - /usr/bin/yarn
npm: 6.14.5 - ~/.nvm/versions/node/v10.19.0/bin/npm
Browsers:
Chrome: 84.0.4147.89
Firefox: 78.0.2
npmPackages:
@gridsome/source-contentful: ^0.5.3 => 0.5.3
gridsome: ^0.7.0 => 0.7.19
npmGlobalPackages:
@gridsome/cli: 0.3.3
Note about environment: This happens to my colleagues who use a Macbook and Windows 10. It also happens on a production website
Note about me adding API keys in the repo: I don't care, I created this account solely for the purpose to demonstrate this bug.

I don't know if the <g-image> component is actually made for this purpose. I think it would make more sense to use the g-image directive in this case.
<template>
   ...
   <img
      :data-src="url"
      :data-srcset="srcset"
      :data-sizes="sizes"
      v-image
   />
   ...
</template>

<script>
import Image from "gridsome/app/directives/image";

export default {
  ...
  directives: {
    image: Image,
  },
  ...
}
</script>

Unfortunately this is not working correctly now if you use it without data-srcset and data-sizes.
A change in gridsome/app/directives/image.js would prevent this:
function loadImage(el) {
  ...
  if (srcset) el.srcset = srcset;
  if (sizes) el.sizes = sizes;
  ...
}

Thank you for your reply helloiamlukas. Could you please explain why would it make more sense using the directive instead of a component?
And if the <g-image> component was not meant for this use case, I think it should be mentioned in the docs - although honestly it doesn't make sense to me why it shouldn't work in this case. Outputting images dynamically from API data is not that uncommon. It is also obviously possible since the v-lazy-image can do this out of the box

As far as the documentation states, <g-image> is mainly to output progressive images. Lazy loading is just a part of this. That's why I thought the directive might be a good choice in your case.
But I agree with you that <g-image> could also do this out of the box. Maybe @hjvedvik can join this discussion?

I see, thank you for clarifying.
I think lazy loading dynamic images from an API would be a nice addition then - although I would kinda understand if the gridsome team disagrees. In case they disagree, I think it would be important to point that out in the docs.
For example, there is this alert stating only local images with relative URL paths will be compressed

📣 Only local, relative image paths will be compressed by Gridsome.

Maybe changing to something like this would be really informative

📣 Only local, relative image paths will be compressed and lazy lodaded by Gridsome.

@helloiamlukas Yes, I agree. We should let g-image lazy load external images since Gridsome already has the ability to do it built-in. Right now it's only possible by passing a special object as the src property, which is very inconvenient. That object is created automatically for local images. But I think it would be much better if we could do something like this manually:
<g-image
  placeholder="data:image/svg+xml,......." <!-- or a URL to a super small image -->
  src="https://url.to/large-image.jpg"
  srcset="https://url.to/medium-image.jpg 480w, https://url.to/large-image.jpg 800w"
  sizes="(max-width: 600px) 480px, 800px"
/>

@hjvedvik That would be pretty awesome. And at the same time could we allow to disable srcsets? Maybe with :srcset="false" or :sizes="false"?

@hjvedvik That would be pretty awesome. And at the same time could we allow to disable srcsets? Maybe with :srcset="false" or :sizes="false"?

@hjvedvik Submitted a PR that makes this one work:
<g-image :src="{
        src: 'https://picsum.photos/200/300',
        size: {width: 200, height: 300},
        dataUri: 'data:image/gif;base64,R0lGODlhAQABAIABAP///wAAACwAAAAAAQABAAACAkQBADs=', // http://probablyprogramming.com/2009/03/15/the-tiniest-gif-ever
}" />

So, the above makes it easier to use g-image's lazy-loading feature for e.g. external images, but the main problem pointed out in this issue is the pre-processing/compression of local but dynamic assets.
I stumbled into this when adding local images in a loop, as seen in the OP's repo:
https://github.com/luka-bacic/reproduction-g-image-bug/blob/master/src/components/DynamicPictures.vue#L6
(in my case even with a static range: v-for="i in range(1, 32)")
My question is: is it possible to get the amazing pre-processing & responsiveness features of g-image also for dynamic src attributes?
Can someone maybe point me to how the images are pre-processed? I figured out the basic functionality of the AssetsQueue, but not why the dynamic rendered ones would not be added to the queue when the HTML is rendered at build time?

authors: baernholdt-jf helloiamlukas hjvedvik luka-bacic tennox

repo: gridsome/gridsome


text:
WebLoader load call fails on URL with empty content

Describe the bug
The webloader fails on a web page that has valid html but no content. Can happen for certain pages. For example I passed in the URL for a page that had the following html -
<meta http-equiv='refresh' content='0;url=/?_cookiecheck=1' />

I was passing in multiple links using the load_collection call provided by the WebLoader and the entire call failed because of this one page.

@zenofsahil can you please share the error output?

In [19]: WebLoader().load("https://page.com")
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Cell In[19], line 1
----> 1 WebLoader().load("https://page.com")

File ~/Desktop/griptape/.venv/lib/python3.11/site-packages/griptape/loaders/web_loader.py:13, in WebLoader.load(self, url, include_links)
     12 def load(self, url: str, include_links: bool = True) -> list[TextArtifact]:
---> 13     return self._load_page_to_artifacts(url, include_links)

File ~/Desktop/griptape/.venv/lib/python3.11/site-packages/griptape/loaders/web_loader.py:22, in WebLoader._load_page_to_artifacts(self, url, include_links)
     21 def _load_page_to_artifacts(self, url: str, include_links: bool = True) -> list[TextArtifact]:
---> 22     return self.text_to_artifacts(self.extract_page(url, include_links).get('text'))

File ~/Desktop/griptape/.venv/lib/python3.11/site-packages/griptape/loaders/web_loader.py:44, in WebLoader.extract_page(self, url, include_links)
     42     raise Exception("can't access URL")
     43 else:
---> 44     return json.loads(
     45         trafilatura.extract(
     46             page,
     47             include_links=include_links,
     48             output_format="json",
     49             config=config
     50         )
     51     )

File ~/homebrew/Cellar/python@3.11/3.11.4_1/Frameworks/Python.framework/Versions/3.11/lib/python3.11/json/__init__.py:339, in loads(s, cls, object_hook, parse_float, parse_int, parse_constant, object_pairs_hook, **kw)
    337 else:
    338     if not isinstance(s, (bytes, bytearray)):
--> 339         raise TypeError(f'the JSON object must be str, bytes or bytearray, '
    340                         f'not {s.__class__.__name__}')
    341     s = s.decode(detect_encoding(s), 'surrogatepass')
    343 if (cls is None and object_hook is None and
    344         parse_int is None and parse_float is None and
    345         parse_constant is None and object_pairs_hook is None and not kw):

TypeError: the JSON object must be str, bytes or bytearray, not NoneType

Have substituted the actual URL and provided the HTML in the message above.

authors: collindutter zenofsahil

repo: griptape-ai/griptape


text:
Consider running detekt on all kotlin files

Detekt is currently setup using the gradle plugin which means that it's easy to run it on files matching something like src/**/*.kt.
This excludes *.kts files and anything in buildSrc. It would be good to run detekt on those files too.

There are two existing GH actions for detekt, one which installs it, and the other which runs it in a Docker container.
The problem with using either of those is choosing which version of detekt to run. The version is set in the gradle build,
and any way of getting that value out of the build files will be hacky at best.
A possible solution is to write a gradle task to download the cli version of detekt from GH releases, getting the version number
from the gradle build.

repo: grodin/map-librarian


text:
🛑 Secret Site is down

In 1fcabbc, Secret Site ($RECREO_SITE) was down:

HTTP code: 405
Response time: 217 ms

Resolved: Secret Site is back up in b861601.

repo: grodrigo/upptime


text:
Getting URLResolve Error after choosing a server.

Getting URLResolve Error after choosing a server. Can't play any episodes.

Update to latest ResolveURL should fix it. If there’s still an issue then it’s on your end. Perhaps ISP blocking.

authors: Jerry-Dragon groggyegg


text:
Add examples

Provide complete coverage of the benchit feature set with one example per feature. Document the examples with a readme file.
Note: don't start this work until the benchit feature set stabilizes.

@danielholanda said: https://github.com/groq/mlagility/pull/44#discussion_r1093695644

repo: groq/mlagility


text:
better error reporting for timeouts; fix internal timeout api usage

I'm getting a timeout running the tests locally. I noticed that the timeout registration was broken. So, I fixed that, but I'm still not sure why I'm seeing a timeout here.
$ npm test

> webdriver-http-sync@1.0.0 pretest /home/sean/source/webdriver-http-sync
> npm run build

> webdriver-http-sync@1.0.0 build /home/sean/source/webdriver-http-sync
> npub prep && coffee -cbo lib src

> webdriver-http-sync@1.0.0 test /home/sean/source/webdriver-http-sync
> mocha

  Webdriver
PhantomJS is launching GhostDriver...
[INFO  - 2015-03-18T15:11:31.640Z] GhostDriver - Main - running on port 4499
    1) "before all" hook: create driver

  request
[INFO  - 2015-03-18T15:11:31.652Z] Session [0f249b10-cd81-11e4-a732-8f5dc8231bc4] - CONSTRUCTOR - Desired Capabilities: {"browserName":"phantomjs"}
[INFO  - 2015-03-18T15:11:31.652Z] Session [0f249b10-cd81-11e4-a732-8f5dc8231bc4] - CONSTRUCTOR - Negotiated Capabilities: {"browserName":"phantomjs","version":"1.9.0","driverName":"ghostdriver","driverVersion":"1.0.3","platform":"linux-unknown-64bit","javascriptEnabled":true,"takesScreenshot":true,"handlesAlerts":false,"databaseEnabled":false,"locationContextEnabled":false,"applicationCacheEnabled":false,"browserConnectionEnabled":false,"cssSelectorsEnabled":true,"webStorageEnabled":false,"rotatable":false,"acceptSslCerts":false,"nativeEvents":true,"proxy":{"proxyType":"direct"}}
[INFO  - 2015-03-18T15:11:31.652Z] SessionManagerReqHand - _postNewSessionCommand - New Session Created: 0f249b10-cd81-11e4-a732-8f5dc8231bc4
    ✓ sends a GET request
    ✓ sends a POST request

  2 passing (4s)
  1 failing

  1) Webdriver "before all" hook: create driver:
     Error: Assertion failed: Failed to start WebDriver session: Error: Request connection timed out after 2000ms to: http://127.0.0.1:4499/session
  at Object.callback (/home/sean/source/webdriver-http-sync/lib/request.js:101:22)
  at Object.CurlRequest.end (/home/sean/source/webdriver-http-sync/node_modules/http-sync/http-sync.js:86:34)
  at /home/sean/source/webdriver-http-sync/lib/request.js:103:18
  at module.exports (/home/sean/source/webdriver-http-sync/lib/session.js:48:14)
  at new WebDriver (/home/sean/source/webdriver-http-sync/lib/index.js:75:11)
  at Context.<anonymous> (/home/sean/source/webdriver-http-sync/test/driver.test.coffee:43:19)
  at callFn (/home/sean/source/webdriver-http-sync/node_modules/mocha/lib/runnable.js:266:21)
  at Hook.Runnable.run (/home/sean/source/webdriver-http-sync/node_modules/mocha/lib/runnable.js:259:7)
  at next (/home/sean/source/webdriver-http-sync/node_modules/mocha/lib/runner.js:268:10)
  at /home/sean/source/webdriver-http-sync/node_modules/mocha/lib/runner.js:284:7
  at done (/home/sean/source/webdriver-http-sync/node_modules/mocha/lib/runnable.js:222:5)
  at /home/sean/source/webdriver-http-sync/node_modules/mocha/lib/runnable.js:242:9
  at Socket.<anonymous> (/home/sean/source/webdriver-http-sync/test/driver.test.coffee:38:9)
  at Socket.emit (events.js:117:20)
  at Socket.<anonymous> (_stream_readable.js:765:14)
  at Socket.emit (events.js:92:17)
  at emitReadable_ (_stream_readable.js:427:10)
  at emitReadable (_stream_readable.js:423:5)
  at readableAddChunk (_stream_readable.js:166:9)
  at Socket.Readable.push (_stream_readable.js:128:10)
  at Pipe.onread (net.js:529:21)

Expected: 408
Actually: 200
    at error (/home/sean/source/webdriver-http-sync/node_modules/assertive/lib/assertive.js:441:12)
    at Object.assert.equal (/home/sean/source/webdriver-http-sync/node_modules/assertive/lib/assertive.js:105:15)
    at module.exports (/home/sean/source/webdriver-http-sync/lib/session.js:49:10)
    at new WebDriver (/home/sean/source/webdriver-http-sync/lib/index.js:75:11)
    at Context.<anonymous> (/home/sean/source/webdriver-http-sync/test/driver.test.coffee:43:19)
    at callFn (/home/sean/source/webdriver-http-sync/node_modules/mocha/lib/runnable.js:266:21)
    at Hook.Runnable.run (/home/sean/source/webdriver-http-sync/node_modules/mocha/lib/runnable.js:259:7)
    at next (/home/sean/source/webdriver-http-sync/node_modules/mocha/lib/runner.js:268:10)
    at /home/sean/source/webdriver-http-sync/node_modules/mocha/lib/runner.js:284:7
    at done (/home/sean/source/webdriver-http-sync/node_modules/mocha/lib/runnable.js:222:5)
    at /home/sean/source/webdriver-http-sync/node_modules/mocha/lib/runnable.js:242:9
    at Socket.<anonymous> (/home/sean/source/webdriver-http-sync/test/driver.test.coffee:38:9)
    at Socket.emit (events.js:117:20)
    at Socket.<anonymous> (_stream_readable.js:765:14)
    at Socket.emit (events.js:92:17)
    at emitReadable_ (_stream_readable.js:427:10)
    at emitReadable (_stream_readable.js:423:5)
    at readableAddChunk (_stream_readable.js:166:9)
    at Socket.Readable.push (_stream_readable.js:128:10)
    at Pipe.onread (net.js:529:21)

npm ERR! Test failed.  See above for more details.
npm ERR! not ok code 0

This was a phantomjs version issue. After updating to 1.9.8, the tests pass for me locally.

@jkrems fixes timeout usage from https://github.com/groupon-testium/webdriver-http-sync/pull/26

LGTM! I think the previous behavior was to throw an error instead of creating a fake response. I don't feel strongly either way. What was your reason for the faux response?

Ah, yes. That was the previous behavior.
This behavior makes the error more obvious while still including a lot of detail. I also don't feel strongly about it, though.

The problem I see here is that it's possible to ignore errors (or rather: miss errors). E.g. if something just calls the POST /session/xy/input and does not explicitly check the status code, it will silently fail. Maybe a gofer-style error with httpHeaders/body properties would make sense? Same information available but it can't be missed by accident?

Ah, I was using it to throw an error in a different location (in src/session), but yes, this will also possibly hide an error from the library user, which is bad.

Switching timeouts to throw errors instead. Added a test for it.

:shipit:

1.1.0

authors: EndangeredMassa jkrems

repo: groupon-testium/webdriver-http-sync


text:
feat: adding release workflow

Description
adding helper packages for lerna

:tada: This PR is included in version 1.0.0 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

repo: growcss/growcss


text:
FAILED: cloud_to_prod_auth:gateway_v4:python:per_rpc_creds

failed with unavailable
2017-08-16 14:03:49,987 running run_interop
Traceback (most recent call last):
  File "src/python/grpcio_tests/setup.py", line 102, in <module>
    test_runner=TEST_RUNNER,)
  File "/usr/lib/python2.7/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/var/local/git/grpc/src/python/grpcio_tests/commands.py", line 184, in run
    self.run_client()
  File "/var/local/git/grpc/src/python/grpcio_tests/commands.py", line 200, in run_client
    client.test_interoperability()
  File "/var/local/git/grpc/src/python/grpcio_tests/tests/interop/client.py", line 126, in test_interoperability
    test_case.test_interoperability(stub, args)
  File "/var/local/git/grpc/src/python/grpcio_tests/tests/interop/methods.py", line 480, in test_interoperability
    _per_rpc_creds(stub, args)
  File "/var/local/git/grpc/src/python/grpcio_tests/tests/interop/methods.py", line 420, in _per_rpc_creds
    response = _large_unary_common_behavior(stub, True, False, call_credentials)
  File "/var/local/git/grpc/src/python/grpcio_tests/tests/interop/methods.py", line 138, in _large_unary_common_behavior
    response = response_future.result()
  File "/var/local/git/grpc/py27/local/lib/python2.7/site-packages/grpc/_channel.py", line 279, in result
    raise self
grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with (StatusCode.UNAVAILABLE, Endpoint read failed)>

2017-08-16 14:03:49,988 FAILED: cloud_to_prod_auth:gateway_v4:python:per_rpc_creds [ret=1, pid=28735]

sponge log is in https://kokoro.corp.google.com/job/grpc/job/ubuntu/job/pull_request/job/grpc_interop_toprod/1139/

Based on the status code, I think it's a duplicate of #12204

authors: adelez apolcyn

repo: grpc/grpc


text:
HoloLens and gRPC

I was trying to develop an application in HoloLens using Unity but it does not work. I followed the steps detailed in https://github.com/grpc/grpc/tree/master/src/csharp/experimental to use gRPC in Unity (grpc_unity_package.1.17.0-dev.zip). The application works in Unity Editor (version 2018.2.8f1). However, when I build the application in Unity to generate the Visual Studio Solution for HoloLens I get some errors such as:
Reference rewriter: Error: type System.AppDomain doesn't exist in target framework. It is referenced from Grpc.Core.dll at System.Void Grpc.Core.GrpcEnvironment/ShutdownHooks::Register().
UnityEngine.Debug:LogError(Object)
PostProcessWinRT:RunReferenceRewriter() (at C:/buildslave/unity/build/PlatformDependent/MetroPlayer/Extensions/Managed/PostProcessWinRT.cs:1058)
PostProcessWinRT:Process() (at C:/buildslave/unity/build/PlatformDependent/MetroPlayer/Extensions/Managed/PostProcessWinRT.cs:208)
UnityEngine.GUIUtility:ProcessEvent(Int32, IntPtr)
Any idea to solve this problem?

In Unity, the SDK for the Universal Windows Platform selected was 10.0.16299.0

With urhosharp we were able to use grpc on the hololense. You might want to try that out.

@vgarciavazquez  interesting. The target framework used by gRPC C# Unity support is net45, so the type System.AppDomain, should be available, because it's part of net45.

authors: AtosNicoS jtattermusch vgarciavazquez


text:
Unable to install grpc gem with JRuby

The glcoud-ruby project has an issue opened by a user (GoogleCloudPlatform/gcloud-ruby#712) that is unable to install the latest version due to the dependencies on the grpc and google-protobuf gems not installing on jruby. I am not able to get the grpc gem to install on my mac using versions 9.1.1.0 or 9.0.0.0. I have the latest libgrpc installed, using both homebrew and built from source.
Here is the install on mac:
$ ruby -v
jruby 9.1.1.0 (2.3.0) 2016-05-19 fe84e89 Java HotSpot(TM) 64-Bit Server VM 25.91-b14 on 1.8.0_91-b14 +jit [darwin-x86_64]

$ gem install --ignore-dependencies grpc
Fetching: grpc-0.14.1.gem (100%)
Building native extensions.  This could take a while...
ERROR:  Error installing grpc:
    ERROR: Failed to build gem native extension.

    current directory: /Users/blowmage/.gem/repos/jruby-9.1.1.0-grpc/gems/grpc-0.14.1/src/ruby/ext/grpc
/Users/blowmage/.rubies/jruby-9.1.1.0/bin/jruby -r ./siteconf20160524-43017-endf8.rb extconf.rb
NotImplementedError: C extensions are not supported
    <top> at /Users/blowmage/.rubies/jruby-9.1.1.0/lib/ruby/stdlib/mkmf.rb:1
  require at org/jruby/RubyKernel.java:944
   (root) at /Users/blowmage/.rubies/jruby-9.1.1.0/lib/ruby/stdlib/rubygems/core_ext/kernel_require.rb:1
    <top> at extconf.rb:30

extconf failed, exit code 1

Gem files will remain installed in /Users/blowmage/.gem/repos/jruby-9.1.1.0-grpc/gems/grpc-0.14.1 for inspection.
Results logged to /Users/blowmage/.gem/repos/jruby-9.1.1.0-grpc/extensions/universal-java-1.8/2.3.0/grpc-0.14.1/gem_make.out

Strangly enough, it does install on linux! Here is that install:
$ ./bin/jruby -v
jruby 9.1.1.0 (2.3.0) 2016-05-19 fe84e89 OpenJDK 64-Bit Server VM 24.95-b01 on 1.7.0_95-b00 +jit [linux-x86_64]

$ gem install --ignore-dependencies grpc
Building native extensions.  This could take a while...

As far as I know, we haven't done any work to get the gem working on jruby, and frankly, I'm surprised that it work at all.

Well, I said it installed, not worked. :wink: We are also blocked by the fact that google-protobuf fails to install.

The primary issue here is that the library is built on a C extension which uses a variety of Ruby C APIs. I don't think that is supposed to work with jruby.

I believe that sufficiently modern jruby supports C extensions with sufficiently modern versions of OpenJDK

Ahh, well that explains that!

@raggi looking into this, but as far as I can see jruby support for the mri-c extensions was tried earlier on but deprecated in jruby 1.7.0

My understanding is that support for native C extensions are back in JRuby 9000, which is probably all anyone needs to worry about any more as the 1.7.x series is being end-of-lifed at the end of this year.

Hi,
Any update on this issue ?

Is the C extensions issue still blocking progress on this? Has a ruby wrapper around the Java client jar been considered?

@JasonLunn at least in the near-future I unfortunately it's not currently on the road map. With the large amount of c-extension code in the gem, wrapping the java client should be pretty involved - basically a reimplementation.
The truffle solution interpreted-C-extension might be an option but I'm not sure about the consequences - the core functionality of the grpc-ruby is pretty much all a C-library.

@apolcyn: Assume for the purposes of argument that I was willing to try to create such a wrapper around grpc-java, since I'm not able to switch to truffle in production any time soon. Would you want the PR to be submitted here, since this repository seems to own the Ruby gem, or would you want the PR submitted to the grpc-java? The goal in either case being not to create a new grpc-java gem that only works on JRuby, but to create a version of the grpc gem that has a platform of java?

I think this depends mostly on:

Are you looking for a drop-in replacement of the current grpc-ruby that can be used on the java ruby platform? E.g., API-compatible with grpc-ruby, don't have to regenerate grpc-related .proto files?

In this case this should probably go into grpc-ruby repo, as an addition to the grpc-ruby project. But this would also have to fit in to the same testing setup as grpc.

Is a grpc implementation that just works on jruby good enough? Has wrapping the grpc-java client from within jruby "app-level" code been considered?
The main work that the grpc-ruby C extensions do is wrap the grpc C-core library. This could potentially also be wrapped with JNI, and then possibly a lot of the grpc-ruby "pure-ruby" code could be reused in that way.

For 1) and 2), these should be introducing fairly big changes to the grpc-ruby project. Just to save going down the wrong direction, could you please provide a proposal before the PR?

note though that an addition to grpc-ruby like this might be difficult to bring in, just because of the overall complexity it might add.

Or you can use extract the C extension + some light wrapper code into a grpc-ruby-ext gem which grpc gem depends on only for CRuby platform. For java platform it can depend on grpc-java-ext which implements the same API wrapper and can live in the grpc-java codebase.
I'm working on a project which uses Google Cloud APIs and I would like to use run on JRuby, too. It would be nice if the JRuby version would support the same grpc API without any code change.

also @JasonLunn if a plan was created it would probably fit into grpc project-wide proposals. see https://github.com/grpc/proposal

@apolcyn - what I'm looking for is the ability for Ruby dependency management tools like bundler to Do the Right Thing™ when higher level gems (like google-cloud-datastore for example) express a dependency on the grpc gem under a JRuby interpreter. From the perspective of the Gemspec, the approach that the Google Protobuf took is near ideal for my purposes: when executed on the JRuby interpreter, include the jar file rather than the C implementation files. In Protobuf's case, the job of getting your hands on the jar is a little bit more straightforward as it is built from the same repo as ruby gem, but there already exist tools to leverage Maven dependencies from JRuby rather than store the jar binary alongside the ruby source. From there it is about building a shim over the Java implementation (to the extent necessary) to provide Ruby API compatibility.

I took a stab at writing a proposal, @apolcyn - see the PR
Any feedback would be appreciated.
CC: @teodor-pripoae @blowmage

@apolcyn what is the status of this issue?

I'll close this since I don't think there will be any action on this from grpc team. If there's progress on this, I suspect it would come as an open source contribution; (I believe @JasonLunn has made some progress here).

authors: JasonLunn apolcyn blowmage murgatroid99 muxi raggi teodor-pripoae


text:
Building grpc++ as dynamic library (DLL) with exported symbols for windows using bazel

Problem
Unable to use one instance of grpc library between different windows dynamic libraries in one application.
Example
Some application (client.exe) uses two dynamic libraries (a.dll and b.dll). Both dynamic libraries (a.dll and b.dll) contain different implementations of different grpc clients (generated by protoc.exe). Every dynamic library compiled with static grpc library (grpc++.lib) inside, and as result - every dynamic library (a.dll and b.dll) contain the same implementation of grpc++ static libraries. This is a problem, because the application after this contains duplicated implementation of grpc++ and fails with error in runtime.
Compilation grpc++ as dynamic library (DLL) resolves this problem because application loaded only once instance of grpc++ library.
About changes

Add rule for bazel 'grpc++_shared' to build grpc as a dynamic library with exported symbols.
Hide public static fields inside implementation and make accessors for that, because bazel can't export symbols of static fields (this fields are used in public headers and as result when we link grpc++.dll to other project we got 'unresolved external symbol' error. Accessors exported normally and fix this)

How to use
$ bazel build grpc++_shared.dll

So, the thing I am really worried with this kind of features is that memory management for Windows DLLs is fairly complicated. Crossing DLL boundaries for objects and other memory allocations is usually a bad idea, and the our C++ surface API doesn't attempt to guard in any way against such pattern - quite the contrary.

We understand that memory allocation across DLL boundaries in Windows is tricky business.
I expect Windows/C++ developers know this is a problem - and adopt sane discipline - if you allocate in a DLL, free in the same DLL.
The problem with the current situation is that it makes it simply impossible to use GRPC under Windows in C++ -- since pretty much all large-scale applications (especially client side) end up using DLLs.
Our modification includes 2 aspects:

Protecting access to static variables by wrapping them in getters/setters
The bazel build modifications to produce the Windows DLL

What I would like to ask is to at least merge the first aspect - this static var wrapping would not hurt anyone.
This way you make it easy for anyone to decide with which rope to hang themselves - we still can produce DLLs if we foolishly believe we can work with DLLs under Windows by just triggering the compilation option for this - but at least the codebase allows for it, without damage to anyone else who is not interested in running C++/DLLs.
I also would like to note this moment. The compilation of several static libraries (gpr, grpc, grpc++) occurs into one DLL (grpc++), so we always allocate and free memory inside one dynamic library.

I agree with you about the bundling together of the three libraries, but surely the surface API does delegate objects to the application, right? @vjpai

As we agree, we excluded from the pool request changes on bazel part for compilation of dlles.
Please, check and accept proposed change of encapsulation members to Getter/Setter methods.

Hi! @nicolasnoble & @ikishchenko , Do you have any follow ups on consuming grpc as dlls on windows? And could someone has similar requests as me point me to the right place to discuss this issue?

Hi! @nicolasnoble & @ikishchenko , Do you have any follow ups on consuming grpc as dlls on windows? And could someone has similar requests as me point me to the right place to discuss this issue?

We have been using GRPC as DLL for more than a year in production. No problems were detected.

@ikishchenko Is the fork that you use in production open source? Is it the master-winbuild on your fork of grpc or some other branch?
I am trying to do the same, build grpc as a dll, but it looks like I have to use bazel to build the dll (I saw the changes in one of your commits in this pull request). Is there also a CMakeLists with the same changes?

@ikishchenko Is the fork that you use in production open source? Is it the master-winbuild on your fork of grpc or some other branch?

I remove fork from my github account, but you can make patch from this pull request and apply it to actual version of GRPC. In production we use old grpc 1.14.x

I am trying to do the same, build grpc as a dll, but it looks like I have to use bazel to build the dll (I saw the changes in one of your commits in this pull request). Is there also a CMakeLists with the same changes?
For CMake: https://github.com/grpc/grpc/pull/14558

authors: Maxpeng92 bjayanth ikishchenko nicolasnoble


text:
Introduce grpc_slice_from_moved_string.

Suggested by @markdroth to avoid extra allocation and copy when it's not
needed.

This change is

Thank you @vjpai for the approval.
grpc_slice_from_moved_string is used in  the following files:
src/core/lib/http/httpcli.cc
120:                         grpc_slice_from_moved_string(std::move(addr_text))));
src/core/ext/transport/chttp2/transport/frame_rst_stream.cc
106:                             grpc_slice_from_moved_string(

Existing issues #18997

Thank you @vjpai !


text:
Resolve uninitialized warning in oauth2_credentials

The new code introduced in #19032 caused  "uninitialized" warning to token_lifetime. This change is to suppress the warning.

I think we should fix this down the stream in the call rather than cover it here?

@yang-g - In this particular function the only case for token_lifetime being uninitialized is when error != GRPC_ERROR_NONE, and in such case token_lifetime is not used anyway. So I don't think there's any risk covering up something in this change.

@muxi I thought if there is an error we should not even touch the token_lifetime?

I'm not sure I get what you mean by that

LGTM
after offline discussion.

Thanks everyone. Waiting for #19488 merge in to get required tests pass.

@muxi I have already fixed the broken test in #19493 can you please retry the test?
since #19488  requires an internal cherry-pick I'd be block to steal the pony, etc.

Ah I missed that. That's great thanks Soheil. Restarting the tests.

Sorry about that and thanks for the fix.

Basic Tests ObjC MacOS failure is #18542. Bazel RBE ASAN C/C++ can't be related. Interop tests failure is #19419

authors: jboeuf muxi soheilhy yang-g


text:
Clean up descriptor.upbdefs dependency of BUILD

Fixing #24904.
Idea here is removing descriptor.upbdefs.* from bazel build file because it conflicts with upb_lib_descriptor while keeping it in the non-bazel build configuration because they still need them.
In addition to this, some upb_lib_descriptor are fixed with upb_lib_descriptor_reflection (upbdef is for reflection)
Internal counterpart cl/346678433 got submitted.

Interestingly, when I try to build the latest version of this PR (using the repro mentioned in the issue), I get a different error:
bazel build //:grpc++ --spawn_strategy=local

results in
ERROR: /usr/local/google/home/jtattermusch/.cache/bazel/_bazel_jtattermusch/473402ebb46aca5e4ea9eb310c6f9e93/external/com_google_protobuf/BUILD:354:15: Generating upb protos for :descriptor_proto failed (Exit 1): protoc failed: error executing command bazel-out/host/bin/external/com_google_protobuf/protoc '--upb_out=bazel-out/k8-fastbuild/bin/external/com_google_protobuf' '--plugin=protoc-gen-upb=bazel-out/host/bin/external/upb/protoc-gen-upb' ... (remaining 2 argument(s) skipped)
bazel-out/k8-fastbuild/bin/external/com_google_protobuf/google/protobuf/descriptor.upb.c: Permission deniedTarget //:grpc++ failed to build
Use --verbose_failures to see the command lines of failed build steps.

@veblush  is that something you're seeing as well?

@jtattermusch Oh that's a good point. Thanks! I was able to reproduce this problem.
On master
$ bazel build :grpc++
ERROR: C:/cygwin64/home/kbuilder/grpc/BUILD:3188:1: undeclared inclusion(s) in rule '//:google_api_upbdefs':
this rule is missing dependency declarations for the following files included by 'src/core/ext/upbdefs-generated/google/protobuf/descriptor.upbdefs.c':
  'bazel-out/x64_windows-fastbuild/bin/external/com_google_protobuf/google/protobuf/descriptor.upbdefs.h'

On upb-descriptor
$ bazel build :grpc++
ERROR: C:/cygwin64/home/kbuilder/_bazel_kbuilder/7z4tdihz/external/com_google_protobuf/BUILD:354:2: Generating upb protos for :descriptor_proto failed (Exit 1)
bazel-out/x64_windows-fastbuild/bin/external/com_google_protobuf/google/protobuf/descriptor.upb.c: Permission deniedTarget //:grpc++ failed to build

After some tests, it appears that bazel 3.7 can build this only with this PR. I guess bazel 2.2 doesn't go well with @upb:descriptor_upb_proto_reflection. Bazel 3.7 still doesn't build gRPC without this PR, though so I assume that this will start working with the another PR bumping the version of Bazel to 3.7.

Although this is built well on Windows after upgrading Bazel to 3.7.1, it still doesn't work on Linux when building it with --spawn_strategy=local .
$ bazel clean --expunge

$ bazel build grpc++ --spawn_strategy=local --verbose_failures
INFO: Running bazel wrapper (see //tools/bazel for details), bazel version 3.7.1 will be used instead of system-wide bazel installation.
ERROR: /usr/local/google/home/veblush/.cache/bazel/_bazel_veblush/c4652c20fd8d5880d194bf82693e4fee/external/com_google_protobuf/BUILD:354:15: Generating upb protos for :descriptor_proto failed (Exit 1): protoc failed: error executing command
  (cd /usr/local/google/home/veblush/.cache/bazel/_bazel_veblush/c4652c20fd8d5880d194bf82693e4fee/execroot/com_github_grpc_grpc && \
  exec env - \
  bazel-out/host/bin/external/com_google_protobuf/protoc '--upb_out=bazel-out/k8-fastbuild/bin/external/com_google_protobuf' '--plugin=protoc-gen-upb=bazel-out/host/bin/external/upb/protoc-gen-upb' '--descriptor_set_in=bazel-out/k8-fastbuild/bin/external/com_google_protobuf/descriptor_proto-descriptor-set.proto.bin' google/protobuf/descriptor.proto)
Execution platform: @local_config_platform//:host
bazel-out/k8-fastbuild/bin/external/com_google_protobuf/google/protobuf/descriptor.upb.c: Permission deniedTarget //:grpc++ failed to build

$ ls -al bazel-out/k8-fastbuild/bin/external/com_google_protobuf/google/protobuf
total 228
drwxr-x--- 2 veblush primarygroup   4096 Dec 17 19:22 .
drwxr-x--- 3 veblush primarygroup   4096 Dec 17 19:22 ..
-rw-r--r-- 1 veblush primarygroup  16550 Dec 17 19:22 descriptor.upb.c
-r-xr-xr-x 1 veblush primarygroup  46180 Dec 17 19:22 descriptor.upbdefs.c
-r-xr-xr-x 1 veblush primarygroup   7271 Dec 17 19:22 descriptor.upbdefs.h
-rw-r--r-- 1 veblush primarygroup 145081 Dec 17 19:22 descriptor.upb.h

From the error logs, it appears that protoc failed to generate descriptor.upb.c because of permission. This is caused by the permission of descriptor.upb.c, rw- which blocks its modification.

It appears that this sometimes works. So this has some indeterministic factor involved. Presumably an order of building targets.
$ bazel clean --expunge

$ bazel build grpc++ --spawn_strategy=local --verbose_failures
INFO: Running bazel wrapper (see //tools/bazel for details), bazel version 3.7.1 will be used instead of system-wide bazel installation.
Target //:grpc++ up-to-date:
  bazel-bin/libgrpc++.a
  bazel-bin/libgrpc++.so

$ ls -al bazel-out/k8-fastbuild/bin/external/com_google_protobuf/google/protobuf
total 216
drwxr-x--- 2 veblush primarygroup   4096 Dec 17 21:16 .
drwxr-x--- 3 veblush primarygroup   4096 Dec 17 20:06 ..
-r-xr-xr-x 1 veblush primarygroup  16427 Dec 17 21:16 descriptor.upb.c
-r-xr-xr-x 1 veblush primarygroup  46180 Dec 17 21:16 descriptor.upbdefs.c
-r-xr-xr-x 1 veblush primarygroup   7271 Dec 17 21:16 descriptor.upbdefs.h
-r-xr-xr-x 1 veblush primarygroup 134803 Dec 17 21:16 descriptor.upb.h

This is my guess on what actually happened.
Upb has two types of code generating rules; upb_proto_library  and upb_proto_reflection_library. Both use the same code generator which happenes to generate *.upb.* and *.upbdefs.* at all time. As a result,  upb_proto_library(proto) will create proto.upb.* and proto.upbdefs.*.  upb_proto_reflection_library(proto) will do the same thing.
This should be fine when building with the sandbox spawn_strategy because each target has an isolated environment. But, it could go wrong with the local spawn_strategy because these two targets can share the same directory. Let's assume there is a target relying on upb_proto_library(descriptor) and upb_proto_reflection_library(descriptor). Bazel will execute following steps;

[G1] build upb_proto_library(descriptor): generates descriptor.upb.* and descriptor.upbdefs.* in the protobuf directory.
[G2] build upb_proto_reflection_library(descriptor): generates descriptor.upb.* and descriptor.upbdefs.* in the protobuf directory.

And bazel appears to make generated files which will be used actually later readonly. So it will work like for the target above

[M1] make descriptor.upb.* ready-only for upb_proto_library(descriptor).
[M2] make descriptor.upbdefs.* ready-only for upb_proto_reflection_library(descriptor).

This behavior making those files read-only can be observed from the files above with permission -r-xr-xr-x. These four steps's dependency is like [M1] -> [G1] and [M2] -> [G2] so there are a few of possible execution orders. And let's take a look at two possible cases.

[G1] [M1] [G2] [M2]: M1 step makes  descriptor.upb.* read-only so [G2] will fail.
[G1] [G2] [M1] [M2]: G1 and G2 happens before M1 and M2. It will succeed.

This is why it sometimes succeeds and sometimes fails. This explanation is consistent with the file log below.
Case 1 [G1] [M1] [G2] [M2]: Fail
$ inotifywait -r -m bazel-out/k8-fastbuild/bin/external/com_google_protobuf/google/protobuf
CREATE descriptor.upb.c
OPEN descriptor.upb.c
MODIFY descriptor.upb.c
CLOSE_WRITE,CLOSE descriptor.upb.c
CREATE descriptor.upb.h
OPEN descriptor.upb.h
MODIFY descriptor.upb.h
CLOSE_WRITE,CLOSE descriptor.upb.h
CREATE descriptor.upbdefs.c
OPEN descriptor.upbdefs.c
MODIFY descriptor.upbdefs.c
CLOSE_WRITE,CLOSE descriptor.upbdefs.c
CREATE descriptor.upbdefs.h
OPEN descriptor.upbdefs.h
MODIFY descriptor.upbdefs.h
CLOSE_WRITE,CLOSE descriptor.upbdefs.h
ATTRIB descriptor.upb.c
OPEN descriptor.upb.c
ACCESS descriptor.upb.c
CLOSE_NOWRITE,CLOSE descriptor.upb.c
ATTRIB descriptor.upb.h
OPEN descriptor.upb.h
ACCESS descriptor.upb.h
CLOSE_NOWRITE,CLOSE descriptor.upb.h

Case 1 [G1] [G2] [M1] [M2]: Success
$ inotifywait -r -m bazel-out/k8-fastbuild/bin/external/com_google_protobuf/google/protobuf
CREATE descriptor.upb.c
OPEN descriptor.upb.c
MODIFY descriptor.upb.c
CLOSE_WRITE,CLOSE descriptor.upb.c
CREATE descriptor.upb.h
OPEN descriptor.upb.h
MODIFY descriptor.upb.h
CLOSE_WRITE,CLOSE descriptor.upb.h
CREATE descriptor.upbdefs.c
OPEN descriptor.upbdefs.c
MODIFY descriptor.upb.c
OPEN descriptor.upb.c
MODIFY descriptor.upbdefs.c
CLOSE_WRITE,CLOSE descriptor.upbdefs.c
CREATE descriptor.upbdefs.h
OPEN descriptor.upbdefs.h
MODIFY descriptor.upb.c
MODIFY descriptor.upbdefs.h
CLOSE_WRITE,CLOSE descriptor.upb.c
CLOSE_WRITE,CLOSE descriptor.upbdefs.h
MODIFY descriptor.upb.h
OPEN descriptor.upb.h
MODIFY descriptor.upb.h
CLOSE_WRITE,CLOSE descriptor.upb.h
MODIFY descriptor.upbdefs.c
OPEN descriptor.upbdefs.c
MODIFY descriptor.upbdefs.c
CLOSE_WRITE,CLOSE descriptor.upbdefs.c
MODIFY descriptor.upbdefs.h
OPEN descriptor.upbdefs.h
MODIFY descriptor.upbdefs.h
CLOSE_WRITE,CLOSE descriptor.upbdefs.h
ATTRIB descriptor.upbdefs.c
OPEN descriptor.upbdefs.c
ACCESS descriptor.upbdefs.c
ACCESS descriptor.upbdefs.c
ACCESS descriptor.upbdefs.c
ACCESS descriptor.upbdefs.c
ACCESS descriptor.upbdefs.c
ACCESS descriptor.upbdefs.c
CLOSE_NOWRITE,CLOSE descriptor.upbdefs.c
ATTRIB descriptor.upbdefs.h
OPEN descriptor.upbdefs.h
ACCESS descriptor.upbdefs.h
CLOSE_NOWRITE,CLOSE descriptor.upbdefs.h
ATTRIB descriptor.upb.c
OPEN descriptor.upb.c
ACCESS descriptor.upb.c
CLOSE_NOWRITE,CLOSE descriptor.upb.c
ATTRIB descriptor.upb.h
OPEN descriptor.upb.h
ACCESS descriptor.upb.h
CLOSE_NOWRITE,CLOSE descriptor.upb.h

Okay, I roughly figured out what's wrong with the linux build with local spawn_strategy. This PR doesn't solve the linux build issue but can solve the windows issue, which is a blocker for Cloud C++ library's gRPC upgrade. @jtattermusch Shall we merge this?

Upb has two types of code generating rules; upb_proto_library  and upb_proto_reflection_library. Both use the same code generator which happenes to generate *.upb.* and *.upbdefs.* at all time. As a result, upb_proto_library(proto) will create proto.upb.* and proto.upbdefs.*. upb_proto_reflection_library(proto) will do the same thing.

Given that bazel always wants to have each file created by exactly one rule, this seems like a problem.  @haberman, can we change the code generator to generate only the relevant targets in both upb_proto_library and upb_proto_reflection_library?

Given that bazel always wants to have each file created by exactly one rule, this seems like a problem.

I think this was more or less Bazel-correct, because each rule only declared one set of outputs. It just so happened that the code generator binary would output both, but it doesn't usually matter if a binary creates extra files that are not declared outputs, Bazel will just ignore them.
The problem was arising when Bazel was used in non-sandboxed mode, because multiple concurrent runs of the code generator would be sharing the same output directory, and so would conflict as the parallel invocations were not fully isolated from each other.

@haberman, can we change the code generator to generate only the relevant targets in both upb_proto_library and upb_proto_reflection_library?

That was done in https://github.com/protocolbuffers/upb/issues/354

Would this problem be fixed by updating to a version of upb that includes protocolbuffers/upb#356?

I verified the recent upb fix works with this. So upgrading our upb to  https://github.com/protocolbuffers/upb/commit/60607da72e89ba0c84c84054d2e562d8b6b61177 should fix this linux local bazel build issue. This can be done with on-going https://github.com/grpc/grpc/pull/24987 or a separate PR upgrading it.

Upb upgrade is done by https://github.com/grpc/grpc/pull/25037 so this is now working.

authors: haberman jtattermusch markdroth veblush


text:
pin rake compiler to 1.1.1 and fix macos breakage

This attempts to fix the remaining macos issue in https://github.com/grpc/grpc/pull/28320
I'm not sure why macos builds are still failing yet. This PR will at least get the linux artifact and distrib tests to start passing, while we continue to debug the macos builds.

macos breakage still tracked by b/209603283


text:
Backport "Drop support for ruby 2.5 (#30699)" to v1.49.x

As title

failures unrelated


text:
Refactor of createOrder function

The objective of this PR is to refactor the function createOrder in
meaningful portions of code.
Some things to consider about this function are:

Heavy use of flags.
Duplicated parameters.
Duplicated code.

Changes:

All the logic to build the description field was moved to its own function.
Parameters buyer and seller removed in favor of user parameter.

Flags on ternary operators removed due to this change.

New paymentAction variable to increase shared code in description build for
buy and sell orders.
Repeated code to set description in buy and sell orders was joined and
only the disjoint fields were left in the conditional logic.

Things to consider:

priceFromAPI carries redundant information already present in the amount
parameter, but its readability was preferred over the number of parameters and
data duplication.
Although buildDescription is a new and different function, its utility is
totally related to createOrder. The objective of these changes is to
separate and derive sub tasks in code. It was not created to reuse in other
parts of the code. Hence its private character.

Great job! thanks
tACK

authors: csralvall grunch


text:
implement network interface nuke

Description
Partially Fixing https://github.com/gruntwork-io/cloud-nuke/issues/476

TODOs
Read the Gruntwork contribution guidelines.

[ ] Update the docs.
[ ] Run the relevant tests successfully, including pre-commit checks.
[ ] Ensure any 3rd party code adheres with our license policy or delete this line if its not applicable.
[ ] Include release notes. If this PR is backward incompatible, include a migration guide.
[ ] Attention Grunts - if this PR adds support for a new resource, ensure the nuke_sandbox and nuke_phxdevops jobs in .circleci/config.yml have been updated with appropriate exclusions (either directly in the job or via the .circleci/nuke_config.yml file) to prevent nuking IAM roles, groups, resources, etc that are important for the test accounts.

Release Notes (draft)

Added / Removed / Updated [X].
Migration Guide

Conflicting files
README.md

repo: gruntwork-io/cloud-nuke


text:
Update CODEOWNERS

Remove Zack and include @hongil0316 as the code owner.

Description
Fixes #000.

TODOs
Read the Gruntwork contribution guidelines.

[ ] Update the docs.
[ ] Run the relevant tests successfully, including pre-commit checks.
[ ] Ensure any 3rd party code adheres with our license policy or delete this line if its not applicable.
[ ] Include release notes. If this PR is backward incompatible, include a migration guide.

Release Notes (draft)

Added / Removed / Updated [X].
Migration Guide

Closing https://github.com/gruntwork-io/git-xargs/pull/136 since there are some duplicate contents.

repo: gruntwork-io/git-xargs


text:
Terragrunt caching info from GIT

Terragrunt seems to be caching my terraform scripts from GIT. Consequently each time I need to re-run terragrunt apply after changing my terraform scripts I need to first do rm -r -f .terragrunt-cache/ certainly that's not by design? How do I tell terragrunt to stop using the local cache?

I'll answer my own question since I stumbled upon the answer:
Important gotcha: Terragrunt caching
The first time you set the source parameter to a remote URL, Terragrunt will download the code from that URL into a tmp folder. It will NOT download it again afterwords unless you change that URL. That’s because downloading code—and more importantly, reinitializing remote state, redownloading provider plugins, and redownloading modules—can take a long time. To avoid adding 10-90 seconds of overhead to every Terragrunt command, Terragrunt assumes all remote URLs are immutable, and only downloads them once.
Therefore, when working locally, you should use the --terragrunt-source parameter and point it at a local file path as described in the previous section. Terragrunt will copy the local files every time you run it, which is nearly instantaneous, and doesn’t require reinitializing everything, so you’ll be able to iterate quickly.
If you need to force Terragrunt to redownload something from a remote URL, run Terragrunt with the --terragrunt-source-update flag and it’ll delete the tmp folder, download the files from scratch, and reinitialize everything. This can take a while, so avoid it and use --terragrunt-source when you can!

repo: gruntwork-io/terragrunt


text:
Update cli-options.md

Added a note explaining that due to the shared stdin and stdout meaning you can't approve any given individual apply, the use of run-all apply or apply-all will silently add -auto-approve.
This appears to have been true for several years, but I saw no mention of it on this documentation page or anywhere outside of finding the original GitHub issue, so when I changed a workflow from run-all apply to just apply today it broke in a non-obvious way that I couldn't diagnose with the documentation...

Thank you for the contributions! Merging now.

authors: gchappel rhoboat


text:
Fixed searching for configs with non-default names #2704.

Description

Fixed searching for config with explicitly specified --terragrunt-config and run-all command.
Added the ability to explicitly specify the name of dependency configuration files, which may differ from the default name terragrunt.conf.

Fixes #2031 .

@denis256, thanks for the review!

Resolved in v0.50.15 release.


text:
Terraform 0.15 requires sensitive = true for certain output variables based on RM provider

Several modules require sensitive=true on the output variables that are marked sensitive by the resource provider.  See references below.
This PR addresses the issue for #azure modules.
REFERENCES:
Releases · hashicorp/terraform (github.com)
Upgrading to Terraform v0.15 - Terraform by HashiCorp - sensitive output variables

thanks @robcamer .This issue was addressed in this merged PR . @yorinasub17 could you please close this off.

Thanks, closing now per @HadwaAbdelhalem's comment!

authors: HadwaAbdelhalem brikis98 robcamer

repo: gruntwork-io/terratest


text:
VISTA DEL PANEL EL TITULO ESTA MAL ESCRITO

En la etiqueta  esta mal el codigo del nombre

Se corrigio el titulo con el nombre correcto
commit 42c596db5976b4a6c7b6d9898d651ce363a7d04e

repo: grupovisualcont/visualcont


text:
🛑 bretterhofer.at is down

In 82b6a3d, bretterhofer.at (https://bretterhofer.at) was down:

HTTP code: 0
Response time: 0 ms

Resolved: bretterhofer.at is back up in 4b6cf32.


text:
🛑 bretterhofer.at is down

In 376488e, bretterhofer.at (https://bretterhofer.at) was down:

HTTP code: 0
Response time: 0 ms

Resolved: bretterhofer.at is back up in 61bc757.


text:
🛑 volkstanz.st is down

In 5dd3186, volkstanz.st (https://volkstanz.st) was down:

HTTP code: 0
Response time: 0 ms

Resolved: volkstanz.st is back up in 90b7475.


text:
🛑 bretterhofer.at is down

In 26b50ee, bretterhofer.at (https://bretterhofer.at) was down:

HTTP code: 0
Response time: 0 ms

Resolved: bretterhofer.at is back up in 4ec36fb.


text:
🛑 volkstanz.st is down

In 34aeda9, volkstanz.st (https://volkstanz.st) was down:

HTTP code: 0
Response time: 0 ms

Resolved: volkstanz.st is back up in a65e3cb.


text:
🛑 h4.bretterhofer.at is down

In f3d6e97, h4.bretterhofer.at (https://h4.bretterhofer.at/toggle.php) was down:

HTTP code: 0
Response time: 0 ms

Resolved: h4.bretterhofer.at is back up in a333f5f after 1 hour, 15 minutes.


text:
More cleanup.

I'm not sure whether you like all changes. Some can be categorized as style, although in general they should lead to easier code maintainability. If you do not like some, please let me know which ones, and I'll create a new pull request.

merge?

authors: kuraga vanderhoorn

repo: gshutler/useragent


text:
Refactor Operating System implementation

This will allow new operating systems to be added on a easy way.

I find this much harder to follow in general. Previously, all the code fit in 45 lines of a single file which was quite easy to understand (and I'm not the original maintainer). With this change, in order to understand how iOS versions are extracted I need to have 3 files open.
Without there being a new operating system to add I can't see how this is better overall than what is there already, though I'm willing to be convinced otherwise.
I will say I do prefer your usage of RegExp#match rather than relying on $ variables. If you were to open a PR with just that I would merge that in a heartbeat!

@gshutler if this gem is going to be the end all be all of user agent processing, this PR makes sense to me, as it allows us to add many more operating systems (i.e., Linux, Android, watchOS, BlackBerry, ...) without making giant unmaintainable files.
I'd like to see the OS class made available to other parts of the system though. In a user agent parser, it'd be nice to be able to go operating_system.is_a?(MacOsX) or something like that.

If this were adding more operating systems it would make a more compelling case for the refactor. As it doesn't I'm erring on the side of YAGNI as it is less clear, to me, after the change than before it.
If it surfaced the OS class, again that's something that would make it a more compelling change (but would need some consideration as to how to avoid it being a breaking change given the current functionality) as that would potentially eliminate confusion such as #5, but it doesn't do that either.
A refactor done in the context of such changes may end up being done differently as they would be guided by a use case. That is why I'm reluctant to merge this PR as it stands.

+1 Being able to parse Linux and others would be very useful.

+1 to solve this

+1 to solve this, Edge and Linux!

authors: EdgarOrtegaRamirez gshutler kuraga sandstrom ziggythehamster


text:
PostMan Profile and Git Check

Tarea de @ricardovrodri

Git Check: Registrar información en el repositorio común de la asignatura
A. Tener correctamente clonado el repositorio común de la asignatura  https://github.com/gti-sos/SOS2223 en local. de forma
que al hacer el comando en bash “git remote -v” sale correctamente enlazado con github.
B. Tener sincronizado el repositorio del grupo (https://github.com/gti-sos/SOS2223-XX) local de forma que al hacer ejecutar el
comando “git pull” se muestre “up to date”).
C. Asegurarse que NO se incluye la carpeta node_modules al control de versiones git

PostMan Profile: Tener creada una cuenta en la herramienta POSTMAN

Tarea terminada satisfactoriamente


text:
Remove some unneeded mem::forget() calls and Option wrappers

See individual commits.
@GuillaumeGomez @EPashkin

@sdroege Thanks, 👍

authors: EPashkin sdroege

repo: gtk-rs/glib


text:
[BUG] ObjectBuilder property population gets slower after application startup

Bug description
I have these three variants used to construct 1 million GObject subclass instances each:
    pub fn new_builder(id: u64, name: String) -> Self {
        let obj: AccountObject = Object::builder()
            .property("id", id)
            .property("name", name)
            .build();
        obj
    }

    pub fn new_setter(id: u64, name: String) -> Self {
        let obj: AccountObject = Object::builder()
            .build();
        obj.set_name(name);
        obj.set_id(id);
        obj
    }

    pub fn new_imp(id: u64, name: String) -> Self {
        let obj: AccountObject = Object::builder()
            .build();
        {
            let mut data = obj.imp().data.borrow_mut();
            data.id = id;
            data.name = name;
        }
        obj
    }

One uses ObjectBuilder to set properties, one uses property-setters and one just modifies the data directly.
The results of the creation:
Creation with new_builder() took 16385ms
Creation with new_setter() took 10925ms
Creation with new_imp() took 3867ms

According to my profiler, most of the time in the new_builder variant is spent in:
Object::new_internal() -> ObjectClassExt::list_properties

This makes a noticable different when constructing large ListModels for big tables.
EDIT
Reproduction repository here: https://github.com/exi/gtk-rs-obj-builder
The slowness of the ObjectBuilder variant only appears after the application is started up.

That is actually very known. The problem is the various checks that are made by new_internal and we would need some (unsafe?) variant that doesn't go through them.
That would be useful for builder patterns that are generated by gir and possibly in the future for a builder pattern generated by the Properties macro

Are there any downsides to directly inject properties into the imp()?
I'd guess we would miss some property-notify-event signals, but those would not be fired in the ObjectBuilder as well.
Or are there some other hazards I should be aware of?

Can you provide the full, runnable code for this? The numbers for the second variant are confusing and I'd like to know what's going on there.

@bilelmoussaoui @sdroege I boiled it down to a reproducible change, which was quite surprising:
https://github.com/exi/gtk-rs-obj-builder
ObjectBuilder gets significantly slower after the application is started up.
The code in the repo results in output like this:
Before startup
Setter took 9223ms
Builder took 9134ms
After startup
Setter took 9626ms
Builder took 12054ms

Untangled this a bit. When running it separately (each of the 4 cases is a separate process) to avoid caching effects (e.g. the way you create the list will keep the allocation for the next check after the clear()):
After startup
Setter took 5666ms
After startup
Builder took 7374ms
Before startup
Setter took 5690ms
Before startup
Builder took 5667ms

So the main question here is indeed why the builder takes longer after startup. The others all seem approximately the same.

g_object_class_list_properties() -> g_param_spec_pool_list() needs about 10x as many instructions after startup, that seems to be the main culprit here.
  g_hash_table_foreach (pool->hash_table,
                        G_TYPE_IS_INTERFACE (owner_type) ?
                          pool_depth_list_for_interface :
                          pool_depth_list,
                        &data);

This hash table contains all pspecs of all types. So after startup it contains quite many pspecs. That's obviously not very efficient.
The setter variant goes through g_object_class_find_property() -> g_param_spec_pool_lookup(). And that just does one or more (once for each parent class) normal hash table lookups with the type and property name. That's obviously faster if there are a lot of types registered.
Considering that implementation inside GObject, our approach to use list_properties() was clever but unfortunately defeated the purpose because it's super slow compared to just looking up each property individually.
Preparing a PR for here...

After my PR:
After startup
Setter took 5519ms
After startup
Builder took 5469ms
Before startup
Setter took 5536ms
Before startup
Builder took 5597ms

Now they're all about the same, so object construction is about 30% faster now.

authors: bilelmoussaoui exi sdroege

repo: gtk-rs/gtk-rs-core


text:
Link to cross compile libraries is bunk

In the tutorial for cross compiling Windows from Linux, there is a link to download the mingw-w64-gtk3 libraries from win32builder.gnome.org. However, that site does not exist. Is there another place to get the libraries for distributions other than Arch?

We should just link to https://www.gtk.org/docs/installations/windows/

@sdroege I agree. I did that in my PR here.
However, because I did do not find GTK Windows installations instructions particularly friendly, I also kept the instructions for Arch Linux and added those for Fedora. They make it much easier to achieve cross-compilation.
I am curious to hear whether you agree or not and find the PR acceptable.

authors: Barugon anieuwland sdroege

repo: gtk-rs/gtk-rs