melon loader wont launch multiple instances.

All of the following criteria must be met

[X] All Requirements must be installed.
[X] Changed the title so that it doesn't just says "[Bug]: "
[X] I have searched the GitHub issues for my bug, even in the closed issues.

All of the following are optional to answer

[X] Tried reinstalling the Game.
[X] Tried reinstalling MelonLoader.
[X] Tried restarting PC.
[ ] Was able to see the Start Screen.

Describe the issue.
version 6.0.3. was working in version 5.7.4. the game crashes before the start screen.
The game was Karlson 3d by Dani
Latest.log
Did you attach your log file?
Yes, I attached my log file to the text box above.

This issue is already resolved in the latest alpha-development nightly build for an upcoming v0.6.5 update.


build: improve a17 e2e app dx

Seems IDE got confused following symlinks, adding paths so it can follow Typescript imports.
Also, adding run config to build A17 E2E app

Current dependencies on/for this PR:

main

PR #42   👈

This stack of pull requests is managed by Graphite.


Cannot find declaration file

Installed tailwindcss-animate into a workspace and keep getting an error. I tried adding a global.d.ts file with declare module 'tailwindcss-animate', but nothing seems to work. Any ideas on how to fix this?

Published new version


Pin OneTimePassword library to exact commit

This will pin the OneTimePassword swift package to an exact commit (The one already in Package.resolved). This will avoid problems if users accidentally click "Update to Latest Package Versions" which will pull the latest OneTimePassword develop branch -- which will break Loop builds.
Once this merges, we will need to run "Update to Latest Package Versions" in the Loop workspace which should update the below file, like the diff I have copied below, to reflect that we point to a commit and not a branch.
Loop.xcworkspace/xcshareddata/swiftpm/Package.resolved
       "kind" : "remoteSourceControl",
       "location" : "https://github.com/mattrubin/OneTimePassword",
       "state" : {
-        "branch" : "develop",
         "revision" : "8e4022f2852d77240d0a17482cbfe325354aac70"
       }

I'm not sure about the Xcode change... Opening Xcode automatically adds the "branch" line back in.
I think users running "Update to Latest Package Versions" is not advised anywhere, and I think anyone trying it (an actual developer) should be prepared for breaks.

@ps2  I just pulled the latest dev workspace with these updates and Xcode wants to kill that "branch" line which is what I'd expect with our package changes. We can see how it goes for others.

@ps2 Actually it is pretty aggressively trying to remove that branch line... Unfortunately we may want to revert this change if it is forcing the opposite on other Xcode installs. I'm not sure why that would be happening but i suspect caching.


[DNM] raftstore: use read index to serve read request

So we can reduce apply count and improve read performance.
Please note that, this pr should not be merged until coreos/etcd#7331 is closed and related changes are ported.
@siddontang @hhkbp2 @zhangjinpeng1987 PTAL

@hhkbp2 do we need to port https://github.com/coreos/etcd/pull/7332 now?

@siddontang As @BusyJay commented before, it should be ported before this PR could be merged.


Update QuickStart doc.

The API in the QuickStart example is out of date:
https://github.com/TheoBourdais/ComputationalHypergraphDiscovery/blob/5cfe4349119ea8ee58dcce336f75959e3996b294/src/ComputationalHypergraphDiscovery/_GraphDiscoveryMain.py#L73
It seems that the example should be updated like this:
kernels=CHD.Modes.LinearMode()+CHD.Modes.QuadraticMode()
graph_discovery = CHD.GraphDiscovery.from_dataframe(df,mode_kernels=kernels)

Thank you for pointing this out, this is fixed.


Add tfrs.Model type support

Describe your changes and why you are making these changes
Adds type support for any non-pickleable classes that inherit from tf.keras.Model. tf.keras.Model objects themselves are actually picklable, and so are already supported by our typing system.
In the example notebook torn pulled from https://www.tensorflow.org/recommenders, we can actually get it working with the existing system if train_model returns the user and movie models directly, instead of the MoveLensModel, which is a tfrs.Model (which inherits from tf.keras.Model).
If train_model() returns a MovieLensModel, we get the following error:
ValueError: Model <__main__.train_model.<locals>.MovieLensModel object at 0x7f1f20436100> cannot be saved either because the input shape is not available or because the forward pass of the model is not defined.To define a forward pass, please override `Model.call()`. To specify an input shape, either call `build(input_shape)` directly, or call the model on actual data using `Model()`, `Model.fit()`, or `Model.predict()`. If you have a custom training step, please make sure to invoke the forward pass in train step through `Model.__call__`, i.e. `model(inputs)`, as opposed to `model.call()`.

I wonder if there's an easy way to get around this? I can take a look at specifying an input shape in the meantime.
Related issue number (if any)
ENG-1822
Loom demo (if any)
Checklist before requesting a review

[ ] I have created a descriptive PR title. The PR title should complete the sentence "This PR...".
[ ] I have performed a self-review of my code.
[ ] I have included a small demo of the changes. For the UI, this would be a screenshot or a Loom video.
[ ] If this is a new feature, I have added unit tests and integration tests.
[ ] I have run the integration tests locally and they are passing.
[ ] I have run the linter script locally (See python3 scripts/run_linters.py -h for usage).
[ ] All features on the UI continue to work correctly.
[ ] Added one of the following CI labels:

run_integration_test: Runs integration tests
skip_integration_test: Skips integration tests (Should be used when changes are ONLY documentation/UI)

@cw75 from this it sounds like tf keras models are supposed to be picklable "for now", but that they recommend using model.save()? I still like our ordering though because of that bug in the description.


Does this support ckks bootstrapping

No, this library does not currently support bootstrapping.

Can you add CKKS's bootstrapping


Issue with amulet2.0 generating remainder in primary inputs only

I was trying to run another test case with an internal node s-a-0. I see that amulet1.0 and amulet1.5 are able to generate the correct remainders in terms of primary inputs only. However, amulet2.0 generates a remainder in terms of non-primary inputs for the exact same test case.
Attached the test case (blif/aig)
4-bit-n18-sa-0.zip

@d-kfmnn

In amulet2.0 I use a different ordering method than in amulet1.x
Thanks again for the test case. I'll check out what causes the problems.
Best, Daniela

Hi,
indeed the new ordering in AMulet2 broke on your example, which is now fixed.
Daniela


Terragrunt Plan requiring a real value for mock_outputs with resource azurerm_windows_function_app

Running a plan against the new azurerm_windows_function_app resource results in the error below and will not accept a mock output and continue. The exact same setup with the deprecated azurerm_function_app works as expected and honors the mock values. Based on the error details, it appears the new resource requires actually seeing what tier the service plan is on and it can't get that from a mock value. Both tests were performed using the azurerm_service_plan resource for the app service plan.
Error: could not read new Service Plan to check tier Service Plan: (Serverfarm Name "mock-asp" / Resource Group "mock-rg"): web.AppServicePlansClient#Get: Failure responding to request: StatusCode=404 -- Original Error: autorest/azure: Service returned an error. Status=404 Code="ResourceGroupNotFound" Message="Resource group 'mock-rg' could not be found."
A plan does run successfully when using the resource ID of an existing App Service Plan (actual resource existing in Azure) entered as the mock output in the terragrunt.hcl of the Function app. For reference: https://github.com/hashicorp/terraform-provider-azurerm/issues/17376
Since the whole point of mock outputs is to not have resources already existing, an adjustment to how Terragrunt handles this resource type will probably be needed. We shouldn't have to use a real value for a mock output. While using a real ASP ID is a sort of workaround, it isn't sustainable since if the referenced App Service Plan is deleted, the code will be broken. This also doesn't work if the app is being deployed in a new subscription or a subscription that doesn't have any App Service Plans deployed yet.
Also of note, using any of the 3 options for mock_outputs_merge_strategy_with_state, results in the same: Error: could not read new Service Plan to check tier Service Plan
Function App resource
resource "azurerm_windows_function_app" "function_app" {
app_settings = var.fa_app_settings
location = var.region
name = "test-azf"
resource_group_name = var.resource_group_name
service_plan_id = var.fa_service_plan_id
}
Dependency and Input in Terrarunt.hcl
include {
path = find_in_parent_folders()
}
dependency "app_service_plan01" {
config_path = "../../appserviceplan/appserviceplan01"
mock_outputs = {
asp_id = "/subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/mockrg/providers/Microsoft.Web/serverfarms/mockasp"
}
mock_outputs_allowed_terraform_commands = ["validate", "plan"]
mock_outputs_merge_strategy_with_state = "shallow"
}
inputs = {
fa_service_plan_id = dependency.app_service_plan01.outputs.asp_id
}
Output from the App Service Plan module
output "asp_id" {
description = "ID of ASP"
value = module.asp.asp_id
}

Hi,
I suspect existing resource ID should be imported to Terraform state to be picked correctly during Terragrunt execution
https://developer.hashicorp.com/terraform/cli/import

Seeing the same issue.

any update to this? we are seeing this issue as well and it is a massive pain point when deploying to different subscriptions.

bump - this is a priority for our organization. Is anyone actively working to resolve this?

now ran into the same issue cant execute terragrunt run-all plan to actually deploy a service function without an existing deployment

Same here: 2 folders deployment, a secret for secret manager is created into the first folder, the second folder terrafrom is supposed to read it and use it into an RDS deployment, mock value added as part of outputs from the first folder:
Error: Secrets Manager Secret "mock-secret" not found

Is there any way to get someone to look at this? It is a recurring pain point for us.

Hi, I suspect existing resource ID should be imported to Terraform state to be picked correctly during Terragrunt execution
https://developer.hashicorp.com/terraform/cli/import
We are not working with existing infrastructure here that needs to be imported. These are net new deployments that need the mock outputs to work without requiring real resources to exist in advance.

@denis256 Could you take a second look at this? I believe this was orifinally misdiagnosed as something needing to be imported.

I'm experiencing the same issue, please fix.

Hi,
can be shared example code/repository where this issue happens?

We don't have the code in a public repo but the example provided should hopefully be enough to reproduce:
Function App resource: Main.tf
resource "azurerm_windows_function_app" "function_app" {
app_settings = var.fa_app_settings
location = var.region
name = "test-azf"
resource_group_name = var.resource_group_name
service_plan_id = var.fa_service_plan_id
}
Dependency and Input: Terragrunt.hcl
include {
path = find_in_parent_folders()
}
dependency "app_service_plan01" {
config_path = "../../appserviceplan/appserviceplan01"
mock_outputs = {
asp_id = "/subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/mockrg/providers/Microsoft.Web/serverfarms/mockasp"
}
mock_outputs_allowed_terraform_commands = ["validate", "plan"]
mock_outputs_merge_strategy_with_state = "shallow"
}
inputs = {
fa_service_plan_id = dependency.app_service_plan01.outputs.asp_id
}

