Accelerated GPU instance NodePool definition yields error "no instance type satisfied resources"

Description
Context:
Hey! I have Karpenter deployed very neatly to an EKS cluster using FluxCD to automatically manage Helm charts:

(click to expand) Helm release for Karpenter
# including HelmRepository here, even though it is in a separate file
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: HelmRepository
metadata:
  name: karpenter
  namespace: flux-system
spec:
  type: "oci"
  url: oci://public.ecr.aws/karpenter
  interval: 30m
---
apiVersion: v1
kind: Namespace
metadata:
  name: karpenter
---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: karpenter-crd
  namespace: karpenter
spec:
  interval: 5m
  chart:
    spec:
      chart: karpenter-crd
      version: ">=1.0.0 <2.0.0"
      sourceRef:
        kind: HelmRepository
        name: karpenter
        namespace: flux-system
  install:
    remediation:
      retries: 3
  values:
    webhook:
      enabled: true
      serviceName: karpenter
      serviceNamespace: karpenter
      port: 8443
---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: karpenter
  namespace: karpenter
spec:
  interval: 5m
  chart:
    spec:
      chart: karpenter
      version: ">=1.0.0 <2.0.0"
      sourceRef:
        kind: HelmRepository
        name: karpenter
        namespace: flux-system
  install:
    remediation:
      retries: 3
  values:
    webhook:
      enabled: true
      port: 8443
    replicas: 2
    logLevel: debug
    controller:
      resources:
        requests:
          cpu: 1
          memory: 1Gi
        limits:
          cpu: 1
          memory: 1Gi
    settings:
      clusterName: "bench-cluster"
      interruptionQueue: "Karpenter-bench-cluster"
    serviceAccount:
      create: true
      annotations:
        eks.amazonaws.com/role-arn: "arn:aws:iam::<redacted>:role/KarpenterController-20240815204005347400000005"

I then have three NodePools (and associated EC2NodeClasses) that take different workloads, depending on what pods get launched with what affinities/taints to request where they go. The two NodePools that rely on normal compute instance types like C/M/R work very well, and Karpenter works flawlessly to scale the node pools and serve those pods!
However...
Observed Behavior:
The third NodePool is for workloads that require a G instance with NVIDIA compute to run.
Simple enough, right? YAML:

(click to expand) Karpenter resource definition YAML
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: ep-nodeclass
spec:
  amiFamily: AL2
  role: "bench-main-ng-eks-node-group-20240620210345707900000001"
  subnetSelectorTerms:
    - tags:
        "karpenter.sh/discovery-bench-cluster": "true"
  securityGroupSelectorTerms:
    - tags:
        "karpenter.sh/discovery-bench-cluster": "true"
  amiSelectorTerms:
    # acquired from https://github.com/awslabs/amazon-eks-ami/releases
    - name: "amazon-eks-gpu-node-1.30-v*"
  kubelet:
    maxPods: 1
