Human friendly structured logging

Uses Zap to provide configurable and structured logging support.
Description
All logging is changed to use structured logging in json. Zap library is used for this purpose and it is extremely light and fast. Program and request logs are now separated, though defaulted to stdout. The log level is defaulted to info, and is configurable.
Issue #90 for more information.
Motivation and Context
Most enterprises aggregate logs into tools like splunk, elastic, etc so they can be processed further. This PR switches to structured logging, so log ingestion in to these tools becomes extremely easy.
How Has This Been Tested?
Unit tests are added to test the ability to write the log to a file. Unit tests added to test log-level configuration.
Checklist:

[ ] My change requires a change to the documentation or CHANGELOG.
[x] I have updated the documentation/CHANGELOG accordingly.
[ ] I have created a feature (non-master) branch for my PR.

@JoelSpeed Can you please review?

Hi @terala, before I review this, there is an existing PR open (#52) to restructure the login throughout this project. This allows users to choose their own templates for the logging structure.
Could the configuration options in that PR not be used to define templates similar to that which Zap would give us? What is the benefit of this PR over #52?

Hi @JoelSpeed,
There is a small overlap with #52, but the purpose of this PR is different.
As mentioned in the PR description, this feature allows logging into json format, or the pseudo-json (human friendly) format. The intent of json logging is to pipe these logs into logging aggregators like elastic, splunk, etc. This is very useful when oauth2_proxy is run in an container (esp in k8s). Most container orchestration systems running in the enterprise usually pipe it to these log aggregators. So, a separate file rotation is usually not necessary.
These are the differences between #100 and #52:

Feature
Structured Logging #100
Auth / Standard Logging #52

json Logging
Yes
No

Human Friendly
Partial (Human + mixed)
Yes

Selectable Log Messages
No
Yes

Builtin File Rolling
No. External rotators like logrotate is recommened
Yes

Structured
Yes
No

Hi @JoelSpeed,
There is a small overlap with #52, but the purpose of this PR is different.
As mentioned in the PR description, this feature allows logging into json format, or the pseudo-json (human friendly) format. The intent of json logging is to pipe these logs into logging aggregators like elastic, splunk, etc. This is very useful when oauth2_proxy is run in an container (esp in k8s). Most container orchestration systems running in the enterprise usually pipe it to these log aggregators. So, a separate file rotation is usually not necessary.
These are the differences between #100 and #52:

Feature
Structured Logging #100
Auth / Standard Logging #52

json Logging
Yes
No

Human Friendly
Partial (Human + mixed)
Yes

Selectable Log Messages
No
Yes

Builtin File Rolling
No. External rotators like logrotate is recommened
Yes

Structured
Yes
No

Separate logs for http and Oauth2_proxy
Yes
No

@JoelSpeed Any thoughts?

@JoelSpeed Is there any interest in this PR? If not, please let me know so I can close it.

@terala Could you please provide an example of some of the log lines that this PR generates?

@JoelSpeed Typical output looks like this (for console option): It uses a mix of json and regular output formatting.
2019-04-25T23:17:31.949-0700    INFO    oauth2_proxy/oauthproxy.go:217  OAuthProxy configured   {"provider": "Google", "clientid": "bazquux"}
2019-04-25T23:17:31.949-0700    INFO    oauth2_proxy/oauthproxy.go:225  Cookie Settings {"name": "_oauth2_proxy", "secure": true, "httponly": true, "expiry": "168h0m0s", "domain": "", "refresh": "disabled"}
2019-04-25T23:17:31.949-0700    INFO    oauth2_proxy/oauthproxy.go:189  Mapping path to upstream        {"path": "/", "upstream": "http://<IP_ADDRESS>:53157"}
2019-04-25T23:17:31.950-0700    INFO    oauth2_proxy/oauthproxy.go:217  OAuthProxy configured   {"provider": "Test Provider", "clientid": "bazquux"}
2019-04-25T23:17:31.950-0700    INFO    oauth2_proxy/oauthproxy.go:225  Cookie Settings {"name": "_oauth2_proxy", "secure": false, "httponly": true, "expiry": "168h0m0s", "domain": "", "refresh": "disabled"}

A full json log, when enabled via -json-logging flag dumps in the following way:
{"level":"INFO","timestamp":"2019-04-25T23:30:21.762-0700","caller":"oauth2_proxy/options.go:175","msg":"Validing OIDC Issuer URL","oidc_issuer_url":"https://nordstrom.oktapreview.com/oauth2/app_redacted"}
{"level":"DEBUG","timestamp":"2019-04-25T23:30:23.067-0700","caller":"oauth2_proxy/options.go:215","msg":"Discovered OIDC configuration","oidc_issuer_url":"https://nordstrom.oktapreview.com/oauth2/app_redacted","AuthURL":"https://nordstrom.oktapreview.com/oauth2/app_redacted/v1/authorize","TokenURL":"https://nordstrom.oktapreview.com/oauth2/app_redacted/v1/token"}
{"level":"INFO","timestamp":"2019-04-25T23:30:23.067-0700","caller":"oauth2_proxy/options.go:224","msg":"Configured OIDC scopes","scopes":"openid email profile"}
{"level":"INFO","timestamp":"2019-04-25T23:30:23.067-0700","caller":"oauth2_proxy/oauthproxy.go:189","msg":"Mapping path to upstream","path":"/","upstream":"https://localhost:10443"}
{"level":"INFO","timestamp":"2019-04-25T23:30:23.067-0700","caller":"oauth2_proxy/oauthproxy.go:217","msg":"OAuthProxy configured","provider":"OpenID Connect","clientid":"someclientid"}
{"level":"INFO","timestamp":"2019-04-25T23:30:23.067-0700","caller":"oauth2_proxy/oauthproxy.go:225","msg":"Cookie Settings","name":"_oauth2_proxy","secure":false,"httponly":true,"expiry":36000,"domain":"localhost","refresh":"disabled"}
{"level":"info","ts":"2019-04-25T23:30:23.068-0700","caller":"oauth2_proxy/http.go:64","msg":"HTTP Listening","listenAddress":":4180"}

Being fully json enabled makes it very easy to search when indexed via ElasticSearch, Splunk or similar log ingestion tools.

Any update @JoelSpeed?

The reason I asked for sample logs is because I believe you can get a similar output to your Zap style log using the work done in #52 (which seems to be a more flexible logging implementation).
#52 allows you to set your own format for logging, for instance for standard requests the format is currently by default:
{{.Client}} - {{.Username}} [{{.Timestamp}}] {{.Host}} {{.RequestMethod}} {{.Upstream}} {{.RequestURI}} {{.Protocol}} {{.UserAgent}} {{.StatusCode}} {{.ResponseSize}} {{.RequestDuration}}

Though one could set it to:
{"client": {{.Client}},  "username": {{.Username}}, "timestamp": {{.Timestamp}}, "host": {{.Host}}, "method": {{.RequestMethod}},  "upstream": {{.Upstream}}, "uri": {{.RequestURI}}, "proto":{{.Protocol}}, "user agent": {{.UserAgent}}, "status": {{.StatusCode}}, "response size": {{.ResponseSize}}, "duration": {{.RequestDuration}}

Which would then produce structured JSON log similar to that produced by your PR. If my thoughts here are correct then I think I would rather accept #52 over this PR as it should be slightly more flexible and allow both use cases.

I've merged #52 so am going to close this PR in favour of the changes in #52, please reopen if you still think there's merit to updating the logging architecture

A problem with just using a template that looks like json is that the values won't be escaped for json strings. E.g. you might try:
{"uri": "{{.RequestURI}}",  "user_agent": "{{.UserAgent}}", ...

but these values might theoretically have a backslash or double quote in them, and the result would not be machine-readable json.
But the go templates lib include some functions you can use, include js, I think maybe like so:
{"uri": {{js .RequestURI}},  "user_agent": {{js .UserAgent}}, ...

That's a very good point, thanks @ploxiln


GroupAction is not processed on Nette\Forms 3.1

With datagrid version 6.6.1/dev-master and Nette\Forms 3.1.0 there is no possible to submit GroupActions.
Issue is in Ublaboo\DataGrid\GroupAction\GroupActionCollection in method at line 170 - 177:
		$values = (array) $form->getValues();
		$values = $values['group_action'];

		if (
			($submitter->getName() === 'submit' && $submitter->isSubmittedBy())
			 && ($values->group_action === 0 || $values->group_action === null)) {
			return;
		}

getValues do not return group_action control with value.
Possible reason:
At release notes of Nette\Forms 3.1.0: Form::getValues() returns only controls in scope (BC break)

Thanks for the info. I am not a fan of Nette releasing BC breaks in minor version. :/ Uff.

Thanks for the info. I am not a fan of Nette releasing BC breaks in minor version. :/ Uff.

Can you please check referenced PR, if this issue can be fixed this way?

New datagrid now requires nette/forms ^3.1.3. See https://github.com/contributte/datagrid/releases/tag/v6.8.0


Where is the folder ‘depthcharge’？

I failed to find the ‘depthcharge’ folder

Depthcharge isn't a folder, it's a separate software library that provides functionality for Casanovo.
Are you encountering a specific error related to Depthcharge? In that case, could you please share the full error message?


Resource leak - temporary directory java-templateXXXX left after maven plugin execution

Temporary directory created at
https://github.com/openrewrite/rewrite/blob/65fb0cf71643037d1c472348317fa88a2f32bb3b/rewrite-java/src/main/java/org/openrewrite/java/JavaTemplate.java#L49 is left in file system with
java-template9656347799495757644
└── org
    └── openrewrite
        └── java
            └── internal
                └── template
                    ├── __M__.class
                    └── __P__.class

Oh wow, thanks for calling that out! Would you want to add a small change to delete that file on exit? That should help I suppose.


Resolving Queries on .NET Core 3.0 fails

I wanted to use this Library in my project, but couldn't test it in my project. So I've downloaded the sample one and done some investigation.
I found out that running the app on .NET Core 3.0 and trying to resolve some query is throwing the following logs:
System.NotSupportedException: The collection type 'EntityGraphQL.QueryVariables' on 'EntityGraphQL.QueryRequest.Variables' is not supported.    at System.Text.Json.Serialization.JsonClassInfo.GetElementType(Type propertyType, Type parentType, MemberInfo memberInfo)    at System.Text.Json.Serialization.JsonClassInfo.CreateProperty(Type declaredPropertyType, Type runtimePropertyType, PropertyInfo propertyInfo, Type parentClassType, JsonSerializerOptions options)    at System.Text.Json.Serialization.JsonClassInfo.AddProperty(Type propertyType, PropertyInfo propertyInfo, Type classType, JsonSerializerOptions options)    at System.Text.Json.Serialization.JsonClassInfo..ctor(Type type, JsonSerializerOptions options)    at System.Text.Json.Serialization.JsonSerializerOptions.GetOrAddClass(Type classType)    at System.Text.Json.Serialization.JsonSerializer.ReadAsync[TValue](Stream utf8Json, Type returnType, JsonSerializerOptions options, CancellationToken cancellationToken)    at System.Threading.Tasks.ValueTask`1.get_Result()    at Microsoft.AspNetCore.Mvc.Formatters.SystemTextJsonInputFormatter.ReadRequestBodyAsync(InputFormatterContext context, Encoding encoding)    at Microsoft.AspNetCore.Mvc.ModelBinding.Binders.BodyModelBinder.BindModelAsync(ModelBindingContext bindingContext)    at Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.BindModelAsync(ActionContext actionContext, IModelBinder modelBinder, IValueProvider valueProvider, ParameterDescriptor parameter, ModelMetadata metadata, Object value)    at Microsoft.AspNetCore.Mvc.Controllers.ControllerBinderDelegateProvider.<>c__DisplayClass0_0.<<CreateBinderDelegate>g__Bind|0>d.MoveNext() --- End of stack trace from previous location where exception was thrown ---    at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeInnerFilterAsync>g__Awaited|13_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|19_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)    at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)    at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

Thanks. I've not tried on dotnet 3.0 which I believe is still in pre release?
It looks like the new Jason serialiser is having trouble with the dictionary type. I'll try to play with dotnet 3.0 soon

From: Jakub Kuniszewski<EMAIL_ADDRESS>Sent: Wednesday, August 21, 2019 7:14 pm
To: lukemurray/EntityGraphQL
Cc: Subscribed
Subject: [lukemurray/EntityGraphQL] Resolving Queries on .NET Core 3.0 fails (#22)
I wanted to use this Library in my project, but couldn't test it in my project. So I've downloaded the sample one and done some investigation.
I found out that running the app on .NET Core 3.0 and trying to resolve some query is throwing the following logs:
System.NotSupportedException: The collection type 'EntityGraphQL.QueryVariables' on 'EntityGraphQL.QueryRequest.Variables' is not supported. at System.Text.Json.Serialization.JsonClassInfo.GetElementType(Type propertyType, Type parentType, MemberInfo memberInfo) at System.Text.Json.Serialization.JsonClassInfo.CreateProperty(Type declaredPropertyType, Type runtimePropertyType, PropertyInfo propertyInfo, Type parentClassType, JsonSerializerOptions options) at System.Text.Json.Serialization.JsonClassInfo.AddProperty(Type propertyType, PropertyInfo propertyInfo, Type classType, JsonSerializerOptions options) at System.Text.Json.Serialization.JsonClassInfo..ctor(Type type, JsonSerializerOptions options) at System.Text.Json.Serialization.JsonSerializerOptions.GetOrAddClass(Type classType) at System.Text.Json.Serialization.JsonSerializer.ReadAsync[TValue](Stream utf8Json, Type returnType, JsonSerializerOptions options, CancellationToken cancellationToken) at System.Threading.Tasks.ValueTask`1.get_Result() at Microsoft.AspNetCore.Mvc.Formatters.SystemTextJsonInputFormatter.ReadRequestBodyAsync(InputFormatterContext context, Encoding encoding) at Microsoft.AspNetCore.Mvc.ModelBinding.Binders.BodyModelBinder.BindModelAsync(ModelBindingContext bindingContext) at Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.BindModelAsync(ActionContext actionContext, IModelBinder modelBinder, IValueProvider valueProvider, ParameterDescriptor parameter, ModelMetadata metadata, Object value) at Microsoft.AspNetCore.Mvc.Controllers.ControllerBinderDelegateProvider.<>c__DisplayClass0_0.<g__Bind|0>d.MoveNext() --- End of stack trace from previous location where exception was thrown --- at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.g__Awaited|13_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted) at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Awaited|19_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted) at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Logged|17_1(ResourceInvoker invoker) at Microsoft.AspNetCore.Routing.EndpointMiddleware.g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger) at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/lukemurray/EntityGraphQL/issues/22?email_source=notifications&email_token=AABGHUORDOIWOLO6LLBWIZLQFUE7BA5CNFSM4IOEMOIKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HGOZNVA, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AABGHUI7SKIVUX7ROXM2Q2TQFUE7BANCNFSM4IOEMOIA.

@lukemurray  I also wanted to add something new what I found out a few minutes ago. Updating to .NET Core 3.0 is also causing some issues with relationship between DbContext and your Code. Every queries are being resolved to proper SQL statements, but it returns empty data sets in json.

@JakubK I installed dotnet 3.0 and changed the demo project to 3.0 and I can make queries etc fine. Any change you can replicate this using the demo project or another one you can share with me? Thank

Well I've just upgraded the demo to dotnet 3.0 again and it still doesn't work.
However I had to make some other changes than just updating the verion in *.csproj.
There are also some things to do in the Startup before you can run your app.
I'll attach here the zip with my Project that fails to resolve the Query.
EntityGraphQLDemo.zip

So I'm currently using dotnet 3.x and this library. I no longer get the above errors with the latest release. Let me know if you have any other issues.


Datadog collector plugin

This is an implementation of MetricCollector  for Datadog

so i'm not sure how i feel about this. i can merge, but then i will be on the hook to maintain an integration with a service i have no experience using, testing or verifying.
i'm wondering if hystrix-go should move to the model where implementations like this live in external repos, and we maintain a list here for discovery.  what do you think?

If there were a good answer for versioning dependencies in Go I'd agree with an external repo. I'd peg my changes against the versions of hystrix-go and Datadog's statsd that I developed against. There's no reason for these plugins to be in the main repo since (1) they simply implement MetricCollector and (2) since they introduce a whole slew of new and unrelated dependencies into the plugins package.
Since there isn't a good answer I think there's already precedent for potentially broken transitive dependencies (e.g. if I use hystrix-go and develop against a different version of github.com/cactus/go-statsd-client/statsd than StatsdCollector was developed against) so I'm not sure the expectations for maintenance are very high. I regularly run into problems with dependencies in Go.
Fwiw I'm happy to be on the hook for maintaining this as github.com/DataDog/datadog-go/statsd changes over time. I don't expect this to be an issue in practice but I certainly understand the concern.
Let me know what you decide.

sounds reasonable. we can always evict things like this later if it becomes a maintenance headache.


Modified recovery timeout message for clarity

It actually just waits for the quorum, no other things.

Closing per request at https://s.apache.org/V8r3


Add examples to FluxBench.jl

FluxBench.jl
Would be good to have some unique examples.

Maybe lack of datasets. Add datasets here yuehhua/GraphMLDatasets.jl#21.


Add a Gitter chat badge to README.md

DevWurm/webpack-war-plugin now has a Chat Room on Gitter
@DevWurm has just created a chat room. You can visit it here: https://gitter.im/DevWurm/webpack-war-plugin.
This pull-request adds this badge to your README.md:

If my aim is a little off, please let me know.
Happy chatting.
PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.

Coverage remained the same at 86.207% when pulling 69d806557eb72fba076f746cf24da846cbefbf03 on gitter-badger:gitter-badge into aaa3b063c26b692d0894bd48b8f2425a4ee64aa9 on DevWurm:master.

Coverage remained the same at 86.207% when pulling 69d806557eb72fba076f746cf24da846cbefbf03 on gitter-badger:gitter-badge into aaa3b063c26b692d0894bd48b8f2425a4ee64aa9 on DevWurm:master.

Coverage remained the same at 86.207% when pulling 69d806557eb72fba076f746cf24da846cbefbf03 on gitter-badger:gitter-badge into aaa3b063c26b692d0894bd48b8f2425a4ee64aa9 on DevWurm:master.

Coverage remained the same at 86.207% when pulling 03dfce1247540ce998bf60ee2ba13f70d098f567 on gitter-badger:gitter-badge into 3947cb279bf3470d6f28586562e636561a949d9b on DevWurm:master.


Add suffix to mbedtls_log to avoid link name conflict error

Summary of Changes in this PR
This PR addresses the link name conflict error that occurs when using different versions of the mbedtls crate in a single project, by adopting the approach used in PR #234.
Rationale Behind the Approach
During testing, it was discovered that simply renaming mbedtls_log resolves the linking error. Therefore, the export_name attribute is employed here, as done in PR #243.
Upon further investigation, it was found that the linker error stems from multiple definitions of mbedtls_log in the Rust code. The C compiler attempts to locate and link the mbedtls_log function implemented in Rust to the C library, but it encounters duplicate instances of the function with the same name.
It's important to note that the linking search direction is from C to Rust, so naming on the C side is not a concern. Functions named mbedtls_printf in multiple rust_printf.c files are similar to other functions in the C mbedtls code and do not cause link name conflict errors.

I got your point. You're correct
I had wrong understanding here

Functions named mbedtls_printf in multiple rust_printf.c files are similar to other functions in the C mbedtls code.

Let me rephrase what happened here:
First, compiler will compile rust_printf.c to rust_printf.o where: mbedtls_log is Undefined symbol and mbedtls_printf is local defined symbol
# part output of `nm rust_printf.o`
                 U mbedtls_log
0000000000000000 T mbedtls_printf

So compiler try to find mbedtls_log in rust compiled objects and here is where original error occurs.
And by changing name of mbedtls_log , this error is resolved by this PR.
But there indeed are multiple mbedtls_printf in multiple rust_printf.o. By inspecting to the compiled libmbedtls-abc.rlib files, the the content of rust_printf.o is being placed to the rlib file correspondingly because mbedtls rlib file is compiled separately by the build.rs script.
So I guess the reason why compiler do not throw conflict error here is: it does not detect the usage/re-export on mbedtls_printf, but this is not guaranteed in runtime and the behavior on runtime will become undefined.
In short, the approach in this PR does not solve the problem correctly.
I will close this PR, and could you please review the approve the #244 if it's ok?


kscript --idea scriptWithoutExtension copies a script instead of symlinking it

Scripts without .kt[s] extension already run fine with kscript, with the only remaining broken piece being the --idea experience.
So I think it would be better to symlink the script instead of copying it, adding .kt[s] extension so that idea correctly recognizes it.
Simplest way would be to just always symlink as .kts, although a more sophisticated implementation might try to figure out if the file was meant as .kt instead.
Motivation for extension-less scripts support/usage:
With #195 now merged, scripts can now be shared with kotlin/kscript being a hidden implementation detail, that the end user doesn't have to be educated about, which is way less friction.
The only remaining hurdle remains that the end user likely have never dealt with .kt[s] files before, so might not know it can be just run directly.
It is also more conventional for command-line tools to not have an extension, e.g. kscript instead of kscript.sh
PS: Happy to work on a PR if this looks ok. I believe there should be no downside to changing this behavior.

scripts can now be shared with kotlin/kscript being a hidden implementation detail, that the end user doesn't have to be educated about,

+1
kscript also supports regular kotlin kt files https://github.com/holgerbrandl/kscript#use-entry-to-run-applications-with-main-method which might interfere with a quick fix.
So, to implement your suggestion the/an easy way would be to replace usages scriptFile.extension with an extension method that infers the type if needed from the content if an extension is missing. Like
fun File.guessExtension(): String {
    return if (extension.isNotBlank()) {
        extension
    } else {
        if (Script(this).findEntryPoint() != null) "kt" else "kts"
    }
}

Then we'd need another else in
https://github.com/holgerbrandl/kscript/blob/4dabdd729f5c0706ab04343dc6a0b0dd77d27bf7/src/main/kotlin/kscript/app/Kscript.kt#L363
to check if the argument file is a kscript without an extension (e.g. by checking the shebang) and avoiding the creation of a temporary kts (as it down at the moment in the final else). We may need to be careful here, because it may be that e.g. file substitution handles (which also come without an extension) can be just read once.
So in total I'm not yet sure if the benefits (it's a minor feature only) outweigh the putative complexity of the patch. However, if you're still interested and would manage to put it into a reasonally compact PR (including a unit test if possible) feel welcome.