@denis256 It's great to see this added to the roadmap. Any timeline on getting this one fixed?

Hey @bdorplatt ,
I'd like to understand this issue better. Please confirm if my understanding is correct, and let me know if my response makes sense.
My understanding of the issue is that the resource azurerm_windows_function_app throws an error during applies with mocked values for the attribute service_plan_id, because the Azure provider is trying to lookup a corresponding service plan with an ID that doesn't exist within Azure.
It attempts to make a network request to Azure to fetch information about the service_plan_id, and returns the following error (formatted to make it easier to parse):
Error: could not read new Service Plan to check tier
Service Plan: (Serverfarm Name "mock-asp" / Resource Group "mock-rg"): web.AppServicePlansClient#
Get: Failure responding to request: StatusCode=404 --
Original Error: autorest/azure: Service returned an error. Status=404
Code="ResourceGroupNotFound"
Message="Resource group 'mock-rg' could not be found."

This is an error returned from the OpenTofu/Terraform Azure provider based on the value passed in at the OpenTofu/Terraform layer. So on plan, OpenTofu/Terraform attempts to make a network request using the value set on service_plan_id.
Assuming I'm understanding the issue correctly, what you're looking to accomplish with Terragrunt is populate the value of fa_service_plan_id with something that the provider will use in such a way that the network request it emits to Azure won't return a 404 HTTP status code like with the value of https://.../mock-rg used from the mocked value.
In order to accomplish this, you'll want to use Terragrunt to populate the input such that the provider will submit a network request and get a 200 HTTP status code back, which will allow you to finish the plan.
There are two ways you can accomplish this.
First, you can hard-code a valid asp_id:
dependency "app_service_plan01" {
	config_path = "../../appserviceplan/appserviceplan01"
	mock_outputs = {
		asp_id = "/subscriptions/<a real id>/resourceGroups/<a real resource group id>/providers/Microsoft.Web/serverfarms/<a real value>"
	}
	mock_outputs_allowed_terraform_commands = ["validate", "plan"]
	mock_outputs_merge_strategy_with_state = "shallow"
}

inputs = {
	fa_service_plan_id = dependency.app_service_plan01.outputs.asp_id
}

What this will do is make it so that the network request that's sent by the provider always sends the request to that hard-coded value, regardless of the context of how it's being used.
Note that if you do this, the plan that you will see will show the value of the service_plan_id set to that hard-coded value. During applies, the real value will be fetched from the dependency, so you will end up with the real provisioned resource being referenced.
If the resource is going to be deployed in many different contexts, and you cannot use a single hard-coded value, see if you can leverage something like run_cmd to solve this problem.
I don't know much about the Azure CLI, and I don't have access to an Azure account, but you would presumably be able to combine the command az appservice plan show with run_cmd to accomplish something like the following:
dependency "test" {
  config_path = "test"

  mock_outputs = {
  	mock_id = run_cmd("--terragrunt-quiet", "date")
  }
  mock_outputs_allowed_terraform_commands = ["validate", "plan"]
  mock_outputs_merge_strategy_with_state = "shallow"
}

generate "main" {
  path = "main.tf"
  if_exists = "overwrite"
  contents = <<EOF
variable "mock_id" {}

output "mock_id" {
  value = var.mock_id
}
EOF
}

inputs = {
  mock_id = dependency.test.outputs.mock_id
}

In this example, you can see that the value used for mock_id is something dynamic like date. When the dependency test doesn't have any values, Terragrunt will instead execute the date command, and use that as the value for mock_id. Thus, my plan looks like this:
❯ terragrunt plan

Changes to Outputs:
  + mock_id = "Fri Jul 19 14:43:51 EDT 2024"

In your use-case, you would replace this: mock_id = run_cmd("--terragrunt-quiet", "date") with something using the Azure CLI to return a valid fa_service_plan_id, then pass that through when mocked.
Let me know if that helps, or if I've misunderstood your problem.

Hello @yhakbar the solution you are suggesting, using a real resource ID is the exact workaround we are currently implementing. We would like a real solution to this where using a generic mock value will not return an error. This works correctly with every other Azure resource type we have coded mock inputs for.  azurerm_windows_function_app is the only one resource we see this issue with, and as mentioned in my original submission, the exact same setup with the deprecated azurerm_function_app works as expected and honors the mock values. So certainly, this should be something that can be fixed, and not use the workaround as a permanent solution.

Hey @bdorplatt ,
Is it clear that the thing returning an error is the Azure OpenTofu/Terraform provider?
This is where that would be adjusted: https://github.com/hashicorp/terraform-provider-azurerm
Terragrunt provides tooling for orchestrating updates to Terraform/OpenTofu, but it's the providers that actually send the network requests based on the inputs they're given.
If you would like to have it so that the provider will accept a mock value as input to the service_plan_id attribute of azurerm_windows_function_app, that's something the team managing the Azure provider will have to change. We have no control over that.
Yousif

Why does this work for every other resource? Why is this one different from all of the others? If this is a provider issue interacting with Terragrunt, can someone from Gruntwork team engage the AzureRM provider team to find a fix?

According to the explanation in https://github.com/hashicorp/terraform-provider-azurerm/issues/17376, this works on other resources because they don't need to perform a schema check based on the service plan's configuration to determine whether or not the value is appropriate.
Maybe I'm misunderstanding, but didn't the maintainers of the AzureRM provider indicate that this behavior was intentional in that issue? I don't think they're open to discussing a fix, as they want the resource to work this way.
To confirm, you can replicate this issue using OpenTofu/Terraform directly, correct? Terragrunt calls one of those tools installed locally on your machine, which uses the AzureRM provider to dispatch API requests to Azure.
What Terragrunt is going to be able to do is help you set up appropriate values expected by the provider in OpenTofu/Terraform.

That doesn't make sense since this also works for azurerm_windows_web_app which interacts with the azurerm_service_plan in the same way. In the referenced Terraform issue that we opened, it was concluded that this was a Terragrunt issue: "this is specific to Terragrunt mocking and isn't a provider bug "
@denis256 added this issue to the roadmap, so surely there is something that can be done to fix it on the Terragrunt side.

I'll make sure to double-check with him, but as far as I can tell, there isn't actually a fix that Terragrunt can make that will result in the provider accepting an invalid value for the service_plan_id on the azurerm_windows_function_app resource.
How are you looking to have this issue solved, though? The provider needs a valid value for service_plan_id, right? Would a solution that fetches the ID for a different service plan as the mocked value be sufficient?

Hey @bdorplatt ,
I've confirmed with @denis256 , and we were adding this to the roadmap to investigate why the issue happened and to document potential workarounds. I can see why that was confusing, and agree that putting it on the roadmap can reasonably give the impression that there's a fix that can be made when there isn't.
We'll update our process to account for this to make it clear that something is either going on the roadmap to be worked on in the future, or give an explanation on the issue why else it is being placed on the roadmap.

If Gruntwork can't fix this then who is able to? Is it Microsoft, Hashicorp? The inconsistency hasn't been addressed as to why azurerm_windows_web_app which interacts with the azurerm_service_plan works with a mock (not real) value but azurerm_windows_function_app which interacts with the azurerm_service_plan in the same way does not.
Using a real value as a mock input, which we have been using as a workaround all along, defeats the purpose of using mock inputs. If the real service plan that is referenced goes away, our code becomes broken.

Hello! I tried to reach out to Felipe to try to schedule a call about this.
If you can, please reach out to<EMAIL_ADDRESS>so we can set up a call. We want to chat about what the problem is and why it's happening and why it feels inconsistent in a medium that has a little more interaction.
FWIW, I just ran into the exact same issue plotting multi-account examples using mock outputs for subnet id's in the AWS provider.


feat: add NewClientFromCredentials function

Instead of reading credentials from environment variables (like NewClient),
NewClientFromCredentials has four parameters:

email
password
keycloakEnabled
apiHost

NewClient now calls NewClientFromCredentials after reading the
credentials from the environment variables.

This is useful for the Terraform provider which stores the Taikun credentials in its schema and uses taikungoclient for API calls.


Calculate GitOID as part of CalculateDigestSet function

Title: Calculate GitOID as part of CalculateDigestSet function
Currently, the GitOID is only calculated for the file attestor, which means that the GitOID calculation logic is not reusable in other parts of the codebase. To address this issue, we should move the GitOID calculation logic into the CalculateDigestSet function and make it an option that can be enabled via the options pattern.
To achieve this, we can define a new WithGitOid option that sets a boolean flag indicating whether the GitOID calculation should be performed. We can also define a CalculateDigestSetOptions struct to hold the various options for the CalculateDigestSet function, including the hash functions to be used for digest calculation.
Using the options pattern, the CalculateDigestSet function signature would look like this:
func CalculateDigestSet(r io.Reader, opts ...CalculateDigestSetOption) (DigestSet, error)
By moving the GitOID calculation logic into the CalculateDigestSet function and making it an option, we make the GitOID calculation more reusable and maintainable.

This may exist today but, we need to check.


Fix thrift mapper for DomainConfiguration

What changed?
Add missing field to thrift mapper for DomainConfiguration

Why?

How did you test it?
manual test

Potential risks

Release notes

Documentation Changes

Pull Request Test Coverage Report for Build 018801f2-6b1f-4525-ae2b-16894c33b85d

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
279 unchanged lines in 18 files lost coverage.
Overall coverage decreased (-0.05%) to 57.159%

Files with Coverage Reduction
New Missed Lines
%

common/task/fifoTaskScheduler.go
2
87.63%

common/task/weightedRoundRobinTaskScheduler.go
2
89.12%

common/util.go
2
52.98%

service/history/execution/mutable_state_util.go
2
35.95%

common/persistence/nosql/nosqlplugin/cassandra/workflow.go
3
59.1%

common/persistence/statsComputer.go
3
94.64%

service/matching/taskListManager.go
3
81.15%

service/history/task/fetcher.go
4
91.24%

service/history/task/transfer_standby_task_executor.go
4
86.51%

common/persistence/serialization/parser.go
8
63.91%

Totals

Change from base Build 0187fe29-6d96-4c7b-892a-38a7e530a265:
-0.05%

Covered Lines:
86013

Relevant Lines:
150481

💛  - Coveralls


Gradle should explicitly control set of include paths used

We investigated a failure on two different machines for #551.  Ultimately, we traced this back to a couple of issues:

Without supplying the macOS platform, you cannot use headers/libraries from the macOS platform.
Adding the macOS platform by default can break some builds because of the implicit ordering enforced by the compiler and the set of "standard includes" used by the compiler.

