System.BadImageFormatException after Omnisharp started

Issue Description
I get a System.BadImageFormatException after OmniSharp started. OmniSharp logs don't show any errors. But the "Window" log in Vs Code, logs the exception below.
I can navigate through my code and Code Lens is working. Code completion is not working though.
Apparently the Microsoft.CodeAnalysis.CSharp.Features assembly is of a bad image format (wrong bitness?). I noticed this assembly is provided with the OmniSharp extension, so i'm assuming it's trying to access that. I've tried re-installing VS Code, I've removed the .vscode\extensions folder. Re-installed OmniSharp and even re-installed Visual Studio.
I'm really just trying to figure out what might be wrong with my setup. I most likely just need to remove and re-install some application, but I cannot figure out what that is. I've tried re-installing everything I could think of already.
Steps to Reproduce
I'm pretty sure it's related to my machine setup. I've asked colleagues with similar setups and they cannot reproduce this issue.
Expected Behavior
No errors and working code completion (Intellisense)
Actual Behavior
Intellisense code completion not working.
Logs
Window (Log):
[renderer1] [error] "System.InvalidOperationException: Failed to create instrance of Microsoft.CodeAnalysis.CSharp.UseCompoundAssignment.CSharpUseCompoundAssignmentCodeFixProvider
  in Microsoft.CodeAnalysis.CSharp.UseCompoundAssignment.CSharpUseCompoundAssignmentCodeFixProvider, Microsoft.CodeAnalysis.CSharp.Features, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
  ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
  ---> System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)

at Microsoft.CodeAnalysis.CSharp.UseCompoundAssignment.CSharpUseCompoundAssignmentCodeFixProvider..ctor()
--- End of inner exception stack trace ---
at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)
at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
at System.Activator.CreateInstance(Type type, Boolean nonPublic)
at System.Activator.CreateInstance(Type type)
at OmniSharp.Utilities.ReflectionExtensions.CreateInstance[T](Type type) in D:\a\1\s\src\OmniSharp.Shared\Utilities\ReflectionExtensions.cs:line 122
--- End of inner exception stack trace ---
at OmniSharp.Utilities.ReflectionExtensions.CreateInstance[T](Type type) in D:\a\1\s\src\OmniSharp.Shared\Utilities\ReflectionExtensions.cs:line 120
at System.Linq.Enumerable.WhereSelectEnumerableIterator2.MoveNext()
at System.Linq.Enumerable.WhereEnumerableIterator1.MoveNext()
at System.Linq.Buffer1..ctor(IEnumerable1 source)
at System.Linq.Enumerable.ToArray[TSource](IEnumerable1 source)
at System.Collections.Immutable.ImmutableArray.CreateRange[T](IEnumerable1 items)
at OmniSharp.Services.AbstractCodeActionProvider..ctor(String providerName, ImmutableArray1 assemblies) in D:\\a\\1\\s\\src\\OmniSharp.Roslyn\\Services\\AbstractCodeActionProvider.cs:line 39
at lambda_method(Closure , LifetimeContext , CompositionOperation )
at System.Composition.Hosting.Core.LifetimeContext.GetOrCreate(Int32 sharingId, CompositionOperation operation, CompositeActivator creator)
at System.Composition.Hosting.Providers.ImportMany.ImportManyExportDescriptorProvider.<>c__DisplayClass3_21.b__4(ExportDescriptor e)
at System.Linq.Enumerable.WhereSelectArrayIterator2.MoveNext()
at System.Linq.Buffer1..ctor(IEnumerable1 source)
at System.Linq.Enumerable.ToArray[TSource](IEnumerable1 source)
at lambda_method(Closure , LifetimeContext , CompositionOperation )
at System.Composition.Hosting.Core.LifetimeContext.GetOrCreate(Int32 sharingId, CompositionOperation operation, CompositeActivator creator)
at lambda_method(Closure , LifetimeContext , CompositionOperation )
at System.Composition.Hosting.Core.CompositionOperation.Run(LifetimeContext outermostLifetimeContext, CompositeActivator compositionRootActivator)
at System.Composition.Hosting.Providers.Lazy.LazyWithMetadataExportDescriptorProvider.<>c__DisplayClass2_22.<GetLazyDefinitions>b__4()
at System.Lazy1.CreateValue()
at System.Lazy1.LazyInitValue()
at OmniSharp.Endpoint.EndpointHandler2.<>c.b__11_0(Lazy2 export) in D:\\a\\1\\s\\src\\OmniSharp.Host\\Endpoint\\EndpointHandler.cs:line 80
at System.Linq.Enumerable.WhereSelectArrayIterator2.MoveNext()
at System.Linq.Enumerable.d__591.MoveNext()
at System.Linq.Lookup2.Create[TSource](IEnumerable1 source, Func2 keySelector, Func2 elementSelector, IEqualityComparer1 comparer)
at System.Linq.GroupedEnumerable3.GetEnumerator()
at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement](IEnumerable1 source, Func2 keySelector, Func2 elementSelector, IEqualityComparer1 comparer)
at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement](IEnumerable1 source, Func2 keySelector, Func2 elementSelector)
at OmniSharp.Endpoint.EndpointHandler2.LoadExportHandlers(IEnumerable1 handlers) in D:\a\1\s\src\OmniSharp.Host\Endpoint\EndpointHandler.cs:line 88
at System.Lazy1.CreateValue()\r\n--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Lazy1.get_Value()
at OmniSharp.Endpoint.EndpointHandler2.<HandleAllRequest>d__21.MoveNext() in D:\\a\\1\\s\\src\\OmniSharp.Host\\Endpoint\\EndpointHandler.cs:line 243
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()
at OmniSharp.Endpoint.EndpointHandler2.<Process>d__16.MoveNext() in D:\\a\\1\\s\\src\\OmniSharp.Host\\Endpoint\\EndpointHandler.cs:line 131
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()
at OmniSharp.Stdio.Host.d__13.MoveNext() in D:\a\1\s\src\OmniSharp.Stdio\Host.cs:line 215"

OmniSharp log

Starting OmniSharp server at 31-1-2020 09:10:13
    Target: c:\Projects\MyProject\MySolution.sln
OmniSharp server started.
Path: c:\Users\ThisIsMe\.vscode\extensions\ms-vscode.csharp-1.21.9.omnisharp\1.34.9\OmniSharp.exe
PID: 15272
    Starting OmniSharp on Windows 6.2.9200.0 (x64)

    DotNetPath set to dotnet

    Located 2 MSBuild instance(s)
        1: Visual Studio Professional 2019 16.4.29728.190 - "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin"
        2: StandAlone 16.3 - "c:\Users\ThisIsMe\\.vscode\extensions\ms-vscode.csharp-1.21.9\.omnisharp\1.34.9\.msbuild\Current\Bin"

    Registered MSBuild instance: Visual Studio Professional 2019 16.4.29728.190 - "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin"

... continues loading projects without errors

C# log

Installing C# dependencies...
Platform: win32, x86_64
Downloading package 'OmniSharp for Windows (.NET 4.6 / x64)' (32146 KB).................... Done!
Validating download...
Integrity Check succeeded.
Installing package 'OmniSharp for Windows (.NET 4.6 / x64)'
Downloading package '.NET Core Debugger (Windows / x64)' (47489 KB).................... Done!
Validating download...
Integrity Check succeeded.
Installing package '.NET Core Debugger (Windows / x64)'
Downloading package 'Razor Language Server (Windows / x64)' (50022 KB).................... Done!
Installing package 'Razor Language Server (Windows / x64)'
Finished

Environment information
VSCode version: 1.41.1
C# Extension: 1.21.9
Dotnet Information
.NET Core SDK (reflecting any global.json):
 Version:   3.1.101
 Commit:    b377529961