Rejected PR, so closing this ticket as well


frontend.css / vendor.css paths

Hello, I'm upgrading from a previous version of ember-cli-rails and I'm finding it hard to understand how things now work.

I have my ember app under /frontend/
I still have some pages using rails-rendered views, so I'm not using mount_ember_app in routes.rb, instead I'm using the line mount_ember_assets :frontend, to: "/", and I'm rendering when needed my ember html requests to the ember/index.html (empty) view
My ember/index.html view is using a layout with include_ember_stylesheet_tags :frontend and include_ember_script_tags :frontend

My problem now is that for any page which is non root (like http://localhost:3000/profiles/one-user or http://localhost:3000/public for example), when I reload it is looking for Ember stylesheets under the following paths: http://localhost:3000/profiles/assets/frontend.css http://localhost:3000/profiles/assets/vendor.css (so not using the root path, this should be http://localhost:3000/assets/frontend.css and http://localhost:3000/assets/vendor.css).
Any idea where this come from?
Thanks

@Leooo thanks for opening this issue and bringing this to our attention.
Have you tried the steps described in the Mounting Multiple Ember applications section of the README, particularly:

Then set each Ember application's baseURL to the mount point:

// frontend/config/environment.js

module.exports = function(environment) {
  var ENV = {
    modulePrefix: 'frontend',
    environment: environment,
    baseURL: '/',
    // ...
  }
};

Have you checked out my example application, particularly this line?

thanks for quick answer. I tried to infer from the README what to do yes, but in my case I need to keep some pages rendered by rails so I don't think I can use mount_ember_app (maybe I will try to put it last in my routes to see if this helps but I don't think so).
Mounting Multiple Ember applications is not really my use case, I have only one Ember app mounted on the normal /frontend/ path.
I already had the baseUrl: '/' in my app for the previous ember-cli-rails verison which was working fine.