To make this less susceptible to "it works on my machine", Gradle should explicitly control the list of includes.  This means:

Passing -nostdinc (or equivalent) to compiler
Add opt-in convenience for adding standard includes

I did some more reading on this issue and it appears to be a multi-layer problem that seems to suggest other consideration for improvement.
The main issue is that /usr/include seems to contain an older version of libstdc++ (GCC/GNU), more precisely, version 4.2.1. However, Xcode SDK is based around libc++ (LLVM). It seems to be a widespread issue that some project only detect at runtime where both runtimes are linked inside the same binary. The "real" C++ library should be the one inside selected Xcode SDK and /usr/include should be ignored. In fact, there are a lot of "real" C++ library, and it depends on what you are trying to achieve.
To discover the "real" C++ library, we need to use the concept of system root (--sysroot and -isysroot) which is:

Use dir as the logical root directory for headers and libraries. For example, if the compiler normally searches for headers in /usr/include and libraries in /usr/lib, it instead searches dir/usr/include and dir/usr/lib

If we query the toolchain using clang -v -dM -E - < /dev/null we get the following:
#include <...> search starts here:
 /usr/local/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)

However, if we query the toolchain using the Xcode SDK as the system root using clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -v -dM -E - < /dev/null we get the following:
#include <...> search starts here:
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks (framework directory)

Note the discovered include roots are completely different. It's also the key for cross-compiling between macOS and iOS.
I think we should defer for a bit longer using -nostdinc and building our include roots. Instead, we should properly model system root for GCC and Clang.

@adammurdoch could you fix this up?

Could you split this into two issues @adammurdoch for nostdinc and sysroot


auto-select the icon based on the platform

Expecting something like
<Button transparent >
   <Icon name="arrow-back" />
</Button>
or even
<Button transparent >
  <Icon
    nameIOS="ios-arrow-back"
    nameAndroid="md-arrow-back"
  />
</Button>

Instead of current workaround:
<Button transparent >
  <Icon name={Platform.OS === 'ios' ? 'ios-arrow-back' : 'md-arrow-back'} />
</Button>

Hi, platform based icon selection will be a part of v 2.0.0 of native-base. It'll also be backwards compatible so you won't have to worry about that.


The response is very slow when I add a plugin in the version of 0.10.2

Summary
I have upgraded Kong to the version of 0.10.2. When I add a plugin to my Api, it will return the response data about 40 senconds. It's very slow for me.
Steps To Reproduce
When I add the plugin like
apiName: test1
name: key-auth
Then add the plugin by curl：
curl -X POST http://localhost:8001/apis/test1/plugins
--data "name=key-auth"
So I will get the response data：
{"api_id":"83378633-1f68-4789-9599-c260dc23bafd","id":"467d37ed-c03b-49f7-8754-44beafb52868","created_at":1494152015000,"enabled":true,"name":"key-auth","config":{"hide_credentials":false,"key_names":["apikey"],"anonymous":""}}
But the return time is about 40 seconds or more, it's too slow.
When I add the plugin in other versions, the return time is very short. How to shorten the return time in the version of 0.10.2, make some modifications to the configuration or waiting for the next version which will fix this bug？ Thank you very much

@ssholder do you see this behavior on every single request, or just the first time you attempt to consume this API?

@p0pr0ck5 For all Apis when I add the plugin, the return time for response data is too slow.

Do you see this with just the key-auth plugin, or all plugins?
There's nothing in Kong 0.10.2 that should cause such a massive delay; sounds like there is a problem elsewhere in your environment, such as a poor/timing out connection to postgres/cassandra. Do you see anything in the error logs of note (default location: /usr/local/kong/logs/error.log)?

@p0pr0ck5 Thank you for your help.
1) I check the error logs when I add a plugin, then I get the error information:
 [error] 7390#0: *157 [lua] reports.lua:49: log(): [reports] could not set peer name for UDP socket: [toip() name lookup failed]: failed to receive reply from UDP server <IP_ADDRESS>:53: timeout, client: <IP_ADDRESS>, server: kong_admin, request: "POST /apis/test1/plugins HTTP/1.1", host: "localhost:8001"
2017/05/10 21:01:25 [error] 7390#0: *15288 [lua] reports.lua:49: log(): [reports] could not set peer name for UDP socket: [toip() name lookup failed]: failed to receive reply from UDP server <IP_ADDRESS>:53: timeout, context: ngx.timer

2) After that, I find my DNS server (IP address:<IP_ADDRESS>) is not working, I restart that server and start the DNS service. The DNS server is working now, and I use the command to ensure Kong server can use that DNS server:
command: nc -uvz <IP_ADDRESS> 53
return data: Connection to <IP_ADDRESS> 53 port [udp/domain] succeeded!

3) add the plugin by curl and get the response data:
curl -X POST http://localhost:8001/apis/test2/plugins --data "name=key-auth"

{"api_id":"58378633-1f68-2389-6290-c260dc23baec","id":"357d37ed-c03b-49f7-2653-89beafb52821","created_at":1494152015000,"enabled":true,"name":"key-auth","config":{"hide_credentials":false,"key_names":["apikey"],"anonymous":""}}

The return time has been reduced from 40 seconds to 10 seconds, the speed is much more faster than before, but I think it's slow, the speed should be faster and response time should be controlled within one second like before.
4) Check the error logs again and find that:
[error] 12024#0: *47249 [lua] reports.lua:49: log(): [reports] could not set peer name for UDP socket: [toip() name lookup failed]: dns server error; 2 server failure, client: <IP_ADDRESS>, server: kong_admin, request: "POST /apis/test3/plugins HTTP/1.1", host: "localhost:8001"
I can connect to DNS server from Kong server and the DNS service is working, how to solve that problem? Thank you very much.

Sounds like a DNS resolver issue. @Tieske didn't you recently mention something about a 10 sec timeout bug due to potential record type confusion?

@Tieske updates ^ ?

@ssholder do you see this with an upgrade to 0.10.3?

@p0pr0ck5 When I found this issue: https://github.com/Mashape/kong/issues/2596 . I disable reporting by setting anonymous_reports off in the Kong config file, problem has been solved for the version of 0.10.x (include 0.10.3) , thank you very much!

Wonderful, thank you!


Feature add map filter

Description
Fixes # (issue)
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Change Status

[ ] Complete, tested, ready to review and merge
[x] Complete, but not tested (may need new tests)
[ ] Incomplete/work-in-progress, PR is for discussion/feedback

How Has This Been Tested?

[ ] Test A
[ ] Test B

Checklist

[ ] My code follows the style guidelines of this project
[ x] I have performed a self-review of my own code
[ ] My code has been reviewed by at least one peer
[ x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] There are no merge conflicts

Please update PR body description to describe what this PR accomplishes.


Queue names ending with '.fifo' yield 404

We are going to use FIFO queues, which just have a queue name ending in .fifo. When I change the names of my queues accordingly, moto only will give 404 errors.
The create queue calls appear to work, but then the queues are not found.

Can you give some more details? The following code works for me
@mock_sqs
def test_create_queue_with_dot_in_name():
    sqs = boto3.resource('sqs', region_name='us-east-1')
    new_queue = sqs.create_queue(QueueName='test.queue')
    new_queue.should_not.be.none
    new_queue.should.have.property('url').should.contain('test.queue')

    queue = sqs.get_queue_by_name(QueueName='test.queue')
    queue.attributes.get('QueueArn').should_not.be.none
    queue.attributes.get('QueueArn').split(':')[-1].should.equal('test.queue')


Need prefersStatusBarHidden in ScrollingNavigationController