Runtime Environment:
OS Name:     Windows
OS Version:  10.0.18362
OS Platform: Windows
RID:         win10-x64
Base Path:   C:\Program Files\dotnet\sdk\3.1.101\
Host (useful for support):
Version: 3.1.1
Commit:  a1388f194c
.NET Core SDKs installed:
2.2.105 [C:\Program Files\dotnet\sdk]
3.1.101 [C:\Program Files\dotnet\sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download

Visual Studio Code Extensions

Extension
Author
Version

csharp
ms-vscode
1.21.9

could you also try to go to the location of the assembly and right-mouse click it. Then go to the General tab and click “unblock” and see if it helps?

Thanks for that suggestion. I don't see the Unblock button, so I'm assuming the dll is trusted already.
I've also checked the dll in dotPeek to see if there's anything unusual, but I cannot see anything out of the ordinary.

Does this look ok for you to?
I'm starting to think there's most likely nothing wrong with the assembly. But I'm pretty much out of idea's of what else it may be...

I haven't seen this nor been able to reproduce it with the latest bits. If you see this with the latest version of the plugin, let us know and we can re-open this.

I haven't been able to reproduce it either on any other machine. I'm going to stop trying to look into this this too. I hope it'll magically resolve itself at some point 🤞 . Thanks for the help!

I have started getting this last few days, not sure when
ms-dotnettools.csharp-1.21.18/.omnisharp/1.35.2-beta.38

[fail]: OmniSharp.MSBuild.ProjectManager
        Error occurred while processing project updates: System.BadImageFormatException: type 0x00 not handled in do_mono_metadata_parse_type on image /Users/nils/.vscode/extensions/ms-dotnettools.csharp-1.21.18/.omnisharp/1.35.2-beta.38/omnisharp/Microsoft.CodeAnalysis.CSharp.dll
File name: 'Microsoft.CodeAnalysis.CSharp'
  at Microsoft.CodeAnalysis.CSharp.CSharpCompilationOptions.Equals (System.Object obj) [0x00000] in <c2962771cf0648a1b0a500975001be59>:0

I don't know if this helps at all (and it even seems kind of bizarre to me), but the DLL doesn't seem to be the problem.
I can resolve this error by building omnsiharp with the following change to src/OmniSharp.Roslyn/Services/AbstractCodeActionProvider.cs
--- a/src/OmniSharp.Roslyn/Services/AbstractCodeActionProvider.cs
+++ b/src/OmniSharp.Roslyn/Services/AbstractCodeActionProvider.cs
@@ -37,13 +37,13 @@ protected AbstractCodeActionProvider(string providerName, ImmutableArray<Assembl
                 .ToImmutableArray();

             this.CodeFixProviders = types
-                .Where(t => typeof(CodeFixProvider).IsAssignableFrom(t))
+                .Where(t => typeof(CodeFixProvider).IsAssignableFrom(t) && t.Name != "CSharpUseCompoundAssignmentCodeFixProvider")
                 .Select(type => type.CreateInstance<CodeFixProvider>())
                 .Where(instance => instance != null)
                 .ToImmutableArray();

             this.CodeDiagnosticAnalyzerProviders = types
-                .Where(t => typeof(DiagnosticAnalyzer).IsAssignableFrom(t))
+                .Where(t => typeof(DiagnosticAnalyzer).IsAssignableFrom(t) && t.Name != "CSharpUseCompoundAssignmentDiagnosticAnalyzer")
                 .Select(type => type.CreateInstance<DiagnosticAnalyzer>())
                 .Where(instance => instance != null)
                 .ToImmutableArray();

To clarify, I was receiving this error from vscode running v1.37.5 originally. Then I cloned the source, checked out v1.37.5 tag and still got the error with the output executable. I was very surprised to find that some types within the DLL Microsoft.CodeAnalysis.CSharp.Features load successfully.
It turns out that the only problem types are "CSharpUseCompoundAssignmentCodeFixProvider" and "CSharpUseCompoundAssignmentDiagnosticAnalyzer". I think I can live without them, so my custom build suits my needs, but I wonder what's special about those classes.

I don't know if this helps at all (and it even seems kind of bizarre to me), but the DLL doesn't seem to be the problem.
I can resolve this error by building omnsiharp with the following change to src/OmniSharp.Roslyn/Services/AbstractCodeActionProvider.cs
--- a/src/OmniSharp.Roslyn/Services/AbstractCodeActionProvider.cs
+++ b/src/OmniSharp.Roslyn/Services/AbstractCodeActionProvider.cs
@@ -37,13 +37,13 @@ protected AbstractCodeActionProvider(string providerName, ImmutableArray<Assembl
                 .ToImmutableArray();

             this.CodeFixProviders = types
-                .Where(t => typeof(CodeFixProvider).IsAssignableFrom(t))
+                .Where(t => typeof(CodeFixProvider).IsAssignableFrom(t) && t.Name != "CSharpUseCompoundAssignmentCodeFixProvider")
                 .Select(type => type.CreateInstance<CodeFixProvider>())
                 .Where(instance => instance != null)
                 .ToImmutableArray();

             this.CodeDiagnosticAnalyzerProviders = types
-                .Where(t => typeof(DiagnosticAnalyzer).IsAssignableFrom(t))
+                .Where(t => typeof(DiagnosticAnalyzer).IsAssignableFrom(t) && t.Name != "CSharpUseCompoundAssignmentDiagnosticAnalyzer")
                 .Select(type => type.CreateInstance<DiagnosticAnalyzer>())
                 .Where(instance => instance != null)
                 .ToImmutableArray();

To clarify, I was receiving this error from vscode running v1.37.5 originally. Then I cloned the source, checked out v1.37.5 tag and still got the error with the output executable. I was very surprised to find that some types within the DLL Microsoft.CodeAnalysis.CSharp.Features load successfully.
It turns out that the only problem types are "CSharpUseCompoundAssignmentCodeFixProvider" and "CSharpUseCompoundAssignmentDiagnosticAnalyzer". I think I can live without them, so my custom build suits my needs, but I wonder what's special about those classes.

I don't know if this helps at all (and it even seems kind of bizarre to me), but the DLL doesn't seem to be the problem.
I can resolve this error by building omnsiharp with the following change to src/OmniSharp.Roslyn/Services/AbstractCodeActionProvider.cs
--- a/src/OmniSharp.Roslyn/Services/AbstractCodeActionProvider.cs
+++ b/src/OmniSharp.Roslyn/Services/AbstractCodeActionProvider.cs
@@ -37,13 +37,13 @@ protected AbstractCodeActionProvider(string providerName, ImmutableArray<Assembl
                 .ToImmutableArray();

             this.CodeFixProviders = types
-                .Where(t => typeof(CodeFixProvider).IsAssignableFrom(t))
+                .Where(t => typeof(CodeFixProvider).IsAssignableFrom(t) && t.Name != "CSharpUseCompoundAssignmentCodeFixProvider")
                 .Select(type => type.CreateInstance<CodeFixProvider>())
                 .Where(instance => instance != null)
                 .ToImmutableArray();

             this.CodeDiagnosticAnalyzerProviders = types
-                .Where(t => typeof(DiagnosticAnalyzer).IsAssignableFrom(t))
+                .Where(t => typeof(DiagnosticAnalyzer).IsAssignableFrom(t) && t.Name != "CSharpUseCompoundAssignmentDiagnosticAnalyzer")
                 .Select(type => type.CreateInstance<DiagnosticAnalyzer>())
                 .Where(instance => instance != null)
                 .ToImmutableArray();

To clarify, I was receiving this error from vscode running v1.37.5 originally. Then I cloned the source, checked out v1.37.5 tag and still got the error with the output executable. I was very surprised to find that some types within the DLL Microsoft.CodeAnalysis.CSharp.Features load successfully.
It turns out that the only problem types are "CSharpUseCompoundAssignmentCodeFixProvider" and "CSharpUseCompoundAssignmentDiagnosticAnalyzer". I think I can live without them, so my custom build suits my needs, but I wonder what's special about those classes.

I don't know if this helps at all (and it even seems kind of bizarre to me), but the DLL doesn't seem to be the problem.
I can resolve this error by building omnsiharp with the following change to src/OmniSharp.Roslyn/Services/AbstractCodeActionProvider.cs
--- a/src/OmniSharp.Roslyn/Services/AbstractCodeActionProvider.cs
+++ b/src/OmniSharp.Roslyn/Services/AbstractCodeActionProvider.cs
@@ -37,13 +37,13 @@ protected AbstractCodeActionProvider(string providerName, ImmutableArray<Assembl
                 .ToImmutableArray();

             this.CodeFixProviders = types
-                .Where(t => typeof(CodeFixProvider).IsAssignableFrom(t))
+                .Where(t => typeof(CodeFixProvider).IsAssignableFrom(t) && t.Name != "CSharpUseCompoundAssignmentCodeFixProvider")
                 .Select(type => type.CreateInstance<CodeFixProvider>())
                 .Where(instance => instance != null)
                 .ToImmutableArray();

             this.CodeDiagnosticAnalyzerProviders = types
-                .Where(t => typeof(DiagnosticAnalyzer).IsAssignableFrom(t))
+                .Where(t => typeof(DiagnosticAnalyzer).IsAssignableFrom(t) && t.Name != "CSharpUseCompoundAssignmentDiagnosticAnalyzer")
                 .Select(type => type.CreateInstance<DiagnosticAnalyzer>())
                 .Where(instance => instance != null)
                 .ToImmutableArray();

To clarify, I was receiving this error from vscode running v1.37.5 originally. Then I cloned the source, checked out v1.37.5 tag and still got the error with the output executable. I was very surprised to find that some types within the DLL Microsoft.CodeAnalysis.CSharp.Features load successfully.
It turns out that the only problem types are "CSharpUseCompoundAssignmentCodeFixProvider" and "CSharpUseCompoundAssignmentDiagnosticAnalyzer". I think I can live without them, so my custom build suits my needs, but I wonder what's special about those classes.


Extension installs but keyboard shortcuts do not work.

Have installed both via VS Code Marketplace as well as manually and then adding snippets to User / Snippets /erb.json, neither has the keyboard shortcuts work. This extension does not work.

@jbk2  Hmm, I just fresh installed on a new machine and it works for me 🤔
On VSCode v 1.85.1.
Could you share your settings.json

D'oh, apologies of user error my end, here's my settings.json:
{
    "workbench.colorTheme": "Default Dark+",
    "editor.tabSize": 2,
    "git.autofetch": true,
    "window.zoomLevel": 1,
    "workbench.startupEditor": "none",
    "diffEditor.ignoreTrimWhitespace": false,
    "github.copilot.enable": {
        "*": true,
        "plaintext": false,
        "markdown": true,
        "scminput": false
    },
    "emmet.includeLanguages": {
        "html.erb": "html"//,
        // "erb": "html",
        // "*erb": "html"
    }
}


Add IP Address to interface metrics and metadata

What does this PR do?

Add interface IP Address
Requires this PR https://github.com/DataDog/datadog-agent/pull/10155
Motivation

Additional Notes

Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] PR title must be written as a CHANGELOG entry (see why)
[ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
[ ] PR must have changelog/ and integration/ labels attached

Closing, an interface might have multiple IPs. The feature is postponed for now.


Support automatically port forwarding to flux instances in a Kubernetes cluster.

Simplify accessing flux instances in a Kubernetes cluster by automatically creating
port forwards, just like Helm does.
This is based on the port forward implementations from kubectl and Helm:

https://github.com/kubernetes/helm/blob/master/pkg/kube/tunnel.go
https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/cmd/portforward.go

The flow is:

If neither --flux-namespace nor FLUX_NAMESPACE are set, then this code will do nothing
and everything will work as before.
If it is, it will instantiate a Kubernetes client and search for pods in FLUX_NAMESPACE
that have the name=flux labels set.
If the number of pods with name=flux in the namespace are not exactly 1, it will
return an error.
It will find an empty port (by first binding to port 0 and then closing the port) and
start a port forward on that port that forwards to the flux pod on port 3030.
It will set the flux url to http://<IP_ADDRESS>:$port/api/flux.
The port forward goroutine will get cleaned up automatically when fluxctl terminates.

Use-cases:

Easier use of standalone flux instances.
Discourage exposing flux apis to the internet (hopefully nobody does this).
More easily manage large numbers of flux instances.

Fission also has a port forward implementation: https://github.com/fission/fission/blob/master/fission/portforward/portforward.go
This seems like something useful to a lot of projects, so I think it would be better for me to factor this out into a separate library and pull that in here.

Another thing that occurred to me: it'd be wonderful if this were the default mode of operation, so people have no reason to be tempted to expose the API. This is a bit tricky though, since we'd have to account for people that have already made shell scripts, etc. Though I am not adverse to a small amount of breakage in the interest of encouraging people to use port-forwarding instead of e.g., a NodePort, when either would work.

I also saw name=fluxd on some old documentation on your website just now, too. So I’ll have it search for a couple labels if you don’t specify one.
I’m not sure which command line I prefer. The first one is nice because if we are searching by label hopefully all you need to change is the namespace so it’s less verbose. But the second one keeps in line with the rest of flux and is more flexible since it lets you pass in a resource name (especially if you have more than one flux in a namespace).
I wasn’t sure about making it the default since it looks like weavcloud connect through the Weave Cloud API. Is that not the case?.

I’m not sure which command line I prefer. The first one is nice because if we are searching by label hopefully all you need to change is the namespace so it’s less verbose. But the second one keeps in line with the rest of flux and is more flexible since it lets you pass in a resource name (especially if you have more than one flux in a namespace).

On balance I think I like the first one, since it's progressive -- you can just flip the switch, or you can supply a namespace, or you can supply the whole lot if you need to.

I wasn’t sure about making it the default since it looks like weavcloud connect through the Weave Cloud API. Is that not the case?.

That is the case, yup. You have to supply an auth token as well (either with --token,-t or FLUX_SERVICE_TOKEN or WEAVE_CLOUD_TOKEN), so we can in principle detect when people have it set up that way. We would get a false positive in cases that people have set up an ingress or NodePort or the like; those ones I think I'd be prepared to break, temporarily, for the greater good. We can deal with changing the default after this PR, though -- I don't want to pile more requirements on.

I also saw name=fluxd on some old documentation on your website just now, too. So I’ll have it search for a couple labels if you don’t specify one.

I think I have conflated .metadata.name=flux and selection by label -- does that change anything?

Though I am not adverse to a small amount of breakage in the interest of encouraging people to use port-forwarding instead of e.g., a NodePort, when either would work.

Thinking about this more, I don't actually think we'll break anything at all here! fluxctl with no arguments was never a valid configuration - you always had to either pass a token or a URL in order for fluxctl to work. Now, if you pass neither of those, it will attempt a port forward instead.

Okay, I've implemented everything I described above:

The command line interface logic.
We search for pods that match the label selector name in (flux, fluxd, weave-flux-agent)

This is good to go from my end!

Demo:
Default port forward fails, since my flux is in kube-system:
➜  flux git:(master) ✗ ./fluxctl list-controllers
Error: Could not find pod for selector: labels "name in (flux,fluxd,weave-flux-agent)"
Run 'fluxctl list-controllers --help' for usage.

Search for flux in kube-system and create a port forward:
➜  flux git:(master) ✗ ./fluxctl -f kube-system list-controllers
CONTROLLER                                              CONTAINER                      IMAGE                                                                  RELEASE  POLICY
default:daemonset/elasticsearch-operator-sysctl         sysctl-conf                    busybox:1.26.2                                                         ready

Try to connect to weave cloud with fake token:
➜  flux git:(master) ✗ ./fluxctl -t mytoken list-controllers
== Error ==

The request failed authentication

This most likely means you have a missing or incorrect token. Please
make sure you supply a service token, either by setting the
environment variable FLUX_SERVICE_TOKEN, or using the argument --token
with fluxctl.

Set a URL and connect directly:
➜  flux git:(master) ✗ ./fluxctl -u http://<IP_ADDRESS>:3030/ list-controllers
Error: Get http://<IP_ADDRESS>:3030/v6/services?namespace=default: dial tcp <IP_ADDRESS>:3030: connect: connection refused
Run 'fluxctl list-controllers --help' for usage.


Timeline dosn't work with this

In timeline section there is only kernel's times working.

I'm not familiar with the timeline section, could you be more elaborate in your description. Maybe some steps to reproduce?


Alternative 3D mapping

Is there an alternative for the assets writer? I want to use the cartographer and get 3D maps live, not with a bag file.I am able to use the assets writer, but it's not satisfactory. I tried to increase the decay time of the point cloud, but the solution is not that good. I have looked a little bit around and found this link: https://www.youtube.com/watch?v=Ve9kWX_KXus
Is there an algorithm that I can use to get this? Or is there any plug in or tool?
I hope you can help me with this

Closing as inactive.


How to flatten the array?

In the section: Part 1: Flatten the array into individual fields
You showed the results of flattening the array. I wonder how can we flatten the array properly. Is it possible to be done on Portal?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: eabe2975-9ff9-12cb-0a19-c2857127390c
Version Independent ID: d2fc3b74-ab07-3432-fb6c-a91830b81536
Content: How to model complex data types - Azure Search
Content Source: articles/search/search-howto-complex-data-types.md
Service: search
GitHub Login: @brjohnstmsft
Microsoft Alias: brjohnst

@zhouchong90
Thanks for the feedback! We are currently investigating and will update you shortly.


Suggestion: use gradle-incap-helper to generate META-INF file for Gradle incremental annotation processing

See https://github.com/tbroyer/gradle-incap-helper
This is basically the auto-service of incremental processing.

Done.
One nuance: I also had to add testCompileOnly 'net.ltgt.gradle.incap:incap', else I would get this error:
> Task :immutable-processor:compileTestJava FAILED
warning: unknown enum constant IncrementalAnnotationProcessorType.ISOLATING
  reason: class file for net.ltgt.gradle.incap.IncrementalAnnotationProcessorType not found
warning: unknown enum constant IncrementalAnnotationProcessorType.ISOLATING
  reason: class file for net.ltgt.gradle.incap.IncrementalAnnotationProcessorType not found
error: warnings found and -Werror specified
1 error
2 warnings

Ah, right, I'll update the readme.
One possibility would be compileOnlyApi but it adds the dependency as <scope>compile</scope> in the POM; that's probably small enough to be negligible.


Article titles buried within a binc subtag not being populated to text only title field.

Due to the way xml_get_subelement_textsingleton worked, these are not returning text.

First draft fix in place, but need to fully test and see if that's the best fix.


Add conditions to creation default security grop resources

What

Add conditions to creation default security grop resources

Why

https://github.com/cloudposse/terraform-aws-ec2-instance/issues/18

Plan


fix(carbon-accounting): deleted incorrect plugin aspect

Fixes #977

@jordigiam Thank you very much for the quick reaction!


Refactor AWS client

Coverage decreased (-25.01%) to 17.909% when pulling 5457d6ff373816384f0150bc248944ed0fc2bd42 on aws-refactor into 98c09b16726f6171ad5194071177691f6ceae503 on master.

the only place left with the global Cloudsvc is in loadbalancer/main.go now

/lgtm

/override coverage/coveralls

/override coverage


No module named 'elmoformanylangs'

Hello! How to solve this error? I can't just get this with pip install
It arises while I do the convertion of checkpoints:

Traceback (most recent call last):
File "/home/jupyter/ner-bert-master/convert_tf_checkpoint_to_pytorch.py", line 27, in
from modules.layers.bert_modeling import BertConfig, BertModel
File "/home/jupyter/ner-bert-master/modules/init.py", line 1, in
from .train.train import NerLearner
File "/home/jupyter/ner-bert-master/modules/train/train.py", line 9, in
from modules.models.released_models import released_models
File "/home/jupyter/ner-bert-master/modules/models/init.py", line 1, in
from .bert_models import BertBiLSTMCRF, BertBiLSTMAttnCRF
File "/home/jupyter/ner-bert-master/modules/models/bert_models.py", line 1, in
from modules.layers.encoders import *
File "/home/jupyter/ner-bert-master/modules/layers/encoders.py", line 3, in
from .embedders import BertEmbedder
File "/home/jupyter/ner-bert-master/modules/layers/embedders.py", line 9, in
from elmoformanylangs.modules.embedding_layer import EmbeddingLayer
ModuleNotFoundError: No module named 'elmoformanylangs'

Also it arises when I do import

ModuleNotFoundError                       Traceback (most recent call last)
 in
----> 1 from modules import BertNerData as NerData
~/ner-bert-master/modules/init.py in
----> 1 from .train.train import NerLearner
2 from .data.bert_data import BertNerData
3 from .models.bert_models import BertBiLSTMCRF
4
5
~/ner-bert-master/modules/train/train.py in
7 import json
8 from modules.data.bert_data import BertNerData
----> 9 from modules.models.released_models import released_models
10
11
~/ner-bert-master/modules/models/init.py in
----> 1 from .bert_models import BertBiLSTMCRF, BertBiLSTMAttnCRF
2
3
4 all = ["BertBiLSTMCRF", "BertBiLSTMAttnCRF"]
~/ner-bert-master/modules/models/bert_models.py in
----> 1 from modules.layers.encoders import *
2 from modules.layers.decoders import *
3 from modules.layers.embedders import *
4 import abc
5 import sys
~/ner-bert-master/modules/layers/encoders.py in
1 from torch import nn
2 import torch
----> 3 from .embedders import BertEmbedder
4
5
~/ner-bert-master/modules/layers/embedders.py in
7 import json
8 from torch import nn
----> 9 from elmoformanylangs.modules.embedding_layer import EmbeddingLayer
10 from elmoformanylangs.frontend import Model
11
ModuleNotFoundError: No module named 'elmoformanylangs'

install your requirements:
pip install -r ner-bert/requirements.txt
install ELMoForManyLangs using git clone:
git clone https://github.com/HIT-SCIR/ELMoForManyLangs.git
pip install -e ELMoForManyLangs/
Then it should be resolved!

Thank you for answering, but it didn't work for me
It turns out that I have more specific problem that I thouht.
I use Google Cloud Platform with Jupyter Notebook in browser and ssh console. So I've done installation in console, and it was successful, but for some reason it can't be imported in jupyter. I don't know why.
I tried to do installation from jupyter notebook directly (it is how I usually instal modules here), but it fails in importing:
!python /home/jupyter/ner-bert-master/ELMoForManyLangs-master/setup.py install

running install
running bdist_egg
running egg_info
writing elmoformanylangs.egg-info/PKG-INFO
writing dependency_links to elmoformanylangs.egg-info/dependency_links.txt
writing requirements to elmoformanylangs.egg-info/requires.txt
writing top-level names to elmoformanylangs.egg-info/top_level.txt
reading manifest file 'elmoformanylangs.egg-info/SOURCES.txt'
writing manifest file 'elmoformanylangs.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-x86_64/egg
running install_lib
warning: install_lib: 'build/lib' does not exist -- no Python modules to install
creating build/bdist.linux-x86_64/egg
creating build/bdist.linux-x86_64/egg/EGG-INFO
copying elmoformanylangs.egg-info/PKG-INFO -> build/bdist.linux-x86_64/egg/EGG-INFO
copying elmoformanylangs.egg-info/SOURCES.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying elmoformanylangs.egg-info/dependency_links.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying elmoformanylangs.egg-info/requires.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying elmoformanylangs.egg-info/top_level.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
zip_safe flag not set; analyzing archive contents...
creating 'dist/elmoformanylangs-0.0.2-py3.7.egg' and adding 'build/bdist.linux-x86_64/egg' to it
removing 'build/bdist.linux-x86_64/egg' (and everything under it)
Processing elmoformanylangs-0.0.2-py3.7.egg
Removing /opt/anaconda3/lib/python3.7/site-packages/elmoformanylangs-0.0.2-py3.7.egg
Copying elmoformanylangs-0.0.2-py3.7.egg to /opt/anaconda3/lib/python3.7/site-packages
elmoformanylangs 0.0.2 is already the active version in easy-install.pth
Installed /opt/anaconda3/lib/python3.7/site-packages/elmoformanylangs-0.0.2-py3.7.egg
Processing dependencies for elmoformanylangs==0.0.2
Searching for overrides==1.9
Best match: overrides 1.9
Adding overrides 1.9 to easy-install.pth file
Using /opt/anaconda3/lib/python3.7/site-packages
Searching for numpy==1.14.5
Best match: numpy 1.14.5
Adding numpy 1.14.5 to easy-install.pth file
Using /opt/anaconda3/lib/python3.7/site-packages
Searching for h5py==2.8.0
Best match: h5py 2.8.0
Adding h5py 2.8.0 to easy-install.pth file
Using /opt/anaconda3/lib/python3.7/site-packages
Searching for torch==1.0.0
Best match: torch 1.0.0
Adding torch 1.0.0 to easy-install.pth file
Installing convert-caffe2-to-onnx script to /opt/anaconda3/bin
Installing convert-onnx-to-caffe2 script to /opt/anaconda3/bin
Using /opt/anaconda3/lib/python3.7/site-packages
Searching for six==1.12.0
Best match: six 1.12.0
Adding six 1.12.0 to easy-install.pth file
Using /opt/anaconda3/lib/python3.7/site-packages
Finished processing dependencies for elmoformanylangs==0.0.2

import elmoformanylangs

ModuleNotFoundError                       Traceback (most recent call last)
 in
----> 1 import elmoformanylangs
ModuleNotFoundError: No module named 'elmoformanylangs'

And I tried your code:
!git clone https://github.com/HIT-SCIR/ELMoForManyLangs.git

Cloning into 'ELMoForManyLangs'...
remote: Enumerating objects: 171, done.
remote: Total 171 (delta 0), reused 0 (delta 0), pack-reused 171
Receiving objects: 100% (171/171), 81.14 KiB | 0 bytes/s, done.
Resolving deltas: 100% (86/86), done.

!pip install -e ELMoForManyLangs/

Obtaining file:///home/jupyter/ner-bert-master/examples/ELMoForManyLangs
Requirement already satisfied: torch in /opt/anaconda3/lib/python3.7/site-packages (from elmoformanylangs==0.0.2) (1.0.0)
Requirement already satisfied: h5py in /opt/anaconda3/lib/python3.7/site-packages (from elmoformanylangs==0.0.2) (2.8.0)
Requirement already satisfied: numpy in /opt/anaconda3/lib/python3.7/site-packages (from elmoformanylangs==0.0.2) (1.14.5)
Requirement already satisfied: overrides in /opt/anaconda3/lib/python3.7/site-packages (from elmoformanylangs==0.0.2) (1.9)
Requirement already satisfied: six in /opt/anaconda3/lib/python3.7/site-packages (from h5py->elmoformanylangs==0.0.2) (1.12.0)
Installing collected packages: elmoformanylangs
Found existing installation: elmoformanylangs 0.0.2
Uninstalling elmoformanylangs-0.0.2:
Successfully uninstalled elmoformanylangs-0.0.2
Running setup.py develop for elmoformanylangs
Successfully installed elmoformanylangs
Traceback (most recent call last):
File "/opt/anaconda3/bin/pip", line 11, in
sys.exit(main())
File "/opt/anaconda3/lib/python3.7/site-packages/pip/_internal/init.py", line 78, in main
return command.main(cmd_args)
File "/opt/anaconda3/lib/python3.7/site-packages/pip/_internal/cli/base_command.py", line 184, in main
timeout=min(5, options.timeout)
File "/opt/anaconda3/lib/python3.7/site-packages/pip/_internal/cli/base_command.py", line 79, in _build_session
insecure_hosts=options.trusted_hosts,
File "/opt/anaconda3/lib/python3.7/site-packages/pip/_internal/download.py", line 337, in init
self.headers["User-Agent"] = user_agent()
File "/opt/anaconda3/lib/python3.7/site-packages/pip/_internal/download.py", line 126, in user_agent
setuptools_version = get_installed_version("setuptools")
File "/opt/anaconda3/lib/python3.7/site-packages/pip/_internal/utils/misc.py", line 836, in get_installed_version
working_set = pkg_resources.WorkingSet()
File "/opt/anaconda3/lib/python3.7/site-packages/pip/_vendor/pkg_resources/init.py", line 562, in init
self.add_entry(entry)
File "/opt/anaconda3/lib/python3.7/site-packages/pip/_vendor/pkg_resources/init.py", line 618, in add_entry
for dist in find_distributions(entry, True):
File "/opt/anaconda3/lib/python3.7/site-packages/pip/_vendor/pkg_resources/init.py", line 1883, in find_eggs_in_zip
if metadata.has_metadata('PKG-INFO'):
File "/opt/anaconda3/lib/python3.7/site-packages/pip/_vendor/pkg_resources/init.py", line 1402, in has_metadata
return self.egg_info and self._has(self._fn(self.egg_info, name))
File "/opt/anaconda3/lib/python3.7/site-packages/pip/_vendor/pkg_resources/init.py", line 1757, in _has
return zip_path in self.zipinfo or zip_path in self._index()
File "/opt/anaconda3/lib/python3.7/site-packages/pip/_vendor/pkg_resources/init.py", line 1634, in zipinfo
return self._zip_manifests.load(self.loader.archive)
File "/opt/anaconda3/lib/python3.7/site-packages/pip/_vendor/pkg_resources/init.py", line 1591, in load
mtime = os.stat(path).st_mtime
FileNotFoundError: [Errno 2] No such file or directory: '/opt/anaconda3/lib/python3.7/site-packages/elmoformanylangs-0.0.2-py3.7.egg'

after installing it you need to import it ** As a local library **
try this:
import ELMoForManyLangs.elmoformanylangs as elmoformanylangs

wow it works! thank you so much!!
by the way, how did you know about this fact?

My pleasure :))
I faced the same issue!


can't find include files

Hi, i'm trying to learn this fantastic project. But when i clone your project, i can't find include files below which are included in src\vkgs\engine\engine.cc, so i wonder where i can find them? thank you for replying me and your awesome work!
#include "generated/parse_ply_comp.h"
#include "generated/projection_comp.h"
#include "generated/rank_comp.h"
#include "generated/inverse_index_comp.h"
#include "generated/splat_vert.h"
#include "generated/splat_frag.h"
#include "generated/splat_geom_vert.h"
#include "generated/splat_geom_geom.h"
#include "generated/color_vert.h"
#include "generated/color_frag.h"

Hi,
those files are generated when you run cmake:
$ cmake . -B build
$ cmake --build build --config Release

generation command is defined as:
https://github.com/jaesung-cs/vkgs/blob/52a4bc159b54bf75e95df446c67130335c521441/CMakeLists.txt#L17-L43
https://github.com/jaesung-cs/vkgs/blob/52a4bc159b54bf75e95df446c67130335c521441/CMakeLists.txt#L87-L96
if the cmake build command runs successfully, you will find cmake output message at the beginning like this:
  1>Checking Build System
  Compiling C:/workspace/vkgs/src/generated/color_frag.h
  C:/workspace/vkgs/src/shader/color.frag
  Building Custom Rule C:/workspace/vkgs/CMakeLists.txt
  Compiling C:/workspace/vkgs/src/generated/color_vert.h
  C:/workspace/vkgs/src/shader/color.vert
  Building Custom Rule C:/workspace/vkgs/CMakeLists.txt
...

please confirm you have installed VulkanSDK>=1.2 in your system:
$ vulkaninfo | grep Version  # (Linux/MacOS)
$ vulkaninfo.exe | findstr Version  # (Windows)
Vulkan Instance Version: 1.3.280

thanks! i have solved the problem


Update to Unity 2019.4.24f1 and associated package updates

Thanks. That textmeshpro update is pretty important; because we don't have the UI option to "Import TMP Essential Resources", we have to do it manually in the CI file.

This compilation might take a bit of time, since it'll need a new cache. Don't wait around for the binaries :-)

Q2 seems happy!


keyboard_suggestions flag not working even when input_type is set to 'text'

Software Versions

Python: 3
OS: android
Kivy: 2.1.0
Kivy installation method:pip installation

Describe the bug
A clear and concise description of what the bug is.
We have the keyboard_suggestions flag in TextField widget class to enable / disable the suggestion words shown in keyboard.
Expected behavior
When I focus on textfield with keyboard_suggestions flag set to false, keyboard should not show suggestions
Actual behavior
Irrespective of keyboard_suggestions flag set to false/true, keyboard (Gboard) always show suggestions
To Reproduce
keyboard_suggestionsBug.zip
Code and Logs and screenshots

https://user-images.githubusercontent.com/58268827/206899982-dbfa3ba1-7913-46ea-933f-8dee8ac9a7f3.mp4

**Additional context**
keyboard_suggestions doesn't seems to have any effect on text field.
Device details:
Device : IQOO Z5 Pro, Android : 12, Keyboard : GBoard.

We already had some discussion at kivy user support google groups regarding this : [[[https://groups.google.com/d/msgid/kivy-users/638f4ca5.050a0220.acb7d.a403SMTPIN_ADDED_MISSING%40gmr-mx.google.com](https://groups.google.com/d/msgid/kivy-users/638f4ca5.050a0220.acb7d.a403SMTPIN_ADDED_MISSING%40gmr-mx.google.com?utm_medium=email&utm_source=footer)](url)](https://groups.google.com/g/kivy-users/c/yQIuLZPf-jg) with @ElliotGarbus and @RobertFlatt and @misl6  was mentioned by them in between to understand the issue better in between the conversation

Please help me resolve this issue :)

@tshirtman @misl6 @RobertFlatt Created an issue to track what can be done as part of conversation : https://groups.google.com/g/kivy-users/c/yQIuLZPf-jg .  Can anyone please acknowledge this issue ?

@tshirtman @misl6 @RobertFlatt Created an issue to track what can be done as part of conversation : https://groups.google.com/g/kivy-users/c/yQIuLZPf-jg .  Can anyone please acknowledge this issue ?

Hi @Aravind0007 !
Please see: https://github.com/kivy/kivy/pull/8089
Unfortunately, we can't do quite much if Android keyboards are ignoring this flag. I've added a warning with a workaround to the docs.

Thanks @misl6 ! I will try the work around and look how it works,


WIP: Add GitLab Application deployment using Crossplane Resources example

Resolves #
Checklist:

[ ] Documentation has been updated, if necessary.
[ ] Pending release notes updated with breaking and/or notable changes, if necessary.
[ ] Upgrade from previous release is tested and upgrade user guide is updated, if necessary.
[ ] Code generation (make generate) has been run to update object specifications, if necessary.
[ ] CRD manifests generation (make manifests) has been run to update CRD manifests yaml file specifications, if necessary.
[ ] Update dependencies (make vendor) has been run to update Gopkg.lock file, if necessary
[ ] RBAC permissions in clusterrole.yaml have been updated to include new types, if necessary
[ ] All related commits have been squashed to improve readability.
[ ] Comments have been added or updated based on the standards set in CONTRIBUTING.md

Nice work! Does this assume that gitlab and crossplane run in the same cluster, or are we operating on a remote GKE cluster? I think both are interesting.

As written, this example will create a new GKE Kubernetes cluster for GitLab deployment.
I created https://github.com/crossplaneio/crossplane/issues/436 to track GKE in-cluster example.


Add decode api test framework for all codecs

This patch set not intend to merge. I just use it for preview and collect patch set from different component owner.
Hi @chivakker
Could you help to fix mpeg2 patch? It will break the yamidecode. The dumped md5 is totally wrong.
Please also help to add mpeg2 releated unit test in DecoderApi_unittest.cpp too.

This is a fix for https://github.com/01org/libyami/issues/661, one important feature missed here, flush. We will add this later.

@lizhong1008 , Please helpto review h264 patch, please give some suggestion for the failed case mentioned in the commit. thanks

close this since we have #695


Syntax highlighting of nested comments is broken

Hi,
Syntax highlighting of nested comments is broken:
/*
let foo = 1
/*
let bar = 1
*/
let baz = 1
*/

GitHub has the same problem, so the code block above is a good demonstration. The compiler seems to support nested comments.

Let's say that the compiler doesn't support nested comment anymore btw. In the current situations regarding the syntax and various toolings, nested comment isn't a safe assumption to make.
Though the highlighting should be fixed. Thanks for the report! Done just now

Let's say that the compiler doesn't support nested comment anymore btw. In the current situations regarding the syntax and various toolings, nested comment isn't a safe assumption to make.
Though the highlighting should be fixed. Thanks for the report! Done just now

Let's say that the compiler doesn't support nested comment anymore btw. In the current situations regarding the syntax and various toolings, nested comment isn't a safe assumption to make.

Oh, really? That's too bad. I think, nested comments are extremely useful (mostly when debugging by uncommenting code that has comments itself).
Isn't it pretty easy to parse nested comments?

Though the highlighting should be fixed.

Thanks!

Let's say that the compiler doesn't support nested comment anymore btw. In the current situations regarding the syntax and various toolings, nested comment isn't a safe assumption to make.

Oh, really? That's too bad. I think, nested comments are extremely useful (mostly when debugging by uncommenting code that has comments itself).
Isn't it pretty easy to parse nested comments?

Though the highlighting should be fixed.

Thanks!

Your debugging will still work either way, since it doesn’t rely on knowing about nested comments. All the code sees is that there’s a bigger region of code commented out.
Parsing nested comment can be done. But this will now be a sometime confusing parse error:
/*
  hi /* bye
*/

ironically that might trip up your debugging workflow.

That makes sense, thank you.

That makes sense, thank you.


C#: A script that inherit a type from external C# project is marked as out of sync forever

Tested versions
v4.3.dev.mono.custom_build [8ff821670]
System information
Godot v4.3.dev.mono (8ff821670) - Windows 10.0.17763 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4060 Ti (NVIDIA; <IP_ADDRESS>01) - AMD Ryzen 9 5900X 12-Core Processor (24 Threads)
Issue description
When inspecting a node with a script that inherits a type from external C# project attached to it, Godot will always show it is out of date, even if the C# project has been built.

Steps to reproduce

Download and extract the included InspectorError.zip
Open InspectorErrorProject with Godot Editor
Build the C# project
Select the Node inside the scene tree
Inspect
Build the C# project again
Inspect

Minimal reproduction project (MRP)
InspectorError.zip

Video is here
https://github.com/godotengine/godot/assets/71481700/8f6744b6-f643-403b-9480-ad2c34a1420a

I don't think this should be tagged as regression, since types from external assemblies aren't especially supposed to work as Godot types.

I don't think this should be tagged as regression, since types from external assemblies aren't especially supposed to work as Godot types.

Should this behavior be documented, or should a separate warning be produced instead of the out-of-sync warning? This can be unclear to users.

Close as the mono module (aka GodotSharp) wasn't designed for handling external scripts, and this reminder doesn't enable that support either. Let's wait for the new binding implementation.


libepoxy was skipped: missing required distro feature 'opengl' (not in DISTRO_FEATURES)

All recipes that rely on cv-bridge and hence on opencv are unbuildable if the distro feature 'opengl' is not in DISTRO_FEATURES.
bitbake reports a number of NOTE errors during parsing of this kind:
NOTE: Runtime target 'compressed-depth-image-transport' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['compressed-depth-image-transport', 'cv-bridge', 'opencv', 'gtk+3', 'libepoxy']

The Build Configuration for this failure was:
BB_VERSION        = "1.31.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-14.04"
TARGET_SYS        = "i586-oe-linux"
MACHINE           = "qemux86"
DISTRO            = "nodistro"
DISTRO_VERSION    = "nodistro.0"
TUNE_FEATURES     = "m32 i586"
TARGET_FPU        = ""
meta              = "master:b746223787a0195c3a4d16523003c62ec0ac8451"
meta-oe
meta-multimedia
meta-python       = "master:aa8e156d56d487d5419dd353da50778d56d47703"
meta-ros          = "master:e8f3e9c255731a88a9001abcc8340695a4def583"

The additional DISTRO_FEATURE check was added in commit 3edf08b38b:
http://cgit.openembedded.org/openembedded-core/commit/?id=3edf08b38b0af93cef0933b061349264dc86d54c

libepoxy builds successfully for meldoic when opengl appears in DISTRO_FEATURES (as it does when DISTRO is webos). @bulwahn < Can this issue be closed?

"Silence implies consent" (see http://wiki.c2.com/?SilenceImpliesConsent).


HIP13: Transfer hotspot

Original PR: #42
Authors: @mrallen1, @abhay

Summary: This proposal introduces a new type of transaction to the Helium blockchain called transfer_gateway_v1. This transaction will be an atomic transfer of an onboarded Hotspot / gateway from one owner to another. This transaction can have an optional amount of HNT associated.
Rendered version: https://github.com/helium/HIP/blob/9cf52310b532d98232d21de33449ce789c58ef10/0099-transfer-hotspot.md

Rough consensus among the community was discussed and memorialized at the September 2020 community call: https://docs.google.com/document/d/1bMm2alBigBj3detA775Dn0Gz9UM5XczAeK9vnjBB3l0/edit#bookmark=id.sdsw04n7xjcg


Wrong yaml block in 'Restore keys' example

[Enter feedback here]
There is a YAML example of using cache restore keys in 'Use Cache task' part, 'Restore keys' subparagraph.
According to the description, it should have 2 restore keys: 'yarn | "$(Agent.OS)"' and 'yarn'.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 77c20289-dab2-7a6e-4f63-4b30eaff2c71
Version Independent ID: d75cc196-90c1-8291-9907-ff405bde4edf
Content: Pipeline caching - Azure Pipelines
Content Source: docs/pipelines/release/caching.md
Product: devops
Technology: devops-cicd-release
GitHub Login: @ramiMSFT
Microsoft Alias: rabououn

@Thank you for your feedback!


Option to show green flag/stop sign buttons

Maybe to hide the fact that it's Scratch, it should be the triangle play icon. Should it be alongside the fullscreen button? It also must be large enough for touch
De Discord (discrim 4800)

https://scratch.mit.edu/users/Sheep_maker/#comments-104430554


code highlight

Very nice theme ❤
Unfortunately the code highlight isn't very nice:

sorry, seems to be another plugin :/


Update init method of meta.py

the ClassifierFeature class accept a classifier positional parameter, it should be a Classifier instance. But when we  use process.pipeline.Pipeline.load() to load our system's config file(e.g,config.json), it will create a ClassifierFeature instance with 'ranker' as classifier parameter which is not a Classifier instance and will  raise a error when scoring for a doc. I modify the code in the __init__  as follow:
        if isinstance(classifier,(str,unicode)):
           self.classifier = Classifier.load(classifier)
        elif isinstance(classifier,Classifier):
            self.classifier = classifier
        else:
            raise Exception("Unknown classifier %s."%classifier)

After that, the following code can run through:
        linker = Pipeline('config.json')
        doc = linker(doc)

I hope it is useful.

Good catch. Looks like this was broken in 86a8114995c8230ab495d0e621fb108c1b7d41c9.
I would suggest a slightly different approach to avoid overloading the class parameters and checking types.
def __init__(self, classifier=None, classifier_model_tag=None):
    if (classifier_model_tag is None) != (classifier is None):
        raise Exception('You must provide a classifier_model_tag or classifier instance, but not both.')
    self.classifier = classifier or Classifier.load(classifier_model_tag)

This would then require updating config.json to provide the 'classifier_model_tag' parameter instead, which has the benefit of making it consistent with how the other features work!

@andychisholm great! your suggestion is much reasonable. I will close this pull request later.

Would be great if you could add it to this PR, i'll then merge it in. Thanks!


Add ec.fetch_oci_blob rego function

~It implements #1070, but it doesn't resolve it just yet. As a followup PR, I'll add acceptance tests to complete this functionality.~
UPDATE: Acceptance tests are now included.

I was wondering about the naming, and if ec.oci.blob could be a better name, or even if we want to push this upstream to OPA and have it opa.blob?

Updated to go with ec.oci.blob.
I think you probably meant oci.blob on your second suggestion. If so, that sounds like a good upstream name if/when this function is part of opa itself. For now, since it is implemented in EC, let's make it super obvious that it is related to EC by having the ec. prefix.

Caching is not working. I need to rethink the approach. Put it in draft for now.

I'm gonna hold off on the cache approach for this PR due to https://github.com/google/go-containerregistry/issues/1821.

FYI, code coverage is failing to be uploaded. It is a known issue and it happens from time to time...


✨ Add support for closing issues as "not planned"

Ref https://github.com/tiangolo/issue-manager/discussions/24
Shortly after opening the discussion I did some digging and figured that it might not be too difficult to do. Let me know if I went into a wrong direction.
Thanks again for this neat tool 🙏🏻

Hey @tiangolo apologies for tagging, just in case you missed it... Do you think it would be worth adding? Did I miss anything? Thanks

Thank you!
I would consider "not planned" something to close feature requests, but then I would normally just close the issue directly. So I wouldn't really think it would make sense to add it here.
I just replied to the discussion, let's continue the conversation there for now.


Bump to latest go-digest.

This renames the license file (so automated tooling can find it, which I care
about) and also pulls in some documentation and comment changes, plus some
functional changes:
PR#33 -- future-proof the algorithm field.
PR#34 -- disallow upper case in hex portion.
No changes appear to be required to containerd code.
Signed-off-by: Ian Campbell<EMAIL_ADDRESS>(same as https://github.com/moby/buildkit/pull/356, seemed like it made sense to do it here too)

Hmm, unlucky change picked up https://github.com/LK4D4/vndr/commit/1fc68ee0c852556a9ed53cbde16247033f104111 ?

LGTM

Codecov Report

Merging #2319 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2319   +/-   ##
=======================================
  Coverage   45.41%   45.41%
=======================================
  Files          83       83
  Lines        9210     9210
=======================================
  Hits         4183     4183
  Misses       4351     4351
  Partials      676      676

Flag
Coverage Δ

#linux
49.9% <ø> (ø)
:arrow_up:

#windows
41.24% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4219f7b...623407a. Read the comment docs.

LGTM


Document process for moving collections from Incubator to Stable.

At the moment, the Kabanero Collections are all in incubator status.  We need to document the process which collections are graduated to stable, and how does that affect the Kabanero operator by default?

@stephenkinder I think we are getting to a point where it would be fair to consider the ICP4A, Kabanero and Appsody versions of a stack separate entities. What are your thoughts on this?

@stephenkinder The collections are today stored in github under separate repository directories, ie experimental, incubator, stable, and the location of the collections determines the stage of the collection.  The criteria for a collection being in in a specific stage is not clearly defined, if at all, and their current stage is based on their stage within the Appsody repository.
If we (Kabanero) or Champ are going to be moving collections to a different stage without the upstream stacks being moved, then having Champ have a fork of Kabanero collections and that as a fork of Appsody is a bit of a waste of time. As soon as Champ or we move a stack/collection the entire use of the fork / merge process becomes a real nightmare and redundant.  We need to make a decision on whether we stick with forking Appsody or not?
@kilnerm and I have also been thinking that  having the stacks/collection in different stage directories makes this process a bit cumbersome. We have been thinking of having a flat structure and having the stage ie incubator, stable  etc as an element within the stack metadata. This will make the process of moving from incubator to stable a lot easier and would also allow Champ to have his own values, ie beta, alpha, pre-prod etc.
The above suggestion would need changes to quite a few other components, Kabanero build process, Appsody CLI, Kabanero Operator, .....    We will also discuss this with the Appsody team to see what they think about the idea.
@kilnerm is going to be writing up our proposal and will pass this around for comments etc when done.

@stephenkinder @kilnerm
With the github structure we have today, I think the process for moving a collection from incubator to stable would be this:

Stack owner has some criteria to determine that a collection is now stable and should be moved. This criteria is not currently defined and is not something I think we can dictate to a stack owner. So the decision on when to move a collection into the stable state is in their hands.

Within the github repository, move the collection directory from within the incubator directory to within the stable directory

Increase the major version in the stack.yaml (and possibly the collection.yaml) to something other than 0, ie 1.0.0

Rebuild and release the collection

Once this is done and a new version of the collection is available then Jane will be able to use that new collection.

Need agreement on the architecture descions before implementation.

According to Neeraj, Appsody will be creating a draft from Appsody point of view.. but it won't be ready this week. They hope to have it in next sprint (2 weeks today).

According to Steve it can close


Add free stream preservation tests for non-conforming P4estMesh

In 3D, FSP only works in special cases for curved meshes (Kopriva et al., 2019, Section 6).
The three relevant cases (the other require different implementations) are:

conforming meshes,
two-dimensional extrusions,
meshes with N >= 2*Ngeo, where Ngeo is the degree of the geometry interpolant (kwarg polydeg of P4estMesh) and N is the polynomial degree of the solver (kwarg polydeg of DGSEM).

Case 1 is boring. I added tests for case 2 and case 3.
I also made the mesh in the 2D FSP example non-conforming.

Congratulations on the devilish PR number by the way :imp:

Great work @efaulhaber ! Everything looks good from my end with respect to the errors / testing. Also, everything is documented for the FSP restriction of N>=2N_geo


SDN-4062: Revert "SDN-4042: Increase upgrade rollout timers"

Reverts openshift/hypershift#2881
IC upgrades were a one time thing, reverting this back to original values in 4.15/main branch.

/approve
/lgtm


Instructions for docker

Could you please add instructions on how to run the script correctly in docker and docker-compose.yml?
Seems like I'm missing something when trying to run script with docker containers...

Example docker-compose file
services:
  yt-dlp-tg-bot:
    build: .
    restart: always
    environment:
      # https://my.telegram.org/apps
      API_ID: 12345678
      API_HASH: 476c7a3_example_hash_d1f9edc0a74
      BOT_TOKEN: "1234567890:ABCDEFGab_UG0_example_token_yMtSVBe"
      ALLOWED_USERIDS: "123456789,987654321"
      ADMIN_USERIDS: "123456789"
      ALLOWED_GROUPIDS: ""
      MAX_SIZE: 512MB


[Question] Is there a way to create a tag which is restricted to specific user and specifc channel?

I tried to use require block, but unable to check two parameters (&& check) with it.
I want role "r1" to be able to use tag "t1" only in channel "c1".
I tried {require(r1, c1):Error Message} {command: c1} This tag is working if any of r1 or c1 is satisfied. I want it to work only if both are satisfied
Is there any other way?
If this section is not meant for these type of questions. Sorry

Currently this is not possible, however, it does seem like a useful feature so I will be converting this issue into a feature request. In the future, if you have questions head over to my channel named #support_phen-cogs in the Cog Support Server.

Alright!


Add prefer-flow-prop-types rule

I would love a rule for preferring Flow types instead of propTypes. Our team is migrating and it would be great to use the linter for this purpose.
For example, it would produce an error on the following code:
export default class Statements extends React.Component {
  static propTypes = {
    items: PropTypes.array.isRequired,
    fetchStatements: PropTypes.func,
    isLoading: PropTypes.bool
  };
  // ...
}

But this code would remain valid:
export default class Statements extends React.Component {
  props : {
    items: string[],
    fetchStatements?: () => void,
    isLoading?: boolean
  };
  // ...
}

Flow isn't always a replacement for propTypes - you can do things with custom propTypes that you can't do with Flow.
A rule that required you use Flow types instead of the built in prop-types package might make sense, but I'm not sure how valuable it'd be.

Here at Uber we almost never use custom prop types, so the rule would be very useful to us. And it would be very easy for the rule to simply not warn when a custom function was used.

I strongly endorse https://npmjs.com/airbnb-prop-types; you can get much more useful warnings than Flow is capable of giving you ;-)
A new rule, require-flow-vs-proptypes is probably good, that starts out with no options and only warns against React.PropTypes/prop-types.


Direct JATS implementation first

Sections get converted into sections first. Flattening is done in another transform/conversion step.

Should we get this merged for the start of the week? :)

Yip. I will cleanup, first.

@michael next iteration on new PR :)


Improve open submissions list

Removed comma from Submission ID
Added submission date

Feel free to think it makes sense to display more attributes for each submission.
I initially wanted to display the date/time when the submissions were last assessed but after going through the API found out that it is not sent (field of the class Result is marked with @JsonIgnore).
I also had to use another date formatter as for some reason the date format for the submission date is different from the ones we had so far (AssessmentDueDate, etc.)

I would suggest you just check the web app code. I know they have it in their assessments list and they, so they also have to get it from somewhere.

I would suggest you just check the web app code. I know they have it in their assessments list, so they also have to get it from somewhere.

Did you mean the text "a few seconds ago" here?

For every submission, an array of results are sent and we only need the last (latest) result.
There is a field "completionDate" for each result, for which the assessment has been completed, which means that the assessment has been submitted, not just saved. Otherwise the completionDate is not there, hence the text "(a few seconds ago)" being displayed for all submissions that are still open.

I think it wouldn't make much sense to include this since we would just have a list that looks like this:

It clutters the view and gives the user no additional information, in my opinion :)

Its definitely more useful than the submission date 🤷♂

Its definitely more useful than the submission date 🤷♂

I mean we could go with this as well, it's already implemented. What does everybody else think?

I agree with both of you. So I would leave the last assessed time in the sections, as it is already implemented and we can talk to our customer again next walk what he prefers.

I like it! But in this case i think an ascending order would definitely make more sense. Am I the only one?

Looks really nice! I am just not 100% about the sorting. Maybe we should think of sorting it by submission due date?

Good idea, should we sort it from the latest (most recent) submission or the other way around?

Looks really nice! I am just not 100% about the sorting. Maybe we should think of sorting it by submission due date?

Good idea, should we sort it from the latest (most recent) submission or the other way around? I think it'd be better if we sort it from the submission with the oldest submission date, like so:

Yes, I would also recommend your proposed solution.

I tested everything and it works fine! One thing I would change, which hasn't anything to do with this PR but could be changed in here anyway is the size of the exercise title. I think .title2 looks good, so maybe add this in ExerciseListItem

Like this?

I tested everything and it works fine! One thing I would change, which hasn't anything to do with this PR but could be changed in here anyway is the size of the exercise title. I think .title2 looks good, so maybe add this in ExerciseListItem

Like this?

Yes, definetely better than before, maybe make the font weight a bit thicker like semibold

I tested everything and it works fine! One thing I would change, which hasn't anything to do with this PR but could be changed in here anyway is the size of the exercise title. I think .title2 looks good, so maybe add this in ExerciseListItem

Like this?

Yes, definetely better than before, maybe make the font weight a bit thicker like semibold

Good idea!

I like it!

I tested everything and it works fine! One thing I would change, which hasn't anything to do with this PR but could be changed in here anyway is the size of the exercise title. I think .title2 looks good, so maybe add this in ExerciseListItem

Good catch! Let's make that consistent.

In the submissionslist too?

In the submissionslist too?

Not so sure about that one, the only thing that changes in each cell is the id, and it is not that important

But it doesnt't look bad either, go for it

In the submissionslist too?

Not so sure about that one, the only thing that changes in each cell is the id, and it is not that important

I'd just make the submission IDs semibold then

Yeah you could try that

Yeah you could try that

Looks more subtle :)


add stricter Omit helper type

Search Terms
omit strict
Suggestion
The new Omit type does not restrict the omitted keys to be keys actually present on the given type. There should be some avenue to express "omit, but only with keys that are present", likely either a change to Omit or some other Omit-like type.
Use Cases
Copied from https://github.com/pelotom/type-zoo/pull/31.
The benefit that a stricter type has is primarily:

Preventing typos.
Allowing the compiler to pick up on rename refactors automatically.

Currently, permissive Omit acts as a "barrier" that prevents rename refactors from passing through, which means that any such refactor generates whole bunches of errors that have to be manually fixed. If the field in question is optional, this can actually introduce bugs.
And some further color:
I generally use Omit with string literal unions (as opposed to, say, generic types that extends string), because I often use them for defining higher-order React components that wrap another component except for this one prop. As such, in my use case, I never want a permissive Omit.
Examples
interface ImplementationDetailProps {
  publiclyVisibleFoo: Foo;
  filePrivateBar: Bar;
}

class ImplementationDetail extends React.Component<ImplementationDetailProps> { ... }

export type PublicProps = Omit<ImplementationDetailProps, "filePrivateBar">;

export class Public extends React.Component<PublicProps> { ... }

Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

I was disappointed when I saw that the Omit type added in #30552 was not the strict one suggested in #30455, and what most third-party type libraries provide. Like @seansfkelley mentioned, there are many benefits of making it strict. One more reason, is the ability for everyone using these type libraries to use the built-in one. This will not be possible if the built-in one is not strict.
// @BendingBender @CvX

Currently, permissive Omit acts as a "barrier" that prevents rename refactors from passing through

Could this be fixed instead?

Currently, permissive Omit acts as a "barrier" that prevents rename refactors from passing through

Could this be fixed instead?

That would help a lot, I think, but doesn't catch cases where someone does a manual refactor or just outright typos a field name and ends up exposing the wrong type to a consumer (i.e., a type that has fields that should not be visible).

It seems like the constrained Omit type is going to make at least half of users unhappy based on declarations within DefinitelyTyped. We've decided to go with the more permissive built-in which your own constraints can build on.

I wish I hadn't encouraged opening this issue in the first place. It just made the situation worse than before as the Omit name is now taken by TS, so we have to rename our strict versions to prevent confusion...

It seems like the constrained Omit type is going to make at least half of users unhappy based on declarations within DefinitelyTyped.

And now half of the users are unhappy because it's loose. I totally understand that decisions like this are though, but you can't make everyone happy. Sometimes you have to make people unhappy for the greater good. And in my opinion, strict typing is the greater good.
The current situation is that everyone is still using a custom Omit, e.g. StrictOmit which again should be defined everywhere. Hence, we're back to start.

I like having a loose Omit option available, but I agree it would be nice to see Omit stay consistent with how the community uses and understands it today. Providing both seems like a win-win.
Maybe we could find an alternate name for it?

OmitIf
Exclude
Remove
Without

it would be nice to see Omit stay consistent with how the community uses and understands it today.

I have to clear up this misconception. There were 12 different definitions of Omit on DT and the two most popular definitions differed on whether or not to constraint the key:
(hit count, definition)
15
type Omit<T, K extends keyof T> = Pick<T, Exclude<keyof T, K>>
13
type Omit<T, K> = Pick<T, Exclude<keyof T, K>>;
11
type Omit<T, K extends keyof T> = Pick<T, ({ [P in keyof T]: P } & { [P in K]: never } & { [x: string]: never, [x: number]: never })[keyof T]>;
3
type Omit<T, K extends keyof any> = Pick<T, Exclude<keyof T, K>>;
2
type Omit<T, K extends keyof T> = Pick<T, Diff<keyof T, K>>;
2
type Omit<T, K> = { [key in Exclude<keyof T, K>]: T[key] };
2
type Omit<T1, T2> = Pick<T1, Exclude<keyof T1, keyof T2>>;
1
type Omit<T, E extends keyof T> = { ...
1
type Omit<T, K extends keyof any> = T extends any ? Pick<T, Exclude<keyof T, K>> : never;
1
type Omit<T, K extends keyof T> = Pick<T, ({ [P in keyof T]: P } & { [P in K]: never } & { [x: string]: never })[keyof T]>;
1
type Omit<T, K extends keyof T> = T extends any ? Pick<T, Exclude<keyof T, K>> : never;
1
type Omit<T, K extends string> = Pick<T, Exclude<keyof T, K>>;

You can pick at the numbers and try to declare a democratic majority or something, but the reality is that only one definition doesn't break a substantial portion of people.
Moreover there is nothing wrong with passing non-keyof T arguments to K:
type Omit1<T, K> = Pick<T, Exclude<keyof T, K>>;
type Omit2<T, K extends keyof T> = Pick<T, Exclude<keyof T, K>>;

// Can't use Omit2 here
declare function combineSpread<T1, T2>(obj: T1, otherObj: T2, rest: Omit1<T1, keyof T2>): void;

type Point3d = { x: number, y: number, z: number };
declare const p1: Point3d;
// OK
combineSpread(p1, { x: 10 }, { y: 5, z: 2 });
combineSpread(p1, { x: 1, y: 3 }, { z: 2 });
// Error
combineSpread(p1, { x: 10 }, { z: 2 });

Moreover there is nothing wrong with passing non-keyof T arguments to K

This is true, and why the original suggestion was worded to allow for "some other Omit-like type". That said, as I noted in an earlier comment:

I actually don't understand the use-case for permissive Omit at all

Which is still mostly true, though your provided example seems like a thing I would eventually write at some point, I suppose. Currently, I use type-zoo's OmitStrict everywhere and therefore, the name collision doesn't matter to me, practically speaking.
I always default to strict rather than lenient, and if the standard library doesn't want to, that's okay. I simply figured that if the standard library was going to try to be helpful by providing what until recently was a de facto community-standard type, it would want to address all the related use-cases, and I saw an opportunity to roll more of type-zoo into the standard library where I think it would be very helpful.

@RyanCavanaugh I appreciate that you want to look at the facts as opposed to passing opinion. Totally fair. That said, I want to make sure I'm following which packages you're talking about.
The two top packages I see, type-fest and typical, both look like they require the key to be present (if I'm reading them correctly).
Package Usage

See npmtrends.com/type-fest-vs-ts-essentials-vs-type-zoo-vs-typelevel-ts-vs-typical-vs-typical-ts-vs-typepark
Definitions
type-fest definition:
export type Omit<ObjectType, KeysType extends keyof ObjectType> = Pick<ObjectType, Exclude<keyof ObjectType, KeysType>>;

typical definition:
export type Omit<T, K extends keyof T> = T extends any ? Pick<T, Exclude<keyof T, K>> : never;

You can pick at the numbers and try to declare a democratic majority or something, but the reality is that only one definition doesn't break a substantial portion of people.

@RyanCavanaugh I think this is a reasonable point.
That said, historically the TypeScript docs have always shown examples as the strict version.

We did not include the Omit<T, K> type because it is trivially written as Pick<T, Exclude<keyof T, K>>

(from https://www.typescriptlang.org/docs/handbook/advanced-types.html)

Also worth noting that, historically, the TypeScript docs have always shown examples as the strict version.

We did not include the Omit<T, K> type because it is trivially written as Pick<T, Exclude<keyof T, K>>

(from https://www.typescriptlang.org/docs/handbook/advanced-types.html)

All that said, I agree that Omit should stay loose and OmitStrict (or an alternatively named type helper) should be added in addition.

This is really misfortune to be declined.  Can someone tell me what is the motivation why we add Omit when the decision was made at 2.8 saying it's trivial???  It's definitely NOT as trivial.  Also, should the doc also get updated to avoid confusion for the future developers?
In the release note, it's been said that TS core team finally realize it's so common so hoping to standardize its implementation for the community. I see it's a great move to make our life easier, but then I see it just get shipped sloppily. 🙁
@RyanCavanaugh, I did surprise you dig into the DT and count these implementations and use it justify something that is shaky.  I do appreciate this empathy to ensure not making too much noisy while ensure everyone can be happy whenever it is possible. But I do hope you and other members in the core team to rethink about the Omit implementation. If you guys really want to make it useful while ensure the backward compatibility then perhaps we should get a much different and less frequent name like it was did on choosing naming for Exclude over Diff.
Also, we can consider Pick, the closer friends of Omit, you can see how similarity they are and how they can be complimentary to each other.
Pick: pick members from a group to get a sub-group;
Omit: omit members in a group to get a sub-group;
It looks pretty nature and intuitive when we see them together, isn't it? But how come Omit is a permissive type while Pick isn't??? Reminder: Pick do constrains the second typed variable.
When we make comparison, compare Omit with Exclude is like compare egg with chicken. Exclude is comparable with Extract not Omit, which should be Pick, IMHO.

Uh... I see where this weird (Omit v.s. Exclude/Extract) comparison came from (#30738). I think it is not good to post my comment there so I did it here. Here is how I justify the API surface for the built-in helper types:
              non-permissive        permissive

anti-selective   Omit* <-----------> Exclude
                  ^                     ^
                  |                     |
                  v                     v
selective        Pick <------------> Extract

For the above relationship and reason, I really believe Omit shouldn't be permissive.  If it has to be, please, please, please, find another noisy naming for it... and so the 2.8 doc don't need to get updated too, win-win?! 🤔.

I've always wanted a suggestive type, which can give both intellisense and permissive type, e.g. for Omit:
type Omit<T, K extends keyof T | keyof any> = Pick<T, Exclude<keyof T, K>>;

Or maybe just keyof (T | any), either way, this is against subtype reduction.

Personally I agree that Omit should be strict, given it's the opposite of Pick (@leoyli pretty much nailed it).

You can pick at the numbers and try to declare a democratic majority or something, but the reality is that only one definition doesn't break a substantial portion of people

which only becomes a reality when those people both update to 3.5, and remove their definition of Omit.
Case and point, I can do this no problem:
type Pick = string;

const picked: Pick = 'hello';

I mean given that you have to update eitherway, you could have easily made both parties happy by implementing LooseOmit & StrictOmit, and then decided if you wanted to make a call to which one gets to be "Omit", if any.

only one definition doesn't break a substantial portion of people

That's assuming that everyone not using StrictOmit is doing so loosely. You might have looked into this more than just the numbers, but if you've not then I don't think they're that valuable, as it depends on how they're actually being used.
For example, it's quite reasonable the people using LooseOmit have been doing so in a "strict" sense i.e their typings don't require the looseness, it just happens to be how they wrote the typing at the time.
However, in saying all this, for me my whole actual problem with having LooseOmit, is the lack of intellisense. It's just plain annoying, especially given Pick, and that the whole reason you'd use a string literal with Omit would be for a defined property (i.e LooseOmit doesn't make any sense when you're omitting string literals)
I've found that in WebStorm intellisense if you have type Omit<T, K extends keyof T | any> = Pick<T, Exclude<keyof T, K>>; but sadly that's not the case in playground or VSCode.
Off the top of my head (which is a head that has little idea how the internals of TS work for generating intellisense), could the intellisense somehow ignore any in unions? i.e so that keyof T | any would become keyof T for the intellisense only.
That wouldn't be a breaking change, and imo what is suggested for any is unpredictable anyway, since is any: you can suggest anything.

Finally, a crazy idea: what about omit.strict and omit.loose libs? I don't know enough about how libs work internally & in dependencies to know if that'll just straight up break, say if you uses lib: [ 'omit.strict' ] and installed a DT package that uses loose, but that would let us pick between the two.

is it possible that a future release (3.6, 4.0, etc.) could tighten the strictness? i can understand the "open arms" approach here, but i really would prefer a stricter version of the type at some point for basically all the reasons mentioned so far.

If you want to enforce that no-one on your project accidentally uses the built-in Omit, here's an ESLint rule for that:
{
  rules: {
    '@typescript-eslint/ban-types': [
      'error',
      {
        types: {
          Omit: "Prefer `OmitStrict`.",
        },
      },
    ],
  }
}

It seems like the constrained Omit type is going to make at least half of users unhappy based on declarations within DefinitelyTyped.

It looks like the typescript team might have accidentally found a technical solution to what is actually a people problem: what do users want this type to be? What are programmers trying to express when they write Omit<Props, 'className'>?
There are plenty of conceivable reasons an Omit in DT might not constrain the keys. One is low-quality or under-maintained packages. Another is that the definition was written for TypeScript 2.0 which didn't have keyof yet. I think the latest version of the stdlib should be held to a higher standard than miscellaneous DT packages. I hope we can find a path forward towards improving this situation.

Just an FYI: WebStorm 2019.2.2 will ship WEB-40482 that'll mean it will provide intellisense for the second argument of Omit based off the first argument:

Artificially supplied Omit's second argument with the expected type containing all the keys of the first argument.
Now completion, go to declaration, find usages and rename will work for properties referenced in Omit's second argument.

After much discussion, we think libraries providing their own "stricter" versions of Omit (as well as Exclude and other friends) is preferable. The Strict versions of these types are very infectious in terms of forcing upstream constraints and it's not clear that people will wisely choose between them. This can induce some real friction if not carefully managed.
This is actually more true now that Omit is in the lib - if we pick OmitStrict (for which I'm sure there are in turn multiple definitions to pick from) then there's not much in terms of good names left in userspace. There are a few ways to write all of these helper types and letting developers choose the one that matches their own definition of "strict" is the option that's going to maximize individual freedom.
The reaction here and on Twitter to our (entirely defensible IMO) choice of the definition of Omit shows why we're not really excited about picking an OmitStrict that is going to anger some 30-70% of developers because we don't pick their preferred definition. It appears it's only really a good idea to add things to the lib if its definition is entirely unambiguous, and OmitStrict doesn't fit that criteria. In retrospect, neither did Omit, and perhaps we should have just left it out.
Go forth, developers, with your chosen definitions of OmitStrict happy and secure in the knowledge that TS isn't going to stomp on that name 😬

Apologies for resurrecting this thread, but I did stumble upon a behavioral difference that made me very happy for my usage of OmitStrict. I respect the team's decision to not include it in the standard library, but I thought this example was worth having recorded somewhere, and I don't believe it's been mentioned in previous comments.
I'll let the example speak for itself:
type OmitStrict<T, K extends keyof T> = T extends any ? Pick<T, Exclude<keyof T, K>> : never;

interface Foo {
  foo: string;
}

// Silently produces dangerous {} type.
type T1 = Omit<Foo | undefined, "bar">;

// Complains, regardless of what you provide to the second type parameter.
type T2 = OmitStrict<Foo | undefined, "bar">;

// Complains like you would expect.
type T3 = OmitStrict<NonNullable<Foo | undefined>, "bar">;

// Ah, type safety.
type T4 = OmitStrict<NonNullable<Foo | undefined>, "foo">;

Playground Link

Thanks for the OmitStrict helper, @seansfkelley.

@RyanCavanaugh,
I take your point that no matter what you do as far as Omit vs. OmitStrict, people are going to complain, but here's one more suggestion to mull over:
Could there not be a TSConfig option strictOmit? I know there are already a million switches in TSConfig already, but this would allow people to opt into a type-checked Omit if that's already how they're using it in their project.
Happy to raise this as a separate issue if you think it's worth considering and doesn't already exist.

@devuxer a flag would mean that you could change the behavior of types on a third-party project, which doesn't seem like it'd work out too well.

What @ljharb said. Flags like that are just asking for errors to appear ex nihilo in your imported .d.ts files, which no one wants.

Couldn't Omit just accept another optional argument strict = false? That way it should behave consistently and users wouldn't need to create a wrapper (or worse, import a 3rd party library for just StrictOmit)
PoC:
type Omit<
  T,
  K extends S extends true ? keyof T : keyof any,
  S extends boolean = false
> = Pick<T, Exclude<keyof T, K>>;

interface X {
  foo: string;
  bar: string;
}

type A = Omit<X, "baz">;        // Backward compatible, no errors
type B = Omit<X, "baz", true>;  // Error: Type '"baz"' does not satisfy the constraint 'keyof X'


Update cri-tools commit to pick up latest tests and changes

Picks up new pid namespace tests.
Also picks up the changes made to critest so it doesn't depend on the source code.
Signed-off-by: umohnani8<EMAIL_ADDRESS>

@mrunalp PTAL. Please let me know if I missed updating something else.

LGTM
Do we need to run cri tests?

@umohnani8 You might need to change critest.yml to account for how -f has changed.

The tests should work after upgrading to latest cri-tools here.

Tests are green!

/test all

@mrunalp I can't see why/where the tests are failing.

STDERR:
---
go build github.com/kubernetes-incubator/cri-tools/cmd/critest: no buildable Go source files in /go/src/github.com/kubernetes-incubator/cri-tools/cmd/critest
---

This seems to be the issue in integration @umohnani8

same error in critest

test/integration/build/cri-tools.yml
3:- name: clone cri-tools source repo
5:    repo: "https://github.com/kubernetes-incubator/cri-tools.git"
6:    dest: "{{ ansible_env.GOPATH }}/src/github.com/kubernetes-incubator/cri-tools"
11:  command: "/usr/bin/go install github.com/kubernetes-incubator/cri-tools/cmd/crictl"
14:  command: "/usr/bin/go install github.com/kubernetes-incubator/cri-tools/cmd/critest"

last line here is failing ;)

/test critest_rhel

/test all

/test critest_rhel

So critest_rhel is failing because the ginkgo.skip flag is not skipping the NoNewPrivs test. The flag definitely works locally.

@mrunalp looks like it is getting the latest version of ginkgo, which is what I have locally as well.
- name: install Go tools and dependencies
  shell: /usr/bin/go get -u "github.com/{{ item }}"
  with_items:
    - tools/godep
    - onsi/ginkgo/ginkgo

/test all

/test all

/test critest_rhel

/test all

/test all

/test all


Problem with tool change automation

Prerequisites

[ 3.18.3 ] Are you running the latest version?
[ Yes ] Are you reporting to the correct repository?
[ Yes ] Did you perform a cursory search?

Description
I am trying to change using the buttons, the selected tool.
In an earlier version (3.5.3) I had no problem, but of course, more tools and more options have been added.
I have the problem with some of these tools, which didn't give me any problems before.
For example:
· "EllipticalRoiTool" and "RectangleRoiTool", if you add them by hand through the browser console, they work correctly. Following those same steps by automating the actions, do not draw either the circle or the square of either of these two tools. Nor does it return any errors.
· "EraserTool" literally does nothing. It used to work with the indicated version but now it does not remove the marks of other tools or return any problems.
The vast majority of tools work, but for some reason some of them are not working.
How could I see why they are not working as they should?

Estoy tratando de cambiar usando unos botones, la tool seleccionada.
En una versión anterior (3.5.3) no tuve ningún problema, pero claro, se han ido añadidiendo más herramientas y más opciones.
El problema lo tengo con algunas de estas herramientas, que antes no me daban ningún problema.
Por ejemplo:
· "EllipticalRoiTool" y "RectangleRoiTool", si las añado a mano a través de la consola del navegador funcionan correctamente. Siguiendo esos mismos pasos automatizando las acciones, no dibuja ni el círculo ni el cuadrado de ninguna de estas dos herramientas. Tampoco devuelve ningún error.
· "EraserTool", no hace literalmente nada. Antes funcionaba con la versión indicada pero ahora no quita las marcas de otras herramientas ni devuelve ningún problema.
Funcionan la gran mayoría de herramientas, pero por algún motivo no están funcionando algunas de ellas.
Cómo podría ver el por qué no están funcionando como deberían?
Steps to Reproduce
let element = this.elementRef.nativeElement;
let tool = this.selectedTools['leftMouseButtonMask'];

let toolState = cornerstoneTools.getToolForElement(element, tool.name.replace('Tool', ''));
if (toolState === undefined) {
  cornerstoneTools.addToolState(element, tool.tool, tool.name.replace('Tool', ''));
  toolState = cornerstoneTools.getToolForElement(element, tool.name.replace('Tool', ''));
}
console.log(toolState);
if (toolState.mode === 'disabled' || toolState.mode === 'passive') {
  cornerstoneTools.setToolActiveForElement(element, tool.name.replace('Tool', ''), { mouseButtonMask: tool.mouseButtonMask });
}

@daviddgn, can you create a CodePen that demonstrates your issues? What is the current behavior? What is the expected behavior? By changing only the cornerstone-tools version to an older version, does that same CodePen exhibit the expected behavior?

I am sorry to say that I cannot create a CodePen.
The current behavior is that I have several checkboxes to indicate which tools are active, depending on whether they are pressed with the left mouse button or with the right button they are assigned to it when the tool is put into active mode (if it is a tool Use for the mouse wheel no matter what button you press).
The problem is that the tool change works with all except 8 of them all:

EllipticalRoiTool
RectangularRoiTool
EraserTool
FreeHandSculpterMouseTool
BrushTool
TextMarkerTool
LengthTool
ProbeTool

FreeHandSculpterMouseTool and BrushTool if they return errors, therefore I will try to solve this later.
But the other 6 simply do not return any errors.
The behavior that I expect from the code is that when you switch to one of those 6 tools that are not functioning correctly, when you select them, they are activated and can perform their function.
They should work, since it is not normal for the other 14 that I have active to work and these 6 are not.
I have already seen how to enable debug mode in the browser terminal, but the only thing that appears when I use the EllipticalRoi tool are lines detecting movement:
cornerstoneTools:eventListeners:mouseEventListeners mousemove: 1 +0ms cornerstoneTools.js:1279 cornerstoneTools:eventListeners:mouseEventListeners mousemove: 1 +12ms cornerstoneTools.js:1279 cornerstoneTools:eventListeners:mouseEventListeners mousemove: 1 +15ms cornerstoneTools.js:1279 cornerstoneTools:eventListeners:mouseEventListeners mousemove: 1 +8ms cornerstoneTools.js:1279 cornerstoneTools:eventListeners:mouseEventListeners mousemove: 1 +15ms cornerstoneTools.js:1279 cornerstoneTools:eventListeners:mouseEventListeners mousemove: 1 +7ms cornerstoneTools.js:1279 cornerstoneTools:eventListeners:mouseEventListeners mousemove: 1 +17ms cornerstoneTools.js:1279 cornerstoneTools:eventListeners:mouseEventListeners mousemove: 1 +12ms cornerstoneTools.js:1279 cornerstoneTools:eventListeners:mouseEventListeners mousemove: 1 +20ms cornerstoneTools.js:1279 cornerstoneTools:eventListeners:mouseEventListeners mousemove: 1 +13ms cornerstoneTools.js:1279
I tried to install the previous version with which it worked but I also have the same problem (only that in that version I could not activate the SVG cursors, therefore I have returned to the latest version).

I'm not sure I understand the issue you're experiencing. What is the behavior? What is the expected behavior? What have you tried (code snippets)?
Does a recent netlify demo work as you'd expect?
https://deploy-preview-991--cornerstone-tools.netlify.com/


[BUG]

Describe the bug
When you enter the main screen of this app and then click some of those reference comic, the content of that comic can be loaded incorrectly. To be more clearly, the shown comic is not consistent with the title page.
To Reproduce
Steps to reproduce the behavior:

Open the app and get in to main screen
Click the comic randomly
You may see the bug

Please complete the following information:

Device: iPhone 13 Pro Max
OS: iOS 16 beta 6
App Version: latest version

@chihchy fixed in #275.


Want to design the Our Service pages.

Want to make an our services page and make it redirect after clicking on these things.

Please assign me for this work @tushargupta1504  and add the label.

Assign me this issue @tushargupta1504. I will do significant change.
Thanks for considering.


[Limitation] TiCDC can't not handle DDL as alter table xx add column xx datetime default current_timestamp properly

What did you do?
Reproduction Steps

Create a table t1
create table t1 (id int primary key);

Create a changefeed to replicate this table

Insert some data into t1

Pause changefeed (the purpose is to manually create synchronization delay), assuming the current time is time1.

Add a new column to t1
alter table t1 add column `updatetime` datetime default current_timestamp;

Resume the changefeed and wait for the changefeed to replicate the above DDL downstream. Assume the current time is time2.
When comparing the upstream and downstream data, it will be found that the values of the newly added column updatetime upstream and downstream inconsistent. The difference in this column upstream and downstream is time2 - time1.

Reason: This is because cdc only synchronizes the DDL itself when synchronizing DDLs that will cause destructive changes like add column, and does not synchronize the row changes caused by the DDL. The reason for doing this is to reduce synchronization latency.
Currently, these inconsistent data can only be manually fixed.
What did you expect to see?
No response
What did you see instead?
As described above.
Versions of the cluster
Upstream TiDB cluster version (execute SELECT tidb_version(); in a MySQL client):
(paste TiDB cluster version here)

Upstream TiKV version (execute tikv-server --version):
(paste TiKV version here)

TiCDC version (execute cdc version):
All version.

if it's caused by different value of current_timestamp  in upsteam and downstream, it should be able to fix like https://github.com/pingcap/tiflow/pull/7036

@lance6716 Thank you very much for your useful insights!

/found customer

Only fix this issue from v6.5.


aligning README.md and CONTRIBUTING.md to FINOS project blueprint language

aligning README.md and CONTRIBUTING.md to FINOS project blueprint language

Can one of the admins verify this patch?

Codecov Report

Merging #132 into dev will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##             dev    #132   +/-   ##
=====================================
  Coverage   88.9%   88.9%
=====================================
  Files         36      36
  Lines        820     820
  Branches      88      88
=====================================
  Hits         729     729
  Misses        59      59
  Partials      32      32

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f107d58...ef0cb5f. Read the comment docs.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?