---
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ep-base
spec:
  template:
    metadata:
      labels:
        example.com/taint-ep-base: "true"
      annotations:
        Env: "staging"
        Project: "autotest"
    spec:
      taints:
      - key: example.com/taint-ep-base
        effect: NoSchedule
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: kubernetes.io/os
          operator: In
          values: ["linux"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        # - key: node.kubernetes.io/instance-type
        #   operator: In
        #   values: ["g5.2xlarge", "g6.2xlarge"]
        - key: karpenter.k8s.aws/instance-family
          operator: In
          values: ["g5", "g6"]
        - key: karpenter.k8s.aws/instance-gpu-count
          operator: In
          values: ["1"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: ep-nodeclass
      expireAfter: 168h # 7 * 24h = 168h
  limits:
    cpu: 64
    memory: 256Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 1m

The CPU and memory limits are set just as the others are, and leave plenty of room for the G instance specs based on the docs.
This is defined identically to the other functional NodePools, except for the G instance family specifications (particularly the newer card offerings).
When Karpenter takes this in, and I launch a pod with the necessary Kubernetes specs:
# an Argo Workflow launches this pod
      resources: # not required; I have tried this without this subset
        requests:
          nvidia.com/gpu: 1
        limits:
          nvidia.com/gpu: 1
    affinity: # standard; works flawlessly to route pods to the tc-base and tc-heavy NodePools
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: "{{workflow.parameters.ep_pod_tolerance}}"
              operator: "Exists"

It validates it successfully and attempts to spin up a node to serve it... to yield the following:

(click to expand) kubectl logs output of JSON, formatted
{
    "level": "DEBUG",
    "time": "2024-08-26T21:51:35.612Z",
    "logger": "controller",
    "caller": "scheduling/scheduler.go:220",
    "message": "226 out of 801 instance types were excluded because they would breach limits",
    "commit": "62a726c",
    "controller": "provisioner",
    "namespace": "",
    "name": "",
    "reconcileID": "0c544d27-9a71-4c1d-9c72-839aea9c9238",
    "NodePool": {
        "name": "ep-base"
    }
}
{
    "level": "ERROR",
    "time": "2024-08-26T21:51:35.618Z",
    "logger": "controller",
    "caller": "provisioning/provisioner.go:355",
    "message": "could not schedule pod",
    "commit": "62a726c",
    "controller": "provisioner",
    "namespace": "",
    "name": "",
    "reconcileID": "0c544d27-9a71-4c1d-9c72-839aea9c9238",
    "Pod": {
        "name": "e2e-test-stage-kane-p7wck-edge-pipeline-pickle-2973982407",
        "namespace": "argo"
    },
    "error": "incompatible with nodepool \"tc-heavy\", daemonset overhead={\"cpu\":\"380m\",\"memory\":\"376Mi\",\"pods\":\"4\"}, did not tolerate example.com/taint-tc-heavy=:NoSchedule; incompatible with nodepool \"tc-base\", daemonset overhead={\"cpu\":\"380m\",\"memory\":\"376Mi\",\"pods\":\"4\"}, did not tolerate example.com/taint-tc-base=:NoSchedule; incompatible with nodepool \"ep-base\", daemonset overhead={\"cpu\":\"380m\",\"memory\":\"376Mi\",\"pods\":\"4\"}, no instance type satisfied resources {\"cpu\":\"380m\",\"memory\":\"376Mi\",\"pods\":\"5\"} and requirements karpenter.sh/capacity-type In [on-demand spot], karpenter.sh/nodepool In [ep-base], kubernetes.io/arch In [amd64], kubernetes.io/os In [linux], node.kubernetes.io/instance-type In [g5.2xlarge g6.2xlarge], example.com/taint-ep-base In [true] (no instance type has enough resources)",
    "errorCauses": [{
            "error": "incompatible with nodepool \"tc-heavy\", daemonset overhead={\"cpu\":\"380m\",\"memory\":\"376Mi\",\"pods\":\"4\"}, did not tolerate example.com/taint-tc-heavy=:NoSchedule"
        }, {
            "error": "incompatible with nodepool \"tc-base\", daemonset overhead={\"cpu\":\"380m\",\"memory\":\"376Mi\",\"pods\":\"4\"}, did not tolerate example.com/taint-tc-base=:NoSchedule"
        }, {
            "error": "incompatible with nodepool \"ep-base\", daemonset overhead={\"cpu\":\"380m\",\"memory\":\"376Mi\",\"pods\":\"4\"}, no instance type satisfied resources {\"cpu\":\"380m\",\"memory\":\"376Mi\",\"pods\":\"5\"} and requirements karpenter.sh/capacity-type In [on-demand spot], karpenter.sh/nodepool In [ep-base], kubernetes.io/arch In [amd64], kubernetes.io/os In [linux], node.kubernetes.io/instance-family In [g5 g6], example.com/taint-ep-base In [true] (no instance type has enough resources)"
        }
    ]
}

The scheduler does checks to filter instance types on available limit overhead -- but no matter what set of configs I try, the provisioner just refuses to take without being more explicit about what resources are missing from the instance types it can see (even though the instance types desired very much support the small resource requirements it is reporting on).
Notes and things I have tirelessly tried to get around this:

The EKS cluster and all associated infrastructure (managed by Terraform) is running in us-east-1.
I made sure there was plenty of overhead G instance quota in the AWS account to support this operation.
The run above had a workload pod not specify the nvidia.com/gpu resource requirement to try and rule that out, to no avail.
I loosened the requirements to any G instance type and removed instance-gpu-count`; observed the same issue.
I increased the resource limits to cpu: 1000 and memory: 1024Gi (and removed the nvidia.com/gpu limit I had at one point) and watched the filtered instance type count decrease; observed the same issue.
I modified/generified the EC2NodeClass AMI selection to use the latest version of any of the three supported types (AL2, AL2023, Bottlerocket) one after another; observed the same issue.
I drilled into Karpenter source to understand where exactly this error is emitted, but did not modify it to obtain visibility into which of the 801 instance types the controller had discarded for consideration.
I made sure the nvidia-k8s-device-plugin was provisioned and active to the latest version in kube-system namespace (there is a manual EC2 G-instance node group in this cluster that is also used for active workloads as a live workaround).

Expected Behavior:
One of two things:

The Karpenter controller provides observability into which instance types it filtered for resource selection and why, in order to correlate + disambiguate the provided error above as a config error, internal bug, or cluster bug.
The Karpenter controller selects a G instance type (like a nice g4dn/g5/g6.2xlarge) to spawn, do so, then assign the pod to the node and let it work its magic.

Reproduction Steps (Please include YAML):

Deploy below Karpenter resources YAML to a clean Karpenter-enabled EKS cluster (latest: v1.0.1):

(click to expand) Karpenter resources YAML
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: ep-nodeclass
spec:
  amiFamily: AL2
  role: "bench-main-ng-eks-node-group-20240620210345707900000001"
  subnetSelectorTerms:
    - tags:
        "karpenter.sh/discovery-bench-cluster": "true"
  securityGroupSelectorTerms:
    - tags:
        "karpenter.sh/discovery-bench-cluster": "true"
  amiSelectorTerms:
    # acquired from https://github.com/awslabs/amazon-eks-ami/releases
    - name: "amazon-eks-gpu-node-1.30-v*"
  kubelet:
    maxPods: 1
---
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ep-base
spec:
  template:
    metadata:
      labels:
        example.com/taint-ep-base: "true"
      annotations:
        Env: "staging"
        Project: "autotest"
    spec:
      taints:
      - key: example.com/taint-ep-base
        effect: NoSchedule
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: kubernetes.io/os
          operator: In
          values: ["linux"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        # - key: node.kubernetes.io/instance-type
        #   operator: In
        #   values: ["g5.2xlarge", "g6.2xlarge"]
        - key: karpenter.k8s.aws/instance-family
          operator: In
          values: ["g5", "g6"]
        - key: karpenter.k8s.aws/instance-gpu-count
          operator: In
          values: ["1"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: ep-nodeclass
      expireAfter: 168h # 7 * 24h = 168h
  limits:
    cpu: 64
    memory: 256Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 1m

Attempt to run any test pod with the following Kubernetes requirements:

(click to expand) YAML subset for requirements
      resources:
        requests:
          nvidia.com/gpu: 1
        limits:
          nvidia.com/gpu: 1
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: example.com/taint-ep-base
              operator: "Exists"

Observe Karpenter controller fail to provision a GPU node.

Versions:

Chart Version: latest (">=1.0.0 <2.0.0")
Kubernetes Version (kubectl version):

Client Version: v1.29.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.30.2-eks-db838b0

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

I observed the same issue as you today.

I am observing this bug as well. I have defined a nvidia.com/gpu resource requirement in my deployment manifest. I also have a separate gpu-nodepool which is using a bottleneck AMI type nodeclass. The only configuration I have placed is that the instance-gpucount is 1. For some reason a g5g.xlarge which has 3000m+ cpu is not able to schedule a deployment that requires only 150m. Please help.

I think I figured it out. If it's a new account, you can check your karpenter pod logs, the gpu instances might fail to launch due to MaxSpotInstances exceeded. So your node claim will then be deleted and it will be displayed that there are no instances avaiable to satisfy your requirements. You may check these docs:- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-limits.html

the gpu instances might fail to launch due to MaxSpotInstances exceeded

Hmm, but the node pool specifies both spot and on-demand nodes. So if spot node cannot satisfy the request then it should switch to on-demand nodes. Right?

You're right. As per AWS docs, it should fall back to on-demand. My only other guesses come from daemonset issues. Somewhere it mentioned that it tries to add up daemonsets as well and include it in resources and if it can't be found in the available g5 g6 families defined above it will not schedule it. But even then again I doubt that is the actual cause here.

I confirm that I'm facing the same issue trying to use G6 but no issues with G4dn. no instance type satisfied resources


Update MENTORS.md

Things added/changed:

Added my name (Neel Shah) in mentor's list [Mentor.md] .

Please resolve the merge conflicts here. Let us know if you need any help! :)

Conflicts were resolved. :)

@neelshah2409: Really apologize for being late, great to see you on boarding, feel free to join in DEVSTR😊NS' discord server!
Thank you! :heart:


Add MessageFormat library for formatting UI messages

PCL library. https://github.com/jeffijoe/messageformat.net

@jeffijoe no need to create an issue first.
Please read the contributing docs for more info.


prop pageScale doesn't work

Please provide a working example with a bug (git repo, codesandbox, source code at least, etc).
It takes a lot of time to set up environment to confirm an issue.
So I will resolve issues faster.
Configuration:

Web browser and it`s version:
app runs on the phone
Operating system and it`s version:
android, ios
vue-pdf-app version:
2.1.0

Steps to reproduce the problem:
init vue-pdf-app with the prop "pageScale"
What is the expected behavior?
the page should be scaled
What went wrong?
prop pageScale doesn't work
Attachments (screenshots, links, etc)

@w5400013936 @sandanat
page-scale does not work properly.
But @pages-rendered work.
<VuePdfApp :pdf="pdf" theme="dark" @pages-rendered="pagesRendered" />

<script>
methods: {
  pagesRendered(vuePdf) {
    setTimeout(() => (pdfApp.pdfViewer.currentScaleValue = "0.2"))
  }
}
</script>

AppOptions.set("disableHistory", true);
Just turn off this feature


cl /kernel builds

In /kernel builds there is (very likely) a version of
void __declspec(noreturn) __stdcall
    _com_raise_error(HRESULT hr, IErrorInfo* perrinfo = 0) ;

Which raises the Structured Exception (of an SEH fame).  Thus /kernel builds "just work". Perhaps there should be some documentation on that for C++ /kernel builders.
It seems the same mechanism is implemented for MS STL  /kernel builds so they do "just work" too.
SEH is not C++ exceptions. C++ destructors are not called and such. I think a lot of C++ /kernel people might get confused because they are unaware of "SEH in action" in them builds.

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

ID: bd14af26-554d-811a-3417-4d738e85d9be
Version Independent ID: ec58f164-e920-9204-d07d-9e6a3bce5f87
Content: _com_raise_error
Content Source: docs/cpp/com-raise-error.md
Product: visual-cpp
Technology: cpp-language
GitHub Login: @corob-msft
Microsoft Alias: corob

@DBJDBJ
I'm not sure what you're suggesting we document. You can't use _com_raise_error under /kernel because it throws a C++ exception. I don't see any suggestion of a /kernel-specific alternative in use in the library. You can use the same STL for kernel-mode code; it just has some differences in which member functions it exposes, controlled by a preprocessor macro. You can search the source yourself; look for the _HAS_EXCEPTIONS macro, defined as 0 under /kernel, which defines _KERNEL_MODE=1. You could conceivably raise and handle an SEH exception for COM-style errors if you wanted to in kernel code, but I'm not sure why you would. The traditional handling of HRESULTs as return values is all I can find reference to.
I'm happy to reopen the issue if you have evidence there's something happening in the Microsoft C++ compiler or libraries that I didn't see here. Depending on what you're referring to, it may be more appropriately documented in the Windows hardware developer documentation.

I'm not sure what you're suggesting we document. You can't use _com_raise_error under /kernel because it throws a C++ exception.

As I have written:
void __declspec(noreturn) __stdcall
    _com_raise_error(HRESULT hr, IErrorInfo* perrinfo = 0) ;

Do NOT throw an C++ exception in /kernel builds. IT DOES raise SE (aka Structured Exception).
You/me/everyone can use it. I am happily building ATL exe server using ATL and COM client using <comdef.h>. Two projects both using the /kernel build. _com_raise_error must exist in both of them and _com_raise_error must raise SE in both of them.  That is very obvious and logical?
I am/was just asking for that to be clearly documented somewhere.

@DBJDBJ
Is the SE code EXCEPTION_RO_ORIGINATEERROR? (0x40080201L)
// in comdef.h
inline void __declspec(noreturn) __stdcall _com_raise_error(HRESULT hr, const wchar_t* message)
{
    size_t length = (message == nullptr) ? 0 : ::wcslen(message);

    if (UINT_MAX < length)
    {
        length = 0;
    }

    ::Windows::Foundation::Diagnostics::OriginateError(hr, static_cast<unsigned int>(length), message);
    throw _com_error(hr, message);
}

// in roerrorapi.h
namespace Windows
{
    namespace Foundation
    {
        namespace Diagnostics
        {
            typedef enum {
                None               = RO_ERROR_REPORTING_NONE,
                SuppressExceptions = RO_ERROR_REPORTING_SUPPRESSEXCEPTIONS,
                ForceExceptions    = RO_ERROR_REPORTING_FORCEEXCEPTIONS,
                UseSetErrorInfo    = RO_ERROR_REPORTING_USESETERRORINFO,
                SuppressSetErrorInfo = RO_ERROR_REPORTING_SUPPRESSSETERRORINFO,
            } RoErrorReportingFlags;

            DEFINE_ENUM_FLAG_OPERATORS(RoErrorReportingFlags);

            // ...

            inline BOOL OriginateError(_In_ HRESULT error, _In_ UINT cchMax,
                _When_(cchMax == 0, _In_reads_or_z_opt_(MAX_ERROR_MESSAGE_CHARS) )
                _When_(cchMax > 0 && cchMax < MAX_ERROR_MESSAGE_CHARS, _In_reads_or_z_(cchMax) )
                _When_(cchMax >= MAX_ERROR_MESSAGE_CHARS, _In_reads_or_z_(MAX_ERROR_MESSAGE_CHARS) )
                 PCWSTR message)
            {
                if (SUCCEEDED(error))
                {
                    return FALSE;
                }

                return ::RoOriginateErrorW(error, cchMax, message);
            }

            // ...
        }
    }
}
// ...
// The various versions of RoOriginateError will raise and catch a structured exception with an
// exception code of EXCEPTION_RO_ORIGINATEERROR and the following information in the
// ExceptionInformation array. The characterCount element is the number of characters in the message,
// not including the NULL terminator.
// ExceptionInformation[0] -- HRESULT error
// ExceptionInformation[1] -- UINT characterCount
// ExceptionInformation[2] -- PCWSTR message
//
// ...
//
// As documented in MSDN, the ExceptionInformation can be retrieved in the filter expression
// of a frame-based exception handler by calling GetExceptionInformation. A debugger can
// retrieve these values by calling WaitForDebugEvent, keeping in mind that exception records have
// a different binary layout between 32bit and 64bit processes.

So, _com_raise_error calls ::Windows::Foundation::Diagnostics::OriginateError, which invokes RoOriginateErrorW, which can raise a SE if the error reporting flags are set appropriately. I don't know how the compiler can give a pass to the throw _com_error(hr, message); statement under /kernel, though. It looks like the OriginateError call is just meant as a debugger hook. But, it's possible something similar to this code path is what you're seeing.
If there's different internal code invoked within the kernel to handle raising an error as a SE, it's opaque to me, and can't be documented here. That code doesn't belong to the C++ team. That goes for the internals of OriginateError as well, even though I can see them in the header.

Ah, we are talking now :) As you might have seen (about me here and on MS STL github repo) during last week or two I am keenly interested in C++ /kernel builds. And that (I have learned) means C++ & Structured Exceptions (SE).
Let me rephrase: MS C++ and /kernel builds == SE .Yes I know and have followed to the Ro ... . Ok and fine.  This all works and behaves quite well.
It is just it is not documented. I mean MS STL, CL c++ behaviour under /kernel builds ... Has nothing to do with the Ro ... stuff. Just a behaviour on the surface.
I am not, but ISO C++ experts too are (it seems) unaware about all of this (example Ben Craig at https://github.com/microsoft/STL/issues/1289#issuecomment-699760934 ) ... One page on MS Docs will clarify completely.
Basically MS STL works undert /kernel and anything else CL C++ related works under /kernel but there are no C++ exceptions in that universe. And the population at large thinks MS STL can not be used in (many) projects where exceptions are no allowed.  Neither people do know /kernel switch even exist.

You can't use _com_raise_error under /kernel because it throws a C++ exception.

Yes, we can :)
// (c) 2020 by<EMAIL_ADDRESS>// sampling MSVC in the /kernel build
//
#include <stdio.h>
#include <stdlib.h>
#include <comdef.h> // _com_raise_error() #221

#ifndef _KERNEL_MODE
#error This must be compiled with the /kernel switch
#endif // ! _KERNEL_MODE

#if _HAS_EXCEPTIONS
#error _HAS_EXCEPTIONS must be 0 in this build
#endif //  _HAS_EXCEPTIONS

// --------------------------------------------------------------------------
int main(int argc, char** argv)
{
    __try
    {
        __try {

            // for example, raise SE :
            // "The server did not respond after being launched."
            _com_raise_error(CO_E_SERVER_START_TIMEOUT); // comdef.h #221
            // at above point on debugger F11, debugger wants to go to
            // d:\agent\_work\3\s\src\vctools\Compiler\CxxFE\SL\vccom\comraise.cpp
            // message is
            // Exception thrown at 0x771F9962 in ... .exe: Microsoft C++ exception: _com_error at memory location 0x010FF7E0.
            // but that was not "C++ exception" thrown that was SE
        }
        __finally {
            fprintf(stderr , ":  __finally block\n");
        }
    }
    __except ( 1 /* 1 aka EXCEPTION_EXECUTE_HANDLER */ )
    {
        // "throws" are caught here
        // as now they are SE
        fprintf(stderr , ": __except block: Structured Exception caught\n");
    }
    fprintf(stderr , ": Leaving...\n");
    return 42;
} // main

HTH

@DBJDBJ
After consultation with the libraries team, we think we have a handle on what's going on.
The bad news is, what you're seeing is the emergent behavior of kernel-mode code linked to the non-kernel mode COM support library. None of the functions declared in comdef.h are intended for or tested for use in kernel-mode code. The vccomsup.lib library can't even be compiled under /kernel. The _com_raise_error function you've made use of just happens to work, since there's no code path that goes through the final throw expression when a structured exception is raised. However, you can't count on C++-style stack unwinding to work when using SEH, except in very limited ways. And there's no guarantee that any of the other COM support functions will work at all. There's no intention of supporting the effect you've discovered under /kernel. It might quit working in the future. And, it won't be documented, because it's an unsupported use case.
Reading the other thread you referenced, I don't want you to get the idea that compiling with /kernel is some magic "get out of exceptions free" flag. SEH has always been supported both under /kernel and in user mode. If you can live with its restrictions on stack unwinding, you can use it in C++ code whether compiled under /kernel or not. Be aware, these unwinding restrictions are substantial, and not as robust as standard C++ unwinding semantics. SEH has the same kinds of costs as C++ exception handling, just smaller in magnitude without the type matching machinery and extra unwinding mechanics involved. MSVC actually implements C++ exception handling on top of SEH internally. Under /EHs it also does the extra stuff to guarantee standard C++ unwinding behavior.
I hope this helps with understanding what's going on.

@corob-msft  Many thanks on time spent and information provided. I will spend some time investigating, quick points if I may:

Terminology. When you say:  "get out of exceptions free". Do you mean C++ exceptions or SEH?
Using MS STL under /kernel works. Am I right in saying this is not by accident?
<comdef.h> : I see no issue in making that "accidental" SEH modus operandi official? Or to put it differenlty: there is no point of tying <comdef.h> to C++ exceptions when MS STL is not?
What is now the role of the _CPPUNWIND macro? It is not mentioned in that good page.
All we/I do care is not to have WIN executables bigger and slower due to usage of C++ exceptions. Not more and not less.
Humble I also use C99/C11/Win32 probably as a primary language. I am fully aware on what is SEH since approx 1994. (gasp!)

Again, many thanks for your time ... DBJ

Going point by point, I mean you don't need to use /kernel to create C++ code that has no standard C++ exception machinery. Compiling with /kernel is meant for kernel-mode code, which is used for drivers and OS components. Object files compiled for kernel mode may not play nicely when linked with user-mode code. If you're not building code to run in kernel mode, then I don't recommend you use that compiler option.
The parts of the STL that don't rely on exceptions do generally work in kernel mode. More of the STL was made kernel-mode compatible in the last major release. However, large sections of the STL rely on exception support, and those parts won't work.
There's no chance of <comdef.h> being sanctioned for kernel-mode code. COM utilities and the kernel are not designed or tested to work together. Using it may lead to blue screens, or worse. Consider it officially not recommended.
_CPPUNWIND is a predefined preprocessor macro.. It's defined with a value of 1 if either /EHs or /EHa is specified, whether explicitly or implicitly, and undefined otherwise.
To avoid the overhead of C++ exceptions, don't define /EHs or /EHa. That's all you need to (not) do.
SEH dates back at least to the first Win32 APIs, so early 90's sounds about right. Sadly, I got rid of my reference books and software from that era twenty years ago, when they seemed hopelessly obsolete.

@corob-msft  ah ok thanks for warning about when and why not to use /kernel. '<comdef.h>' and friends I used last time commerically (I think) 1999 (gasp, again!), although it still works rather well.
Honestly in all the projects spanning the decades, I never got that interested into anything elase but /EHsc . But now there is this "clash of titans" in the C++ world arround exceptions. I am in the "no exceptions" corner (laugh), And I am OK with SEH. And I am not keen on any std lib in general.
MS STL seems to work for me with /kernel ?  Fully and completely including destructors calling.  Please look into my toy project here.
There is only eight exceptions thrown out of MS STL (it seems). All implemented here.
In _NO_EXCEPTIONS builds, that  _THROW  macro is defined as
// <yvals> #482
_THROW(x) x._Raise()

And in <yvals.h> there is this _RAISE macro which also seems to be used
#ifdef _DEBUG
#define _RAISE(x) _invoke_watson(_CRT_WIDE(#x), __FUNCTIONW__, __FILEW__, __LINE__, 0)
#else // _DEBUG
#define _RAISE(x) _invoke_watson(nullptr, nullptr, nullptr, 0, 0)
#endif // _DEBUG

To cut to long story short, there is no official MS STL /kernel test being done. Ben Craig is doing one "as we speak". But I see no MS STL team involvement.
So far I need no test (lagh) it all seem just to work for me ...


Differing outputs between languages

Hey,
I'm signing an identical message with the same key between this package and Rust's ed25519-dalek. The first 32ish bytes of both signatures are identical but the last bytes are not the same. Do you know why this could be?

No. Does it differ between different private keys?

It differs with identical priv/pub keys, message

If you could provide a key/message pair, I will investigate this.

Key = [     232,     153,     76,     227,     11,     132,     39,     134,     89,     190,     9,     20,     251,     142,     65,     240,     252,     233,     70,     28,     233,     56,     14,     173,     81,     44,     139,     150,     139,     39,     200,     79,     88,     142,     42,     150,     88,     187,     51,     210,     155,     30,     26,     116,     229,     17,     165,     115,     112,     160,     123,     184,     142,     69,     194,     128,     197,     8,     92,     208,     49,     92,     178,     25, ]
Message = [             110, 123, 209,  66, 178, 255, 153,  11,  45,             235, 189, 244,  42,   9, 152, 192, 181, 183,              40, 140, 216, 194, 141, 222, 128, 251, 237,             133, 207, 198, 131,  71, 242, 117, 246, 186,             189, 138, 117, 253,  31, 141, 117,  17, 179,             138, 224, 131           ]

your key is 64 bytes. ed25519 private keys are 32 bytes.
let sc = SecretKey::from_bytes(&Key[0..32]).unwrap();
let pubkey = PublicKey::from(&sc);
println!("SC {:?}", sc);
println!("SC/pub {:?}", hex::encode(pubkey.to_bytes()));
let kp = Keypair { public: pubkey, secret: sc };
    // Returns
    // 98FC99FD2869EFC7AA0743801620B8BD40DAA6DD798A8985BD43AE151E4C7C1A2937808FC199A76708FA046E06206F82B776EB4E05A426CB8F8B4ED4FB4AEC0F
    // Same as noble code:
    //   const privateKey = new Uint8Array(Key).slice(0, 32);
    //   const pub = await ed.getPublicKey(privateKey);
    //   console.log('PUB', Buffer.from(pub).toString('hex'));
    //   const signature = await ed.sign(new Uint8Array(Message), privateKey);
    //   console.log('SIG', signature, Buffer.from(signature).toString('hex'));
    println!("SIG {:?}", kp.sign(&Message));

your key is 64 bytes
The first 32 bytes is the secret key and the second 32 is the public key

See my code -- the outputs match


yabai -m space --focus - Stopped working

yabai -m space --focus [NUMBER]

this used to work until yesterday. Anything else works. Any ideas?

Restart yabai service or reboot your laptop.

done and done. no change. updated and reinstalled aswell

$ yabai -V
> yabai: could not acquire lock-file! abort..

is there a way i can observe the logs, eventstream or something?
this is terribly annoying.

What changed on your system? It doesnt just stop working for no reason. macOS update? Apple Service?
Try reinstalling the scripting addition. Also, see https://github.com/koekeishiya/yabai/wiki/Configuration#debug-output-and-error-reporting

sudo yabai --uninstall-sa
sudo yabai --install-sa

Fixed it <3

Thanks a lot for documenting this ❤ . Just had the issue and fixed it.

I have the same issue since i did the big sur upgrade.
'sudo yabai --load-sa' solves it. But i have to do it any time i reboot the mac. Is there a way to add this command to the yabai start command?
Thanks a lot in advance

I added some instructions in the wiki here: https://github.com/koekeishiya/yabai/wiki/Installing-yabai-(latest-release)
Just scroll down a bit, or ctrl+f Big Sur

Thanks!

I did like explained there, but i do not see any effect. If it is done correctly i should also be able to do, in a terminal 'sudo yabai --load-sa' without being asked for a password, correct?
Moreover, i'm wondering why the line in the yabai file in sudoers.d is
' ALL = (root) NOPASSWD: /opt/local/bin/yabai --load-sa'
(when there is no /opt/local/... directory)

# open/create a new file for writing using the vim editor (use nano or something if you are not familiar with vim)
sudo vim /private/etc/sudoers.d/yabai

# input the line below into the file you are editing.
# replace <user> with your username (output of whoami).
# change the path to the yabai binary if necessary
<user> ALL = (root) NOPASSWD: /opt/local/bin/yabai --load-sa


[KOGITO-3045] Set image's deployment properties

https://issues.redhat.com/browse/KOGITO-3045
If pipeline is unstable due to tests failing, then we still push to registry but properties were not set because of success post whereas the pipeline is no more success ...
Properties will be set normally after the push and PR created
Many thanks for submiting your Pull Request :heart:!
Please make sure that your PR meets the following requirements:

[x] You have read the contributors' guide
[x] Pull Request title is properly formatted: [KOGITO-XYZ] Subject
[x] Pull Request contains link to the JIRA issue
[x] Pull Request contains description of the issue
[x] Pull Request does not include fixes for issues other than the main ticket
[ ] Your feature/bug fix has a unit test that verifies it
[x] You've tested the new feature/bug fix in an actual OpenShift cluster

@Kaitou786 the review requested from the bot seems weird here as well. The Jenkinsfile changes also triggers Filippe and I?

@Kaitou786 the review requested from the bot seems weird here as well. The Jenkinsfile changes also triggers Filippe and I?

@ricardozanini looking at the reviewers.yml this behaviour was expected. The change is in Jenkinsfile.deploy which doesn't fall under any path. Hence the default reviewers were requested. The path have only have Jenkinefile we should change it Jenkinsfile*.


Make GKE jobset rescheduling more robust.

What's the status of this PR? Do we want to merge it?

What's the status of this PR? Do we want to merge it?

Thanks for checking -- I held off because of the unintended scheduling changes discussed internally. Once I validate that this works with the updated tpu provisioner I will merge.


python3Packages.python3-application 3.0.4 -> 3.0.6 and unmark as broken on aarch64-linux

Description of changes
also unmark as broken on aarch64-linux
https://github.com/AGProjects/python3-application/compare/release-3.0.4...release-3.0.6
for some reason they only maintain change log for debian package
Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 239513 run on aarch64-linux 1

4 packages built:

python310Packages.python3-application
python310Packages.python3-application.dist
python311Packages.python3-application
python311Packages.python3-application.dist


Singular Visual Line Should Be Identified as a Single TextElement

Problem
For MSFT<PHONE_NUMBER>-23-014423, the top section title "PART I. FINANCIAL INFORMATION " is identified as two semantic elements:
{
"cls_name": "TopSectionTitle",
"level": 0,
"section_type": "part1",
"text_content": "PART I. FINANCI"
},
{
"cls_name": "TitleElement",
"level": 0,
"text_content": "AL INFORMATION"
}
This should be:
{           "cls_name": "TopSectionTitle",
"level": 0,
"section_type": "part1",
"text_content": "PART I. FINANCIAL INFORMATION"
}
Ideas about a possible solution
Adjust text element merger to keep merging elements until a new visual line.

Noticed this happening when working with 10-Ks as well, seems to be isolated to the way microsoft formats their filings


Fix /start message

/start message should be written in two languages: english and russian.
If language wasn't determined for user, use his ctx.from.language_code

Done here.


To services CIDR and Port rules generation on endpoint changes

Implements #1668
This only implements matching services by their name and namespace. No labels matching against services yet.

TODO: Act on CNP add/delete in k8s watcher

Found a bug which duplicates ToCIDR entries when manually deleting the endpoint. Will fix tomorrow.

TODO: can this work only for headless services? Seems like additional data about services needs to be stored inside LB.

@tgraf @aanm moved logic to k8s package, removed unused ToPorts logic, PTAL

@tgraf @manalibhutiyani @aanm CI passed, PTAL again.


BED-4963: Clean Up and Tighten Enforcement of Linters

Description
Describe your changes in detail
This PR is composed of several separate commits for different fixes and improvements to code that was showing up in our linter warnings.

Removal of our own errors package, leading to a refactor that switches all usages to the stdlib errors package
Clean up of unused code, incorrect function signatures, and other minor fixups recommended by the linter
Two problematic deprecations were added to our ignore list for now, with tickets generated to cover properly resolving them in the future
Now that there were no warnings, upgraded all existing warn level issues to error level
Enabled errcheck as our new warning to start the long process of resolving errcheck issues, before promoting it to error level (no other linters are being turned on yet since errcheck is going to be a very large undertaking on its own, we'll evaluate other useful linter rules after errcheck graduates)

Motivation and Context
This PR addresses: BED-4963
Why is this change required? What problem does it solve?
Our linter warnings were piling up, and they're not super helpful to devs when there's that many. This PR aims to resolve existing warnings (or add exclusions until proper fixes can be evaluated), graduate all existing warnings to error level events (requiring devs to resolve or add exclusions before merging), and enable the next linter rule in our quest for continuous improvement.
How Has This Been Tested?
Please describe in detail how you tested your changes.
Include details of your testing environment, and the tests you ran to
see how your change affects other areas of the code, etc.
All code builds and tests fine after the changes. No logical changes should exist outside of wiring up an unused part of the OpenCypher compiler.
Types of changes

Chore (a change that does not modify the application functionality)

Checklist:

[x] I have met the contributing prerequisites

Assigned myself to this PR
Added the appropriate labels
Associated an issue: https://github.com/SpecterOps/BloodHound/issues/672
Read the Contributing guide: https://github.com/SpecterOps/BloodHound/wiki/Contributing

[x] I have ensured that related documentation is up-to-date

Open API docs
Code comments (GoDocs / JSDocs)

[x] I have followed proper test practices

Added/updated tests to cover my changes
All new and existing tests passed

Much clean, so better, such lovely.
While I only had nits, I did have a few questions:

Did we want to establish a naming convention for errors as it seems we have some variance there, perhaps something like ErrFooBar?
Did we want to verify public / private exporting ?
There was a handful of non sentinel errors, did we want to shore those up as well?

The language default for errors is ErrFooBar and is what the linter enforces currently. A good portion of our errors already follow this strategy, and this PR should get the rest in line.
Public/Private would be nice, but I'm currently not aware of a good linter for that, so it'll need to be addressed in a different way
Fixed up the non-sentinels where it made sense. We probably shouldn't use the ErrFooBar for string constants, but that's a terminology problem for a different refactor. Updated them to keep things consistent for now.


Do not create bitmap with 0 height/width during early render.

when specify background color in react-native even parent view height/width could become zero
https://github.com/react-native-community/react-native-svg/issues/823

@netmaxt3r Thanks for this! Published v8.0.8


problem in prepro.py

When running prepro.py,  KeyError: 'conv1_1'

do you solve it ?can you tell me, thanks!

Sry for answering too late, i have fixed vggnet.py to load the vggnet's parameters.
You should fix the function build_params() in ./core/vggnet.py using the codes below:
def build_params(self):
model = scipy.io.loadmat(self.vgg_path)
layers = model['layers'][0]
self.params = {}
with tf.variable_scope('encoder'):
for i, name in enumerate(vgg_layers):
layer_type = name[:4]
layer_name = name
if layer_type == 'conv':
w = layers[i][0][0][0][0][0].transpose(1, 0, 2, 3)
b = layers[i][0][0][0][0][1].reshape(-1)
self.params[layer_name] = {}
self.params[layer_name]['w'] = tf.get_variable(layer_name+'/w', initializer=tf.constant(w))
self.params[layer_name]['b'] = tf.get_variable(layer_name+'/b',initializer=tf.constant(b))
Hope it could help you.

thanks for your answering，I did this yesterday. but I have the following error
InvalidArgumentError: Shape must be rank 1 but is rank 2 for 'BiasAdd_7' (op: 'BiasAdd') with input shapes: [?,224,224,64], [1,64].

Thanks for your answering

thanks for your answering，I did this yesterday. but I have the following error
InvalidArgumentError: Shape must be rank 1 but is rank 2 for 'BiasAdd_7' (op: 'BiasAdd') with input shapes: [?,224,224,64], [1,64].

I didn't encounter this porb, but it seems like your bias in neural network's node has an inconsistent shape size.

I slove it by using your approach,thanks very much


Error: NotSupported for add example inside docker container

All,
Today I followed the instructions at https://github.com/Rust-GPU/Rust-CUDA/blob/master/guide/src/guide/getting_started.md#docker and I appear to have a successful, running docker container for building Rust-CUDA.
The Nvidia tools seems to report successfully:
root@ad244cfbfe70:~/rust-cuda/examples/cuda/cpu/add# nvidia-smi
Mon Jun 13 19:34:30 2022
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 510.73.05    Driver Version: 510.73.05    CUDA Version: 11.6     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  NVIDIA T1000        Off  | 00000000:06:00.0 Off |                  N/A |
| 82%   63C    P0    N/A /  50W |      0MiB /  4096MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+
root@ad244cfbfe70:~/rust-cuda/examples/cuda/cpu/add#

The host OS is Gentoo on x86_64, using this to install nvidia-container-runtime:
https://forums.gentoo.org/viewtopic-p-8469852.html?sid=2f635b28a650993b900c03245ade9029#8469852

IIUC, I've set the environment up correctly.  However, I get the following when I try to run the add example:
$ docker run -it --gpus all -v $RUST_CUDA:/root/rust-cuda --entrypoint /bin/bash rust-cuda
root@ad244cfbfe70:/# cd ~/rust-cuda/examples/cuda/cpu/add/
root@ad244cfbfe70:~/rust-cuda/examples/cuda/cpu/add# cargo run
info: syncing channel updates for 'nightly-2021-12-04-x86_64-unknown-linux-gnu'
info: latest update on 2021-12-04, rust version 1.59.0-nightly (532d2b14c 2021-12-03)
info: downloading component 'cargo'
info: downloading component 'clippy'
info: downloading component 'llvm-tools-preview'
info: downloading component 'rust-docs'
info: downloading component 'rust-src'
info: downloading component 'rust-std'
info: downloading component 'rustc'
info: downloading component 'rustc-dev'
info: downloading component 'rustfmt'
info: installing component 'cargo'
info: installing component 'clippy'
info: installing component 'llvm-tools-preview'
info: installing component 'rust-docs'
info: installing component 'rust-src'
info: installing component 'rust-std'
info: installing component 'rustc'
info: installing component 'rustc-dev'
info: installing component 'rustfmt'
    Updating crates.io index
/**** SNIP ****/
  Downloaded 62 crates (9.8 MB) in 2.65s (largest was `curl-sys` at 3.0 MB)
   Compiling curl-sys v0.4.55+curl-7.83.1
   Compiling curl v0.4.43
   Compiling rustc_codegen_nvvm v0.3.0 (/root/rust-cuda/crates/rustc_codegen_nvvm)
   Compiling cuda_builder v0.3.0 (/root/rust-cuda/crates/cuda_builder)
   Compiling add v0.1.0 (/root/rust-cuda/examples/cuda/cpu/add)
    Finished dev [unoptimized + debuginfo] target(s) in 3m 49s
     Running `/root/rust-cuda/target/debug/add`
cust::quick_init(): NotSupported
Error: NotSupported
root@ad244cfbfe70:~/rust-cuda/examples/cuda/cpu/add#

The third to the last line is an error message I added, since Error: Not Supported isn't very helpful...
$ git diff
diff --git a/examples/cuda/cpu/add/src/main.rs b/examples/cuda/cpu/add/src/main.rs
index 8ced6476e9ba..fb52be41ba67 100644
--- a/examples/cuda/cpu/add/src/main.rs
+++ b/examples/cuda/cpu/add/src/main.rs
@@ -18,7 +18,13 @@ fn main() -> Result<(), Box<dyn Error>> {
     // initialize CUDA, this will pick the first available device and will
     // make a CUDA context from it.
     // We don't need the context for anything but it must be kept alive.
-    let _ctx = cust::quick_init()?;
+    let _ctx = match cust::quick_init() {
+        Ok(c) => c,
+        Err(e) => {
+            println!("cust::quick_init(): {:?}", e);
+            return Err(Box::new(e));
+        }
+    };

     // Make the CUDA module, modules just house the GPU code for the kernels we created.
     // they can be made from PTX code, cubins, or fatbins.

Is there anything I've missed?

Ok, I'm quickly becoming not a fan of ? error handling.  In cust::quick_init(), which line would throw NotSupported?
#[must_use = "The CUDA Context must be kept alive or errors will be issued for any CUDA function that is run"]
pub fn quick_init() -> CudaResult<Context> {
    init(CudaFlags::empty())?;
    let device = Device::get_device(0)?;
    let ctx = Context::new(device)?;
    ctx.set_flags(ContextFlags::SCHED_AUTO)?;
    Ok(ctx)
}


Replace TripleO images by TCIB images

We imported container build tools from TripleO as TCIB[1]. Now we are retiring TripleO and should complete the migration.
Note that openstack-tripleoclient container was replaced by openstack-client container during migration to TCIB.
[1] https://github.com/openstack-k8s-operators/tcib

/test precommit-check

@kajinamit now that we have the webhooks fully implemented I think we can just drop most of these from our config samples: https://github.com/openstack-k8s-operators/openstack-operator/pull/298
Going forward we can control the defaults in the respective operators. In the product we now have ENV variables to easily control the defaults in the CSV

@kajinamit now that we have the webhooks fully implemented I think we can just drop most of these from our config samples: #298
Going forward we can control the defaults in the respective operators. In the product we now have ENV variables to easily control the defaults in the CSV

Yeah I think that is better. I've removed the image names in config samples to leverage the defaults in operators.

Ah ok I noticed removal was done by e7c1cb5bec1190d757fbdc7923aa93d00fe6519a . I didn't notice until I rebased my change. So now this only updates the default images defined in this specific operators.


Console errors in reporter app

When I launch a reporter app, I see the following console errors in dev
https://localgovdev.mapsdevext.arcgis.com/apps/instant/reporter/index.html?appid=948a3fab38cc4115845713360d4cac66
When submitting a report

When voting

@skrishn

When submitting a report

We are not able to reproduce this now, it could be due to dev env. Could you please check this once and let us know

When voting

We have fixed this and will deliver it in the next code drop

@sumitzarkar I cant repro it now, but I saw it last night. Let me try today and tomorrow, and let you know if it comes back.

@skrishn
Cause

When the like/dislike button was clicked in feature details, the refresh method was called on the feature list to update the like count and maintain page state. However, if the pagination reference element was missing, an error occurred.

Solution

When the like/dislike button is clicked in feature details, if pagination is present, maintain the page state. Otherwise, just refresh the feature list to update the like count.

Dev Checklist

Items
Is required
Status
Comments

Required NLS changes?
No

Required Backward compatibility
No

Required 508
No

Need Sanitize?
No

Impact Analysis Report

Impacted Areas
Comments

Have Configuration changes?
No

Have Runtime changes?
Yes

Impact on RTL
No

Impact on runtime
- No console errors should occur when the like/dislike button is clicked in feature details.  - When like/dislike button is clicked then feature list's like count should get updated.

I see this error when viewing a feature on a layer and choosing another feature on the same layer. ( I used line for testng)

@skrishn @jmhauck

When we hover over the feature we update the highlightOptions to show the feature highlighted with yellow

With the latest JS API this code is breaking in mapview.js

@jmhauck - It seems like some changes in the JS API causing this console error, please let us know if any changes are required from our side in this

@sumitzarkar This seems like a bug to me but I wasn't able to repro in the first go at a stand alone case. Hopefully this PR is just a temp workaround.

@jmhauck

This functionality was developed in last release and we don't see any issue when we are using JS API 4.30
We are able to reproduce this with the latest JS API 4.31 only.
After the workaroud you did we tested with 4.31 and we no longer able to reproduce this.

@jmhauck @sumitzarkar  I started to see the issue again. Do we have any clue of what's causing this, else I can move it to r1.

@jmhauck @sumitzarkar Not able to reproduce in prod. Closing this.


Feature Request: Support stream copy

Being able to use the -codec option (with copy in my case) would be a nice to have. See https://ffmpeg.org/ffmpeg.html#Stream-copy for details.

What is the status of this? Does the implementation of this clash with something else?
Stream copy is quite useful when you want to just extract audio or video from the stream without reencoding and losing quality.

It already works,
 .output(<video_name>,                  vcodec="copy",                  acodec="copy ")

Thanks @1ghost1!

Thanks. Couldn't figure that out from the documentation.
@kkroening Can you add some more info to the ffmpeg.output method in documentation. It seems to be capable of doing a lot but the documentation on it is scarce. I especially don't understand what is being done with the **kwargs.


Refactor APIs

No need to use different Retrofit instances for Events and Launches as they share the same API service and that is the LL2 base Url. Remove EventsApiService and move the events API call to the LaunchApiService. Rename LaunchApi service to LaunchLibraryApiService.

Due to separation of concerns , it shall remain that way for now


Unittest for base app

The following things need unittests

[x] Nested base tables
[x] App detection
[x] Model detection

This is closed by dcdb517dca7fd4ce6e89e84265a331407e0397ec.

Closed with #37


feat(frontend): support explain format json

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Closes https://github.com/risingwavelabs/risingwave/issues/18816 https://github.com/risingwavelabs/risingwave/issues/17218 https://github.com/risingwavelabs/risingwave/issues/14168
We just use the Pretty IR, wrap it in a newtype, derive a serde instance for it.
We intentionally do NOT use serde already implemented for the proto output of the to_proto phase (i.e. when to_stream_prost / to_batch_prost are called). That's because it locks the plan type to the stream_proto / batch_proto type.
EXPLAIN FORMAT JSON should only change the format, and not determine the underlying plan type (logical / stream / batch / to_proto).
Explain terse doesn't need to be supported. Using the json output, we can just do (see before/after below):
 jq 'def extract: {name: .name, children: [.children[] | extract]}; extract' plan.json

before
    {
      "name": "LogicalProject",
      "fields": {
        "exprs": [
          "approx_percentile($expr1)"
        ]
      },
      "children": [
        {
          "name": "LogicalAgg",
          "fields": {
            "aggs": [
              "approx_percentile($expr1)"
            ]
          },
          "children": [
            {
              "name": "LogicalProject",
              "fields": {
                "exprs": [
                  "t.v1::Float64 as $expr1"
                ]
              },
              "children": [
                {
                  "name": "LogicalScan",
                  "fields": {
                    "columns": [
                      "t.v1",
                      "t._row_id"
                    ],
                    "table": "t"
                  },
                  "children": []
                }
              ]
            }
          ]
        }
      ]
    }

after
{
  "name": "LogicalProject",
  "children": [
    {
      "name": "LogicalAgg",
      "children": [
        {
          "name": "LogicalProject",
          "children": [
            {
              "name": "LogicalScan",
              "children": []
            }
          ]
        }
      ]
    }
  ]
}

Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

QQ: Is this just for debugging and not ready to be used widely by users? I assume the format is not finalized and will be subject to change. (If so we can happily merge and try it quickly)

QQ: Is this just for debugging and not ready to be used widely by users? I assume the format is not finalized and will be subject to change. (If so we can happily merge and try it quickly)

Yeah it's mainly for us to get a structured output of the users query plan.

Do we want to document it now? If yes, we should note format stability


Error: Configuration has not been set.

Hi there, thanks for this amazing addon!
I followed your guide and went through all documentation and issues, but I got Configuration has not been set. status code 500 error with api call /screenshot/get and getTheme. I also tried your example repo, same api error also appeared.
I know that this error message indicates setConfig() is empty or not properly read, but I did put required setConfig() as documentation, and I couldn't figure out the way to fix this.
This is a screenshot of error when I run your example repo:

This is a screenshot of error when I run my own repo:

Also, even after I delete  setConfig() script in main.js, the screenshot/get api still calls for all browsers:

I'm not sure if I missed anything as configuration / setup. Thanks in advance for your help!

Hi there, thanks for the quick reply! I installed corresponding package version for playwright, storybook and storybook/addon-knobs and placed setConfig inside main.js. With different console.log(), I think the error originate from UnhandledPromiseRejectionWarning: browserType.launch: Browser closed.

Despite this, I am unable to help you much when it comes to the playwright environment. Are you able to launch the playwright browser without this plugin? You can check playwright functionality by running the following code in NodeJS. (try to run this code with all browser Chromium, Firefox, Webkit)
const { chromium } = require('playwright');

(async () => {
  const browser = await chromium.launch()
  const page = await browser.newPage()
  await page.setViewportSize({ width: 1280, height: 800 })
  await page.goto('https://playwright.dev/')
  await page.screenshot({ path: 'my_screenshot.png' })
  await browser.close()
})()

Hi there, I fixed the error!!! I upgrade the node version to 14.15.0, and then install playwright. Everything works fine right now!

I also runned
npm i -D @playwright/test
# install supported browsers
npx playwright install

from https://playwright.dev/docs/1.17/intro

Nice one, now that you have solved the problem, I am closing the issue.


Update documentation following drop of python<=3.4

Update documentation to match drop of Python <=3.4.
Fix sphinx build warnings
Add graphviz to debian package build dependencies so documentation is built with inheritance images

LGTM


A blank page either electron packager or builder

Describe the issue / bug.
#
npm run dev is OK. However, when release the app using packager or builder, none of those work. Only a blank page obtained.
I checked the router mode, npm version or nodejs version, also the npm pack output is normal.
The environment is windows. There are no errors showed when builder. I put the output of terminal when buld and pack as follows.
How can I reproduce this problem?
# { test2 }  » npm run build                                                          /d/test2 127

<EMAIL_ADDRESS>build D:\test2
node .electron-vue/build.js && build

lets-build
√ building main process
√ building renderer process
Hash: 805fe29aae4a7db20829
Version: webpack 2.6.1
Time: 1656ms
Asset     Size  Chunks             Chunk Names
main.js  1.06 kB       0  [emitted]  main
Hash: 893c91ac3bb246cfb611
Version: webpack 2.6.1
Time: 8747ms
Asset       Size  Chunks             Chunk Names
imgs/logo.png    61.9 kB          [emitted]
renderer.js    96.7 kB       0  [emitted]  renderer
styles.css    1.25 kB       0  [emitted]  renderer
index.html  324 bytes          [emitted]
Child html-webpack-plugin for "index.html":
Asset    Size  Chunks  Chunk Names
index.html  567 kB       0
OKAY  take it away electron-builder
electron-builder 18.3.5
No native production dependencies
Packaging for win32 x64 using electron 1.7.2 to build\win-unpacked
Building NSIS installer
Packaging NSIS installer for arch x64
{ test2 }  »
If visual, provide a screenshot.
#{ test2 }  » npm run pack:renderer                                                       /d/test2

<EMAIL_ADDRESS>pack:renderer D:\test2
cross-env NODE_ENV=production webpack --progress --colors --config .electron-vue/webpack.renderer.config.js

Hash: 893c91ac3bb246cfb611
Version: webpack 2.6.1
Time: 8363ms
Asset       Size  Chunks             Chunk Names
imgs/logo.png    61.9 kB          [emitted]
renderer.js    96.7 kB       0  [emitted]  renderer
styles.css    1.25 kB       0  [emitted]  renderer
index.html  324 bytes          [emitted]
[0] ./~/_vue<EMAIL_ADDRESS>257 kB {0} [built]
[1] ./~/_vue-loader<EMAIL_ADDRESS>2.55 kB {0} [built]
[2] ./src/renderer/store/modules/index.js 238 bytes {0} [built]
[3] ./src/renderer/router/index.js 256 bytes {0} [built]
[4] ./src/renderer/store/index.js 202 bytes {0} [built]
[5] ./src/renderer/App.vue 1.07 kB {0} [built]
[8] ./src/renderer/main.js 382 bytes {0} [built]
[10] ./~/_babel-loader@7.0.0@babel-loader/lib!./~/_vue-loader@12.2.1@vue-loader/lib/selector.js?type=script&index=0!./src/renderer/App.vue 37 bytes {0} [built]
[13] ./~/_extract-text-webpack-plugin@2.1.0@extract-text-webpack-plugin/loader.js?{"omit":1,"remove":true}!./~/_vue-style-loader@3.0.1@vue-style-loader!./~/_css-loader@0.28.4@css-loader?minimize!./~/_vue-loader@12.2.1@vue-loader/lib/style-compiler?{"vue":true,"id":"data-v-1c701646","scoped":false,"hasInlineConfig":false}!./~/_vue-loader@12.2.1@vue-loader/lib/selector.js?type=styles&index=0!./src/renderer/App.vue 41 bytes {0} [built]
[19] ./~/_vue-loader@12.2.1@vue-loader/lib/template-compiler?{"id":"data-v-1c701646"}!./~/_vue-loader@12.2.1@vue-loader/lib/selector.js?type=template&index=0!./src/renderer/App.vue 208 bytes {0} [built]
[23] ./src/renderer/store/modules nonrecursive .js$ 192 bytes {0} [built]
[27] ./~/_css-loader@0.28.4@css-loader?minimize!./~/_vue-loader@12.2.1@vue-loader/lib/style-compiler?{"vue":true,"id":"data-v-1c701646","scoped":false,"hasInlineConfig":false}!./~/_vue-loader@12.2.1@vue-loader/lib/selector.js?type=styles&index=0!./src/renderer/App.vue 185 bytes [built]
[30] ./~/_css-loader<EMAIL_ADDRESS>2.26 kB [built]
[31] ./~/_vue-style-loader<EMAIL_ADDRESS>6.05 kB [built]
[32] ./~/_vue-style-loader<EMAIL_ADDRESS>639 bytes [built]
+ 18 hidden modules
Child html-webpack-plugin for "index.html":
[0] ./~/_lodash<EMAIL_ADDRESS>540 kB {0} [built]
[1] ./~/_html-webpack-plugin@2.28.0@html-webpack-plugin/lib/loader.js!./src/index.ejs 1.24 kB {0} [built]
[2] (webpack)/buildin/module.js 517 bytes {0} [built]
Child extract-text-webpack-plugin:
[0] ./~/_css-loader<EMAIL_ADDRESS>2.26 kB {0} [built]
[1] ./~/_css-loader@0.28.4@css-loader?minimize!./~/_vue-loader@12.2.1@vue-loader/lib/style-compiler?{"vue":true,"id":"data-v-1c701646","scoped":false,"hasInlineConfig":false}!./~/_vue-loader@12.2.1@vue-loader/lib/selector.js?type=styles&index=0!./src/renderer/App.vue 185 bytes {0} [built]
Child extract-text-webpack-plugin:
[0] ./~/_css-loader<EMAIL_ADDRESS>2.26 kB {0} [built]
+ 1 hidden modules
Child extract-text-webpack-plugin:
[0] ./~/_css-loader<EMAIL_ADDRESS>2.26 kB {0} [built]
+ 1 hidden modules
Tell me about your development environment.

Node version: 6.10.2
NPM version: 5.0.2
vue-cli version: (if necessary)
Operating System: windows 7 sp1

@zhengyan-bme
I'm having trouble reproducing this issue. Do you have a project repo that I could look at?

Actually, when my project confronted this issue. I use the default template.
Just vue init simulatedgreg/electron-vue test2. The same problem. There are no my codes at all. I understand it is hard to find the bug. Could you give me some hint about how to solve it.

Ok, instead of npm I used yarn to manage the dependencies of modules. It works!

@zhengyan-bme
Looks like npm still hasn't quite figured everything out  👀 ...
I would still recommend using node@^7 though. Glad you got this sorted out.

I have the same trouble, the packager can work properly at first, and can not work after I just changed some comments. I am very confused about this.

vue init simulatedgreg/electron-vue test
yarn install
yarn run dev
yarn run build:win32

it works well when I use "yarn run dev", but show a blank page when I use "yarn run build:win32".
can not package the project ......

Same issue here

same issue

still relevant to me, any news here? got no errors in console on windows


Allow Name==StableName when possible in test framework

[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Pull Request Attributes
Please check any characteristics that apply to this pull request.
[ ] Does not have any changes that may affect Istio users.

@howardjohn: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-multicluster-tests_istio
7d63b7b26764f3b62c96fdff8e2a976540490099
link
/test integ-pilot-multicluster-tests_istio

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


Fix excessive Metal tile memory preallocation when rendering without attachments.

Metal uses MTLRenderPassDescriptor properties renderTargetWidth, renderTargetHeight, and renderTargetArrayLength to preallocate tile memory storage on machines using tiled rendering. This memory preallocation is not necessary if we are not rendering to attachments, and some apps actively define extremely oversized framebuffers when they know they are not rendering to actual attachments, making this internal tile memory allocation even more wasteful, occasionally to the point of triggering OOM crashes.
Update MoltenVK version to 1.2.2.

Fixes issue #1650.

But wait, then how does it know how many fragment threads to spawn? Does this pass Metal validation?

But wait, then how does it know how many fragment threads to spawn? Does this pass Metal validation?

Yes, it passes Metal validation. I do not see Metal validation errors on Apple Silicon when renderTargetWidth, renderTargetHeight, and renderTargetArrayLength are left unset. And things work correctly. So Metal is figuring out something at actual render time, possibly improvising based on the viewport, etc.
I haven't tested what this might do to performance. It's possible that providing advanced warning to Metal by setting those properties may allow it to better organize and optimize the tile cache and rendering thread groups.

Do we know that it actually does spawn the threads based on the viewport? I'm somewhat worried that it just defaults to 0 in this case and successfully doesn't do anything.

@js6i @cdavis5e
Uggh. You are of course both correct. I realize the testing I did always involved a render target (which is I guess where Metal picks up the frag shader thread count from, and not from the viewport). Thanks for going to the trouble to create a little test app to show me where I went wrong.
I'm not sure how to handle this over-allocation issue identified in #1650 then. We can't be guaranteed to have the correct viewport size (or any viewport size) at the time the Metal render encoder is created. The only option might be to defer creating the Metal render encoder until the first draw (which kinda sorta happens with tess pipelines already).

@js6i @cdavis5e
I've pushed PR #1802 to replace this PR, and fix the issue in #1650 in a way that always sets the Metal render area to something: the frame buffer render area, or the viewport, if there are no attachments. Since the viewport is not guaranteed until the draw call, we now defer creating the Metal renderpass until then (or until needed by other renderpass operations that involve drawing, like clearing attachments).


electron cash 2.9.0 --default_wallet 2fa send bcc bug

error:the transaction was rejected by network rules. singnature must be zero for failed check(multi)sig operation   [01000000029c.................52eee7]

2fa not supported but check workaround


It's possible to create links with "link": null by pasting richtext from the web

We've had this happen on production, the client pasted some HTML in a volto text block, and the page then crashed when saved, because the rendering in UniversalLink didn't expect that the link can be null. It crashed in     at Object.normaliseMail (Url.js:267:13)

I would like to work on this issue, but can you please elaborate on the issue? I tried to save HTML code in the text block and it worked.


support ontrack instead of onaddstream

According to Mozillia Developer Network and the draft w3c spec onaddstream has been replaced by ontrack, however chrome doesn't yet support ontrack.
I had hoped that rtcninja might implement ontrack in a browser agnostic way and therefore provide a future-proof approach, however it doesn't seem implement it.
Is it possible ontrack and friends might be added?

rtcninja is discontinued.

shame. Perhaps you could put a prominent notice saying that.

Unfortunately I no longer have write access to this repository.


⚠ SceneTime has degraded performance

In 8ff1117, SceneTime ($ST) experienced degraded performance:

HTTP code: 200
Response time: 1364 ms

Resolved: SceneTime performance has improved in 1d978e4 after 6 minutes.


Intro to Python

Just a starting point for now

@mcollardanuy @kasparvonbeelen I think I am done with this, which should cover the Monday morning. I have only one exercise at the end but might take them some time as I haven't introduced the if/else statements. But I want to see how they approach something new. At the end there's an example about importing a library, which will be the focus of the afternoon.
Let me know what you think, if I should change / add something etc

Great, I'll have a look at it later! I was thinking, while I was preparing the following day session: we could create a document, where we write down what we assume has already been covered in a previous session, to make sure there are no gaps.


gitea: build package with go 1.13

as gitea 1.11 does not support go 1.14

Motivation for this change
This repairs the gitea wiki on NixOS 20.03, and therefore should be backported.
See https://github.com/go-gitea/gitea/issues/10552 for upstream issue.
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[X] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

@GrahamcOfBorg test gitea

maintainers: It seemed to me like this is the most viable approach, as I coudl not see how this could/should be changed inside the package, even if the change is tied to the actual gitea version.
However, remembering to remove this on next major version will be hard, I guess. :sweat_smile:

Uuhm where did go 1.13 go in master? :thinking:
Ah, there it did: https://github.com/NixOS/nixpkgs/pull/86036

This seems fine for now, but Gitea 1.12 will be released relatively soon - when updating that, this workaround could be removed.

Well, I'm not sure whether we want to backport Gitea 1.12 and if not, we have to fix this for 1.11 for 20.03 at least. Also, when patching this, the build would fail if the patch doesn't apply anymore (e.g. after an update), right?
@florianjacob does it sound ok to you to only apply the patch which fixes the issue?

Thanks to all! Just patching the wiki now and waiting for the imminent gitea 1.12 release is much better. :+1:


Unread messages notice does not hide sometimes

The notice itself should be above the compose box, and not over it!
This happens only sometimes, and the cause can be one of these:

incorrectly counting some message as unread (it used to happen when we didn't take into account hidden
possibly our pointer to what messages are currently on screen is not very precise
something else?

On it!


Use vite

Feel free to ping me if you are stuck on anything with this PR !

Feel free to ping me if you are stuck on anything with this PR !

Appreciate it 🙌 I figured it out after some aha-moments from looking at your implementations in inertia/vite. There are still some rough edges, but it's usable now 😄


ci: gomod changes related for Go 1.17

Changes related to Go 1.17 module changes

recheck

recheck

Codecov Report

Merging #59 (4efc368) into main (fd2b545) will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main      #59      +/-   ##
==========================================
- Coverage   41.14%   41.12%   -0.03%
==========================================
  Files          21       21
  Lines        9012     9012
==========================================
- Hits         3708     3706       -2
- Misses       4136     4138       +2
  Partials     1168     1168

Impacted Files
Coverage Δ

internal/retry/retry.go
93.12% <0.00%> (-1.53%)
:arrow_down:

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 fd2b545...4efc368. Read the comment docs.


Fix #2 and #3, Dockerfile not working

Fix issues #2 and #3 related to the Dockerfile failing to build.

Thanks a lot!


fix(comment)!: consolidate note captures

See
https://github.com/nvim-treesitter/nvim-treesitter/commit/5cc562748729b6dc9563ea5a3d676ff102ab38b1

I had already fixed this locally https://github.com/folke/tokyonight.nvim/commit/ba35fbe16ceea7e5fbe8b9a0247c06804c385538


application launch error

Description
What steps will reproduce the problem?

What is the expected output? What do you see instead?
Please provide any additional information below
File "/Users/wenyuan/anaconda/envs/stats202c/lib/python3.6/site-packages/spyder/plugins/init.py", line 511, in
toggled=lambda checked: self.toggle_view(checked),
File "/Users/wenyuan/anaconda/envs/stats202c/lib/python3.6/site-packages/spyder/plugins/ipythonconsole.py", line 709, in toggle_view
self.create_new_client(give_focus=False)
File "/Users/wenyuan/anaconda/envs/stats202c/lib/python3.6/site-packages/spyder/plugins/ipythonconsole.py", line 991, in create_new_client
self.connect_client_to_kernel(client)
File "/Users/wenyuan/anaconda/envs/stats202c/lib/python3.6/site-packages/spyder/plugins/ipythonconsole.py", line 1027, in connect_client_to_kernel
kc.start_channels(shell=True, iopub=True)
File "/Users/wenyuan/anaconda/envs/stats202c/lib/python3.6/site-packages/qtconsole/kernel_mixins.py", line 43, in start_channels
super(QtKernelClientMixin, self).start_channels(*args, **kw)
File "/Users/wenyuan/anaconda/envs/stats202c/lib/python3.6/site-packages/jupyter_client/threaded.py", line 209, in start_channels
self.shell_channel._inspect = self._check_kernel_info_reply
File "/Users/wenyuan/anaconda/envs/stats202c/lib/python3.6/site-packages/jupyter_client/client.py", line 143, in shell_channel
socket, self.session, self.ioloop
File "/Users/wenyuan/anaconda/envs/stats202c/lib/python3.6/site-packages/jupyter_client/threaded.py", line 202, in ioloop
self._ioloop = ioloop.IOLoop()
File "/Users/wenyuan/anaconda/envs/stats202c/lib/python3.6/site-packages/tornado/util.py", line 312, in new
instance.initialize(*args, **init_kwargs)
File "/Users/wenyuan/anaconda/envs/stats202c/lib/python3.6/site-packages/zmq/eventloop/ioloop.py", line 139, in initialize
super(ZMQIOLoop, self).initialize(impl=impl, **kwargs)
File "/Users/wenyuan/anaconda/envs/stats202c/lib/python3.6/site-packages/tornado/ioloop.py", line 844, in initialize
super(PollIOLoop, self).initialize(**kwargs)
File "/Users/wenyuan/anaconda/envs/stats202c/lib/python3.6/site-packages/tornado/ioloop.py", line 356, in initialize
self.make_current()
File "/Users/wenyuan/anaconda/envs/stats202c/lib/python3.6/site-packages/tornado/ioloop.py", line 314, in make_current
assert asyncio is None
AssertionError
Version and main components

Spyder Version: 3.2.3
Python Version: 3.6.2
Qt Versions: 5.6.2, PyQt5 5.6 on Darwin

Dependencies
pyflakes >=0.6.0 :  1.6.0 (OK)
pycodestyle >=2.3:  2.3.1 (OK)
pygments >=2.0   :  2.2.0 (OK)
pandas >=0.13.1  :  0.22.0 (OK)
numpy >=1.7      :  1.13.1 (OK)
sphinx >=0.6.6   :  1.6.3 (OK)
rope >=0.9.4     :  0.9.4-1 (OK)
jedi >=0.9.0     :  0.10.2 (OK)
psutil >=0.3     :  5.2.2 (OK)
nbconvert >=4.0  :  5.2.1 (OK)
sympy >=0.7.3    :  None (NOK)
cython >=0.21    :  None (NOK)
qtconsole >=4.2.0:  4.3.1 (OK)
IPython >=4.0    :  6.1.0 (OK)
pylint >=0.25    :  1.7.2 (OK)

To fix this, please Terminal.app and run there
conda update pyzmq jupyter_client ipykernel

Also, just FYI your version of Spyder is around half a year out of date; you can update with conda update spyder from the Terminal.

Thanks all for your help!
On Tue, May 15, 2018 at 3:54 PM C.A.M. Gerlach<EMAIL_ADDRESS>wrote:

Also, just FYI your version of Spyder is around half a year out of date;
you can update with conda update spyder from the Terminal.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/spyder-ide/spyder/issues/7137#issuecomment-389339402,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ac7clsSDDZ9b6cLlmkQKbUNtpd6jNg8Zks5ty1zAgaJpZM4UAGFE
.


Fixed a minor typo

Related to #2037

@Ashikpaul Thank you for updating the versioned docs! Next time please add the commits to the PR, where changes were requested. 😄

Sorry @Simek, I didn't understand. Could you please explain?
Thank you

@Ashikpaul Instead of creating new Pull Request you should update the existing one (#2037). If you not familiar with adding commits to the existing PR you can follow GitHub guide. You can alternatively use GitHub Codespaces (if you have an access). I can also recommend reading through the Contibutors guide in the Readme which covers the basic steps when working with local copy of repository.

Oh, I didn't know we could do that. Thank you so much😍


Upgrade lapis

The original Pivotal Tracker story has links to several Zendesk tickets. This one in particular.
It references a bug in lapis.
There is also this recent Community thread.
And a separate Zendesk ticket where Winston has supplied a way of reproducing the issue.

When this is fixed, please let support customer #32274 know.

@ncalies that ticket is linked in the body of the issue, will be sure to update when this happens.

Looks like another report of this: https://rstudioide.zendesk.com/agent/tickets/45349

Another report of this issue:https://rstudioide.zendesk.com/agent/tickets/49937


book: Document adapter types Display2Format, Debug2Format

Documents the workaround for and thereby fixes #320

bors r+


Remove Drush make support

Issue Type

Bug Report

Summary
Drush make file site generation support has been removed as of Drush 9.0.0, see Remove make from Drush9.
Therefore we should, at some point, completely drop support for Drush make from Drupal VM (especially considering #1672 will start defaulting to Drush 9.0.0 with launcher...). It could still be managed to be used by individuals sticking with Drush 8.x, but they would be on their own making sure it was all working correctly.
For the short-term, I'm reworking the Drush make test to explicitly install Drush 8.1.15 from source so tests still pass. But for this ticket:

[ ] Remove drush make bits from the nginx + drush make automated test.
[ ] Remove drush make mentions in documentation.
[ ] Remove the example.drupal.make.yml file.
[ ] Open an upstream issue in the geerlingguy.drupal role to remove Drush makefile build support as well (after it's gone from Drupal VM... hopefully).

Related

https://github.com/geerlingguy/drupal-vm/issues/1672
https://github.com/geerlingguy/drupal-vm/issues/1595

I'm using DrupalVM to support a legacy Drupal 7 project. If Drush make support is removed, how would setting up Drupal 7 VMs work?

@SeanHeavey, where I work we deal exclusively with D7 and we've not used drush make ever since the deprecation was announced.
The idea would be to convert your make files into a composer.json file, but it's not that straight forward. Rest assured they are far more manageable after you make the change.

I would support this change, but it's worth noting that some hosts are still recommending make files for D7 sites. (I also maintain a legacy site.)
For instance, Platform.sh uses make files for both its "profile" and "project" options, and provides a make file in its example D7 site. Acquia Cloud provides options for make files in local development, though it's not prominently suggested anywhere. I didn't see anything in Pantheon regarding make files.
This is perhaps a side issue, but just noting that people who are using DrupalVM to set up local development on these hosts might be frustrated. There are probably workarounds (and it might be worth encouraging Platform, at least, to stop suggesting a make file by default).

@rootwork and @SeanHeavey - Thanks for the feedback. I was considering dropping Drush make support in Drupal VM 6, but I guess I'll let it go at least another version or two for now.
It will always be something that is possible, but at some point I will have to drop the configurations and official docs for it, as it's something I haven't used in a few years now and I'd rather not support it if I can't guarantee it works. Luckily the test that's running for it hasn't been unstable, so as long as that's the case I'll keep it in.


Deployment to pypi

We need CI to do:

[x] Run tests on pull requests
[x] Create deployment to pip on tag creation
[ ] Need to improve the documentation on pypi

This guide seems to hint that TestPyPI is the place to send unstable versions.

I think the action has worked and its on test.pypi.org:
https://test.pypi.org/project/iiif-prezi3/
If we create a tag it should deploy to the real pypi.

It looks like it now works:
https://pypi.org/project/iiif-prezi3/
if you create a tag it deploys to pypi otherwise and changes to master gets deployed to test.pypi

Make the build not fail if you don't change the version number. Maybe overwrite and include branch name?
Build from pypi tests?

Can we deploy to test pypi for tags and live for releases?

See https://github.com/robcast/digilib/blob/master/.github/workflows/docker-image.yml as an example.

Change trigger to releases here:
 tags:

Another example: https://github.com/datacite/bracco/blob/main/.github/workflows/main.yml
on:
  release:
    types: [published]

Have a look if we can deploy to test-pypi on a pre-release and pypi on a full  release. See triggers:
https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#push

Just looking at this tagging vs publication release stuff (i.e. tagging goes to testpypi and publication goes to pypi). I've set it up but it means there isn't a way to create a tag easily in github you have to either create it during a release or do it from the command line.
How about we push pre-releases to testpypi and full releases to pypi?

Done :-):
https://pypi.org/project/iiif-prezi3/


Add homepage section for company sponsors

Our Patreon campaign includes Gold and Platinum sponsorship levels (intended mainly for companies), for which we promise to put company logo (and I guess, a link when you click on the logo) on the homepage.
We should add a horizontal section for that below the "Get involved" section and before the footer:

I guess it could be two columns, with Platinum sponsors on the left and Gold sponsors on the right, and with a link to the Donate page to learn more about sponsoring the project or just supporting it financially. (I still need to write some details about the sponsoring deals on that page, but you can link to it anyway).
Currently we have one Gold sponsor, Gamblify, so their logo should be added:
Gamblify_Logo_2_Colors.zip

The svg you linked doesn't seem to be the same one that appears on their website. Appears it was exported from illustrator, which I guess doesn't have the best svg exporter?

This seems to be a pretty standard layout when it comes to mentioning sponsors:

The Patreon campaign says that "Mini Sponsors" will also have their names featured on the website. Since it seems to be relatively cheap, I'm guessing that there will be more of them. We can leave out Platinum and mini if we don't have any yet and add the sections when we do or keep it there to encourage more companies to sign up.

For "Mini Sponsors" we do mention that they will be featured on the website, but not on the landing page. We'll likely add a "Sponsors" page, or add them to the "Donate" page - the Platinum and Gold sponsors would also be featured there + on the landing page.

I kind of like the idea of including them on the landing page. Look how Webpack handles them.

Regarding the logo, I guess you can use the PNG directly; if there's a need for a different resolution or SVG, we can see with Gamblify to have a better version.

Fixed by fd0612fe5b.

We now have a second Gold sponsor to add to the homepage, GameDev.tv! \o/

Logo
Website


Cannot build on Centos7 ('error: unknown option `first-parent')

Can not build master on Centos7 because build scripts use git options that are not available in git <IP_ADDRESS> that is provided by Centos7.5.
Build.md states following dependencies

git 1.7.1+
git lfs
gcc 4.8.x
scons 2.0.x

Details
$ scons -j8 release=1 package_install scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... cd src; scons -j8 installdir="/tmp/fusion_os_install" release=1 install scons: Reading SConscript files ... GitCommandError: 'git describe --first-parent --tags --match [0-9]*\.[0-9]*\.[0-9]*\-*' returned with exit code 129 stderr: 'error: unknown option first-parent'
usage: git describe [options] *
or: git describe [options] --dirty
--contains            find the tag that comes after the commit
--debug               debug search strategy on stderr
--all                 use any ref
--tags                use any tag, even unannotated
--long                always use long format
--abbrev[=<n>]        use <n> digits to display SHA-1s
--exact-match         only output exact matches
--candidates <n>      consider <n> most recent tags (default: 10)
--match <pattern>     only consider tags matching <pattern>
--always              show abbreviated commit object as fallback
--dirty[=<mark>]      append <mark> on dirty working tree (default: "-dirty")

':
File "/app/earthenterprise/earth_enterprise/src/SConstruct", line 413:
gee_version_number = GetVersion("version.txt", label)
File "scons/getversion.py", line 10:
raw = GetLongVersion(backupFile, label)
File "scons/getversion.py", line 21:
ret = _GitGeneratedLongVersion()
File "scons/getversion.py", line 39:
raw = _GetCommitRawDescription()
File "scons/getversion.py", line 51:
raw = repo.git.describe('--first-parent', '--tags', '--match', '[0-9].[0-9].[0-9]-')
File "/usr/lib/python2.7/site-packages/git/cmd.py", line 440:
return lambda *args, **kwargs: self._call_process(name, *args, **kwargs)
File "/usr/lib/python2.7/site-packages/git/cmd.py", line 834:
return self.execute(make_call(), **_kwargs)
File "/usr/lib/python2.7/site-packages/git/cmd.py", line 627:
raise GitCommandError(command, status, stderr_value)
scons: *** [stage_bin] Error 2
`
$ git --version git version <IP_ADDRESS>
cat /etc/redhat-release  CentOS Linux release 7.5.1804 (Core)

We are working on a fix that will restore backward-compatibility with version <IP_ADDRESS> of git. Recent changes to the build process require a minimum git version of 1.8.4 (the documentation is still catching up).
If you are able and willing to upgrade your version of git to 2.x, you can follow the instructions here.

Thanks.
A better way of installing git on centos (without having to download rpms from some websites) is by using software collections.
https://www.softwarecollections.org/en/scls/rhscl/rh-git29/


iPad browser crashes (triggers a reload) on some devices with ?showPointerAreas

From https://github.com/phetsims/circuit-construction-kit-common/issues/798, @KatieWoe reported:

For https://github.com/phetsims/qa/issues/748
On iPadOS 15.1, with the query parameter ?showPointerAreas, the sim crashed and reloaded after a few minutes of use. This seems similar to https://github.com/phetsims/molecule-shapes/issues/206
This happened after I set up an AC circuit with a lightbulb and let it run for a few minutes.
I tried without ?showPointerAreas and it didn't seem to happen.
 I am using iPad pro iPadOS 15.0. I'm going to update to 15.1 and try to reproduce again.
I was unable to reproduce with iPadOS 15.1, and thus far also unable to reproduce phetsims/molecule-shapes#206

@jonathanolson how do you recommend to proceed?

It takes up some extra memory, perhaps that's related? I'm not sure. We'd presumably need to reproduce it a bit more.

I'm not planning to work on this at the moment.


Update llama_hub/file/pandas_excel/base.py

Copied from https://github.com/kevinlu1248/llama-hub/pull/3 to fix https://github.com/jerryjliu/llama_index/issues/6203.
Description
This PR fixes two issues with the PandasExcelReader class in the llama_hub/file/pandas_excel/base.py file.

The load_data method did not accept a pandas_config argument, causing a TypeError when trying to pass this argument. This PR modifies the load_data method to accept the pandas_config argument.

The __init__ method of the PandasExcelReader class did not correctly initialize the _row_joiner attribute, causing an AttributeError when trying to access this attribute. This PR ensures that the _row_joiner attribute is correctly initialized in the __init__ method.

Changes Made

Modified the load_data method in the PandasExcelReader class to accept a pandas_config argument.
Correctly initialized the _row_joiner attribute in the __init__ method of the PandasExcelReader class.

Related Issue
This PR addresses the issue #1.

Hey @jerryjliu, most of this PR was generated by Sweep. Can we try installing Sweep for this repo & llama-index? Installation instructions at https://github.com/sweepai/sweep#-getting-started