Describe the bug
I want to hide the UIStatusBar at some UIViewControllers. The Problem is I use the popular RESideMenu framework with more than 7k stars (https://github.com/romaonthego/RESideMenu).
The structure is:

ScrollingNavigationController
present a RESideMenu controller with
2.a UIViewController (left)
2.b UIViewController (right)
2.c UIViewController (content - center)

The RESideMenu ask the ScrollingNavigationController which state the prefersStatusBarHidden has. So I need this feature. [[UIApplication sharedApplication] setStatusBarHidden:YES];  is deprecated since iOS 7. Only prefersStatusBarHidden works.
I will create a PR with this feature. So can set this state by shouldPrefersStatusBarHidden.
Default is false.

Subclass the ScrollingNavigationController and override that property. There is no need to add another property.

did you remember ?
https://github.com/andreamazz/AMScrollingNavbar/issues/327#issuecomment-428852427

... My complete project is in Objective C, so I'd like to favor this feature. Otherwise I would have to write my own subclass for this single feature. Do not you think that this is unnecessary? It would make me really happy :-)  This also applies to others.

... My complete project is in Objective C,

You are using this library, so it's not really just ObjC. At any rate, the two languages are interoperable, so I fail to see the issue.

Otherwise I would have to write my own subclass for this single feature.

Like you would if you'd use a plain UINavigationController. Should I add a property for every possible override? It would pollute the API, that I intend to keep as close to the default implementation of the nav controller as possible.

Right, I use Swift Frameworks. But not in my main project with more than 50 UIViewControllers. The reason is simple. Swift was very often modified by Apple Inc. Objective C is more consistent.
I do not think that will pollute the framework. Also the successful framework RESideMenu with more than 7000 likes uses this feature (https://github.com/romaonthego/RESideMenu). This is also a specific UINavigationController extension.

He does that because there's some extra logic behind it: it's hidden (or not) when the menu is visible, and that's a piece of information that shouldn't be handled by the library user. It make sense in Roman's library, not in this one. The decision is final.


Support for MQTT v5

Proposal
Thank you for your hard work. Is there in plan a version for support MQTT v5?

Yes, we have this plan.

Yes, we have this plan and you can see mqtt5 branch in this project.


Update syncblocks.md

@Celia18305 + is the standard way of intidacting >= so even if there is no 2.9.5 yet it will be supported by any version >2.9.4. So if you think it makes more sense to say neo-cli version >= 2.9.4. That is also OK


[SDP-1296] Update POST /wallet-registration/otp to send OTPs through email as well

What
Update POST /wallet-registration/otp to send OTPs through email as well.
Why
Address https://stellarorg.atlassian.net/browse/SDP-1296
Checklist
PR Structure

[x] This PR has a reasonably narrow scope (if not, break it down into smaller PRs).
[x] This PR title and description are clear enough for anyone to review it.
[x] This PR does not mix refactoring changes with feature changes (split into two PRs otherwise).

Thoroughness

[x] This PR adds tests for the new functionality or fixes.
[x] This PR contains the link to the Jira ticket it addresses.

Configs and Secrets

[x] No new CONFIG variables are required -OR- the new required ones were added to the helmchart's values.yaml file.
[x] No new CONFIG variables are required -OR- the new required ones were added to the deployments (pr-preview, dev, demo, prd).
[x] No new SECRETS variables are required -OR- the new required ones were mentioned in the helmchart's values.yaml file.
[x] No new SECRETS variables are required -OR- the new required ones were added to the deployments (pr-preview secrets, dev secrets, demo secrets, prd secrets).

Release

[x] This is not a breaking change.
[ ] This is ready for production.. If your PR is not ready for production, please consider opening additional complementary PRs using this one as the base. Only merge this into develop or main after it's ready for production!

Deployment

[ ] Does the deployment work after merging?

stellar-disbursement-platform-backend-preview is available here:SDP:      https://sdp-backend-pr413.previews.kube001.services.stellar-ops.com/healthAP:       https://sdp-ap-pr413.previews.kube001.services.stellar-ops.com/healthFrontend: https://sdp-backend-dashboard-pr413.previews.kube001.services.stellar-ops.com

stellar-disbursement-platform-backend-preview is available here:SDP:      https://sdp-backend-pr413.previews.kube001.services.stellar-ops.com/healthAP:       https://sdp-ap-pr413.previews.kube001.services.stellar-ops.com/healthFrontend: https://sdp-backend-dashboard-pr413.previews.kube001.services.stellar-ops.com

stellar-disbursement-platform-backend-preview is available here:SDP:      https://sdp-backend-pr413.previews.kube001.services.stellar-ops.com/healthAP:       https://sdp-ap-pr413.previews.kube001.services.stellar-ops.com/healthFrontend: https://sdp-backend-dashboard-pr413.previews.kube001.services.stellar-ops.com

stellar-disbursement-platform-backend-preview is available here:SDP:      https://sdp-backend-pr413.previews.kube001.services.stellar-ops.com/healthAP:       https://sdp-ap-pr413.previews.kube001.services.stellar-ops.com/healthFrontend: https://sdp-backend-dashboard-pr413.previews.kube001.services.stellar-ops.com

Something went wrong with PR preview build please check


configs

Can you tell me the difference between the config files under the configs folder?

Most of them inherit from the library maskrcnn for detection and segmentation. We only added configs/DRM_e2e_relation_X_101_32_8_FPN_1x.yaml for training our model.

When I run the relation_train_net.py, I get an error：
E:\anaconda\envs\DRM\python.exe E:\learn_code\DRM-main\tools\relation_train_net.py
Traceback (most recent call last):
File "E:\learn_code\DRM-main\tools\relation_train_net.py", line 22, in
from maskrcnn_benchmark.data import make_data_loader
File "E:\learn_code\DRM-main\maskrcnn_benchmark\data_init_.py", line 2, in
from .build import make_data_loader, get_dataset_statistics, make_data_infer_loader
File "E:\learn_code\DRM-main\maskrcnn_benchmark\data\build.py", line 13, in
from maskrcnn_benchmark.utils.miscellaneous import save_labels
File "E:\learn_code\DRM-main\maskrcnn_benchmark\utils\miscellaneous.py", line 10, in
from maskrcnn_benchmark.structures.boxlist_ops import boxlist_iou
File "E:\learn_code\DRM-main\maskrcnn_benchmark\structures\boxlist_ops.py", line 7, in
from maskrcnn_benchmark.layers import nms as box_nms
File "E:\learn_code\DRM-main\maskrcnn_benchmark\layers_init.py", line 10, in
from .nms import nms
File "E:\learn_code\DRM-main\maskrcnn_benchmark\layers\nms.py", line 8, in
nms = amp.float_function(_C.nms)
File "E:\anaconda\envs\DRM\lib\site-packages\yacs\config.py", line 141, in getattr
raise AttributeError(name)
AttributeError: nms
I looked and found that I didn't find _C.nms

Can you provide information about _C.nms?

This error appears to be caused by not compiling this repo correctly, you need to carefully follow INSTALL.md to install this code step by step, especially the last command python setup.py build develop.


DROOLS-912 - adding the ability to create the audit log from the Command API

this corresponds with another PR in droolsjbpm-knowledge: https://github.com/droolsjbpm/droolsjbpm-knowledge/pull/98

Can one of the admins verify this PR? Comment with 'ok to test' to start the build.

Merged @ https://github.com/droolsjbpm/drools/commit/d9e37a2c642266c277e510c87248fbdbd473b3a7


[chris] Connect to memcache

One thing I might change is creating some sort of Enum at the top of the file with the different error types instead of the phrases that are currently being used but I don't think it's that big of a deal.  Also, are we sure at this point that one day is where we want the ttl?
In any case, I'm merging!


Members of G5

Who are the members of group 5?

Hi, I couldn't find any member of this group in the contributor section. What is happening in this group?

No response yet.

I can't speak for jimmy, but I have given up. I hope that satisfied your curiosity :)

Sad


chore: migrate EstimateQueryCostButton component from jsx to tsx

SUMMARY

PR for migrating EstimateQueryCostButton component from JSX to TSX
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

[x] Has associated issue:  #10004
[x] Enhancement (new features, refinement)
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

@etr2460 Ptal, thx!


Chart: Update cluster to v1.1.0.

Checklist

[x] Updated CHANGELOG.md.

Trigger E2E tests

/run cluster-test-suites

As E2E Test Suites are forging a test Release from the latest Release with the cluster-azure version of this chart, they will probably fail. Therefore I'll skip CI and test my change in my releases PR: https://github.com/giantswarm/releases/pull/1336.


Support for encrypted pdf

An awesome library for PDF handling.
It would be great if the encrypted pdf handling feature could be added

Thanks for expressing your interest in this feature! I'm going to close this in favor of https://github.com/Hopding/pdf-lib/issues/233 to keep things tidy.


[FEATURE]: An option to specify table type

Is there an existing issue for this feature?

[x] I have searched for this issue

Description of the problem
Right now there is no way to specify table type. If there are multiple table types for the same time on the same day, how will the system know which one to book? It would be great to be able to specify types like 'Indoors', 'Dining Room', 'Outdoors', 'Patio' etc. to make sure to get the right table.
Planned Solution
N/A
Alternatives
N/A
Solution Specifics
N/A

Implemented an interface to the api layer to include a preference for tables. Table preference is decided after each loop of time searches. So the structure is basically, given a priority list of times {T1 T2} and a priority list of table types {Ta1 Ta2}, the checking goes(rough pseudocode)
For slot in slots {
If slot.Time == T1 && slot.Type == Ta1 -> reserve
}
For slot in slots {
If slot.Time == T2 && slot.Type == Ta1 -> reserve
}
For slot in slots {
If slot.Time == T1 && slot.Type == Ta2 -> reserve
}
For slot in slots {
If slot.Time == T2 && slot.Type == Ta2 -> reserve
}
The changes involved modifying the resy api reserve operation, specifically the find step. We search the config of the slot for a field called type, which provides a string declaration of the type of table the slot corresponds to. See api/resy/doc.go for more info.
We still need to implement the command line flag for adding tables, by @justin-s-wong already has a commit in progress for this, should be available sometime tomorrow.

Ok, the command line parsing is done. I'd like some initial testing done for this. @ndbs879827 you can test these changes by cloning the branch 29-feature-an-option-to-specify-table-type. Let us know if this is what you had in mind

As an extra note, since these changes pass my initial testing, if you don't have any other concerns, this branch will get merged into develop in a day or so

I've merged the changes into develop, but I'll keep the feature branch and this issue open for two days to anyone who would like to voice their opinion


Jest Custom Output not working, seems the configuration for JEST is not getting passed in correctly

Your environment
OS Windows 10
Node.js version : v16.5.0
suitecloud-cli version : 1.2.1
Terminal/CMD tool : CMD
Describe the bug
I am attempting to use a custom reporter (https://www.npmjs.com/package/jest-teamcity-reporter), but it appears I cannot get the configuration settings to apply.
To Reproduce
Steps to reproduce the behavior:

Add the following to the package.json
"script": { jest --converage },  "jest": {  "testResultsProcessor": "jest-teamcity-reporter" }

Actual Behavior
Standard output
Expected Behavior
Expect to see TeamCity like outputs, but instead get the standard output. These include tags with the ##teamcity style output.
Additional context
I am trying to use a custom formatter to send unit test results to TeamCity for pass/fail reporting. The workaround is to use the --json option in the "script" and looking for that in the string of failedtests:0 not matching.
I tried to modify the jest.config.js to include the options with the module.export, but that breaks everything else.
I then tried to add the Options in the suitecloud.config.js where the comment // Jest configuration options. exists without any luck as well.
Might be user error here as I am not completely familiar with Jest and how the module exports work. If I could just find the appropriate location for adding the Jest configurations that might resolve this issue.

@Rvice Can you share a complete package.json?
Which version of team-city-reporter are yo using?

Thanks @Rvice. Is this still an issue?

I see where the problem comes in, it's in the jest.config.js
module.exports = SuiteCloudJestConfiguration.build({ 	projectFolder: cliConfig.defaultProjectFolder, 	projectType: SuiteCloudJestConfiguration.ProjectType.ACP, 	testEnvironment : 'node', 	testResultsProcessor: "jest-teamcity", 	coverageReporters: [ 	"lcov", 	"text", 	"teamcity" 	], 	reporters: ["default", "jest-teamcity"] });
If I move the reporters/testResultsProcessor/etc as the module.exports then it works. How can I get these additional config parameters to Jest? Is there a "passthrough" part of the SutieCloudJestConfiguration.build?

This may have resolved the issue in the jest.config.js
const nsExport = SuiteCloudJestConfiguration.build({
	projectFolder: cliConfig.defaultProjectFolder,
	projectType: SuiteCloudJestConfiguration.ProjectType.ACP
});

const jestParams = {
	"testEnvironment" : "node",
	"testResultsProcessor": "jest-teamcity",
	"coverageReporters": [
		"lcov",
		"text",
		"teamcity"
	],
	"reporters"	: ["default", "jest-teamcity"]
};

module.exports = {
	...nsExport,
	...jestParams
}

Closing this issue as the jest.config.js steps above fixed it.


Show field directives inside of FieldDoc.

hey thanks for this! can you make the PR against 1.1.1 branch, instead of 2.x, as we are rewriting the docs component?

Right, sorry, will do!


Replace operator-framework/operator-sdk/pkg/ready

Changes
As part of the decoupling from the operator-sdk code base, there is the need
to introduce a replacement for their convenience ready package.
Add new ready package within build that has a comparable usage style.
Add code to make the ready filename configurable.
Change default ready filename to remove operator reference.
This addresses part of #584
See https://github.com/operator-framework/operator-sdk/pull/3476 for details regarding the recommendation to create an own ready helper package if required.
Submitter Checklist

[X] Includes tests if functionality changed/was added
[ ] Includes docs if changes are user-facing
[X] Release notes block has been filled in, or marked NONE

See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.
Release Notes
action required: The default filename to indicate readiness in the pod was renamed from /tmp/operator-sdk-ready to /tmp/shipwright-build-ready. If you use custom deployment mechanisms, please have a look at the respective readiness probe settings to adjust for the change.

The branch misses Improve test stability #614 which is causing some tests to fail. But, there is a green integration and e2e test in at least one K8s version. Therefore manually merging.

I stumbled across this new ready package while looking into something else, and I wonder if we need it at all?
It seems to only write the file then delete it when main exits, and seemingly nothing else uses it to determine readiness.
Even if it did, I wonder if we need a readinessProbe at all. Readiness probes are intended to tell a Service that traffic should be routed to the Pod, but in our case, AFAIK, there are no Services that read the status of the readiness probe.

I stumbled across this new ready package while looking into something else, and I wonder if we need it at all?
It seems to only write the file then delete it when main exits, and seemingly nothing else uses it to determine readiness.
Even if it did, I wonder if we need a readinessProbe at all. Readiness probes are intended to tell a Service that traffic should be routed to the Pod, but in our case, AFAIK, there are no Services that read the status of the readiness probe.

Good question. At the time, I just decided to take the operator SDK based ready package implementation mostly as-is into a package of our own. Could be that this was actually also the recommended migration action from their documentation.
I agree that it does not very much for us. Correct me if I am wrong, but we could do with just a liveness probe configured against the metrics endpoint. If I am not totally wrong here, we even discussed something like that before. @SaschaSchwarze0 Do you recall that?

@SaschaSchwarze0 Do you recall that?

Yes, Jason is right, readiness checks make only sense for services so that Kube can rule out pods that currently cannot accept traffic.
For the liveness check (which uses the same logic), the file-based approach is imo of reasonable.
For the readiness check, we discussed to make that depending on the the pod having leadership. This can use the same file-based approach, just that the file would only get written once the instance became leader. Then one can have a Service for the metrics endpoint and requests would only go to this leader.

For the liveness check (which uses the same logic), the file-based approach is imo reasonable.

I don't know if I agree, unless there's some code to delete the file when the container isn't live anymore. IMO having a liveness check that hits an HTTP endpoint would be able to more easily/accurately determine whether the container is running and healthy than signaling that with the presence/absence of a file.
Tekton does this with a simple HTTP handler that always returns 200 OK (source, https://github.com/tektoncd/pipeline/pull/3489). In practice I'm not sure even that's necessary, since it's much more likely the container will exit rather than get into a state where it's running but unable to serve that HTTP handler.

@ImJasonH yep, agree, you are bringing up questions I also had. So far, the issues we have seen where the controller was not anymore in good shape, always were when it either had a panic, or when it had connectivity issues with the kube-api-server and could not renew the lease. In case of a panic, the process died and kube would restart the pod. In case of the lease-renewal problem, I assume that it also terminates, but I am not sure.


Mobile version of toolbox

Hi, new mod. Not sure if this is the right place to request this. I would love a mobile version of toolbox, even with no support. Its pretty essential as a mod and I do a lot of my modding from my phone. Hopefully you can make this happen. Thanks!

Not likely to happen soon, in the past I got it sort of working on mobile firefox but that was slow and required toolbox to be butchered in order to work properly. These days it is even more difficult due to firefox requiring addons to be signed.

deferred or wontfix, pick one.

I haven't decided yet,  so it is in limbo.

Thanks anyway. It would be great to have at some point. As a moderator, I feel useless on mobile without toolbox.
Good luck :)

De : creesch<EMAIL_ADDRESS>Envoyé : vendredi 29 janvier 2016 22:20
À : creesch/reddit-moderator-toolbox
Cc : kain243
Objet : Re: [reddit-moderator-toolbox] Mobile version of toolbox (#708)
I haven't decided yet, so it is in limbo.

Reply to this email directly or view it on GitHubhttps://github.com/creesch/reddit-moderator-toolbox/issues/708#issuecomment-176974026.

Ok, even more bad news. It seems that mozilla crippled mobile addons even more since I have been going over it with the RES guys and we simply can' t get mobile addons to work with the latest tools.
I am going to keep this issue open though so people can find it.


Simpler injectionPath format for cluster env value with / char

Please provide a description of this PR:
We should also consider deprecating/removing the :ENV: path syntax since it is not recommended and doesn't seem to work when setting the path (vs URL) in the webhook.

@frankbu: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

lint_istio
8886c072c6ecb316f15769d53cc47e2c845d9ff5
link
true
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@frankbu: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

lint_istio
8886c072c6ecb316f15769d53cc47e2c845d9ff5
link
true
/test lint_istio

gencheck_istio
8886c072c6ecb316f15769d53cc47e2c845d9ff5
link
true
/test gencheck_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn

why do we need yet another form?

I want to deprecate/remove the other form. It's klunky, not recommended, and doesn't work in injectionPath (see comment in the changed code).

If we do want to escape / we should probably use the standard %2F

That would be preferable, but unfortunately the path is url unencoded by the time we get to process it.


Self-captured videos:

Hi,@yihua7 ，Thank you for your excellent work. I am trying to run a program with my own video, but I encountered difficulties in data processing. According to the instructions in the readme, I installed MIVOS and placed phone_catch.py, interactive_invoke.py, and colmap2nerf.py in the installation path of MIVOS. Then I ran phone_catch.py, and the output is shown in the figure

I'm confused because after running phone_catch.py, the resulting transforms.json file only contains camera parameters for two photos. How can I obtain camera parameters for every photo so that I can run my data in SCGS?

Hi,
Could you show the frames of your video? The problem should be that your video is hard for camera calibration using COLMAP and only two images are estimated with camera parameters. Maybe you can place a chess board in the scene you captured just like the hand case in our teaser image. Too many textureless objects (e.g. walls and floors) and transients may cause the problem.

Hi,@yihua7 ,Thanks for your reply. According to your suggestion, I tested two more sets of data. The first set is the video in which the human body dynamic target moves forward in the recording scene, as shown below,

and the camera parameters of only two photos can be obtained after the photos are extracted. Another set of data is to record a video of a dynamic target swinging its arm in place, as shown below,

in which case the camera parameters of all the photos can be resolved. I'm a little confused, Is it that colmap is not good at extracting moving dynamic targets?

Hi,@yihua7 ，I tried to train a dynamic 3D model with my own data, but it went wrong. First of all, my data set looks like this：

Then  run the command： python train_gui.py --source_path data/examplexz --model_path outputs/examplexz --deform_type node --node_num 512 --hyper_dim 8 --init_isotropic_gs_with_all_colmap_pcl --eval --gt_alpha_mask_as_scene_mask --local_frame --W 720 --H 1280 --random_bg_color --white_background --gui
But the operation went wrong, as shown below：

I don't know whether the format of my data set is wrong or the input run command is wrong, can you give me some advice?

Hi,
Sorry for the late reply. You can use the function readColmapSceneInfo instead of readNerfSyntheticInfo.


Deploy package

Register in the General repository: https://github.com/JuliaRegistries/General

Ok, let's try this:
@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/72783
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.2 -m "<description of version>" 8413a1e5e68bf3345a27c1b3d6276bca2b676174
git push origin v0.1.2

Also, note the warning: This looks like a new registration that registers version 0.1.2.
Ideally, you should register an initial release with 0.0.1, 0.1.0 or 1.0.0 version numbers
This can be safely ignored. However, if you want to fix this you can do so. Call register() again after making the fix. This will update the Pull request.

Try 2, having setting compatibility entries:
@JuliaRegistrator register

Registration pull request updated: JuliaRegistries/General/72783
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.2 -m "<description of version>" bd742119dc48220f0000f793b0ac4cfdcf8faa35
git push origin v0.1.2

Also, note the warning: This looks like a new registration that registers version 0.1.2.
Ideally, you should register an initial release with 0.0.1, 0.1.0 or 1.0.0 version numbers
This can be safely ignored. However, if you want to fix this you can do so. Call register() again after making the fix. This will update the Pull request.

Success! See https://juliahub.com/ui/Packages/QuasiStableColors/xVmI3/0.2.0?page=0


@SephirothLT  are you in China?
You can try this instead. https://github.com/golang/crypto


java.lang.NullPointerException: Profile name must not be null

Spark link
https://spark.lucko.me/3lkcLZdtRr
Expected behavior
No error / warning
Observed/Actual behavior
java.lang.NullPointerException: Profile name must not be null         at java.util.Objects.requireNonNull(Objects.java:233) ~[?:?]         at com.mojang.authlib.GameProfile.<init>(GameProfile.java:31) ~[authlib-5.0.47.jar:?]         at org.bukkit.craftbukkit.v1_20_R2.inventory.CraftMetaSkull.setOwningPlayer(CraftMetaSkull.java:248) ~[purpur-1.20.2.jar:git-Purpur-2064]         at sk.DexterSK.CoinFlip.common.game.CoinFlipGame.lambda$0(CoinFlipGame.java:54) ~[AdvancedCoinflip-6.7.jar:?]         at org.bukkit.craftbukkit.v1_20_R2.scheduler.CraftTask.run(CraftTask.java:101) ~[purpur-1.20.2.jar:git-Purpur-2064]         at org.bukkit.craftbukkit.v1_20_R2.scheduler.CraftAsyncTask.run(CraftAsyncTask.java:57) ~[purpur-1.20.2.jar:git-Purpur-2064]         at com.destroystokyo.paper.ServerSchedulerReportingWrapper.run(ServerSchedulerReportingWrapper.java:22) ~[purpur-1.20.2.jar:?]         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]         at java.lang.Thread.run(Thread.java:833) ~[?:?]
Steps/models to reproduce
Use setOwningPlayer on PLAYER_HEAD ItemStack
Purpur version
git-Purpur-2064 (MC: 1.20.2)*
Agreements

[X] I am running the latest version of Purpur available from https://purpurmc.org/downloads.
[X] I have searched for and ensured there isn't already an open issue regarding this.
[ ] I ticked all the boxes without actually reading them
[X] My version of Minecraft is supported by Purpur.

Other
https://github.com/PaperMC/Paper/pull/9770

Closing since this is an upstream issue, not a Purpur issue.


Async benches

To avoid 'there is no reactor is running, must be called from the context of a Tokio 1.x runtime'-type errors... needs a bit more work to fully migrate to async, see https://github.com/bheisler/criterion.rs/commit/a74edd9ae8642eec74650df02916b14d29967267
@CastilloDel Please note that this PR is against your current benchmarks branch, not main... don't worry I can tackle the blocking version later, this one seems to be working now ;)

Runs well locally but it does deserve a bit more attention on the criterion_async side and its Futures:
https://github.com/umccr/htsget-rs/runs/3752074281?check_suite_focus=true#step:6:223
will take a look at it...

Will be deprecated by #46


src(attachment): Use attrs + cattrs

src(attachment): Use attrs + cattrs

Depends on #133

Looks good % the missing test. Can you rebase on master while you're at it please?


add write permissions to ADO PAT Docs

Fixes #9
Simple clarification, that you need read and write to ADO.

Great add, thank you @askpatrickw
Just catching back up with the PRs and issues, thanks for your notes in the repo 🙇


document release process

documenting the release process here, and we can migrate to the docs once its finalized.

ensure tests pass and linter --thorough works
update version.py
review changes
a.  capa https://github.com/fireeye/capa/compare/v1.0.0...v1.0.1
b.  capa-rules https://github.com/fireeye/capa-rules/compare/v1.0.0...v1.0.1
update CHANGELOG.txt
a. additions
b. removals (major release only)
c. deprecations
d. breaking changes (major release only)
e. changes
f. fixes
create release in GH using text from changelog
create tag in capa-rules matching release version
verify GH actions upload artifacts upon completion

other stuff:
7. bump FC svc image

This will be useful: https://github.com/actions/create-release 😉

https://blog.yossarian.net/2020/11/05/Towards-an-automated-changelog-workflow

What do you think about moving this issue to the Wiki (it needs to be enabled in the project settings)?

I'd prefer an issue template new_release.md with the above checklist. This could then be associated with each version milestone and contain a task list to check off.

An issue template for the release process would be shown every time someone creates an issue. This may be confusing for some users. In addition, if we modify the release process, we need to update the template and the current milestone (duplication).
I personally think this should be part of the documentation instead of an issue/issue template. We could also add it to the docs folder. But I think the Wiki is used by quite some open source projects to document those kind of things. For example:

jquery
discord.js
rr
open-build-service

personal opinions, not decisions:
We should enable the wiki if we expect many other people to contribute to it; otherwise, I think we should stick to md formatted files embedded within the repo. They get rendered essentially the same within GH and .md documents keep our history within git (vs. GH webapp).
We should really have a release issue with checklist for each release (sorry, I've been lazy in the past, no more!). Whether we use an issue template (possibly prefix with z-ignore- or something) or a block that we copy-pasta from the docs, I don't really care.
The milestone tracks issues that should be included/resolved with a release; I don't think it should duplicate the information in the release issue. The release issue should be a checklist that reminds the releaser to, e.g., update version.py, run the linter, etc.

@williballenthin

We should enable the wiki if we expect many other people to contribute to it; otherwise, I think we should stick to md formatted files embedded within the repo. They get rendered essentially the same within GH and .md documents keep our history within git (vs. GH webapp).

This sounds reasonable 👍  What about a release.md file in our doc folder?

We should really have a release issue with checklist for each release (sorry, I've been lazy in the past, no more!). Whether we use an issue template (possibly prefix with z-ignore- or something) or a block that we copy-pasta from the docs, I don't really care.
The milestone tracks issues that should be included/resolved with a release; I don't think it should duplicate the information in the release issue. The release issue should be a checklist that reminds the releaser to, e.g., update version.py, run the linter, etc.

I am not sure if I understand how this should work. If I want to release, should I create an issue with the checklist and mark the items as I complete them? Why do we need an issue? The list is not that long. Isn't enough that the person releasing follows the list without creating an issue? 😕 Alternatively, it could be copied into the PR for the changelog. 🤔

Alternatively, it could be copied into the PR for the changelog.

even better, i think this is a good place to put the checklist.
the last the i want to do is create more process that is annoying to complete. so, lets definitely not make any bad decisions here. but, i know i keep forgetting steps during release, so i certainly want to refer to a list. putting it in the PR makes it clear which items i've completed, so i'll personally do this, but wont necessarily expect everyone else to (unless we agree).

My reasoning for an issue template was that we only have to update one file and can immediately use it (instead of copying it) when working on a new release. By task list I meant the release process steps such as:

[ ] run tests
[ ] update setup.py
[ ] ...

Versus a numbered list as used above.
Using a PR template should also work. Those are also used by less people, although I don't think it's that confusing to users if we put an explanation in there that this is only meant for use by the core dev team.

Alternatively, it could be copied into the PR for the changelog.

even better, i think this is a good place to put the checklist.
the last the i want to do is create more process that is annoying to complete. so, lets definitely not make any bad decisions here. but, i know i keep forgetting steps during release, so i certainly want to refer to a list. putting it in the PR makes it clear which items i've completed, so i'll personally do this, but wont necessarily expect everyone else to (unless we agree).

I can do it like this as well! It may be also useful if more than one person take care of the release (to know what has been already done).
@mr-tz

Using a PR template should also work. Those are also used by less people, although I don't think it's that confusing to users if we put an explanation in there that this is only meant for use by the core dev team.

I think you can not have more than one PR template. One alternative would be to add it as a comment at the button. The other alternative is to have it in a release.md file in our doc folder and copy it to the PR when we release. 🤔
What about I add a commit to https://github.com/fireeye/capa/pull/476 with a release.md file in our doc folder which documents the release process? We can decide to move it somewhere else afterwards. 🤔

What about I add a commit to #476 with a release.md file in our doc folder which documents the release process

yeah, lets definitely start with that. and we can continue the discussion here if we have further ideas.


RFP - OpenSSL SDK with C development headers

Checklist

[X] The package I am requesting does not already exist on https://chocolatey.org/packages;
[X] There is no open issue for this package;
[X] The issue title starts 'RFP - ';
[X] The download URL is public and not locked behind a paywall / login;

Package Details
Software project URL : https://slproweb.com/products/Win32OpenSSL.html
Direct download URL for the software / installer : https://slproweb.com/download/Win64OpenSSL-1_1_1c.exe
Software summary / short description: OpenSSL SDK (including C headers required to build project using OpenSSL)

For anyone wishing to pick this one up, please note that there was an attempt to submit one a few years ago so ensure that you Contact the site admins on https://chocolatey.org/packages/openssl to request being added as a new maintainer (reference this issue).
It is still considered a new package though, as there have never been any approved version.

Status: In progress

Waiting to be added as maintainer (request already sent to Chocolatey contact-site admins).
Updated package ready to be published: https://github.com/chtof/chocolatey-packages/tree/master/automatic/openssl

Status: Review
https://chocolatey.org/packages/openssl

Status: Still in progress

Can't published currently the package (System.ApplicationException: An error has occurred. It's possible the package version already exists on the repository. ---> System.InvalidOperationException: Failed to process request. 'This package had an issue pushing: Exception of type 'System.OutOfMemoryException' was thrown.'.)
New package ready to be published: https://github.com/chtof/chocolatey-packages/tree/master/automatic/openssl

Status: Review
https://chocolatey.org/packages/openssl

@chtof wondering here, isn't the openssl.cfg usually inside of the /bin/ directory?
e.g. C:\Program Files\OpenSSL-Win64\bin\openssl.cfg
Our build script expected it there...

@jerstlouis Corrected version openssl.<IP_ADDRESS>0 submitted.

Thanks @chtof . So the openssl.cfg was actually in bin/ but the OPENSSL_CONF was set to the wrong thing?
I hard-coded the value of OPENSSL_CONF for now in our travis configuration and we're finally over that hurdle, thanks for all that work.
https://travis-ci.org/ecere/ecere-sdk/jobs/585742118#L41
I am wondering, should we need to execute a 'refreshenv' in the Travis script to pick it up?

Yes, it was a mistake.
And regarding 'refreshenv', I have no opinion as for example, refreshenv shouldn't been put in a chocolatey script but I don't know why!

And regarding 'refreshenv', I have no opinion as for example, refreshenv shouldn't been put in a chocolatey script but I don't know why!

It isn't really about whether you should or shouldn't put refreshenv in chocolatey script, but rather that it wouldn't have any meaning to do so.
When chocolatey runs one of the included scripts, it is ran as a new process. So even if you add refreshenv (Or Update-SessionEnvironment which is the full name of the alias) nothing would change when chocolatey have completed the run. The only time you need to run Update-SessionEnvironment inside a package, is when you need the changed environment variable inside the package (whether it was added by the package itself, an installer or a dependency).

I am wondering, should we need to execute a 'refreshenv' in the Travis script to pick it up?

Any time there are a change to environment variables, you will need to run refreshenv to make those new/updated environment variables available in the same commandline instance.


Date format support for Jump-to-Date: Natural Language date. (JTD:NLD)

I am facing the same issue with Jump-to-Date: Natural Language date. (JTD:NLD)
I use the YYYY-MM-DD dddd format.
The Jump-to-date: Date picker works fine.
However when I use JTD:NLD, I get an Invalid Date error.
I tried it on another vault with the date format as YYYY-MM-DD, and the JTD:NLD works fine there.
Any thoughts / suggestions?
Originally posted by @boksir in https://github.com/TfTHacker/obsidian42-jump-to-date/issues/4#issuecomment-924670469

Thank  you for reporting this. I will be pushing out an update today, 1.0.7 and I hope it will fix this problem. To be honest I could not reproduce the problem, but I am also running with the most current support libraries. So it could be this problem was fixed with another library. Please test it after the update and let me know if it is resolved.
Warm regards!

Thank you. Will check and get back.
best regards!

Sorry, I am still getting an error.
My settings

If I choose JTD - Date Picker - I get no error

If I use JTD-Natural Language

Haven't been able to figure this out

Very odd. I will do some more testing. Thank you for the screen shots too.
Just a questions, is the Natural Language Date plugin working correct when it generates dates?

I believe I have fixed this now. Can you please do an update in obsidian and test it? If it works, please close out the issue.

It works perfectly now!! Thank you!
Closing the issue.
best regards!

Hi, opening this issue again. My date format is YYYY-MM-DD-ddd.
I get an invalid date error for days from 1st to 9th of the month.. All 2 digit days 10th to 31st work fine.
Screenshots below
Single digit Day

Maybe the error is it shows 2021-10-4, instead of 2021-10-04??

2 Digit Day

This error happens for existing dates as well, which are already created. It does not see them as created
Already Created Date

It says the date does not exist

Closing this as I opened a separate issue for this as I felt the issue was slightly different


layer folders outside rootDir are not watched for changes

Environment

Operating System: Darwin
Node Version:     v18.18.2
Nuxt Version:     3.8.0
CLI Version:      3.9.1
Nitro Version:    2.7.2
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      -
Runtime Modules:  -
Build Modules:    -

Reproduction
Reproduction repo
Steps to reproduce:

start the app (wait until installation is done and run $ npm run start:dev)
uncomment the method implementation under apps/site-one/app.vue
uncomment the method under packages/ui/utils/my-utils.ts
the app should throw an error saying myFunction2 does not exists.

Describe the bug
Using layers, it seems like hmr does not work for the extended layers.
for example, if I add a new method under a utils file inside an extended layer while the app is running, it wont add the type declaration for the package under .nuxt folder
Maybe theres something I missing? must be a way to update the .nuxt folder upon file changes
Maybe theres a way to programmatically call nuxi prepare for every file change under packages?
Additional context
No response
Logs
No response

I'm facing the same issue, and most probably due to this, we will not going to have a good "enterprise" monorepo for our project.
At least I can see that is going to happen in version 4.x

Faced the same problem, I need the layer to generate .nuxt for itself.
I was able to understand that the module module.ts is used for generation. It needs a nuxt instance, but since layers are run in the current instance, the module cannot be reused.
It is necessary to somehow put the logic of building files into a separate functionality and reuse it in layers and module.ts.

I made a module that solves this problem https://github.com/hywax/nuxt-layers-prepare
The description says that this is a temporary solution until this functionality is added to the kernel.


e2e: serial: add hugepages test cases

we need to have hugepages coverage. We start with a subset of tests which is

tier1 and
already tabular

so we can quickly add these tests and start get moving.
We start with 2Mi hugepages just because they are a bit easier to manage (less risk of memory fragmentation), but some 1Gi coverage is also needed and should be added in a future PR.

ping (@shajmakh)

Thanks for the useful patch!
I'll handle adding the tests' ids in a different PR since we have similar cases in the project.
/lgtm

trivial rebase

/lgtm


Xml not found

Where is C:/ProgramData/Anaconda3/envs/tensorflow/Library/etc/haarcascades/haarcascade_frontalface_default.xml????

It is where opencv installed. You can find it as illustrated below.
import cv2
def get_opencv_path():
	opencv_home = cv2.__file__
	folders = opencv_home.split(os.path.sep)[0:-1]

	path = folders[0]
	for folder in folders[1:]:
		path = path + "/" + folder

	face_detector_path = path+"/data/haarcascade_frontalface_default.xml"
	eye_detector_path = path+"/data/haarcascade_eye.xml"

	if os.path.isfile(face_detector_path) != True:
		raise ValueError("Confirm that opencv is installed on your environment! Expected path ",face_detector_path," violated.")

	return path+"/data/"
print("your haarcascade xml is here: ", get_opencv_path())


 In a nutshell:
go mod verify
go mod tidy

make vendor

Yes, I also did the the go mod commands in PR:
https://github.com/redhat-developer/build/pull/109
It means it will picked up the ginkgo packages from the new controller unit test directly.

The steps:
go mod verify
go mod tidy

make vendor

specifically the make vendor(go mod vendor), are one more reason why we should ignore the vendor directory in this repo, and put it under the .gitignore.

specifically the make vendor(go mod vendor), are one more reason why we should ignore the vendor directory in this repo, and put it under the .gitignore.

Having the vendor directory on the project repository is a common action for most of the Red Hat Go based project. There are a number of reasons to include it:

OpenShift-CI for "productization" is air-gaped so we can't fetch them from upstream;
Keeping the vendor folder populate prevents losing dependencies, so if repositories are deleted or moved, we still have the changes locally;
During PRs we can keep track of what is actually changing in vendor directory and therefore, we can assure CI and build process is reproducible;

I understand it adds a little more complexity to it, which should then be registered in Makefile to make sure project contributors are aware about the existence of this step.

the air-gaped make sense, this is what @sbose78 mentioned before but I didnt understand at that time.

Yeah, and I think keeping dependencies vendor'd might help you downstream as well @qu1queee - you wouldn't have to maintain a separate vendor'd downstream.

Any way we could avoid vendor-ing test-time dependencies ?

Any way we could avoid vendor-ing test-time dependencies ?
this is what I understood from your previous comments on other PRs :)

Any way we could avoid vendor-ing test-time dependencies ?

It might not be worth saving testing dependencies only, thinking on air-gapped environments it would not help.

If we plan to use ginkgo, I think we need to follow that style for all unit tests or maybe for all e2e tests in future. (right now the ut of generate_task and creds still use go test)
And we won't have other test framework in the repo, so I think it is fine to include it. Because it is also a part of dependencies in pkg.

@sbose78, @qu1queee, I don't think we can avoid it, since every time we ran go mod {verify,tidy} it will update go.mod automatically, so we would have to have a manual intervention afterwards.
Furthermore, when linting the project it was issuing alerts showing that dependencies used in the project were out of sync with Go modules. So, I think the best course of action is to always it keep tight.

go mod verify /tidy is not for the vendor, only go mod vendor.  The go.mod/go.sum definitely required an update, which you propose on your PR.
For the vendor, I think you could in theory skip the ginkgo package and dependencies, because as mentioned before, we run the tests with GO111MODULE=on. However, Im wondering if in the air-gaped environments, this will not work? do you have a concrete use case where this is the case? if not I will suggest to avoid adding this packages into the vendor folder, and only stick to the changes in the go.mod/go.sum.

Also if you have a linter, maybe it make sense to run it as part of the tests when a PR is opened. Which linter would that be?

adding more comments(sorry) just brain storming here in the lack of other space to do this. I think the contents of the vendor dir are merely important when building the binary. If you build with go build -v -mod=vendor -o nene cmd/manager/main.go , it will only use the vendor dir, and the build will be successful. Even without the packages used in testing(e.g. ginkgo), because they are not use during build-time. I think this explains the reasoning of @sbose78
If you run the make build, is the same behaviour, however the make build target runs a go mod vendor, probably we want to avoid doing this, otherwise it will try to pull the missing packages for testing, and this can break on the air-gapped use cases.

Note Openshift CI or any CI environment for that matter is not airgapped. Therefore if tests pull dependencies from the internet, that's ok.
Only the environment where we do downstream builds is airgapped. That's probably the case for most enterprises.
So, in theory, if skipping Gingko deps are possible, we should do so. However, I'm not super picky about it :)

however the make build target runs a go mod vendor, probably we want to avoid doing this,

It actually doesn't 🤔

go mod verify /tidy is not for the vendor, only go mod vendor.

The changes created by go mod {verify,tidy} will be later on reflected on vendor directory, materialized by go mod vendor.
So in practice, go mod {verify,tidy} are meant "for" the vendor.

The go.mod/go.sum definitely required an update, which you propose on your PR and probably thats what the linter showed.

Exactly.

For the vendor, I think you could in theory skip the ginkgo package and dependencies, because as mentioned before, we run the tests with GO111MODULE=on. However, Im wondering if in the air-gaped environments, this will not work? do you have a concrete use case where this is the case? if not I will suggest to avoid adding this packages into the vendor folder, and only stick to the changes in the go.mod/go.sum.

What's the concrete argument to avoid adding all test dependencies in go.{mod,sum}? All other dependencies are currently managed by Go Modules, and therefore I expect testing components to follow the same path.
Having control of testing dependencies is also fundamental for reproducibility, where developers and CI are sharing the same versions, the same tooling.

On a second thought, while building the binary, the test dependencies anyway wouldn't be linked in the binary. So, its okay I think !

On a second thought, while building the binary, the test dependencies anyway wouldn't be linked in the binary. So, its okay I think !

Tests are also performed by a binary built for that reason. The same concerns apply, but this time to the actual results of testing. While not part of the final binary shipped by this project, this testing binary inflicts in the final outcome indirectly.

/lgtm
/approve


Seed the primordial classes, not all of them

Purpose or Intent
Discovered while playing in #11137.
db:seed is for populating the base database tables needed to boot
the rails server.  seed_primordial seeds only the base (primordial) classes.
A normal rake evm:start (evmserver) will do the full seed.
If anything blows up after this change, the missing seeds should be added to
primordial classes:
https://github.com/ManageIQ/manageiq/blob/b1cc742a339b0bb3d766fb84ca7137a69d925faa/lib/evm_database.rb#L6-L20
This saves ~7 seconds (~40%) from rake db:seed.
Note: rake db:seed is called from both bin/setup and bin/update.
Note2: the primordial class VmdbDatabase is not really required but the UI fails
without it.  We really need to remove that from primordial as it's very slow.
Before
12:46:42 ~/Code/manageiq (seed_primordial_in_db_seeds) (2.3.1) + time bin/rake db:seed
bin/rake db:seed  14.05s user 2.33s system 86% cpu 18.857 total

After
12:47:15 ~/Code/manageiq (seed_primordial_in_db_seeds) (2.3.1) + time bin/rake db:seed
bin/rake db:seed  7.85s user 1.85s system 85% cpu 11.340 total

👍

cc @simaishi @psav @dajohnso (this affects bin/setup and bin/update in case we call them)

Note2: the primordial class VmdbDatabase is not really required but the UI fails
without it. We really need to remove that from primordial as it's very slow.

@himdel If you can figure out that one, we save another 2.5 seconds:
[----] I, [2016-09-09T12:47:09.526187 #10807:3fd4f943fa04]  INFO -- : MIQ(EvmDatabase.seed) Seeding VmdbDatabase
[----] I, [2016-09-09T12:47:12.255602 #10807:3fd4f943fa04]  INFO -- : MIQ(EvmDatabase.seed) Seeding... Complete

@jrafanie We seed once and boot many times.
Could we move the slow task (full seed) to the install step (db:seed) and the fast task (primordial_seed) to the run many times task?
Better yet, can we delete everything from primordial seed except for MiqServer.seed?
That would give us a boot improvement.
(personally I always boot with SKIP_PRIMORDIAL_SEED)

@jrafanie We seed once and boot many times.

We do full seed on full server boot.  We do primordial seed with bin/rails s.  We can look at removing the seed from bin/update, bin/setup, or in bin/rails s but that's the way it is now.
Primordial seed should be fast and it is other than the VmdbDatabase which should not be required to be primordial.  The UI needs to remove it's dependence on it and handle missing rows in the various tables.

@jrafanie Could we keep rake db:seed as close to standard rails. Seeding the whole database?
Maybe introduce rake db:seed:primordial to partially seed it. And call that from update?
I agree we need to get setup and update as quick as possible.
But I also want to avoid documenting that a standard rails convention is working differently than what people expect.
Do you think a new person off the street expects rake db:seed to populate all the seed data, or just some of it?

@jrafanie Could we keep rake db:seed as close to standard rails. Seeding the whole database?
Maybe introduce rake db:seed:primordial to partially seed it. And call that from update?

@kbrock Thanks, that's a good point.
# This file should contain all the record creation needed to seed the database with its default values.
# The data can then be loaded with the rails db:seed command (or created alongside the database with db:setup).

I guess the problem is the definition of 'default values' for production vs. development are different things.  Let me think about this.

We do primordial seed with bin/rails s

Is this true?  I know it happens when the UIWorker starts, but in the past it never did this with rails s.  This was part of the reason that those of us who don't usually run evm:start had to seed manually (or at least seed primordial manually).

Could we keep rake db:seed as close to standard rails.

That's a really great point...I agree, let's keep db:seed as is and create somethings else for primordial.

Is this true? I know it happens when the UIWorker starts, but in the past it never did this with rails s. This was part of the reason that those of us who don't usually run evm:start had to seed manually (or at least seed primordial manually).

@Fryguy yes, we do it during bin/rails s
10:14:52 ~/Code/manageiq (master) (2.3.1) + git diff
diff --git a/lib/vmdb/initializer.rb b/lib/vmdb/initializer.rb
index 1620652..8f3fe65 100644
--- a/lib/vmdb/initializer.rb
+++ b/lib/vmdb/initializer.rb
@@ -10,6 +10,7 @@ module Vmdb
       #   * command line(rails server)
       #   * debugger
       if defined?(Rails::Server)
+raise
         # preload_for_worker_role depends on seeding, principally MiqDatabase
         EvmDatabase.seed_primordial

10:15:06 ~/Code/manageiq (master) (2.3.1) - bin/rails s
=> Booting Puma
=> Rails <IP_ADDRESS> application starting in development on http://localhost:3000
=> Run `rails server -h` for more startup options
** Using session_store: ActionDispatch::Session::MemCacheStore
Exiting
/Users/joerafaniello/Code/manageiq/lib/vmdb/initializer.rb:13:in `init': unhandled exception
	from /Users/joerafaniello/Code/manageiq/config/application.rb:158:in `block in <class:Application>'
	from /Users/joerafaniello/.gem/ruby/2.3.1/gems/activesupport-<IP_ADDRESS>/lib/active_support/lazy_load_hooks.rb:36:in `execute_hook'


[140] Issue #140 - August 8, 2019

To contribute to this issue, simply leave a comment here. Please also review our contributing guidelines.
The current draft for this issue in _drafts/. If you want to contribute directly, feel free to open a pull request.

Can be fun one
https://twitter.com/isEqualToDan/status/1154400902083743744
Sent with GitHawk

SwiftUI first impressions with Kateryna, Paul, Erica and John

A bit more than a month after SwiftUI’s grand introduction during WWDC 2019, Kateryna Gridina, Paul Hudson, Erica Sadun and John Sundell discuss their first impressions of Apple’s declarative new UI framework and the Swift language features that enable it.

https://www.swiftcommunitypodcast.org/episodes/6

https://twitter.com/slava_pestov/status/1154862660971900930?s=20

https://twitter.com/dgregor79/status/1155126931198763008
Sent with GitHawk

https://twitter.com/daveverwer/status/1154822943068827648
Sent with GitHawk

The review for SE-0261 has ended and the proposal has been accepted.
https://forums.swift.org/t/accepted-se-0261-identifiable-protocol/27358
Sent with GitHawk

Pitch: A dedicated function for evaluating Void returning closures when Optional instance is not nil
https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367
Sent with GitHawk

A few folks reached out mentioning my post helped them better grok FRP 🙌🏽 https://jasdev.me/duals

The review of SE-0263: Add a String Initializer with Access to Uninitialized Storage begins now and runs through August 9, 2019.
https://forums.swift.org/t/se-0263-add-a-string-initializer-with-access-to-uninitialized-storage/27417

https://twitter.com/slava_pestov/status/1157029945715150848

Exclusivity enforcement is not just about safety - it also enables better optimizations: https://github.com/apple/swift/pull/26440

[PITCH] extractPayload for enum cases having associated value
This is a long requested feature that never saw the light. We have memories of other proposals pitched with Automatically derive properties for enum cases and before with Pitch: Even Smarter KeyPaths? from @stephencelis
https://forums.swift.org/t/pitch-extractpayload-for-enum-cases-having-associated-value/27606
Sent with GitHawk

[PITCH] @unrequired in function signature for optional closure parameters

From a perspective of a framework writer it is important to provide clear and understandable documentation for the correct usage of their APIs. Swift allows us to write functions that are at some extent self documenting, and clearly define what the function will actually do

https://forums.swift.org/t/pitch-unrequired-in-function-signature-for-optional-closure-parameters/27577
Sent with GitHawk

[PITCH] Support for binary dependencies

This draft introduces support for binary dependencies in SwiftPM. It will allow vendors to upload artifacts for all supported platforms which will be resolved, downloaded and linked by SwiftPM. There are still some open things left, which can be found at the bottom, but we wanted to get community feedback before we continue with this.

https://forums.swift.org/t/pitch-support-for-binary-dependencies/27620
Sent with GitHawk

https://twitter.com/swift_unwrapped/status/1158378183953145856
Sent with GitHawk

Development open for Swift 5.0.3 for Linux
We are happy to announce the opening of the development phase for Swift 5.0.3 for Linux with a planned release by the end of August 2019. The process for the dot-releases remains the same as for Swift 4.2

https://forums.swift.org/t/development-open-for-swift-5-0-3-for-linux/27693

https://swiftpm.co/
https://daveverwer.com/blog/launching-the-swiftpm-library/


⚠ ZV800.com has degraded performance

In ca232a3, ZV800.com (https://www.zv800.com//) experienced degraded performance:

HTTP code: 200
Response time: 2138 ms

Resolved: ZV800.com performance has improved in 4065108 after 3 minutes.


Added correct nullability values for initializers

[X] I’ve read and understood the Contributing guidelines and have done my best effort to follow them.
[X] I’ve read and agree to the Code of Conduct.
[X] I’ve been mindful about doing atomic commits, adding documentation to my changes, not refactoring too much.
[X] I’ve a descriptive title and added any useful information for the reviewer. Where appropriate, I've attached a screenshot and/or screencast (gif preferrably).
[X] I’ve written tests to cover the new code and functionality included in this PR.
[X] I’ve read, agree to, and signed the Contributor License Agreement (CLA).

PR Summary

Based on the documentation, I’ve added nullability qualifiers.

Related Issues

N/A

Test strategy

N/A

@ClementPadovani @dzenbot The comment says these initializers may return nil, but looking at the implementation, I don't see why these should be nullable.
- (instancetype)initWithTableViewStyle:(UITableViewStyle)style
{
    NSAssert([self class] != [SLKTextViewController class], @"Oops! You must subclass SLKTextViewController.");
    NSAssert(style == UITableViewStylePlain || style == UITableViewStyleGrouped, @"Oops! You must pass a valid UITableViewStyle.");

    if (self = [super initWithNibName:nil bundle:nil])
    {
        self.scrollViewProxy = [self tableViewWithStyle:style];
        [self slk_commonInit];
    }
    return self;
}

The super designated initializer is not nullable / failable: [super initWithNibName:nil bundle:nil]
Maybe I'm missing something, but it would be nice if we could make these non-failable initializers 🙂


[Feature]  Move  Biodrop version from mid footer to bottom footer section.

Has this bug been raised before?

[X] I have checked "open" AND "closed" issues and this is not a duplicate

Where did you find this bug?
Creating Bug Issue(Github) - Production Version
Version of BioDrop (for example "v1.2.3")
v2.83.5
Description
When creating a bug issue, developers are asked for the version of the web app, and since it's in the mid-footer and not the bottom footer it's not as obvious.
Screenshots
Less visible:

Location for new version in Footer:

Do you want to work on this issue?
Yes
If you want to work on this issue...
I would move the existing version code into the ul li structure on the bottom left footer to make it more visible.

@kbventures I have changed the label to status: ready for dev and assigned this to you - thank you for raising.

@SaraJaoude, I would like to work on this. Please assign me the issue.

SaraJaoude, I would like to work on this. Please assign me the issue.

@YTeyddie22 Thank you for your enthusiasm, but if you if you look at the message just above yours you will see this issue has been assigned to someone else.  It would be helpful if you could please do these checks in future to save notifications and time for maintainers.
Please also do not tag a specific maintainer if you would like to work on an issue - all maintainers receive notifications and can assign.
For more information on how this project is run, I would suggest taking a look at our Contributing Guide.

Hi, I would like to work on this issue, as it is still unresolved.
I think the given version below does not convey the message that the version is of BioDrop.
Desktop view:

Mobile view:

Let me know what you think.


rename epoch to edition

Per issue #5214 let's rename all instances of epoch to Edition

r? @alexcrichton

$ cargo fmt -- --write-mode diff
Diff in /home/travis/build/rust-lang/cargo/src/cargo/util/toml/mod.rs at line 14:
 ⏎
 use core::{GitReference, PackageIdSpec, Profiles, SourceId, WorkspaceConfig, WorkspaceRootConfig};⏎
 use core::{Dependency, Manifest, PackageId, Summary, Target};⏎
-use core::{EitherManifest, Edition, Feature, Features, VirtualManifest};⏎
+use core::{Edition, EitherManifest, Feature, Features, VirtualManifest};⏎
 use core::dependency::{Kind, Platform};⏎
 use core::manifest::{LibKind, Lto, ManifestMetadata, Profile};⏎
 use sources::CRATES_IO;⏎

@bors: r+
Thanks!

:pushpin: Commit 3bbe93c has been approved by alexcrichton

:hourglass: Testing commit 3bbe93cef61ca3fcbaf1eb0b5b86bc7d5c25eb3a with merge 551f6f31ae42d0cbc208b681ea516bc36abdb09f...

:sunny: Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 551f6f31ae42d0cbc208b681ea516bc36abdb09f to master...


MVP: Customize Network Type Configuration

We need the ability to control the network type used here:
https://github.com/openshift/hypershift/blob/73da1bc576c46d5a45f440a79b3b17717f5a3243/control-plane-operator/controllers/hostedcontrolplane/hostedcontrolplane_controller.go#L795
The immediate use case is for IBM Cloud Openshift clusters Calico is utilized as the SDN provider.
Acceptance Critieria:

[ ] Support the ability to configure different NetworkTypes for hypershift clusters

the initial MVP support for this is done future work streams can be opened in a follow up issue (like the OVN-Kubernetes one)

@relyt0925 @enxebre where should I be opening up follow up issues to track customizing network type configuration?


Blocker check for containers should not run when --no-leap is passed

  {
     "id" : "Elevate::Blockers::BootKernel::__ANON__",
     "msg" : "Unable to determine running and boot kernels due to the following error:\n(XID adzgt7) Cannot update this system’s kernel."
  }

Shouldn't be run also isn't it?