Struggling to understand where this may come from.
Only thing which I can think of is: I'm using include_ember_stylesheet_tags :frontend in my layout for the ember/index.html view, which is rendered when going to the http://localhost:3000/public path (so not the usual ember-cli-rails config), so the stylesheets frontend.css etc. seem to be prepended to http://localhost:3000/public/, how could I make it prepended to the root path instead?

Hello, could you help in explaining at least where the frontend.css and vendor.css stylesheets are loaded from in the code? Is it from the ember-cli-rails-addon or from the rails gem? it would help in isolating where the problem comes from this prevents development on my app right now. Thanks

@Leooo I'm sorry, I'm not sure what the issue is.
Would you be able to fork the ember-cli-rails example repo and modify it so that it reproduces the issues you're experiencing?
That way, we can investigate the code diff and have a more concrete discussion about the underlying causes.

ok this was the  tag missing, it is in the docs but so unusual that I just missed it.
Thanks


Unable to disable new/delete memory checks on OSX

I've encountered the same problem as reported here (https://github.com/cpputest/cpputest/issues/302) and have given up trying to link against a recent version of libc++. Instead I've tried to call MemoryLeakWarningPlugin::turnOffNewDeleteOverloads(); from the test case:
#include <stdexcept>
#include <CppUTest/CommandLineTestRunner.h>

TEST_GROUP(CHECK_EXCEPTION) {
};

TEST(CHECK_EXCEPTION, aTest) {
    MemoryLeakWarningPlugin::turnOffNewDeleteOverloads();
    CHECK_THROWS(std::range_error, throw std::range_error(""));
};

int main(int argc, char** argv)
{
    return CommandLineTestRunner::RunAllTests(argc, argv);
}

But this results in the following output:
/Users/dlindelof/Library/Caches/clion10/cmake/generated/fe6adb60/fe6adb60/Debug/check_exception

/Users/dlindelof/Work/endor/libneurobat/check_exception.cpp:12: error: Failure in     TEST(CHECK_EXCEPTION, aTest)
    Memory leak(s) found.
Alloc num (2) Leak size: 8 Allocated at: /Users/dlindelof/Work/endor/libneurobat/check_exception.cpp and line: 12. Type: "new"
     Memory: <0x7ff69bc05570> Content: "�ҿ"
Total number of leaks:  1

Process finished with exit code 11

I'm using CppUTest 3.6 installed via Homebrew. Anything I'm doing wrong here?

Problems with the standard c++ lib are common, because it tends to allocate internal buffers that it "never" frees, well, actually it does when the program terminates, which is way past CppUTest's memory leak check....
It should be possible to turn on and off memory leak detection though. I haven't used 3.6 for a very long time now. Maybe you'd care and venture to try one of the later versions, like 3.7.x?

I'd be happy to test 3.7, but is there a way I can obtain 3.7 through
Homebrew? I'd rather keep on using system includes in my codebase if
possible...
On Mon, Aug 17, 2015 at 5:48 PM arstrube<EMAIL_ADDRESS>wrote:

Problems with the standard c++ lib are common, because it tends to
allocate internal buffers that it "never" frees, well, actually it does
when the program terminates, which is way past CppUTest's memory leak
check....
It should be possible to turn on and off memory leak detection though. I
haven't used 3.6 for a very long time now. Maybe you'd care and venture to
try one of the later versions, like 3.7.x?
—
Reply to this email directly or view it on GitHub
https://github.com/cpputest/cpputest/issues/774#issuecomment-131870110.

--
David Lindelöf, PhD
Chief Technology Officer
M +41 (0)79 415 66 41
T +41 (0)22 552 11 62
F +41 (0)22 552 11 60
<EMAIL_ADDRESS>http://neurobat.net
http://computersandbuildings.com

I just found out that the error goes away when I re-enable the memory checks at the end of the test:
#include <stdexcept>
#include <CppUTest/CommandLineTestRunner.h>

TEST_GROUP(CHECK_EXCEPTION) {
};

TEST(CHECK_EXCEPTION, aTest) {
    MemoryLeakWarningPlugin::turnOffNewDeleteOverloads();
    CHECK_THROWS(std::range_error, throw std::range_error(""));
    MemoryLeakWarningPlugin::turnOnNewDeleteOverloads();
};

int main(int argc, char** argv)
{
    return CommandLineTestRunner::RunAllTests(argc, argv);
}

Interesting. Could you try:
TEST(CHECK_EXCEPTION, aTest) {
MemoryLeakWarningPlugin::turnOffNewDeleteOverloads();
{
CHECK_THROWS(std::range_error, throw std::range_error(""));
}
};

That yields the same problem as above:
/Users/dlindelof/Library/Caches/clion10/cmake/generated/fe6adb60/fe6adb60/Debug/check_exception

/Users/dlindelof/Work/endor/libneurobat/check_exception.cpp:7: error: Failure in TEST(CHECK_EXCEPTION, aTest)
	Memory leak(s) found.
Alloc num (2) Leak size: 8 Allocated at: /Users/dlindelof/Work/endor/libneurobat/check_exception.cpp and line: 7. Type: "new"
	 Memory: <0x7fd5ca405630> Content: "�b�"
Total number of leaks:  1

Process finished with exit code 11

To solve my problem I ended up writing a lock-like object that will disable memory leak checks for individual tests:
#ifndef DISABLEMEMORYCHECKONOSX_H
#define DISABLEMEMORYCHECKONOSX_H

#include <CppUTest/SimpleString.h> // workaround bug in CppUTest
#include <CppUTest/MemoryLeakWarningPlugin.h>

/**
 * Allocate a local instance of this class at the beginning of your test if you need to
 * disable memory-leak checking on OSX, for example to work around implementation bugs in libc++.
 *
 * #include this file just before #including the CppUTest macros.
 */
class DisableMemoryChecksOnOSX {
public:
    DisableMemoryChecksOnOSX() {
#ifdef _LIBCPP_VERSION
    MemoryLeakWarningPlugin::turnOffNewDeleteOverloads();
#endif
    }
    ~DisableMemoryChecksOnOSX() {
#ifdef _LIBCPP_VERSION
    MemoryLeakWarningPlugin::turnOnNewDeleteOverloads();
#endif
    }
};

#endif //DISABLEMEMORYCHECKONOSX_H

This can then be used by allocating a local instance of the class at the beginning of the test:
TEST(SOME_GROUP, SomeTest) {
  DisableMemoryChecksOnOSX _;
  // rest of test
}

That's a really nifty solution. When I find the time, I will try to reproduce the whole thing with the current head.

I tried this with the latest version of CppUTest and I have the same results.
When you turn off memory leak detection as described above, you have to turn it on again at the end of the test case, or leaks will be reported.
@basvodde is this behavior intentional? It seems a bit quirky to me :-)

Not quite sure. It seems the stack object is created before the TurnOff call. Could you move the CHECK_THROWS in a separate function, just to check...

@basvodde not sure how that should change anything? Did the following:
#include "CppUTest/CommandLineTestRunner.h"
#include "CppUTest/TestHarness_c.h"

#include <stdexcept>

void check_func(void) {
    CHECK_THROWS(std::range_error, throw std::range_error(""));
}

TEST_GROUP(CHECK_EXCEPTION) {
};

TEST(CHECK_EXCEPTION, aTest) {
    MemoryLeakWarningPlugin::turnOffNewDeleteOverloads();
    check_func();
};

int main(int argc, char** argv)
{
    return CommandLineTestRunner::RunAllTests(argc, argv);
}

with the same results (why should they differ?)

Hmm. Interesting. I can do:
#include "CppUTest/CommandLineTestRunner.h"
#include "CppUTest/TestHarness_c.h"

#include <stdexcept>

TEST_GROUP(CHECK_EXCEPTION) {
};

TEST(CHECK_EXCEPTION, aTest) {
    CHECK_THROWS(std::range_error, throw std::range_error(""));
};

int main(int argc, char** argv)
{
    return CommandLineTestRunner::RunAllTests(argc, argv);
}

and no leaks will be reported. I can also do this with no leaks being reported:
TEST(CHECK_EXCEPTION, aTest) {
    MemoryLeakWarningPlugin::turnOnNewDeleteOverloads(); // turn ON !

    CHECK_THROWS(std::range_error, throw std::range_error(""));
};

will report leaks :).

Ohhh. My guess is that there is some static memory that was allocated before the test. Thus when you turn off the memory leak detector, perhaps it can't detect its free-ing.
Could you add a crash_on_allocation_number(2) and see the stack trace?

(gdb) i s
#0  defaultCrashMethod () at ../src/CppUTest/Utest.cpp:150
#1  0x00409fe5 in CrashOnAllocationAllocator::alloc_memory (
this=0x41c0e4 <crash_on_allocation_number(unsigned int)::crashAllocator>, size=40,
file=0x412060 "OneTimeThrowAwayTests.cpp", line=9)
at ../src/CppUTest/TestMemoryAllocator.cpp:179
#2  0x0040b750 in MemoryLeakDetector::allocMemory (this=0x8003c830,
allocator=allocator@entry=0x41c0e4 <crash_on_allocation_number(unsigned int)::crashAllocator>, s
ize=size@entry=4, file=file@entry=0x412060 "OneTimeThrowAwayTests.cpp", line=line@entry=9,
allocatNodesSeperately=allocatNodesSeperately@entry=false)
at ../src/CppUTest/MemoryLeakDetector.cpp:598
#3  0x00403d3c in mem_leak_operator_new_debug (size=4, file=0x412060 "OneTimeThrowAwayTests.cpp",
line=9) at ../src/CppUTest/MemoryLeakWarningPlugin.cpp:209
#4  0x00403670 in operator new (size=4, file=0x412060 "OneTimeThrowAwayTests.cpp", line=9)
at ../src/CppUTest/MemoryLeakWarningPlugin.cpp:309
#5  0x0040efb0 in TEST_CHECK_EXCEPTION_aTest_TestShell::createTest (
this=0x41c01c <TEST_CHECK_EXCEPTION_aTest_TestShell_instance>) at OneTimeThrowAwayTests.cpp:9
#6  0x00402def in UtestShell::runOneTestInCurrentProcess (
this=0x41c01c <TEST_CHECK_EXCEPTION_aTest_TestShell_instance>, plugin=0x28ab10, result=...)
at ../src/CppUTest/Utest.cpp:202
#7  0x00401530 in helperDoRunOneTestInCurrentProcess (data=0x28aa24)
at ../src/CppUTest/Utest.cpp:111
#8  0x00406a52 in PlatformSpecificSetJmp (
function=0x401510 <helperDoRunOneTestInCurrentProcess(void*)>, data=0x28aa24)
at ../src/Platforms/Gcc/UtestPlatform.cpp:137
#9  0x004019cb in UtestShell::runOneTest (
this=0x41c01c <TEST_CHECK_EXCEPTION_aTest_TestShell_instance>, plugin=0x28ab10, result=...)
at ../src/CppUTest/Utest.cpp:177
#10 0x00409d44 in TestRegistry::runAllTests (
this=0x41c9a4 TestRegistry::getCurrentRegistry()::registry, result=...)
at ../src/CppUTest/TestRegistry.cpp:62
#11 0x004065d5 in CommandLineTestRunner::runAllTests (this=this@entry=0x28ab7c)
at ../src/CppUTest/CommandLineTestRunner.cpp:105
#12 0x00406679 in CommandLineTestRunner::runAllTestsMain (this=this@entry=0x28ab7c)
at ../src/CppUTest/CommandLineTestRunner.cpp:80
#13 0x004067b7 in CommandLineTestRunner::RunAllTests (ac=1, av=0x28ac0c)
at ../src/CppUTest/CommandLineTestRunner.cpp:62
#14 0x00401419 in main (argc=1, argv=0x28ac0c) at OneTimeThrowAwayTests.cpp:17

The code I used was:
#include "CppUTest/CommandLineTestRunner.h"
#include "CppUTest/TestHarness_c.h"

#include <stdexcept>

TEST_GROUP(CHECK_EXCEPTION) {
};

TEST(CHECK_EXCEPTION, aTest) {
    MemoryLeakWarningPlugin::turnOnNewDeleteOverloads();
    CHECK_THROWS(std::range_error, throw std::range_error(""));
};

int main(int argc, char** argv)
{
    crash_on_allocation_number(2);
    return CommandLineTestRunner::RunAllTests(argc, argv);
}

turnOnNewDeleteOverloads ??

I still think it is the same thing, just the optimizer being smart. Can you put it in a separate function and compile without optimization?

#include "CppUTest/CommandLineTestRunner.h"
#include "CppUTest/TestHarness_c.h"

#include <stdexcept>

TEST_GROUP(CHECK_EXCEPTION) {};

void test_me(void) {
    CHECK_THROWS(std::range_error, throw std::range_error(""));
}

TEST(CHECK_EXCEPTION, aTest) { <-- crashes here, same as before
    MemoryLeakWarningPlugin::turnOnNewDeleteOverloads();
    test_me();
};

int main(int argc, char** argv)
{
    crash_on_allocation_number(2);
    return CommandLineTestRunner::RunAllTests(argc, argv);
}

This is compiled with -O0.

Ok, then I was wrong.
The memory allocation is the creation of the Test at line 67 in UtestMacros. Thus, if you remove the CHECK_THROWS it would also leak memory (or it should). The MemoryLeakWarningPlugin is disabled when deleting the test as this is done before the MemoryLeakPlugin runs.
So, it is ... ok :)

You are right. This "leaks":
#include "CppUTest/CommandLineTestRunner.h"
#include "CppUTest/TestHarness_c.h"

TEST_GROUP(CHECK_EXCEPTION) {};

TEST(CHECK_EXCEPTION, aTest) {
    MemoryLeakWarningPlugin::turnOffNewDeleteOverloads();
};

int main(int argc, char** argv)
{
    return CommandLineTestRunner::RunAllTests(argc, argv);
}

So the moral of the story is, we can't just turn of MLD in a test case, but we must turn it on again. Is this something the Plugin could do automatically? Or would that be too late?

At a minimum:
#include "CppUTest/CommandLineTestRunner.h"

TEST_GROUP(Leaks) {};

TEST(Leaks, thisLeaks) {
    MemoryLeakWarningPlugin::turnOffNewDeleteOverloads();
};

int main(int argc, char** argv) {
    return RUN_ALL_TESTS(argc, argv);
}

(never knew CommandLineTestRunner.h actually includes TestHarness.h ;-)

The RIAA solution is ok though.

Of course it is. But it is not part of CppUTest. This kind of thing shouldn't depend on the skill of a particular user. This should be part of CppUTest, and replace the turnOn/turnOff functionality, which is very misleading the way it works now.

something that could be used like this:
{ // some scope
    MemoryLeakWarningPlugin::disableOverLoads disabler;
    // do stuff
}

The present functions would then be private.

Wouldn't want the present methods to be private :) I think it is pretty obvious you ought to turn it on again.
 No need to put it inside the Plugin class either, I guess.

Whatever :)

I'd be happy to share the memory leak disabler. Would you like me to prepare a formal pull request?

I think the EXPECT_N_LEAKS is perhaps a better way of coping with expected leaks. Closing this for now.


Allow comments in manual overrides

Some devs have been using overrides lately, and it would be good to ignore everything after a #.
This way somebody can include some documentation in each line for everybody else to see

That should already work but needs to be at the start of the line. I can add that it also ignores comments at the end of the line. I thought I had documented this since this was for sure one of the first things I've implemented in the parser. We used that when selectively enabling override rules while switching services.
But there is no test for that and it isn't documented :(
https://github.com/fabiolb/fabio/blob/master/route/parse_new.go#L15
https://github.com/fabiolb/fabio/blob/master/route/parse_new.go#L71-L72
# this is a comment
// this is a comment as well
route add ...

I've added a section to the docs just now:
https://github.com/fabiolb/fabio/wiki/Routing#comments

Hey, cool thank you :D


Problem about caching strategy for Lean

Note: This is based on my assumptions and might not be entirely accurate.
This issue occurs when we update our project from v4.9.0-rc1 to v4.9.0-rc2. https://github.com/iehality/lean4-logic/pull/85
And it seems to be happens same problem branch in the nightly branch of the import-graph.
In our project, we set the GitHub Action cache strategy as follows
path: .lake
key: lake-${{ runner.os }}-${{ hashFiles('lake-manifest.json') }}-${{ github.ref }}
restore-keys: |
    lake-${{ runner.os }}-${{ hashFiles('lake-manifest.json') }}-${{ github.ref }}
    lake-${{ runner.os }}-${{ hashFiles('lake-manifest.json') }}
    lake-${{ runner.os }}

The problem we encountered was with the restore-keys we specified. The issue is that when updating the Lean version itself, the previous version's cache also becomes a fallback candidate. In our project, it seems we referenced the v4.9.0-rc1 cache, which caused the build to fail.
Solution is remove fallbacks of restore-keys to lake-${{ runner.os }}-${{ hashFiles('lake-manifest.json') }}-${{ github.ref }} only.
Currently, the cache strategy of this action is similar (i.e., it doesn't avoid using the cache when the Lean version itself is updated).
https://github.com/leanprover/lean-action/blob/52906d40616a3ed5a566f5f01db39858c0f6eee2/action.yml#L93-L99
This seems to be why the nightly branch of the import-graph is broken.
As a solution, specifying ${{ hashFiles('lean-toolchain') }} as the key should work.

Maybe the cache key should be like this, specifying lean-toolchain and lake-manifest.json
key: lake-${{ runner.os }}-${{ hashFiles('lean-toolchain') }}-${{ hashFiles('lake-manifest.json') }}-${{ github.ref }}
restore-keys: lake-${{ runner.os }}-${{ hashFiles('lean-toolchain') }}-${{ hashFiles('lake-manifest.json') }}-${{ github.ref }}

duplicate of #62

Even though the failure is the same as #62, I think the suggestion to improve the key for the caching is still valid.

Maybe the cache key should be like this, specifying lean-toolchain and lake-manifest.json
key: lake-${{ runner.os }}-${{ hashFiles('lean-toolchain') }}-${{ hashFiles('lake-manifest.json') }}-${{ github.ref }}
restore-keys: lake-${{ runner.os }}-${{ hashFiles('lean-toolchain') }}-${{ hashFiles('lake-manifest.json') }}-${{ github.ref }}

I think this is an improvement over the existing key input for the cache
However, it seems to me that the restore-keys need to be a prefix match of whatever existing cache key is hit. If you have the same value for the key and restore-key input it seems redundant, although I could be missing something here.
For the restore-key input what about:
restore-keys: lake-${{ runner.os }}-${{ hashFiles('lean-toolchain') }}-${{ hashFiles('lake-manifest.json') }}

With this lean-action can restore caches where lean-toolchain and lake-manifest.json remain unchanged.
@SnO2WMaN what do you think?
Also for reference, the initial discussion of what key to use for the hash was here.

Thanks for your advice.
Once considered, we added ${{ github.ref }} to prevent build errors caused by cache from different Lean versions, but now we have switch to use lean-toolchain. It might no longer necessary so we might be able to remove ${{ github.ref }} from both the key and restore-key.

Thank you @SnO2WMaN for raising this issue and coming up with suggestions for improved caching keys! #71 implements these changes.


soc: intel_apl_adsp/intel_s1000: keep irq mask in smp entry

In smp_init_top(), it initializes a dummy thread and set it
to be the current thread. The _current_cpu macro asserts
on intel_apl_adsp since interrupts are unmasked at smp entry.
So don't unmask.
Signed-off-by: Daniel Leung<EMAIL_ADDRESS>

Use #26483 instead.


Use internal texture at internal resolution for calculating luminance (FSR2).

Fixes an error where the exposure was calculated incorrectly if a lower resolution scale was used while using FSR2. Now the behavior is consistent regardless of the resolution scale since it uses the internal texture as it should instead.
Master 0.5

Master 1.0

PR 0.5

PR 1.0

This is a low risk change and only affected results when auto-exposure was enabled on the camera properties.

Thanks!


Cardinality issue in dolt SQL

@fulghum and/or @jennifersp.
Can you take a look at this please and provide @PrathyushaModala some feedback?

We're going to be doing work on getting accurate cardinality counts in info schema tables in the coming months, so I'm going to close this out for now.


Now shown in package control

First, thank you for writing a great package!  In any case, I use Sublime Text 3 and the package is not shown in package control.  I did the manual install and it seems to work great.  Fix that and it will be a whole lot easier for more folks to use your great plugin.

I think it is worth reminding folks that Merlin hasn't updated this in two years. You'll have a better chance forking it and making the changes yourself. I've been wanting to create an updated fork of this for a while now but just haven't had the time to do it myself.

You should use my fork then since it is already updated to ST3

@thatsIch the readme.md on your fork says the recommended install is from the package manager and it's not there as far as I can see.

I did not manage the pull-in from the repository manager. The transition is far from complete since I do not use every feature. I did not want to publish something half-baked. But it "runs" on it. Since I do not make any Rainmeter Skins anymore the interest also dropped maintaining this.

@marlboro it is now possible using package control with a small workaround. please look into the readme in my fork.


Settle on a name

Detailed Description

We should settle on one and only one name that is not overloaded already.
Context

Given we follow the path outlined in #204 then we are in a somewhat fuzzy spot in terms of naming:

This library is historically called Tracer because it was meant to target a very specific aspect of distributed system tracing.
The name was used consistently:

tracer repositoriy
tracer-* modules and artifacts
org.zalando.tracer package
Tracer main API
TracerFilter
TracerHttpRequestInterceptor
TracerAutoConfiguration
tracer configuration namespace (Spring Boot)

OpenTracing has its own concept and overloaded term of a Tracer, hence the switch to **Flow*.
The name is not used consistently right now:

tracer repositoriy :boom:
tracer-* modules and artifacts :boom:
org.zalando.tracer package :boom:
Flow main API
FlowFilter
FlowHttpRequestInterceptor
TracerAutoConfiguration :boom:
tracer configuration namespace (Spring Boot) :boom:

Once we remove the log correlation feature (new library already in the works) then the only responsibility left in this library is legacy flow-id handling.
My suggestion to rename this to legacy-flow.

(Library could become closed source since there is virtually no use case for this outside of Zalando.)

legacy-flow sounds good to me. As well fine with moving to closed source

Superseded by #328


(fix) no argentX popup for initiate withdrawal

It happened only when the ArgentX wallet wasn't pinned

We were not able to reproduce.


correct counter's key value

The key was also translated. Since the right key didn't exist the value form the default language was shown.

@maxyvon thanks for your PR.


Fix generated import path on Windows

When running the generate-model or generate-clusters scripts in the codegen project on Windows, the imports were generated with \  separators instead of /.

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

@spudwebb yopu needto accept the CLA -... else we can not merge here

signed!

And directly merged.


Add option to add last-release tag

The last-release tag should always be on the commit with the latest (as in time, not version-number) release.
The tag is used to calculate the changes since the last release.
Currently I'm setting the tag as an extra CI-step, but this has the disadvantage that the tag will be moved whether there is a new release or not.
The best way I came up with would be to set the last-release tag in the same step the version tag for the individual release is set.
If wanted there could be a global config where this behavior could be enabled/disabled.

Hi, I agree this could be useful. For now, we do this in the CI as an independent step in our workflow. It could be an executor used along with post-targets.

related to #499

the downside of "moving" the "last-release" tag is that you always have to
```git pull -t -f````
before pushing, to update the tag locally.
To avoid that, im pushing a new tag, starting with release- , followed by a number, or a date and time like
git tag -f release-$(date '+%d-%m-%Y-%H-%M-%S')

to get the base for the next nx affected, im using
npx nx affected --target=prepare --base=$(git show-ref --tags | grep release- | tail -n 1 | sed 's~.* refs/tags/~~')

IMHO, this is a bit out of scope of versioning, and more an individual CI flow thing when / how to place a last-release tag.
Another possibility would be to "grep" for the newest version-tag (that depends on your configuration).
e.g. if you
{
 "tagPrefix": "release-${projectName}-"
}

you could also use
git show-ref --tags | grep release- | tail -n 1 | sed 's~.* refs/tags/~~')

to get you base, and you dont have to push an extra tag at all, BUT
if a library/app fails versioning for some reason (upload fails?), you cannot retry you build.

In fact, the version tag and the release tag are two distinct things. The release tag marks the success.
💯 with @ndrsg and @edbzn,tagging last release shouldn't be part of semver.
Last release could even be marked by storing the commit is in a file for instance. So there are way multiple strategies.
Also, even if it's an executor in post targets. It shouldn't be executed for each project but only once so it should only be used at the workspace level.

tagging last release shouldn't be part of semver

I do not totally agree here, as you mentioned "release tag marks the success", imo we should provide something, whatever the strategy used under the hood, for marking the last successful release. It is required for semver to work properly in the CI, but I agree that we can't provide such a feature without the ability to run semver at the workspace level.

Exactly! This can only work at the workspace level.
Also, what I meant is that this is beyond semver. All kind of workflows using affected need a way of marking the last success.
We could even imagine multiple tags for multiple steps:
nx affected --target test --base last-test-success
nx affected --target version --base last-version-success

Actually, it should be an Nx feature.
🤔 just thinking out loud, what about a hook system that could allow us to trigger an executor after nx affected...
Or maybe, we just need an Nx wrapper for the CI.
npx nx-affected-and-tag --target test


Make sure that the error message encoded is in utf8

While helping a user in Qiita I found that if a sample information file contained non-utf8 characters, it will break the communication between the ipython workers and the main server. This PR makes sure that the error message is a utf8 valid string, by replacing the non-utf8 characters with the official U+FFFD REPLACEMENT CHARACTER, as seen below:

Tests passed locally, merging due to restart.


Reflux mixin initial update

When listening from stores or components to stores, the provided mixins don't automatically do an initial action, can this be made optional?
You always have to do like:
this.listenTo(Store, this.onChange);
this.onChange();
or you have to get the store in get Initial state, but that can be cumbersome. The same for the Reflux.connect mixin. Maybe this.listenToAuto(Store, this.onChange)?

There is a third parameter:
this.listenTo(Store, this.onChange, this.onChange);
The store needs a getInitialState method that will be called for the second callback.

Okay, that is fair. But the store will always need the getInitialState then?

Oh, I misread your question.
At the current implementation, yes this is the only way.
There has been discussion in the issue tracker about having the store handle a state by itself (e.g. #290). This would in turn make it possible for stores to automatically populate new components based on what has been triggered. Nothing concrete yet.


Design for ECMPS Resources (Need by 8/23)

@chrisgitsit —
Here are the links to the Resources page for review:

Resources
Resources (dev)

Moving edits to content document: https://usepa.sharepoint.com/sites/CAMDCVPTeam/Shared Documents/Forms/AllItems.aspx?viewid=18eab565-03ba-4600-a594-5eb27c0d799a&id=%2Fsites%2FCAMDCVPTeam%2FShared Documents%2FTheEmissioners%2F6-Content Templates%2F2-Utility Menu%2F1-Resources


🏗 Refactorings for extension controller

How to categorize this PR?

/area open-source
/kind cleanup
What this PR does / why we need it:
This PR refactors the Operator's extension controller, as a suggestion to improve maintenance, tests and readability. This is a preparation for further enhancements, e.g. applying extensions in the runtime cluster.
Which issue(s) this PR fixes:
Part of #9635
Special notes for your reviewer:
/cc @MartinWeindel @oliver-goetz
Release note:

NONE

/kind cleanup

/test pull-gardener-e2e-kind-operator-seed

Looks very good, thanks 🚀
/approve
lgtm for @MartinWeindel


Added changes to open application detail page under settings

Added changes to open application detail page under settings if user opt for never ask again permission and deny. This change will take user to application detail page where they can toggle permission.

Hey sorry, I decided to move away from the grant permission button logic and replaced it with SnackBar.


rsync: Tweak transfer options (delete & compress)

LXD when interacting with recent clients will now support:

--delete (to avoid random conflicts)
--compress --compress-level=2 (to reduce bandwidth usage)

The level 2 compress appears to be the best CPU/bandwidth tradeoff for
most common images and shouldn't cause slowdowns in most cases.
Closes #5215
Closes #5212
Signed-off-by: Stéphane Graber<EMAIL_ADDRESS>

@brauner should be good to go


Replace while-sleep with Event

Description
Instead of sleeping in a while loop, and waiting for a condition to become true, it's preferable to await on an Event object such as: anyio.Event
This way you don't bother event loop every 0.1 seconds (used as default) and handle condition change without waiting additional sleep time.
Type of change
Please delete options that are not relevant.

[ ] Documentation (typos, code examples, or any documentation updates)
[ ] Bug fix (a non-breaking change that resolves an issue)
[ ] New feature (a non-breaking change that adds functionality)
[ ] Breaking change (a fix or feature that would disrupt existing functionality)
[ ] This change requires a documentation update

Checklist

[x] My code adheres to the style guidelines of this project (scripts/lint.sh shows no errors)
[x] I have conducted a self-review of my own code
[ ] I have made the necessary changes to the documentation
[ ] My changes do not generate any new warnings
[ ] I have added tests to validate the effectiveness of my fix or the functionality of my new feature
[ ] Both new and existing unit tests pass successfully on my local environment by running scripts/test-cov.sh
[ ] I have ensured that static analysis tests are passing by running scripts/static-analysis.sh
[ ] I have included code examples to illustrate the modifications

Sorry, we should take a little pause with this PR. Our first implementation worked this way, but we switched to sleeping due nats-py bug. We should check it again

@Olegt0rr I think, we can merge it and come back to the problem if there is a feedback from NATS users
Can u please resolve conflict and remove property to let me merge PR?


reCAPTCHA puzzle is positioned relative to the center of body, not the viewport.

So, I have a very specific issue. Our site has a reCAPTCHA widget inside a sidebar that is positioned outside of the body. For this sidebar to be visible, we only need to add a negative margin-left to the body.
So when the captcha cannot identify the user as real person, the puzzle is rendered but positioned relative to the body, which in our case is too far from the reCAPTCHA widget or simply outside the screen when on mobile. Ideally the puzzle box should be positioned relative to the viewport, but I'm afraid that may be not be easy to fix.
A quickfix would be to simply apply the same margin to the parent div containing the puzzle, but it lacks any class or attribute that could be used to easily select it. Could there be any other workaround? I'd rather not refact our sidebar just because of reCAPTCHA.
Image examples:

Hi to all, i have used the recaptcha widget in angular material modal.Sometimes when i proceed and clicks on recaptcha   widgets then a puzzle box comes and this puzzle box comes far away from the recaptcha widget.I tried to solve this issue but nothing good happened.Please suggest some solution if you find some.Thanks.

Closing super old issues. Please re-raise if still relevant.


improve merge performance with dictionary lookup

I've been looking at the merge.py code, which is the main bottleneck in terms of performance. My last run took 10 hours, the majority of it spent on this step.
This change cuts the time down to a few minutes (~8m) on my machine.
When we take a list of IPs from an extra file and want to merge it into the base RPKI file, we want to check inclusion of the extra network IP in any network IP in the RPKI file. We only want to merge in the IP if it is not contained by any network IP + netmask already present in the PRKI file. Currently we do so by checking the extra IP against every IP in the base file. If the base file is 1 million IPs, we'll check the extra IP against all of them.
Performance is greatly improved by indexing the base file IPs by their leftmost section, and then checking the extra IP against this subset. Since an extra IP will only be a subnet of a base IP if their leftmost section match, and the inclusion check (extra & base_mask == base_net) is sufficient to validate its inclusion in the same way the current merge does. By limiting the comparison to a subset, iterating through each possible base IP set is much faster.
I ran reproduction steps by comparing the data from a run with the original merge code, running only the RPKI and IRR merge via general_merge as well as the full reproduction process with --reproduce, resulting in the exact same output files (the same hashes for the original and the reproduction step, for both merged_file_rpki_irr.txt and final.txt).
This dictionary lookup approach could be improved further: a trie might be the better data structure for this. Additionally, this approach does not rely on parallelization.
Finally, this implementation is a work in progress and very rough at the edges, namely the IPv4 vs IPv6 dict keys are different types, indexing IPv6 should be rethought, and there are more efficient data structures to consider. The goal with this branch is to showcase the performance improvement and gather initial feedback.
To validate this, you can take an existing data set you have from a previous run, and running the ./run map --reproduce data/{run_unix_ts} -t {run_unix_ts}. Validating RPKI still takes about 20-30 minutes, but the whole run should take under 1h depending on your machine. Compare the file hashes between your original run and reproduction run to validate that the merge behaviour hasn't changed.

I successfully reproduced this run with this branch, and got the same final_result hash. Took 48 minutes.

pulled out the dictionary instance and methods into a Networks class.

thanks -- should be ready now @fjahr


Ticket Expired Error when connecting to SQL Server from Red Hat 8 using Active DIrectory Authentication

Environment

Python: 3.7.6
pyodbc: 4.0.0
OS: Red Hat 8
DB: SQL Server (and SQL Server Express)
driver: ODBC Driver for 17 for SQL Server

Issue
Hello! Thanks for making such a great package, and I hope you're staying safe and healthy during these difficult times.
Below is a screenshot detailing the error message I receive upon trying to connect to a particular server at my company using pyodbc.

I don't believe there is an issue with the odbc.ini entry or the server itself because I'm able to connect to the server (from the machine in question) using the R programming language so I believe it has something to do with pyodbc.
Below is the relevant entry in the odbc.ini file (with sensitive information excluded).
[Projects]
Driver = ODBC Driver 17 for SQL Server
Description = Microsoft ODBC Driver 17 for SQL Server
Server = /* sensitive */
ServerSPN = /* sensitive */
Trusted_Connection = yes

I suspect the issue has something to do with the fact we authenticate users using our Active Directory system, and pyodbc has its "prompt" turned off by default. As a result, users aren't able to enter in their credentials. This is just a hunch though, and I figured I would submit this as an issue to see if you had any further insight into what may be causing the issue.

Trusted_Connection=yes will use Kerberos for authentication, and the message indicates the Kerberos ticket has expired. Check that the clock is correct and use the kinit command to request a new one.
See this document for more information: https://docs.microsoft.com/en-us/sql/connect/odbc/linux-mac/using-integrated-authentication

Thanks this solved it!


[doc] Typo on Build Instructions in README

Description
The build instructions in README are wrong:
export WORKDIR=$HOME                                                  # Change this to whatever you want.
cd $WORKDIR                                                           # Switch to working directory.
git clone --recursive https://github.com/demikernel/demikernel.git    # Recursive clone.
cd $WORKDIR/demikernel                                                # Switch to working directory.

The comment on the last line should be something like:
cd $WORKDIR/demikernel  # Switch to repository's source tree.

This issue was addressed in commit 5a69420368fc0d2c58adc042214f3a772d098a9b.


Use MOUSE_FILTER_PASS for all containers

Containers are meant to forward mouse input to their the Controls
they contain.
Fixes #34933.

Putting this up for discussion, I haven't thoroughly tested yet.
Apart from GridContainer and BoxContainer-derived classes which already defaulted to PASS, this changes the behavior for CenterContainer, MarginContainer, PanelContainer, ScrollContainer, SplitContainer, TabContainer, ViewportContainer and the base Container. Might have unforeseen consequences if nobody noticed this discrepancy in 6 years.

Related: #24083 (but that one would be for 4.0).

Parts of the editor code that sets the filtering to pass in containers should be removed too, these are the ones that I found at first glance:
https://github.com/godotengine/godot/blob/33be750634cffe577df4c97963124f27e65e6549/editor/editor_audio_buses.cpp#L859
https://github.com/godotengine/godot/blob/33be750634cffe577df4c97963124f27e65e6549/editor/plugins/asset_library_editor_plugin.cpp#L1455

Thanks, removed all occurrences I found in editor/ and scene/ (notably GraphNode which is a container too).


Question for packages in the ros-image-world

Hi,
I have a question for ros-image-world.
Looking into ros-galactic packages supported by Ubuntu-20.04, there are some differences from ros-image-world in the galactic.
Can you please let me know how I can understand it correctly?
BR,
Mark

Hi Mark,
Galactic was last updated as part of milestone 17: https://github.com/ros/meta-ros/commit/4af30a62a39f1ce1fbc6c6a5c3e681ddc85ba0ee  It reached end of life on December 9th, 2022 ( https://docs.ros.org/en/rolling/Releases.html ).  Since it is no longer supported, I have not tried to update any of the recipes.
I intend to remove the unsupported sub-layers just prior to releasing Milestone 18.  They will still be available in the history if anyone needs them for historical reasons.  I am also happy to not remove the sub-layer and accept fixes if someone is willing to commit to maintaining it.
Regards,
Rob


Remove usage of IndexSearcher#Search(Query, Collector) from monitor package

Relates to: #12892

OK, I think this is still a safe implementation but the change is that multiple collection threads will now be concurrently calling CandidateMatcher#addMatch. I believe this is safe but need another set of eyes on it. The reason I think this works is that we should never be interleaving calls with the same doc value since these are global docIDs.

I am not familiar with this code but I believe you are correct. This should work despite we use a plain ArrayList, because each thread should only get and compute its own docs. Testing would verify that, but I believe we never provide an executor to the searcher we use, neither in test nor in the prod code. Should we try and add that?

Also, thanks a lot for the help here, much appreciated!

Thanks @romseygeek for providing more detail on the monitor implementation and confirming this is safe.
As for your suggestion of providing a sugar method in CollectorManager to do the wrapping for situations like this, I'm a bit conflicted. I took a crack at updating the PR here with a revision that does this for discussion. On one hand, I agree with you that it's pretty verbose (and annoying if I'm honest) for users to have to do their own Collector wrapping like this, so a convenience method would be nice. On the other hand, I'm concerned it could be trappy for users that don't read the "fine print" and end up creating concurrency bugs by incorrectly wrapping in a case where an IndexSearcher is using an Executor (and their Collector isn't thread-safe).
I think it's a balance of how often this single-threaded-collector pattern occurs and how potentially trappy this sugar method is. Thoughts?

There is a test that does the following:
QueryMatch.SIMPLE_MATCHER.createMatcher(searcher);

This uses public API and allows to provide a searcher externally, doesn't it? Do we need to enforce that the searcher used in monitor should not have an executor and/or should not try to apply concurrency?

OK, I think the latest iteration of this is ready to merge, pending any remaining feedback, concerns, etc. I voiced some concerns earlier about the static wrapping method, wanting to make sure we don't provide some trappy implementation for users, but the suggestions around error checking/asserts convinced me this is reasonable (still don't love it, but I think it's reasonable right now).
I'll get this merged in the next couple days if I don't hear any additional concerns, otherwise happy to iterate.

Heads up: I saw there were merge conflicts caused by my recent push hence I went ahead and addressed those.

Thanks @javanna, @romseygeek !  FYI @msfroh just merged and back ported. I saw you had another PR waiting on this.

I've been changing my mind a few times on the topic, but I am concluding that it probably was not a good idea to expose the sequential collector manager. I think we are ok using it internally at our own risk, for situations where we know for sure that we can't possibly have a searcher with an executor set. But exposing it publicly makes it too easy for users to get unexpected failures, and the disclaimer "don't use this with a searcher that has an executor set" is kind of odd. What if those users do have other queries that make already use of concurrency, and use the same searcher for these others that get converted to leveraging the sequential collector manager? It is also trappy that they get errors only once there's more than one slice, so the behaviour may be hard to follow for users.
I would propose that we make the new collector manager private with a bug disclaimer on when it should be used, and make a plan to remove it perhaps in the medium to long term. We should really design all new features with concurrency in mind, and migrate old ones to support concurrency.
There is some urgency around this especially for the 9.12 release, I am happy to open a PR.


Unsupported operation: ReceivePort.listen

Issue
For some reason, I can't seem to use ReceivePort from my browser. After running:
dart2js main.dart  -o main.dart.js
And opening my index.html file locally, I get the following error from Chrome:
Uncaught Unsupported operation: ReceivePort.listen
Sample Code
main.dart
// Dependencies
// ------------

// Libraries
import 'dart:isolate';

// Internal
// --------

void main() {
  ReceivePort receivePort = new ReceivePort();

  receivePort.listen((data) {
    receivePort.close();
  });
}

Information

Dart SDK Version (dart --version)

dart --version
Dart VM version: 2.2.0 (Tue Feb 26 15:04:32 2019 +0100) on "macos_x64"

Whether you are using Windows, MacOSX, or Linux (if applicable)

macOS Mojave (10.14.4)

Whether you are using Chrome, Safari, Firefox, Edge (if applicable)

Chrome and Safari

@jvanderen1 thanks for reaching out. This is basically not supported by design.
Long ago we supported the isolate API on the web. The implementation would manage isolates using web workers. We found that the isolate abstraction was not a great fit on the web and eventually decided to deprecate it and remove the support.
Starting in 2.0 (see announcement and changelog entry), the library implementation was changed to throw by default. It would have been nice to actually make it a compile-time error to import dart:isolate, but if I recall correctly, we made it a runtime error to make it easier to migrate existing code more gradually.
If you need support for background execution, our current recommendation is to use web workers via js-interop.


Add contributor issues

Hello,
I getting this message when i try to add new contributor

did you solve it ?

@MohmmedAshraf I've opend a PR to fix this here #86

Thanks @amshehzad


Feature/create chat

This PR creates a new route that allows users to create a chatroom. The route accepts a chat_name and members, an array of user UUIDs. It then creates a chat in the database and corresponding entries in the XREF table, since chatrooms and users have a many to many relationship. This PR also updates the database schema accordingly

In your PR description, could you include an example payload to use for this endpoint?

https://stackoverflow.com/questions/5884784/how-to-pull-remote-branch-from-somebody-elses-repo


Copy package tag charts with versions

This change tags the helm charts with the versions were are in the package bundle. It seems a lot of work just for that, but we'll want to use this to tag the other images as well once those versions are available.

/cherry-pick release-0.14

/lgtm

/lgtm

/approve


Little change for better understanding

Hello,
I'm currently implementing test for the EquipmentDefinition class.
When I read the init method, I considered that it is a bit incomprehensible because the name of the parameter and the HashMap were the same.

Hi,
I think that the fully qualified access to EquipmentDefinition.definitions provides enough clarity, since definitions is only available within the scope of that method for a short time. It is also very common to name constructor arguments with the same name as the member they're being assigned to and qualifying the member with this, and I think that carries over to this similar static initializer method.
Thanks.


[Feature Request] sort by rating

Why/User Benefit/User Problem
It's not really a problem or anything, bmjust a quick thought, sorting my Mangas by rating would help people with a big library to read first the Mangas that are highly rated and leave the poorly rated for a rainy day... Or even elete them (sub 6/10 usually isn't good)
What/Requirements
Exactly like alphabetical sorting, except it would use the mangadex rating system.

in newest release


Decide on dependency that provides/implements org.freedesktop.secrets

In testing on a very slim Ubuntu instance, it appears that the Ubuntu build does not install something that implements org.freedesktop.secrets. It would appear that gnome-keyring implements this, but there are other implementations as well. I don't know enough about Ubuntu packaging to see if there's a way to generally specify any package that implements org.freedesktop.secrets. If there is, I'd like to go that approach, otherwise a decision needs to be made on what should implement org.freedesktop.secrets, hopefully something that's distribution agnostic.

It would probably be a good idea to decide this for Fedora builds too.

For the time being, I'm going to use gnome-keyring, but I'd really like to figure out a way to have dynamic dependencies IE if you have kwallet installed already, you shouldn't need gnome-keyring.


Fails to resolve main property in package.json

If I have a file with
/* @flow */
var ReactRouter = require('react-router');

flow will fail with:
path/to/file:2 lib
Required module not found

Changing the main property from lib in the package.json of react-router to be lib/index makes it work.

<EMAIL_ADDRESS><EMAIL_ADDRESS>
ref: https://github.com/facebook/flow/issues/46

What is the underlying issue here? Seems like flow doesn't understand node/npm's index.js convention.

@mjackson yes that is my current guess.

I ran into this issue as well. After some testing, it seems that flow does understand index.js convention when requiring (relative) folders in code (i.e. require('./dir')), but it does not support the convention in main property of package.json.

It seems that the issue is fixed 0.5.0

Please reopen if this is still an issue.

I see this error again with Flow 0.16.0. Seems to be tracked by #654 now.

@samwgoldman, I'm seeing this in Flow 0.22.0 with the react-router package, which specifies its 'main' in the package json as just 'lib' instead of 'lib/index.js'.

Just upgraded from 0.21 -> 0.22 and seeing this bug.

This was fixed in 0.22.1, right?

i'm seeing this error with flow-bin 0.29. every import that I do from node_modules is failing.

just ran this test:
mkdir -p test/node_modules/foo/lib
pushd test
printf "// @flow\n\nmodule.exports = 'hello';\n" > node_modules/foo/lib/index.js
echo '{"name": "foo", "main": "lib"}' > node_modules/foo/package.json
printf "// @flow\n\n(require('foo'): number);\n" > index.js
touch .flowconfig
flow check
popd

and got this:
$ flow check
index.js:3
  3: (require('foo'): number);
      ^^^^^^^^^^^^^^ string. This type is incompatible with
  3: (require('foo'): number);
                      ^^^^^^ number

Found 1 error

so I think it's working now (v0.32)

Just bumped into this again. Do NOT add this to your .flowconfig:
[ignore]
.*/node_modules/.*\.json$


Expo?

Does this work with Expo?

Hi @theianjohnson,
I am actually using this project in conjunction with Expo SDK v40, so it does indeed work

Hi @theianjohnson me too, no problems so far


Future specification on binary format

Is there any plan to add into the specification how to convert a typeid to binary format?
In my other personal project utilising typeid, I will need to serialise the ids. So far I'm implementing my own serialisation only for that specific project, but if there will be a formal specification, I can include that in the Haskell implementation as well.

A similar question came up here: https://github.com/jetpack-io/typeid-go/issues/5
So definitely open to having the spec define a formal binary representation. Did you already have a particular binary representation in mind?

So definitely open to having the spec define a formal binary representation. Did you already have a particular binary representation in mind?

I'm still experimenting with it. Currently, I have an 8-bit length indicator of the prefix followed by the raw ASCII of the prefix, then followed by the normal encoding of the UUID.
It's not the most compact way of doing so, e.g. the length only needs 6 bits and each letter only 5 bits. I think I'm happy with what I'm doing now for my particular use case (since I don't need to squeeze every inch of space), but it may not be very suitable as a standard way defined in a spec.

For the spec I think we need to answer what we're trying to optimize for. Things running through my mind include:

How important is size? Do we want the absolute minimal encoding, or are we willing to trade it off for something else? (say speed)
How important is performance? Should we try to keep the encoding 8-bit aligned?
Sortable. TypeIDs promise to be k-sortable, and in some applications like DBs their sorting order is important. Do we want the binary representation to guarantee the same sorting order as the string representation? (if not, some implementations might end up sorting differently depending on which of the representations they use for sorting)

Do you have any thoughts on these?

Tagging people who have implemented typeid libraries in other languages: @cbuctok @sloanelybutsurely @fxlae @softprops @faustbrian @akhundMurad @broothie @conradludgate @johnnynotsolucky @Frizlab @ongteckwu @tensorush
Do you have a need for a binary encoding specification? If so, what properties do you think are important for your use cases?

For a binary encoding, I would expect to have an already typed binary schema. In that case, I'd personally use a UUID big endian 16 byte encoding rather than create anything bespoke. Since my binary schema would already be typed, I would forfeit the type prefix.
For a nontyped binary format like cbor, I could imagine a custom encoding though. Cbor has no byte alignment properties so I would perhaps encode the prefix str and the 16 bytes as a cbor array

I wonder if we're better off not defining a binary enconding as part of the spec and leaving it up to the use case. The examples @conradludgate gives make me think the ideal encoding is use-case dependent. If you can already guarantee the type in your binary format, you can completely elide the prefix, and re-introduce it when decoding the binary representation. If you want to encode the type, you might be better off using the representation suggested by the format you're using (i.e. cbor might represent a string + vector one way, protobufs and jsonb might do it a different way)

I created the lib just "because I could" and am not using it, so I'd be happy with whatever binary encoding specs you guys will come up with 🙂

IMO, it would be better to define several possible encoding options for a variety of use cases.


global: rename of pid_type to depid

Changes the default pid_type to depid. (closes #44)

Removes unused imports.

Signed-off-by: Javier Delgado<EMAIL_ADDRESS>

Coverage remained the same at 94.828% when pulling d3e7508a762cfd7c7a6f3aad321ac9704a207386 on JavierDelgadoFernandez:pid_type_rename into 86a127e925edc4868dd63b2c9042674854c656a6 on inveniosoftware:master.

@JavierDelgadoFernandez can you please check the failing tests?

@jirikuncar @lnielsen With invenio-records-files==1.0.0a2 all the test pass successfully. With 1.0.0a3 or higher, 5 tests are failing. I'm checking now how to fix it.

id has been changed to key

I can confirm, it's failing also for me...
what exactly is changed?
Someone is already in-charge of fix it?


x/pkgsite: Removal of github.com/ChargedByte/Adopter

Hey, I found that one of my old modules was still up on the packages site. I no longer have this repository or the source code so I can't retract it myself, could this be removed from the site.
github.com/ChargedByte/Adopter

Thank you!

Done.


Prefer "Rebase Merging"

I think preserving the commit history of the head branches of PRs when merging can provide value: prefer "Rebase Merging" over the current "Squash Merging" approach. @devoto13 ?

Sound good!


Fix serviceAccount propagation/override from TaskRun

If a Task specify a ServiceAccountName but the TaskRun referencing
it doesn't, the resulting BuildSpec will contain no
ServiceAccountName instead of having the Task one.
Closes #305
Signed-off-by: Vincent Demeester<EMAIL_ADDRESS>

/cc @bobcatfish @pivotal-nader-ziada @shashwathi

/lgtm

Good call! thanks for taking this on @vdemeester :D
/approve
p.s. if you happened to feel like adding some docs on serviceAccounts to using.md that would be super cool :heart_eyes:  just sayin ;)


Output image format (jpg, etc.)

Some users of my script reported that when upscaling a large sum of images, saving frames in JPEG format saves a lot of storage space as compared to PNG.
In waifu2x-caffe, you can specify output image format using the -e option, but I didn't see something similar in waifu2x-converter-cpp's help page.
Would you be interested adding support for other output image formats?

JPEG is a lossy and compressed format. hence the size difference, PNG is lossless and the better alternative for storage purposes.
But yeah, just use -o and change the extension
w2x.exe -i inputfile.png -o outputfile.jpg will save as jpg

I know that it's lossy, but I just wanted to see how big the difference is.
Forget about this issue for now and here's why:
I did some tests with PNG and JPEG, and here are the results with waifu2x-caffe:
PNG

JPEG

The quality loss is way beyond what I was expecting, so please forget about this issuse.

Maybe need to add a jpeg quality option.

Maybe need to add a jpeg quality option.

I do, for FFMPEG. Though at this point I'm questioning whether it's worth it to even try to get JPEG to work, since the whole point of waifu2x is to get sharper image and etc.

w2x.exe -i inputfile.png -o outputfile.jpg will save as jpg

On this topic though, my focus is on the situation where the input is a folder. I tried it earlier on, but if input is JPG, output seems to still be PNG.

convert the output file in jpg with ffmpeg?

convert the output file in jpg with ffmpeg?

then it will lose the point of saving disk space

Fixed via #116, once its merged and reviewed

@DeadSix27 wow nice. Thanks.


Can vllm serving clients by using multiple model instances?

Based on the examples, vllm can launch a server with a  single model instances. Can vllm serving clients by using multiple model instances? With multiple model instances, the sever will dispatch the requests to different instances to reduce the overhead.

Right now vLLM is a serving engine for a single model. You can start multiple vLLM server replicas and use a custom load balancer (e.g., nginx load balancer). Also feel free to checkout FastChat and other multi-model frontends (e.g., aviary). One can make vLLM a model worker of these libraries to have multi-model support.


cmd/compile: switch statement on a custom int32 type with negative values behaves differently in two consecutive calls

What version of Go are you using (go version)?

$ go version
go version go1.12.6 darwin/amd64

Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/bartek/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/bartek/gocode"
GOPROXY=""
GORACE=""
GOROOT="/Users/bartek/Downloads/go"
GOTMPDIR=""
GOTOOLDIR="/Users/bartek/Downloads/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/zv/kh35w1j12wn5_4md98dl9zfr0000gn/T/go-build400417808=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
https://play.golang.org/p/da7SYpb02ed
A switch statement on a custom int32 type with negative values behaves differently in two consecutive calls to the same function. What is strange is that each of the following changes make this application work correctly:

Changing BucketEntryTypeMetaentry to a positive number.
Commenting one or more empty case clauses.
Adding fmt.Println("ok") between entry.MustMetaEntry() lines (lines 40 and 41).
Adding fmt.Println("ok") anywhere inside MustMetaEntry().
Removing MetaEntry on BucketEntry.

What did you expect to see?
No output:

What did you see instead?
panic: oh no

goroutine 1 [running]:
main.BucketEntry.MustMetaEntry(...)
	/Users/bartek/gocode/src/github.com/stellar/go/custom_type.go:31
main.main()
	/Users/bartek/gocode/src/github.com/stellar/go/custom_type.go:41 +0x81
exit status 2

Please note that function call in line 40 does not panic.

Interesting.  Works with Go 1.10 and gccgo, fails with Go 1.11, 1.12, and tip.
CC @randall77 @josharian @dr2chase @mdempsky

Inspecting the GOSSAFUNC=main output, it looks like the "generic deadcode" pass gets rid of the normal Return path, and leaves behind only the two panicking paths.

Minimized:
package main

var x int32 = -1

func main() {
	if x != -1 {
		panic("oh no")
	}
	if x > 0 {
		panic("oh no")
	}
}

Actually that test case only fails at tip. Here's one that fails back at Go 1.11 too:
package main

var x int32 = -1

func main() {
	if x != -1 {
		panic("oh no")
	}
	if x > 0 || x != -1 {
		panic("oh no")
	}
}

Bisected to CL 100278 (29162ec9a).
/cc @rasky

And FWIW, the simpler test case bisects to CL 165617 (4a9064ef41).
It's because that CL swaps the order that the bThen and bElse blocks are created, and apparently prove.go is sensitive to that.

I think the problem is this check:
// Check if the recorded limits can prove that the value is positive
if l, has := ft.limits[v.ID]; has && (l.min >= 0 || l.umax <= math.MaxInt64) {

The l.umax <= math.MaxInt64 check doesn't make sense for int8, int16, or int32, because they still have negative values whose unsigned representation is less than MaxInt64.

I'm curious what folks think about this issue.
On the one hand, it seems embarrassingly bad and in need of a fix and backport.
On the other, it's been in stable releases for almost a year and this is the first we've heard of it?

If the fix seems safe then I would vote for fixing and backporting.

@ianlancetaylor The fix seems straight forward enough to me, but it could definitely use some more eyes from the usual package ssa reviewers. This was my first time looking at prove.go. (Thanks to @josharian for the quick review and +1.)

Thanks for checking this so quickly!

On the one hand, it seems embarrassingly bad and in need of a fix and backport.

One thing I'm wondering about is if it poses any security risk. Consider this code. Obviously, this is a bad code and a simple test (or even testing it manually) would catch it quickly but it shows the potential risks.

On the other, it's been in stable releases for almost a year and this is the first we've heard of it?

Actually, the original code that revealed this bug was different but I submitted the other snippet because it was isolated. The thing is, at first I really though that it's probably something wrong with my code (not Golang) and I could easily fix this by changing entry.MustMetaEntry() to entry.MetaEntry:
	if entry.Type == BucketEntryTypeMetaentry {
		meta2 := entry.MetaEntry
		fmt.Println(meta2)
	}

But I started digging... I guess that maybe (maybe!) there were other instances of this but devs just changed their code to work thinking it's an issue with their code.

cc also @aclements @zdjones for prove

Is the fix enough?
I would expect the minimized test to fail with int8 and int16 but it passes for me in the playground.

I would expect the minimized test to fail with int8 and int16 but it passes for me in the playground.

Hm, interesting.

Just looking at the code, I would guess int8 and int16 don't reproduce the issue simply because prove.go only looks for 32- and 64-bit operations (eg, OpAdd64, OpAdd32, OpConst64, OpConst32).

@gopherbot please open backport issues. This is an important compiler correctness bug with a safe, localized, minimal fix.


Unicode code points >$FFFF

Now engine don't catch code points >FFFF. they are encoded by 2 widechar's. engine sees 1 widechar as 1 code point, it's bad.
codepoints >FFFF must be catched by \S \D \W etc. and also by new \p \P. they must give match with len=2.
Todo.
Docs https://regular-expressions.mobi/unicode.html

example file in UTF16 to test in CudaText.
emoji combined.zip


Add support for fileglobs

This change is backwards compatible. The only odd behavior I encountered during testing is that I had to always quote my glob patterns. This seems to be a limitation of docopt. For example:
❯ mark -f "helpful_cmds/*.md"

Quoting remains unnecessary if being used as before (one file at a time).
Also worth noting that Go does not support double star matching yet (https://github.com/golang/go/issues/11862).

Thank you!


fix(swap): modal

Related to YOMO-910

Working on a improvement

closed in favor of https://github.com/Emurgo/yoroi/pull/2842


Added changes to heading files

All of the required changes to implement CoreLocation's Heading and some general CoreLocation functions, along with tests for those functions included.

@nithishm is added to the review. #Closed

@mnithish is added to the review. #Closed

@jaredhms is added to the review. #Closed

}

nit: these can be easily implemented.

Refers to: Frameworks/CoreLocation/CLHeading.mm:76 in 1de20c3. [](commit_id = 1de20c341c92873973cdae1a46ae46fe2d0aeaec, deletion_comment = False)

:clock1:

Discussed with Jared and Raj today, there doesn't seem to be any compelling reason you would ever want to serialize heading measurements, as the actual usage of heading measurements is to generate and read them on the spot. Because of this, I'm leaving the serialization APIs alone.

FAIL_FAST_IF_MSG((s_extendedExecutionRequestCount == 0), "There is no extended execution session active!");

This fail fast has to be removed - take the case when application is requesting for periodic heading/location update but does not have the required background permission, _removeExtendedExecutionSession will be called with s_extendedExecutionRequestCount = 0. I think the code was added before to catch miss-matched call to add/remove extended execution which is not valid any more with this change.

Refers to: Frameworks/CoreLocation/CLLocationManager.mm:107 in f593e8b. [](commit_id = f593e8b5e3ca16c9cd6f89bbabe681624aec199f, deletion_comment = False)

I went ahead and removed the FAIL_FAST and replaced it with a return if s_extendedExecutionRequestCount == 0. I believe this is what you wanted?

Apologies for the late response to your last update.  Everything looks good, but this branch has merge conflicts.  Can you please address them?

:shipit:

It looks like the conflict just required a minor tweak to the MainViewController. Made this change and it looks like WOCCatalog still has everything I expected in it.

Thanks.  In CI build.


win2012r2-standardcore-ssh.json template has the wrong vm_name for some of the builders

While checking the vm_name for some of the templates, the win2012r2-standardcore-ssh.json template is using the same name for the win2012r2-standardcore.json template. This inconsistency will only affect the template name during building, but prior to post-processing the template into a vagrant box. Things can get funky if you're building both of these templates at the same time from the same directory.

Ftr this only affects the vmware-iso, virtualbox-iso, and parallels-iso builders.
This was found with the following jq query:
jq '([.builders[] | .vm_name] | unique) as $names | {name: $names, length: ($names | length) } | select(.length > 1)' *.json

This is fixed by PR #215.


Add end_time field

Is there an issue about this? Why are we adding it to the protocol if it is calculated from other fields and clients already need to do this anyway?

@leandro-lucarella-frequenz
Issue: https://github.com/frequenz-io/frequenz-service-dispatch/issues/82
Shortly:

We would like to have an option to sort dispatches by end time.
Client doesn't need to calculate the end_time.  End_criteria for reoccurring dispatches is either:
a) optional - infinite dispatch
b) count (how many times to execute)
c) until - max end time  (not accurate)

In b) and c) we need to calculate accurate end time and save as end_time in the database.

Thanks! BTW, I'm now using the GitHub handle @llucax, I only use the frequenz one as admin, so in my every-day work I don't have admin access.


Thoughts on adding a few utility methods?

Just curious if you've considered adding map($callback) and filter($callback) methods to the collections as I find myself wishing these existed quite often.  These would be value operations and wouldn't affect dictionary keys (though I suppose there may be uses for mapping/filtering keys, I haven't run into a use case yet).  Would be happy to implement and submit a pull request if you feel they could be worthwhile additions.
Thoughts?

Have you tried Knapsack?

No, first time I've heard of it.  Looks very interesting...I suppose no real reason to add map/filter functionality when there's another lib that provides it already (because this isn't Javascript, amirite...)
Thanks for the quick response!

Knapsack should work just fine with this package, since it operates on anything that is Traversable. Let us know if it doesn't work for you!


Reserve out_name namespace for compiler internal use

This will allow for compiler internal only names to be used as output without the risk of conflicting with a user supplied out_name. This comes up with the SQL backend with columns that are needed in intermediate results, but that aren't included in the final output.

If you can appease isort, this is fine by me.

Coverage decreased (-0.2%) to 95.065% when pulling edaba93652630b8ccb064a01dbd72868214d9799 on compiler_reserved_words into 53910728e54e49941b855266b7d7259a858bce35 on master.