Coffeescript runtime bug: private static class fields

Coffeescript bug (runtime error)
"civet coffeeCompat"

class API

  HTTP_GET = 'GET'
  HTTP_HEAD = 'HEAD'
  HTTP_VERBS = [HTTP_GET, HTTP_HEAD]

  callApi: ->
    console.log HTTP_VERBS[0]

(new API()).callApi()
# Next line errors in CS as HTTP_VERBS is private attr
# console.log API.HTTP_VERBS[0]

in the Civet playground this compiles, but then errors at runtime with
ReferenceError: HTTP_GET is not defined

whilst in the coffeecsript playground the code compiles and runs with output
GET

Playground links
Coffeescript link
Civet link
Discussion
First off, things are moving along with my migration of multiple Coffeescript codebases to Civet, so thanks for all your hard work! I've moved the codebase build systems from browserify to esbuild with the esbuild-coffeescript plugin. The error above comes from switching the esbuild-coffeescript plugin for the Civet esbuild plugin, hacked to process .coffee files. For this particular codebase, all coffeescript is compiling in Civet with no parse errors, and this is the first runtime error I've seen.
Re the particular error, I often use this pattern for class level private constants (which can be referenced by both other class or class-instance functions). In modern JS terms, the closest concept seems to be a private static field.
In the interests of converting Coffeescript to Civet, it would great if this could be handled via "coffeeCompat". However, longer term, I'd be happy for this pattern not to be in Civet if it doesn't fit philosophically, and could be replaced directly with JS private static fields. If that were the case, it would nice if this pattern triggered a compile time parse error - rather than a run time error - so that the errors could be worked through and addressed one at a time.

I had proposed that CoffeeScript change this behavior here: https://github.com/jashkenas/coffeescript/issues/4552#issuecomment-1019527774
and the response seemed to be that this could considered buggy behavior for CS2, and a change was warranted.  That said, I doubt the behavior will actually change at this point, and given that you're relying on it, supporting it probably makes sense as a coffee-compat flag.
I don't see an easy way to map this feature to private static fields. At least, every reference to the fields would then need to be detected and rewritten, and the resulting class would be different from CoffeeScript's output. I think matching CoffeeScript's output (with an IIFE block that does the assignments and returns the class) might make the most sense. It's a shame we can't just have a class declaration within a braced block, but that prevents the class from being visible at the top level...

I agree that we should match the CS2 behavior when in coffee-compat mode.
For migrating to Civet/ES semantics I would recommend pulling out the = field assignments as := outside the class and explicitly wrapping with a block if you need to limit visibility. I've found that having const assignments alleviates a lot of the trouble around CoffeeScript scoping since you can't accidentally reassign an outer scoped const.

Three points

Matching the CS behaviour in coffee-compat mode would be great. That would enable coffeescript to run safely under civet.
In terms of then moving coffee files fully from coffee-compat mode to full civet, would it be possible to throw a parse error on the offending patterns during compilation, so they can be fixed manually? I.e. civet coffeeCompat -coffeeCrazyClassAttrs throws parse errors. Otherwise if no parse errors are thrown - but runtime errors occur later instead (like now) - then it'll be unclear if a full coffee->civet migration has been successful until the code is exercised.
The pattern of civet coffeeCompat -coffeeCrazyClassAttrs throwing parse errors on coffeescript cases that work under full coffee-compat mode, but are now illegal in full civet (or the behaviour has changed) seems sane to me. It means the developer can review the offending cases for a particular directive, fix them manually, and then move on to removing the next directive, confident that they are moving towards full civet. I confess I haven't check to see if coffee-compat mode does this already - I'm still battling with moving to esbuild!

It would be slightly difficult to add compile time checking since it's valid ES (accessing a global variable inside the method body). Currently opening the file in VSCode with the Civet LSP installed will underline the (now undeclared) global references. I recall there also was interest in a tool to use the same LSP code to do typechecking on .civet files from the CLI so that could be one way of solving this as well.

@STRd6 lack of civet compiler knowledge showing here but.. I suppose I'm thinking if the compiler is running under coffee-compat mode:

[case of civet coffeeCompat +coffeeCrazyClassAttrs] compiler detects the pattern described in this issue, and generates code as per @edemaine's comment (with an IIFE block that does the assignments and returns the class)
[case of civet coffeeCompat -coffeeCrazyClassAttrs] compiler detects the pattern described in this issue, and blows up with parse error instead.

And this pattern applies for all coffee-compat directives.

Currently coffeeCompat is implemented as a meta flag that enables a collection of more specific options. Adding "civet coffeeCompat -coffeeCrazyClassAttrs" would have all the other coffee compat items but omit the class compatibility. This way when someone is ready to rewrite the class code to a new style they would add -coffeeCrazyClassAttrs and adjust their code.
In coffeeCompat it wouldn't be an error and we would match the existing CS2 compilation.
I'm not sure there would be any advantage to a specific error other the TS error about Cannot find name HTTP_GET

It would be possible to add a custom linting step for detecting this pattern but it would be less general and more brittle than using the existing TS error checking and I think the effort could better go towards civet+TS command line type checking.

@STRd6 thanks for the explanation. Make sense. Getting coffeescript running fully under civet coffee-compat would be fantastic regardless. Once that's possible, I'll take a deeper look into the sanest way to jump from coffee to full civet. Seems like using VSCode+Civet LSP would be useful. My prior thoughts/suggestions were motivated by having the safest coffee->civet transition: having compiler parse errors makes it very clear what still needs fixing.

I finally realized what CS2 means by class definitions are blocks of executable code
CoffeeScript 2
I don't think that makes implementing this any harder, it just clarifies the scope for CS2 compatibility.

Any update on this Coffeescript "private static class fields" bug?
I ask, since I'm thinking of again attempting migration of some Coffeescript projects to Civet over Christmas. This bug was the main blocker last time I tried.
Since you have been going great guns on Civet development, I wondered if you had a clearer idea on how to fix this. The latest discussion seemed to be in https://github.com/DanielXMoore/Civet/issues/944#issuecomment-1930032511: "a compatibility flag that triggers CoffeeScript's IIFE behavior, and perhaps the same coffeeClasses flag makes sense"
Many thanks

Sorry, this fell off my radar, but if it's blocking you, we can step it up in priority. Are you interested in trying to implement it yourself? If so, I can provide guidance. If not, I can take a stab directly.
By the way, a similar effect can be achieved with Civet do blocks (putting a class inside a do block). But not CoffeeScript do, so this might not be very convenient if you also need Coffee do.

@edemaine thanks for your prompt reply.
It's blocking me in the sense that I'm holding off migrating several large Coffeescript projects to Civet until the path looks sane. Currently this bug is putting me off, since I'd preferably switch Coffeescript to Civet with all compatibility flags switched on and maintain working code. Then I'd gradually make code changes to full Civet and switch off compat flags one by one. Last time I attempted the migration, I got the Coffeescript code compiling with Civet (and reported various bugs). Then this bug appeared and was awkward since it appeared at runtime. This reduced the certainty that I had working code.
However, this bug isn't blocking me in that I can choose when to do the migration. I really don't have spare time currently, but I might do early next year.
In short, if you want to take a stab now, that would be much appreciated. Otherwise, I can make a go of it next year, with some guidance.
My suspicion is that once this bug is fixed, there might other runtime bugs waiting in the wings..


VM is created at each reconciling

Create a virtual machine from template by cloning. New virtual machine with the same name and a different id is created once a minute with each reconcile. After starting VM manualy, the creation of new ones stops.
This can be caused by different names and an incorrectly created virtual machine.
But it is very desirable that the newly created VM be registered by ID because it is unique, but the name is not unique.
Example:
apiVersion: proxmox.alperen.cloud/v1alpha1
kind: VirtualMachine
metadata:
  name: vm-new1
spec:
  name: vm-new-other1
  # Name of the node where the VM will be created
  nodeName: proxmox1
  template:
    # Name of the template to be cloned
    name: ubuntu-20
    # CPU cores to be allocated to the VM
    cores: 2
    # CPU sockets to be allocated to the VM
    socket: 1
    # Memory to be allocated to the VM
    memory: 4096 # As MB
    # Disk used by the VM
    disk:
      - storage: kvm-disks
        size: 20 # As GB
        type: scsi
    # Network interfaces used by the VM
    network:
      - model: virtio
        bridge: vmbr0

Hi @themoriarti,
Could you please let me know the version/release of the operator and Proxmox you're using? The latest versions of Kubemox do not have a constant reconciliation mechanism. The project originally included continuous reconciliation loops, but I removed that functionality. I want to implement a custom external resource watcher for Proxmox (see #25).
Additionally, it's correct that the operator doesn't depend on the VMID. Kubemox relies on the virtual machine name, which is not a unique value per VirtualMachine or LXC in Proxmox.

Hi @alperencelik.
I use Kubemox latest version, Proxmox 8.2.2.

Hi @themoriarti,
I'm unable to reproduce the issue. I reviewed the code and couldn't understand what might be triggering another reconciliation mechanism. Is there a chance that the vm.yaml file was updated while it was being created? Below is the full log from my run:
As you can see once the VirtualMachine creation got completed the operator verifies the VirtualMachine exists and running.
➜  kubemox git:(v0.0.6-rc2) make run test -s /Users/alperencelik/Desktop/Personal/kubemox/bin/controller-gen && /Users/alperencelik/Desktop/Personal/kubemox/bin/controller-gen --version | grep -q v0.12.0 || \         GOBIN=/Users/alperencelik/Desktop/Personal/kubemox/bin go install<EMAIL_ADDRESS>/Users/alperencelik/Desktop/Personal/kubemox/bin/controller-gen rbac:roleName=manager-role crd webhook paths="./..." output:crd:artifacts:config=config/crd/bases /Users/alperencelik/Desktop/Personal/kubemox/bin/controller-gen object:headerFile="hack/boilerplate.go.txt" paths="./..." go fmt ./... go vet ./... go run ./cmd/main.go 2024-06-02T16:53:28+03:00       INFO    controller-runtime.metrics      Metrics server is starting to listen    {"addr": ":8080"} 2024-06-02T16:53:32+03:00       INFO    Connected to the Proxmox, version is: &{8.2 9355359cd7afbae4 8.2.2} 2024-06-02T16:53:32+03:00       INFO    ManagedVM fedora-template does not exist so creating it 2024-06-02T16:53:32+03:00       ERROR   cert-manager is not installed. Please install cert-manager to use CustomCertificate controller. github.com/alperencelik/kubemox/internal/controller/proxmox.(*CustomCertificateReconciler).SetupWithManager         /Users/alperencelik/Desktop/Personal/kubemox/internal/controller/proxmox/customcertificate_controller.go:173 main.main         /Users/alperencelik/Desktop/Personal/kubemox/cmd/main.go:139 runtime.main         /usr/local/go/src/runtime/proc.go:267 2024-06-02T16:53:32+03:00       INFO    setup   starting manager 2024-06-02T16:53:32+03:00       INFO    starting server {"path": "/metrics", "kind": "metrics", "addr": "[::]:8080"} 2024-06-02T16:53:32+03:00       INFO    Starting server {"kind": "health probe", "addr": "[::]:8081"} 2024-06-02T16:53:32+03:00       INFO    Starting EventSource    {"controller": "virtualmachineset", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "VirtualMachineSet", "source": "kind source: *v1alpha1.VirtualMachineSet"} 2024-06-02T16:53:32+03:00       INFO    Starting EventSource    {"controller": "virtualmachineset", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "VirtualMachineSet", "source": "kind source: *v1alpha1.VirtualMachine"} 2024-06-02T16:53:32+03:00       INFO    Starting Controller     {"controller": "virtualmachineset", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "VirtualMachineSet"} 2024-06-02T16:53:32+03:00       INFO    Starting EventSource    {"controller": "virtualmachinesnapshot", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "VirtualMachineSnapshot", "source": "kind source: *v1alpha1.VirtualMachineSnapshot"} 2024-06-02T16:53:32+03:00       INFO    Starting Controller     {"controller": "virtualmachinesnapshot", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "VirtualMachineSnapshot"} 2024-06-02T16:53:32+03:00       INFO    Starting EventSource    {"controller": "managedvirtualmachine", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "ManagedVirtualMachine", "source": "kind source: *v1alpha1.ManagedVirtualMachine"} 2024-06-02T16:53:32+03:00       INFO    Starting Controller     {"controller": "managedvirtualmachine", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "ManagedVirtualMachine"} 2024-06-02T16:53:32+03:00       INFO    Starting EventSource    {"controller": "container", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "Container", "source": "kind source: *v1alpha1.Container"} 2024-06-02T16:53:32+03:00       INFO    Starting Controller     {"controller": "container", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "Container"} 2024-06-02T16:53:32+03:00       INFO    Starting EventSource    {"controller": "virtualmachine", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "VirtualMachine", "source": "kind source: *v1alpha1.VirtualMachine"} 2024-06-02T16:53:32+03:00       INFO    Starting EventSource    {"controller": "virtualmachinesnapshotpolicy", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "VirtualMachineSnapshotPolicy", "source": "kind source: *v1alpha1.VirtualMachineSnapshotPolicy"} 2024-06-02T16:53:32+03:00       INFO    Starting Controller     {"controller": "virtualmachinesnapshotpolicy", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "VirtualMachineSnapshotPolicy"} 2024-06-02T16:53:32+03:00       INFO    Starting EventSource    {"controller": "storagedownloadurl", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "StorageDownloadURL", "source": "kind source: *v1alpha1.StorageDownloadURL"} 2024-06-02T16:53:32+03:00       INFO    Starting Controller     {"controller": "virtualmachine", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "VirtualMachine"} 2024-06-02T16:53:32+03:00       INFO    Starting EventSource    {"controller": "storagedownloadurl", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "StorageDownloadURL", "source": "kind source: *v1alpha1.StorageDownloadURL"} 2024-06-02T16:53:32+03:00       INFO    Starting Controller     {"controller": "storagedownloadurl", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "StorageDownloadURL"} 2024-06-02T16:53:33+03:00       INFO    Starting workers        {"controller": "managedvirtualmachine", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "ManagedVirtualMachine", "worker count": 5} 2024-06-02T16:53:33+03:00       INFO    Starting workers        {"controller": "virtualmachinesnapshot", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "VirtualMachineSnapshot", "worker count": 3} 2024-06-02T16:53:33+03:00       INFO    Starting workers        {"controller": "container", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "Container", "worker count": 1} 2024-06-02T16:53:33+03:00       INFO    Starting workers        {"controller": "virtualmachine", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "VirtualMachine", "worker count": 10} 2024-06-02T16:53:33+03:00       INFO    Reconciling ManagedVirtualMachine fedora-template       {"controller": "managedvirtualmachine", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "ManagedVirtualMachine", "ManagedVirtualMachine": {"name":"fedora-template","namespace":"default"}, "namespace": "default", "name": "fedora-template", "reconcileID": "eeda4fb5-a57b-4d98-bc1f-3ba8a69f9e74"} 2024-06-02T16:53:33+03:00       INFO    Starting workers        {"controller": "storagedownloadurl", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "StorageDownloadURL", "worker count": 3} 2024-06-02T16:53:33+03:00       INFO    Starting workers        {"controller": "virtualmachinesnapshotpolicy", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "VirtualMachineSnapshotPolicy", "worker count": 3} 2024-06-02T16:53:33+03:00       INFO    Starting workers        {"controller": "virtualmachineset", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "VirtualMachineSet", "worker count": 5} 2024-06-02T16:54:23+03:00       INFO    Reconciling VirtualMachine virtualmachine-sample-clone  {"controller": "virtualmachine", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "VirtualMachine", "VirtualMachine": {"name":"virtualmachine-sample-clone","namespace":"default"}, "namespace": "default", "name": "virtualmachine-sample-clone", "reconcileID": "a99dfc8f-c34c-45f1-b8b8-7c8294df22c4"} 2024-06-02T16:54:23+03:00       INFO    Creating VirtualMachine {"controller": "virtualmachine", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "VirtualMachine", "VirtualMachine": {"name":"virtualmachine-sample-clone","namespace":"default"}, "namespace": "default", "name": "virtualmachine-sample-clone", "reconcileID": "a99dfc8f-c34c-45f1-b8b8-7c8294df22c4", "name": "virtualmachine-sample-clone"} 2024-06-02T16:54:23+03:00       INFO    Creating VM from template: fedora-template 2024-06-02T16:54:23+03:00       INFO    New VM virtualmachine-sample-clone has been creating with ID: 101 2024-06-02T16:54:23+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: create full clone of drive scsi0 (local-lvm:base-100-disk-0) 2024-06-02T16:54:26+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 5.5 GiB of 50.0 GiB (11.04%) 2024-06-02T16:54:26+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 8.0 GiB of 50.0 GiB (16.06%) 2024-06-02T16:54:26+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 5.0 GiB of 50.0 GiB (10.04%) 2024-06-02T16:54:26+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 512.0 MiB of 50.0 GiB (1.00%) 2024-06-02T16:54:26+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 7.5 GiB of 50.0 GiB (15.06%) 2024-06-02T16:54:26+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 2.5 GiB of 50.0 GiB (5.02%) 2024-06-02T16:54:26+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 4.5 GiB of 50.0 GiB (9.04%) 2024-06-02T16:54:26+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 8.5 GiB of 50.0 GiB (17.07%) 2024-06-02T16:54:26+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process:   Logical volume "vm-101-disk-0" created. 2024-06-02T16:54:26+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 1.5 GiB of 50.0 GiB (3.01%) 2024-06-02T16:54:26+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 4.0 GiB of 50.0 GiB (8.03%) 2024-06-02T16:54:26+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 7.0 GiB of 50.0 GiB (14.05%) 2024-06-02T16:54:26+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 2.0 GiB of 50.0 GiB (4.02%) 2024-06-02T16:54:26+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 6.5 GiB of 50.0 GiB (13.05%) 2024-06-02T16:54:26+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 6.0 GiB of 50.0 GiB (12.05%) 2024-06-02T16:54:26+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 1.0 GiB of 50.0 GiB (2.01%) 2024-06-02T16:54:26+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 0.0 B of 50.0 GiB (0.00%) 2024-06-02T16:54:26+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 3.0 GiB of 50.0 GiB (6.02%) 2024-06-02T16:54:26+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 3.5 GiB of 50.0 GiB (7.03%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 22.1 GiB of 50.0 GiB (44.17%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 13.6 GiB of 50.0 GiB (27.11%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 19.1 GiB of 50.0 GiB (38.15%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 15.6 GiB of 50.0 GiB (31.12%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 17.6 GiB of 50.0 GiB (35.14%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 11.0 GiB of 50.0 GiB (22.09%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 22.6 GiB of 50.0 GiB (45.18%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 13.0 GiB of 50.0 GiB (26.10%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 21.1 GiB of 50.0 GiB (42.16%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 10.0 GiB of 50.0 GiB (20.08%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 23.1 GiB of 50.0 GiB (46.18%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 16.1 GiB of 50.0 GiB (32.12%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 17.1 GiB of 50.0 GiB (34.13%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 10.5 GiB of 50.0 GiB (21.08%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 15.1 GiB of 50.0 GiB (30.12%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 14.6 GiB of 50.0 GiB (29.11%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 21.6 GiB of 50.0 GiB (43.17%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 20.6 GiB of 50.0 GiB (41.16%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 12.0 GiB of 50.0 GiB (24.09%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 12.5 GiB of 50.0 GiB (25.10%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 20.1 GiB of 50.0 GiB (40.16%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 11.5 GiB of 50.0 GiB (23.09%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 9.0 GiB of 50.0 GiB (18.07%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 18.6 GiB of 50.0 GiB (37.14%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 19.6 GiB of 50.0 GiB (39.15%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 16.6 GiB of 50.0 GiB (33.13%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 18.1 GiB of 50.0 GiB (36.14%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 14.1 GiB of 50.0 GiB (28.11%) 2024-06-02T16:54:28+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 9.5 GiB of 50.0 GiB (19.07%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 30.1 GiB of 50.0 GiB (60.23%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 35.6 GiB of 50.0 GiB (71.28%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 28.6 GiB of 50.0 GiB (57.22%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 43.2 GiB of 50.0 GiB (86.34%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 40.2 GiB of 50.0 GiB (80.31%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 24.1 GiB of 50.0 GiB (48.19%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 29.1 GiB of 50.0 GiB (58.23%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 39.1 GiB of 50.0 GiB (78.30%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 42.7 GiB of 50.0 GiB (85.33%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 32.1 GiB of 50.0 GiB (64.25%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 40.7 GiB of 50.0 GiB (81.32%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 28.1 GiB of 50.0 GiB (56.22%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 33.1 GiB of 50.0 GiB (66.26%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 37.6 GiB of 50.0 GiB (75.29%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 27.6 GiB of 50.0 GiB (55.21%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 41.2 GiB of 50.0 GiB (82.32%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 33.6 GiB of 50.0 GiB (67.26%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 25.6 GiB of 50.0 GiB (51.20%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 42.2 GiB of 50.0 GiB (84.33%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 26.1 GiB of 50.0 GiB (52.20%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 23.6 GiB of 50.0 GiB (47.18%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 31.1 GiB of 50.0 GiB (62.24%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 34.6 GiB of 50.0 GiB (69.27%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 36.1 GiB of 50.0 GiB (72.28%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 24.6 GiB of 50.0 GiB (49.19%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 26.6 GiB of 50.0 GiB (53.21%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 38.6 GiB of 50.0 GiB (77.30%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 31.6 GiB of 50.0 GiB (63.25%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 41.7 GiB of 50.0 GiB (83.32%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 27.1 GiB of 50.0 GiB (54.21%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 34.1 GiB of 50.0 GiB (68.27%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 36.6 GiB of 50.0 GiB (73.29%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 32.6 GiB of 50.0 GiB (65.25%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 37.1 GiB of 50.0 GiB (74.29%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 35.1 GiB of 50.0 GiB (70.27%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 39.7 GiB of 50.0 GiB (79.31%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 38.1 GiB of 50.0 GiB (76.30%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 30.6 GiB of 50.0 GiB (61.24%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 25.1 GiB of 50.0 GiB (50.20%) 2024-06-02T16:54:30+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 29.6 GiB of 50.0 GiB (59.23%) 2024-06-02T16:54:32+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 43.7 GiB of 50.0 GiB (87.34%) 2024-06-02T16:54:32+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 46.2 GiB of 50.0 GiB (92.36%) 2024-06-02T16:54:32+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 49.2 GiB of 50.0 GiB (98.38%) 2024-06-02T16:54:32+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 49.7 GiB of 50.0 GiB (99.39%) 2024-06-02T16:54:32+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 48.7 GiB of 50.0 GiB (97.38%) 2024-06-02T16:54:32+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 46.7 GiB of 50.0 GiB (93.36%) 2024-06-02T16:54:32+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 47.2 GiB of 50.0 GiB (94.37%) 2024-06-02T16:54:32+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 44.7 GiB of 50.0 GiB (89.35%) 2024-06-02T16:54:32+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 47.7 GiB of 50.0 GiB (95.37%) 2024-06-02T16:54:32+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 44.2 GiB of 50.0 GiB (88.34%) 2024-06-02T16:54:32+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 45.7 GiB of 50.0 GiB (91.36%) 2024-06-02T16:54:32+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 45.2 GiB of 50.0 GiB (90.35%) 2024-06-02T16:54:32+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 50.0 GiB of 50.0 GiB (100.00%) 2024-06-02T16:54:32+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 50.0 GiB of 50.0 GiB (100.00%) 2024-06-02T16:54:32+03:00       INFO    Virtual Machine virtualmachine-sample-clone, creation process: transferred 48.2 GiB of 50.0 GiB (96.37%) 2024-06-02T16:54:41+03:00       INFO    VM virtualmachine-sample-clone has been created 2024-06-02T16:55:02+03:00       INFO    VM virtualmachine-sample-clone has been started 2024-06-02T16:55:02+03:00       INFO    VirtualMachine virtualmachine-sample-clone already exists and running   {"controller": "virtualmachine", "controllerGroup": "proxmox.alperen.cloud", "controllerKind": "VirtualMachine", "VirtualMachine": {"name":"virtualmachine-sample-clone","namespace":"default"}, "namespace": "default", "name": "virtualmachine-sample-clone", "reconcileID": "a99dfc8f-c34c-45f1-b8b8-7c8294df22c4"}


Change warning suppression case

Suppress the warning if they have installed "@angular/cli" in either "devDependencies" OR "dependencies"
Fixes #5443

I signed it!
Note: this was a quick patch done in the GitHub UI without testing. Feel free to close if there are any doubts about the changes.

Superseded by https://github.com/angular/angular-cli/pull/5498, but thanks for the work you put in fixing it!


Add a typeinformation to loadYaml function

This issue was originally filed by<EMAIL_ADDRESS>
The https://pub.dartlang.org/packages/yaml package defines a global loadYaml function.
Pls. add the type-info (YamlNode) for the return value

This issue has been moved to dart-lang/yaml#10.


ENUM definitions are not aligned

The following code is not changed at all by ABAP cleaner
    TYPES:
      BEGIN OF ENUM cost_distribution BASE TYPE vrtkz,
        not_distributed VALUE IS INITIAL,
        by_quantity VALUE '1',
        by_percentage VALUE '2',
        by_amount VALUE '3',
      END OF ENUM cost_distribution.

It would make sense that ABAP Cleaner aligns the VALUE parts of ENUMs, for instance as shown below
    TYPES:
      BEGIN OF ENUM cost_distribution BASE TYPE vrtkz,
        not_distributed VALUE IS INITIAL,
        by_quantity     VALUE '1',
        by_percentage   VALUE '2',
        by_amount       VALUE '3',
      END OF ENUM cost_distribution.

Hi Kjetil,
good point, thanks for the suggestion! Let me set a "new option" label for now, but we'd have to check whether this should be a new option to the "Align declarations" rule or rather a new cleanup rule.
Kind regards,
Jörg-Michael

Hi Kjetil,
thanks again for opening this! With the next release, the "Align declarations" rule will have this new option:

Example:

Existing one-liners are kept …

… unless they come with VALUEs:

Kind regards,
Jörg-Michael

Hi Kjetil,
thanks again for pointing this out – alignment of ENUMs should now work with version 1.13.0!
Kind regards,
Jörg-Michael


Release Process for v7.4.5 not found in winget

Checklist
Why is winget not updated with latest but Microsoft Store is?

All download links only providing <IP_ADDRESS> including the MSI package links so it's not just winget.

There is always a small delay between releases here and them showing up in places like Winget
It is now available so closing this as resolved


Extension validation

We should offer a way to validate the extension against DT cluster API.
We don't want to do that locally as the cluster always carries up-to-date schema definitions and we don't want to track them on our side.

So, the cluster is going the be the golden source of the schema? If it's not then the only way we could go is by open sourcing the schema definitions separately and then use them as a single source for both tenant builds and dt-cli. But, as I understand, this is not the way we are going.
Do we have any information on how to use DT cluster API for schema validation for EF2.0 extensions?

There's a dedicated API endpoint for that, it's also being used by HUB.


Add GitLab Provider from django-allauth

Add GitLab as an option to Social Accounts so that users can connect rtd accounts to thier GitLab repositories. There seems to be the demand and use cases, as discussed in #1068.
Once this issue is resolved,  integrate the gitlab provider into rtd.

Hi, the gitlab provider is implemented, it just needs to be merged, see: https://github.com/pennersr/django-allauth/pull/1231

@saily++

merged, let's wait for a new release and then update our version pins in requirements.txt.

Commit is pinned with work in #1850, which should also include the commits required here. #1893 addresses bumping to the next release.


Replaced the accessors that return optional string_view objects with two separate functions.

This is what we talked about earlier (or last night, if you are reading about this when you wake up).
I removed the use of optional, and updated all the tests. For me, all tests are green. So the following is up for discussion:

Do we need "bool has_x() const" if string_view::data() can be tested against nullptr;
What do we do with "template  intT port() const"?

For 1, I think (weakly) that the answer is "yes"
For 2, I think throw an exception on error
I'm already comfortable with the idea of no longer using optional in this context, my experience already is that is much easier for the user to use and understand.

P.S. If we agree, I want to start integrating this (as a submodule) into the cpp-netlib

Do we need "bool has_x() const" if string_view::data() can be tested against nullptr;

I think so. It's useful to have these specific checks.

What do we do with "template intT port() const"?

I think we can turn this into a string_view too. If users want to turn this into a number, they can choose the many ways to do it.

I'm already comfortable with the idea of no longer using optional in this context, my experience already is that is much easier for the user to use and understand.

SGTM

LGTM


CI: RuntimeKVStoreTest Consul KVStore: Found a "JoinEP: " in Cilium Logs

https://jenkins.cilium.io/job/cilium-ginkgo/job/cilium/job/master/4097/testReport/junit/(root)/Suite-runtime/RuntimeKVStoreTest_Consul_KVStore/
Likely also seen in other test failures.
Stacktrace
/home/jenkins/workspace/cilium-ginkgo_cilium_master/runtime-gopath/src/github.com/cilium/cilium/test/ginkgo-ext/scopes.go:357
Found a "JoinEP: " in Cilium Logs
/home/jenkins/workspace/cilium-ginkgo_cilium_master/runtime-gopath/src/github.com/cilium/cilium/test/ginkgo-ext/scopes.go:546

Standard Output
⚠  Found a "JoinEP: " in logs
⚠  Found a "JoinEP: " in logs
⚠  Found a "JoinEP: " in logs
Number of "context deadline exceeded" in logs: 0
⚠  Number of "level=error" in logs: 6
⚠  Number of "level=warning" in logs: 16
Number of "Cilium API handler panicked" in logs: 0
Number of "Goroutine took lock for more than" in logs: 4
Top 5 errors/warnings:
Unable to release endpoint ID
Error while rewriting endpoint BPF program
endpoint regeneration failed
JoinEP: Failed to load program
generating BPF for endpoint failed, keeping stale directory.

Standard Error
STEP: Starting Cilium with consul as kvstore
STEP: Restarting cilium-docker service
=== Test Finished at 2020-02-20T16:24:14Z====
===================== TEST FAILED =====================
cmd: sudo cilium endpoint list
Exitcode: 1
Stdout:

Stderr:
 	 Error: cannot get endpoint list: Get http:///var/run/cilium/cilium.sock/v1/endpoint: dial unix /var/run/cilium/cilium.sock: connect: no such file or directory
	 Is the agent running?

cmd: sudo cilium status
Exitcode: 1
Stdout:

Stderr:
 	 Get http:///var/run/cilium/cilium.sock/v1/healthz: dial unix /var/run/cilium/cilium.sock: connect: no such file or directory
	 Is the agent running?

===================== Exiting AfterFailed =====================
STEP: Restarting Cilium

JoinEP was for:
Feb 20 21:52:31 runtime cilium-agent[21367]: level=debug msg="Finished writing ELF" error="<nil>" new-elf-path=2426_next/bpf_lxc.o subsys=elf template-path=/var/run/cilium/state/templates/8d3716e7d957e6dc97c94e4743af2ea684c3402f/bpf_lxc.o
Feb 20 21:52:31 runtime cilium-agent[21367]: level=warning msg="JoinEP: Failed to load program" containerID=7b66b8e673 datapathPolicyRevision=0 desiredPolicyRevision=1 endpointID=2426 error="Failed to replace Qdisc for lxcc8e2168b062b: Link not found" file-path=2426_next/bpf_lxc.o identity=30941 ipv4=<IP_ADDRESS> ipv6="f00d::a0f:0:0:4057" k8sPodName=/ subsys=datapath-loader veth=lxcc8e2168b062b

From the cilium-docker.log we can see that the iface was created, and then the endpoint was removed:
Feb 20 21:46:19 runtime cilium-docker[13350]: level=debug msg="Created veth pair" subsys=endpoint-connector vethPair="[tmpb33c1 lxcc8e2168b062b]"
Feb 20 21:46:22 runtime cilium-docker[13350]: level=debug msg="Created new endpoint" endpointID=b33c1a7993a289f5af6562401225219f3bd18fadcc040c82b38540f07b13155a event="{Status:start ID:bab040116751b41601bab8854076d98069af9a42cbd7492d8491e4bba1d70533 From:docker.io/cilium/demo-httpd:latest Type:container Action:start Actor:{ID:bab040116751b41601bab8854076d98069af9a42cbd7492d8491e4bba1d70533 Attributes:map[id.httpd3: id.service1: image:docker.io/cilium/demo-httpd:latest name:httpd3]} Scope:local Time:1582235179 TimeNano:1582235179515756232}" subsys=cilium-docker-driver

[...]

Feb 20 21:48:27 runtime cilium-docker[13350]: level=debug msg="Leave request" event="{Status:start ID:4947d9be24cd0b348845021ac1fd3de462435b6c80a9c24a0c2d6000495840ad From:docker.io/tgraf/netperf:v1.0 Type:container Action:start Actor:{ID:4947d9be24cd0b348845021ac1fd3de462435b6c80a9c24a0c2d6000495840ad Attributes:map[id.app3: image:docker.io/tgraf/netperf:v1.0 name:app3]} Scope:local Time:1582235188 TimeNano:1582235188128291351}" req="&{NetworkID:b23e3e5f7ce8d2e1370f0052e5303ed8cd72cc6d76daaf70af620a147e4c004f EndpointID:b33c1a7993a289f5af6562401225219f3bd18fadcc040c82b38540f07b13155a}" subsys=cilium-docker-driver
Feb 20 21:48:27 runtime cilium-docker[13350]: level=warning msg="Leaving the endpoint failed" error="Delete http:///var/run/cilium/cilium.sock/v1/endpoint/docker-endpoint:b33c1a7993a289f5af6562401225219f3bd18fadcc040c82b38540f07b13155a: dial unix /var/run/cilium/cilium.sock: connect: no such file or directory\nIs the agent running?" event="{Status:start ID:4947d9be24cd0b348845021ac1fd3de462435b6c80a9c24a0c2d6000495840ad From:docker.io/tgraf/netperf:v1.0 Type:container Action:start Actor:{ID:4947d9be24cd0b348845021ac1fd3de462435b6c80a9c24a0c2d6000495840ad Attributes:map[id.app3: image:docker.io/tgraf/netperf:v1.0 name:app3]} Scope:local Time:1582235188 TimeNano:1582235188128291351}" subsys=cilium-docker-driver
Feb 20 21:48:27 runtime cilium-docker[13350]: level=debug msg="Delete endpoint request" event="{Status:start ID:4947d9be24cd0b348845021ac1fd3de462435b6c80a9c24a0c2d6000495840ad From:docker.io/tgraf/netperf:v1.0 Type:container Action:start Actor:{ID:4947d9be24cd0b348845021ac1fd3de462435b6c80a9c24a0c2d6000495840ad Attributes:map[id.app3: image:docker.io/tgraf/netperf:v1.0 name:app3]} Scope:local Time:1582235188 TimeNano:1582235188128291351}" req="&{NetworkID:b23e3e5f7ce8d2e1370f0052e5303ed8cd72cc6d76daaf70af620a147e4c004f EndpointID:b33c1a7993a289f5af6562401225219f3bd18fadcc040c82b38540f07b13155a}" subsys=cilium-docker-driver

So at the time Feb 20 21:52:31 when JoinEP was logged, the endpoint was already removed. However, I'm not sure why the cilium.sock was not available during the removal of the endpoint.

Typically cilium.sock not being available means cilium-agent has crashed. Missing logs would tell the same story?

Maybe the step Restarting Cilium hides the logs of the crashed cilium-agent?

JoinEP being logged after endpoint is removed could indicate that somewhere on the "JoinEP" code path we take the endpoint lock without testing for lineness and fail to bail when endpoint is already deleted?

This indicates that this happens before any policies are installed, of maybe as the reaction for the first policy being imported:
datapathPolicyRevision=0 desiredPolicyRevision=1

This in https://jenkins.cilium.io/job/Cilium-PR-Ginkgo-Tests-Kernel/1640/:
2020-05-21T14:12:28.118236793Z level=debug msg="Finished writing ELF" error="<nil>" new-elf-path=2072_next/bpf_lxc.o subsys=elf template-path=/var/run/cilium/state/templates/4f516e5cd7c790fd72df28e48bfc809ec09b1dcc/bpf_lxc.o
2020-05-21T14:12:28.118393473Z level=warning msg="JoinEP: Failed to load program" containerID=937b325394 datapathPolicyRevision=0 desiredPolicyRevision=2 endpointID=2072 error="Failed to replace Qdisc for lxc3bfb26c6f5f9: Link not found" file-path=2072_next/bpf_lxc.o identity=7139 ipv4=<IP_ADDRESS> ipv6="fd00::42" k8sPodName=default/app2-776cf4f9c6-tlgrj subsys=datapath-loader veth=lxc3bfb26c6f5f9
2020-05-21T14:12:28.118464748Z level=error msg="Error while rewriting endpoint BPF program" containerID=937b325394 datapathPolicyRevision=0 desiredPolicyRevision=2 endpointID=2072 error="Failed to replace Qdisc for lxc3bfb26c6f5f9: Link not found" identity=7139 ipv4=<IP_ADDRESS> ipv6="fd00::42" k8sPodName=default/app2-776cf4f9c6-tlgrj subsys=endpoint
2020-05-21T14:12:28.118519528Z level=debug msg="Reverting endpoint changes after BPF regeneration failed" containerID=937b325394 datapathPolicyRevision=0 desiredPolicyRevision=2 endpointID=2072 identity=7139 ipv4=<IP_ADDRESS> ipv6="fd00::42" k8sPodName=default/app2-776cf4f9c6-tlgrj subsys=endpoint


Typescript should prevent invalid variable assigning in if conditions

Suggestion

🔍 Search Terms

"assigning if", I don't know what else to look for
✅ Viability Checklist

My suggestion meets these guidelines:

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

⭐ Suggestion

I believe a lot of JavaScript programmers have accidentally written code that assigns a new value to a variable instead of comparing it to something else by doing the following
let variable = "text"
if (variable = "value") // rest of the code

When they actually meant to do this
let variable = "text"
if (variable === "value") // rest of the code

And this code is invalid and an error should be thrown by TypeScript before runtime because it is essentially creating an invalid if condition that will never run. A possible problem that could come from creating an error in this would be situations where variables are correctly reassigned and then compared to something, like in the following example:
	let matches;
    while ((matches = this.constructor.CHANNELS_PATTERN.exec(this._content)) !== null) {
      const chan = this.client.channels.cache.get(matches[1]);
      if (chan) this._channels.set(chan.id, chan);
    }

Even though the above example uses a while, it's still a valid use case where an error should not be thrown since it is being compared later.
📃 Motivating Example

TypeScript will now be able to detect invalid if conditions and help you improve them before runtime so that they aren't ignored.
💻 Use Cases

Basically, whenever you're coding while tired and accidentally write this, TS would alert you like all other TS features.

Related: #38826

Related: #38826

Although I can see how that suggestion can relate to this one, it goes one step forward in enforcing a boolean on every condition, which wouldn’t be ideal at least to me. What I’m talking about here is producing an error on something that is actually invalid, so I believe this should be checked for without any additional settings

FWIW this is similar to ESLint's no-cond-assign rule.

FWIW this is similar to ESLint's no-cond-assign rule.

Yep, I know, that’s exactly where I got this idea from! I just don’t really like using ESLint at least for now so it would be nice if TS supported this since it seems like it’s something it should support

Seems like a reasonable candidate for This condition will always return true if the RHS is an always-truthy type, or at least a truthy literal... I don’t think we’d ban this pattern outright (that feels solidly in the domain of a linter), but obviously truthy conditions look beyond suspicious.


Capture Window to File / ClipBoard

[x] Windows Supported
[ ] Mac Supported
[x] Linux Supported

Linux
To File: Working
** To ClipBoard**: Partially working, does have some limitations on the Windows that can be Captured.
For Example:

TouchPortal captures fine
Notepad captures fine
Webrowser doesnt seem to capture
Folders dont seem to capture


last change introduced a runtime error in exception handling

Last commit from me was problematic, sorry ...

I had the same issue,
I just changed 'except e:' by 'except Exception as e:'

I do not have a sound understanding of the error handling myself.
After reading https://wiki.python.org/moin/HandlingExceptions I rolled back my own change of this.
My intent is to have good log of all possible exceptions to help admins while installing.


Added Input Validation for Add Project Screen

Description
In the mobile app, you can create a new project or update an existing one with no values. Hence, a record with no values is stored in the database. Fixed that by adding input validation for the concerned screen.
Fixes #537
Type of change

[x] Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?
Try creating a project without entering any values
Test Configuration:
Realme 3 Pro

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] My changes generate no new warnings
[x] New and existing unit tests pass locally with my changes

@Tushar19varshney Hello! Could you please review it?


How to identify a completed transaction with the given Intent

Hi,
in our app a user chooses from a list of open transactions (each one defined with a unique foreignTransactionId) which one to use next for payment.
Is there a way we can retrieve such a completed transaction in onActivityResult(..) with the
data given back in the Intent parameter?
In our opinion SumUpAPI.Response doesn't contain any information which we could use to match with the transactions from the original list.
SumUpAPI.Response.TX_CODE is not the same as the foreignTransactionId, right?
If there is no identifying feature we would have set the current transaction in a separate field in our app, but we think it would be neater to use the data in the Intent.

Problem solved:
Bundle extra = data.getExtras();
String foreignTransactionId = extra.getString(SumUpAPI.Param.FOREIGN_TRANSACTION_ID);

You were quicker than. I was about to send you the same. We forgot to document that point and will fix that in a very near future.

That's great. Thank you for your message.


Cannot read property 'layout' of undefined

Don't have a reproduction for you, but I've observed when updating data, the following error:
TypeError Cannot read property 'layout' of undefined
This error is located at:
    in Item (at Steve.js:107)
    in Items (at Steve.js:200)
    in RCTView (at View.js:32)
    in View (at createAnimatedComponent.js:448)
    in AnimatedComponent(View) (at createAnimatedComponent.js:459)
    in AnimatedComponentWrapper (at Steve.js:199)
    in RCTView (at View.js:32)
    in View (at createAnimatedComponent.js:448)
    in AnimatedComponent(View) (at createAnimatedComponent.js:459)
    in AnimatedComponentWrapper (at Steve.js:198)
    in PanGestureHandler (at Steve.js:195)

I've also noticed that layout recalculation isn't performed when updating data (items may overlap each other). The library should support data updates, or at a minimum warn users.

@braincore Hi.  Thanks for letting me know.  I really don't have free time to solve the problems in the project and can't promise when I can fix the problem.  Contibutions are welcome :)

No time here either :). I've already worked around the issue by unmounting/remounting the component when data changes. Hopefully anyone else who encounters this issue will see this.  Thanks a lot for this project!

@braincore Thanks for your understanding. I'll take some time and try to figure it out tomorrow.

@braincore Hi! Found a good solution to the issue. Please pull the changes and give it a try to see if it works for you too meanwhile I'll try to fix the other issues.  https://github.com/tsdmrfth/react-native-steve/pull/27

Metro has trouble compiling.
error: Error: Unable to resolve module hooks from /Users/ken/src/superego/mobile/IntertimesMobile/node_modules/react-native-steve/src/Steve.js: hooks could not be found within the project or in these directories:
  node_modules
  ../../../node_modules

Why did you add hooks as a sub-package?


Need update and more information.

This documentation is old and have limited information. Need to know more information like:
Is DFS supported ?  What rights are needed on the share etc.?

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

ID: 927e07a9-dff9-78a7-a351-90c694ea2537
Version Independent ID: ec207175-a445-4f22-9c79-d02d83c59db4
Content: Add File Store
Content Source: Skype/SfbServer/help-topics/help-topobld/add-file-store.md
Product: skype-for-business-itpro
GitHub Login: @kenwith
Microsoft Alias: kenwith

Thank you for this feedback and for contributing to the wellness of the content! This is a good idea and we have added it into our backlog for triage and prioritization.

@tseward Is investigating this.

Hi! Thanks for your feedback.
You can find information on DFS and permissions here https://docs.microsoft.com/en-us/skypeforbusiness/deploy/install/create-a-file-share


[Bug Report]  Error when hovering over empty cells

Element UI version
2.3.8
OS/Browsers version
Windows 10
Chrome  66.0.3359.139
Electron 2.0.0
Vue version
2.5.16
Reproduction Link
https://jsfiddle.net/h9q86pev/
Steps to reproduce
// element-ui/packages/table/src/table-body.js, Line 343
    range.setEnd(cellChild, 1);

And the data in the cell is empty ("")
What is Expected?
No error output.
What is actually happening?
If the cell is empty, when mouse move on to the cell, the console will output:
Uncaught DOMException: Failed to execute 'setEnd' on 'Range': There is no child at offset 1.

This was previous reported here: https://github.com/ElemeFE/element/issues/11203 and has been fixed here: https://github.com/ElemeFE/element/pull/11137


Add default export for backwards compatibility

Fixes:

There is no default export in ESM build (TBH this is my fault) therefore it cannot be imported as import vis from 'vis-network', it has to be imported as import * as vis from 'vis-network'. Although UMD build works (hence working examples). This is definitely breaking change because tools like Webpack or Rollup automatically pick ESM over UMD.

You're welcome.


remove some print in snli file

This PR removes some print statements in snli.py

I guess you can just rebase from master to fix the CI


LeetCode Hard: N-Queens

this is amazing @oops-shlok
thanks for the contribution in my repo and please share in social media and tag me on twitter


35 Fetch bidirectional lazy one-to-many associations

The code could be simplified by changing some methods in ORM but I would prefer to do it as a separate issue and first make sure that this solution makes sense.
The caveat is that this patch skip the path that should resolve collection of elements. But we agreed that it's not necessary to begin with so, hopefully, it should be fine.

@DavideD Nice! I'm looking at this now.

The caveat is that this patch skip the path that should resolve collection of elements.

Sure, that's totally fine: we definitely don't need @ElementCollection for now.

I've sent a new PR with the changes we discussed: https://github.com/hibernate/hibernate-rx/pull/91


fix data race about kubeconfigpath

Ⅰ. Describe what this PR does
fix data race about kubeconfigpath
Ⅱ. Does this pull request fix one issue?

fixes #1303
Ⅲ. List the added test cases (unit test/integration test) if any, please explain if no tests are needed.
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Thanks for your fixing! @wangyanghack


Compact legendre polynomials

Legendre polynomials don't need to be stored zero-padded, we can just concatenate them with proper zero padding.
E.g. on tco2559, this saves up to almost 40GB per rank (used to be 64 GB, now it is 26 GB). Initially, we did this for Leonardo, because legendre coefficients used almost the whole device memory.

(convert to draft for the moment ==> it is fnished but we should first merge the other PR, then rebase and review)

Beside replacing ext_acc with the proper "copy module", we are only left with this PR from the old GPU branch which I now rebased on top of develop. This PR is compacting the legendre polynomials and with this removing zero padding.
This PR is not expected to interfere with any other PR, as it only touches the GEMMs.  Since I am touching the CUDA interfaces anyway, I also added const to pointers in the interface.

[x]  Applied clang-format
[x] Tested that everything is properly deallocated
[x] Tested large sizes for no overflows.

If I can find the time this week, I will take a look. It might have to wait until next year.


HBASE-23894 Support ErrorProne for both JDK8 and JDK11

ErrorProne uses an extension interface that's only available on javac
from JDK9+. Thus, its configuration for JDK8 is quite different from
later JVM versions. These configurations are mutually exclusive, I
haven't seen any documentation for project that compile on both javac
verions. Thus this implementation based on different maven profiles.
The situation is further complicated by maven not allowing profile
activation based on multiple conditions. In our case, we'd like to do
profile select based on both the active JDK and the presense of some
enablement flag, such as -DerrorProne. This seems to be impossible.
Thus, the solution presented here is to define two profiles, neither
active by default. When a user wishes to run Error Prone, they must
activate the profile that is appropriate to their version of javac.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1547/1/console in case of problems.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1547/1/console in case of problems.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1547/1/console in case of problems.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 31s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+0 :ok:
shelldocs
0m  0s
Shelldocs was not available.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

_ Patch Compile Tests _

+1 :green_heart:
shellcheck
0m  2s
There were no new shellcheck issues.

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
xml
0m  1s
The patch has no ill-formed XML file.

+1 :green_heart:
hadoopcheck
5m 50s
Patch does not cause any errors with Hadoop 3.1.2.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1547/1/console in case of problems.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1547/1/console in case of problems.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1547/1/console in case of problems.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m  0s
Docker mode activated.

-1 :x:
docker
0m 17s
Docker failed to build yetus/hbase:6d4e15a7ac.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/1547

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1547/1/console

versions
git=2.17.1

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m  0s
Docker mode activated.

-1 :x:
docker
0m 17s
Docker failed to build yetus/hbase:6d4e15a7ac.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/1547

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1547/1/console

versions
git=2.17.1

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m  0s
Docker mode activated.

-1 :x:
docker
0m 16s
Docker failed to build yetus/hbase:6d4e15a7ac.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/1547

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1547/1/console

versions
git=2.17.1

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

I don't think this is feasible; given how we mask its use behind a profile, we're going to have to run ErrorProne on only one JVM configuration.
Closing old/stale PR.


About incredible low metrics in ITS results

when compared with 608X448 Sots GT (indoor), the results are suprisingly low, including the offical results released, below 17psnr average

i want to bring your attention that, maybe you can offer me a copy of your testing GT, since during my testing, I have already resized the GT image to 608x448, still, not working.


Fix pdeathsig and ppid for supervisor running as pid1

For some reason when the supervisor of a container is PID1 the parent
death signal was being delivered to the container's init process even if
it did not die.  Also the ppid() will return 1 for a container running
in the pid namespace of it's parent and the parent is pid1.
Fixes: https://github.com/docker/docker/issues/12015
Signed-off-by: Michael Crosby<EMAIL_ADDRESS>

LGTM

@crosbymichael @LK4D4 you guys are rock stars, thanks for fixing this.


First item (position 0) item child click is not listening.

I have added in adapter addChildClickViewIds(R.id.plusbtn,R.id.minusbtn,R.id.prodqty);
.
The first item child clicks not working on position 0 item. when i click on any child of position 0 ite does nothing. rest position child working properly.

i have same problem too

fix in #3108

i solved by moving   addChildClickViewIds(); to adapter constructor instead of convet method.


Knowledge transfer with A2C transformer actor-model

Thank you for your work.
Have you considered how implementing a transformer as the actor model may impact the generative capabilities of your transformer? I have tried doing so, but due to computational limitations, I am not so sure of the results. Still, I was able to generate some interesting results.
Using knowledge transfer on the pretrained RNN policy, I was able to pretrain a decoder-only transformer to predict some novel scaffolds and compounds. However, this was within 500 training steps and a batch size of 32.
Here is the link to the repository (I am a novice coder):
https://github.com/resialre/SMILES-RL-Transformer.git
Here is a preliminary run comparing the A2C with the actor model as either the original RNN with LSTM cell-type or the pre-trained transformer run on an actor learning rate of 1e-6:

Thank you for showing interest in this work!
I have considered trying a transformer architecture instead, but have not had the time to implement it. Some recent work by [1] observed no major improvement in using transformers, but I am sure that there is a possible gain in using transformers instead.
By looking at your preliminary run, there seems to be something off. I do not know what score you are using, but I would expect the RNN-based A2C to learn more in 500 steps. It seems like it has not learned anything since the scores are more or less constant. This could of course be due to your low batch size, but I would expect a monotonic improvement.
You are welcome to share any future results.
[1] https://arxiv.org/pdf/2310.02902

Thank you for showing interest in this work!
I have considered trying a transformer architecture instead, but have not had the time to implement it. Some recent work by [1] observed no major improvement in using transformers, but I am sure that there is a possible gain in using transformers instead.
By looking at your preliminary run, there seems to be something off. I do not know what score you are using, but I would expect the RNN-based A2C to learn more in 500 steps. It seems like it has not learned anything since the scores are more or less constant. This could of course be due to your low batch size, but I would expect a monotonic improvement.
You are welcome to share any future results.
[1] https://arxiv.org/pdf/2310.02902


Bugfix/lift

Codecov Report

Merging #222 (eeea8c7) into main (a606ffe) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #222   +/-   ##
=======================================
  Coverage   67.99%   67.99%
=======================================
  Files          72       72
  Lines        2431     2431
  Branches      227      227
=======================================
  Hits         1653     1653
  Misses        713      713
  Partials       65       65

Impacted Files
Coverage Δ

...b/ascopes/jct/workspaces/impl/FileBuilderImpl.java
46.34% <ø> (ø)

...ascopes/jct/workspaces/impl/TempDirectoryImpl.java
100.00% <ø> (ø)


Add Saved Cards Implementation in Payment Methods

@yuvrajsinghgmx I will add "Add Saved Cards" implementation and refactor the cards interface to suit it accordingly .
Kindly assign it to me , I'll work on it immediately ... Cheers:)

Okay @pratheekv39 I am assigning you this but keep in mind that the feature additions that you are making to our app are not unnecessary.


Gallery 2023-07-03

Choose a PR Template
Switch to "Preview" on this description then select one of the choices below.
Click here to open a PR for a Data Plane API.
Click here to open a PR for a Control Plane (ARM) API.

Using this new PR instead: https://github.com/Azure/azure-rest-api-specs/pull/27590


fix: shutdown logging on exit

This closes #8 by shutting down logging when tryceratops is exiting, freeing up the resources in use, namely the log file that Windows didn't want to delete.

This also replaces the mess I made with #10 and the commit history.

Thank you!!


aes: encrypt and decrypt one block at a time

This PR fixes a subtle issue in the AES cipher encryption and decryption functions. When the output buffer is smaller than the input buffer and both are larger than the AES block size (16 bytes), then BCryptEncrypt errors with the STATUS_BUFFER_TOO_SMALL code. This behavior is not what Go implementation expects, as it always encrypts and decrypts one full block at a time, even if the input buffer is larger than that.
This issue is fixed by truncating the input and output buffers to the AES block size before calling BCryptEncrypt and BCryptDecrypt.
Added a new test to make sure that we don't regress and that our AES implementation is fully compatible with upstream AES.
This bug is worth backporting in the next patch release so our backend is more compatible with upstream.

Oh, my comments are on the copied files. Never mind those. 😅

Oh, my comments are on the copied files.


CentOS 7 install error

Hello.
I'm trying to install it in CentOS 7 but it gives me this error.
Can you please help?
[root@localhost LibreSignage]# make configure
Document root (DEF: /var/www): /var/www/html
Server name (domain): localhost
Server name aliases (space separated): localhost
Admin name: home
Admin email: home
Enable debugging? (y/N): N
Write config to 'build/localhost.iconf'.
[root@localhost LibreSignage]# sudo make install
[INFO] Include dependency makefiles.
dep/app/js/main.js.dep:3: *** target pattern contains no `%'.  Stop.

Could you go through this list:

Please check the version of make by running make -v.
What branch are you on when trying to compile? master, next or even something else.
Could you paste the contents of dep/app/js/main.js.dep here.

This issue seems to be the same as issue #48, which was fixed. I'm closing this one for now. If the problem persists you can create a new issue.


Disable Results API configuration DB SSL prod

This does not change the existing state!
For more info see #2965

/lgtm


Unable to Import Content

I am trying to migrate a dashboard from one instance to another. I was able to export the Shared folder, but when I try to deploy the content to another instance I get the following error:
logout
ERROR: Connection Failed.
Did you specify the --no-ssl option for an ssl secured server?
You may need to use --port=443 in some cases as well.

I double-checked the client ID/secret as well as the port. But I am still having issues.
Thanks,
Drew

@drew-hansen Could you share a few more details? Some useful info would be:

What version are you running ldeploy --version
What versions of python and ruby are you using?
I'm assuming you have (at least) two entries in your looker.ini file - if you feel comfortable with it, could you share a sanitized version of that file? (get rid of the client_id and client_secret before sharing!)
Could you rerun the command you tried with the --debug flag and see if it returns any additional information?

Without any additional context I'm guessing that there's something amiss with how the SDK is trying to authenticate. Most typically this is due to the verify_ssl field not being set correctly or an incorrect base_url so you can start there.

@JCPistell, appreciate you following up. It turns out it was a simple error. I had the port wrong. When I went to the API docs it had the port at 19999, when in reality it was 443. All good here now!

👍


Add stricter body protocol

Currently if "body 1" leaves the frame, "body 2" will become "body 1". Some sort of lock using the body id would be useful.

With current "body ID" blocks from #17  you can script this.


support different configurations based on the weight file name

With this pull request the correct configuration is loaded. The configuration name is automatically inferred based on the name of the model file.
The automatic configuration works at least with the downloadable yolact_edge models that are provided in the original yolact_edge repository.

LGTM. Thank you!


Tests are not removed from test explorer after test is deleted

Create new project
Add 2 test files, one with test_A, other with test_B
Open test explorer
Close and reopen solution
Delete all code from test_B and save
Delete test_B's file
Result: Test explorer is not updated to remove the deleted test. Running it results in test failure (not able to load the test).

If the tests was renamed, the test name in Test Explorer should be renamed, but it was not.

Fixed for 16.3.


File Upload

Do anyone have plan to add file upload feature ?

Yep, will add it. It would look like an API endpoint that generates upload URL (to Google Storage Bucket or Amazon S3). The client app would request that URL and upload file(s) directly to cloud storage using fetch({ method: "PUT", ... }).
mutation {
  createUploadUrl(...)
}

Any update on this? Thanks.

@phpb-com yes, there is api/src/mutations/getUploadURL.ts and api/src/mutations/saveUpload.ts on the API side. All you have to do on the client is to request "upload URL", send the file(s) via HTTP PUT to that URL, then send "uploaded file URL" to the saveUpload() API mutation (which copies the file over from a temporary upload bucket location to a permanent place based on the linked content type (user photo, blog post pictures, etc.). As was described here.


feat: support customer managed instance configurations

@saranshdhingra This PR is currently blocked from being merged because you requested changes. Would you mind submitting a new review?


QA: Test get from Store does not return Common Data

Test to ensure that Common Data is received when retrieve the created Log Object

@shehzadsidi please classify/update this card where appropriate

Complete


move CI from travis to github actions

A while ago I started moving hibernated and ddbc to use Github Actions instead of travis. Initially so that CI and the repo were under one roof but I found that the build times were substantially faster on github.
As an example this ddbc build runs a total of 35 builds, across Ubuntu, Mac, and Windows (64 & 32 bit) as well as one of those builds running integration tests against SQLite, MySQL, Postgres, and MS SQL Server 2017.
If you want I can put together a pull request. The yml for the ddbc pipeline looks like this: https://raw.githubusercontent.com/buggins/ddbc/master/.github/workflows/dub.yml

Thanks, yeah, I probably should just drop travis. I did just migrate to travis-ci.com, since .org wasn't completing, but now the .com isn't completing (seems to be only the Mac instances).
The whole mysql-d test system needs a complete overhaul. This is a prerequisite to merging my safe PR, so I need to pay attention to it. Thanks for the offer to set up a PR, but I think it's important for me to understand how the test system works. I do appreciate the help, and if I have questions, I'll probably post back here. I plan to tackle this in the next month.

Dropping travis has become a requirement now. One build using their "credit" system consumed all the credits for free projects (no doubt due to the insane number of builds in the CI config).
I will look at this soon.


how to add child to the tree?

how to add child to the tree?

You need a tree node class . Something that make this possible:
Node root;
Node a= root.child(2).child(4).child(5)
a.append(new Node())
Copy paste the Qt exemple and ajust as you want. You will see, its really
easy to manage your tree after that.
http://doc.qt.io/qt-5/qtwidgets-itemviews-simpletreemodel-example.html
Le lun. 3 sept. 2018 à 07:33, Gibranliu<EMAIL_ADDRESS>a écrit :

how to add child to the tree?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dridk/QJsonModel/issues/12, or mute the thread
https://github.com/notifications/unsubscribe-auth/AB0pF1d66PNABx6JsWxLX1hAbsLV4qauks5uXL8pgaJpZM4WW_T2
.

I did a Tree model  for another project. You can take a look :
https://github.com/dridk/hpo-gui/blob/master/node.h
https://github.com/dridk/hpo-gui/blob/master/hpomodel.h
2018-09-03 10:28 GMT+02:00 Gibranliu<EMAIL_ADDRESS>
I'll try, 3ks
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dridk/QJsonModel/issues/12#issuecomment-418040729,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB0pF-uW52_QdS30eSZMqBcSVSC4ZoBcks5uXOg-gaJpZM4WW_T2
.

--
Dr Sacha Schutz
médecine / génétique moléculaire
Bioinformaticien
+33651571606
dridk.me
www.labsquare.org
Fork me on github https://github.com/

thank you!


Add further examples.

Adds two example yaml files to the examples folder:

med_scale_nk_ILT.yaml:  Medium-scale NK model with inflation-level targeting.
med_scale_nk_PLT.yaml: Medium-scale NK model with price-level targeting.

Great, thanks a lot!


Remove t.Helper() since that's >= go 1.9

I'll merge this after CI to unbreak master.

Coverage decreased (-1.2%) to 84.912% when pulling d86f11f2cbb3d4f5613bb0f0765af5a77078fb42 on akalin/fix-ci into e05d6c9e515d6fec58d9181c92da200f2cb7a6e2 on master.

Coverage decreased (-1.2%) to 84.912% when pulling d86f11f2cbb3d4f5613bb0f0765af5a77078fb42 on akalin/fix-ci into e05d6c9e515d6fec58d9181c92da200f2cb7a6e2 on master.

FYI @oconnor663


MINOR: Update Log Compaction Details in design.html

tiny discrepancy in docs about Log compaction behaviour

Thanks for the PR. Could you rebase?


Doesn't handle 404 errors

If file is not found basket.js saves the 404 message in localStorage. Try something like
basket.require('doesntexist123.js');

I would assume the same problem exists with other errors, like 403 etc, too.

Closing as stale.


Improve messages to students on various abnormal exits/signals

Minimal messages are provided in
execute.cpp, OutputSignalErrorMessageToExecuteLogfile
These messages could be expanded/improved for the newbie programmer, including common causes, and tips for debugging.  These messages might be best customized per programming language, per course, or per assignment.
First we need to collect/create a wide variety of sample submissions that produces errors.

Looking through the execute.cpp, can see that the messages are pretty obtuse.  Is there already an idea of how to customize based on course/language/assignment?  For example, should it be in the config file, a separate configurable file, or changes in the code?


Remove the environments page

I don't think there is a real need for this page. It's trying
to describe what all the environments for while at the same time
giving a bit of technical detail about where they run.
If any of this information is actually valuable I think it should
be moved to other pages or separated out.
There is already a page about what the CI environment does here:
https://docs.publishing.service.gov.uk/manual/jenkins-ci.html
The training environment is not being used at the moment, and there are no
plans to do so until we've moved to AWS.
It would be useful to have something that describes the deployment process
in more detail, but the basic information about what environments exist is something
devs pick up when they join a team, and the getting started guide introduces them.

Not sure about removing it entirely, but I agree with removing the technical details. I think it'd still be useful to point people to somewhere that explains what "integration" is.

That was the approach I started with, but I realised I was just rewriting the entire page and wasn't sure how useful that was. I think it would be better to create a diagram of our deploy pipeline instead. Something where you see how code gets from one place to another. This could also inform discussions about moving towards continuous deployment.


Review the DCL Parsing rule for Oracle

Fixes #2214.

Pull Request Test Coverage Report for Build 7643

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 55.096%

Totals

Change from base Build 7641:
0.0%

Covered Lines:
8692

Relevant Lines:
15776

💛  - Coveralls


Q: Using local variables in .jwmrc config file

What is the recommended way to save / reuse local / environment variables in .jwmrc config file ?
(I need it to define some custom commands /scripts, theme color palette etc. and reuse it inside all over config file)

I don't believe it's currently possible to set environment variables inside a config file, but it is possible to reference them. So you might be able to just define some from .xinitrc or whatever starts JWM.
Adding the ability to set environment variables shouldn't be too hard. I think it would just be a matter of adding a new tag and then having JWM do setenv.

I just wanted to update this since I recently looked into it again. It turns out that environment variables are currently only supported in specific places in the configuration (anything that is a file path). It should be possible to support this in more places without too much work. If that would be useful for anyone I can look into it some more.


combining multiple TIFF's into a single TIFFImageryProvider

I have a set of 57 RGB TIF's which cover  all of Austria, each about 10GB
Do you see a way to combine those into a single TIFFImageryProvider, similar to a GDAL VRT?
or do I need to add each one separately and select the right one?
thanks in advance,
Michael
ps: works great for me - congratulations!

Hello, thank you for your support and encouragement.
This library currently only supports rendering a single TIFF file. Each TIFF file corresponds to a TIFFImageryProvider. If you have multiple TIFF files, you should group them together as a dataset.
When you need to load a specific file, you can create a TIFFImageryProvider and display it on the Cesium globe.
The dataset can be formatted as a simple array, similar to the following format, which can be easily implemented in a frontend project:
type Layer = {
  id: string;
  name: string;
  url: string;
};

type DataSet = {
  id: string;
  name: string;
  layers: Layer[];
}

Nevertheless, loading 57 COG TIFF files of 10GB each onto Cesium puts a significant strain on performance.
If you could test and implement this loading scenario in a similar js library like OpenLayers, please let me know, and I will try to address this performance issue.

@hongfaqiu thanks for the quick reply!
I'll explore your suggestion
I'll also give gdal_merge  a try - probably pushing the envelope at 500GB ;)
appreciated - thanks!
Michael

500GB! That's a tremendous amount, and if GDAL slices are too large, it poses a significant performance challenge for the frontend.

I presented these ideas to him about half a year ago, but I am unsure if he has continued researching them. 😂

what do you think about a tiled approach like so:

create a GDAL VRT of the GeoTIFF's
run titiler on the VRT
massage TIFFImageryProvider to deal with tiled GeoTIFF's

stupid idea or doable?
edit: it seems this project uses titiler-generated tiles - in this case PNG's but not far off
the titiler documentation says it can generate GTIFF's

I believe your idea is entirely feasible. It only requires a simple modification by transforming the TIFFImageryProvider into a class similar to UrlTemplateImageryProvider.
This modified class can load and render pre-split TIFF tiles using a URL template format like /cog/tiles/{z}/{x}/{y}.tiff.
However, it would be necessary to provide the band information and spatial extent of the TIFF in advance.


[BUG] kubectl get pvc shows previews CAPACITY value after expand volume by UI

Describe the bug
kubectl get pvc shows previews CAPACITY value after expand volume by UI
To Reproduce
Steps to reproduce the behavior:

pod_with_pvc1.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: longhorn-volv-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 5Gi

kubectl get pvc

NAME                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
longhorn-volv-pvc   Bound    pvc-69d31dc1-d59a-48ad-8cfa-def9e1b141ce   5Gi        RWO            longhorn       8m40s

expand volume by UI from 5Gi to 8Gi
kubectl get pvc

NAME                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
longhorn-volv-pvc   Bound    pvc-69d31dc1-d59a-48ad-8cfa-def9e1b141ce   5Gi        RWO            longhorn       8m40s

CAPACITY value is still 5Gi, NOT 8Gi
Expected behavior
kubectl get pvc should show new  CAPACITY value of 8Gi after expand volume by UI from 5Gi to 8Gi.
Environment:

Longhorn version:
Longhorn 1.0.0

Kubernetes version:
Kubernetes v1.15.6

Node OS type and version:
CentOS 7.6 64bit

Unfortunately, IIRC, updating PVC status manually is not allowed in Kubernetes. Hence it's hard for Longhorn to update this field after the expansion.
@smallteeths there should be a warning message for this case, can you help check it?
If you want to avoid this inconsistency, it's better to expand the volume via PVC:
https://longhorn.io/docs/1.0.0/volumes-and-nodes/expansion/#via-pvc

@shuo-wu
Kubernetes v1.15.6， I can just expand volume by UI, but can not via PVC?

You are right. I am sorry for missing your Kubernetes version before putting the link...
Expanding volume via PVC relies on the CSI resizer. And the recommended k8s version is v1.16. Hence Longhorn won't deploy this component for Kubernetes 1.15.


What is this?

Just curious, was poking around your repositories after seeing RTag
What is this?

It's a modular multiplatform framework to make plugins for Minecraft servers and proxies that I code in my free time


[Improvement][Registry] Add ZK authorization yaml control & add digest auth UT

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

Description
add digest UT and small refactor on ZK registry yaml for future authentication support
Are you willing to submit a PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

This issue has been automatically marked as stale because it has not had recent activity for 30 days. It will be closed in next 7 days if no further activity occurs.

remove


Enable TypeScript/JavaScript implementation to be used in a browser

As a front-end developer
I want to use the client API directly from the browser
So that a back-end Node.js server is not required as an intermediary
The key issues are the use of Node packages in the implementation, and some exposure of Node packages in the public API. This includes:

fs (for FileCheckPointer).
crypto (for secure random numbers, hashes, private keys and ed25519 signing).
util (just for convenience).
crypto.KeyObject (in the signers.newPrivateKeySigner() API).

The core of the implementation either is or can be implemented without using any Node-specific packages. A workable approach seems to be to split this core capability out into a separate package, which can be depended on by the fabric-gateway package. The fabric-gateway package will then only contain Node-specific additions, such as the default signer, hash and checkpointer implementations. @noble/hashes should provide secure random and hash implementations required by the core package (for transactioncontext.ts) without any dependency on Node.js.
The alternatives available with the existing implementation are:

Use a Node.js back-end server do interact with Fabric on behalf of the browser using the fabric-gateway API, and the off-line signing flow to enable the browser to handle signing using the signing credentials held there.
Use the Gateway gRPC service directly using the  @hyperledger/fabric-protos package.

I created a prototype implementation by:

Move all the Node client code that can be implemented without using Node standard packages into a node/src/core sub-directory. This required:

Implement a simple alternative to a usage of util.inspect in transactionparser.ts.
Use @noble/hashes/sha256 for SHA-256 hash in signingidentity.ts and transactioncontext.ts.
Use @noble/hashes/utils for randomBytes in transactioncontext.ts.
The few files and index.ts remaining in the top-level node/src import (and export) node/src/core as required.

Add an node/src/core/index.ts file to act as a single entry point to all the pure JavaScript code.
Use esbuild to generate a single bundle.js file from all the content in node/dist/core.

The restructuring of the code seems to be successful but the bundling process highlighted that @grpc/grpc-js itself relies on several built-in Node packages. These can be polyfilled but whether or not it will work with these polyfills is uncertain. A fully browser-compatible (no polyfill) implementation would probably need grpc-web to be used instead of @grpc/grpc-js. This appears at first look to be impractical since:

grpc-web currently does not provide all the required gRPC capability. Bi-directional streaming (used for block eventing) is not supported.
The fabric-gateway API accepts a grpc-js Client object as the gRPC connection to use.

My current thinking is that refactoring the current Node implementation so that it (or parts of it) can be run in a browser environment is impractical. It probably makes sense to make use of the WebCrypto (SubtleCrypto) API, and the digest() function it provides is asynchronous. This would cause a breaking change to the synchronous getDigest() and (to a lesser extend) Hash functions exposed by the Fabric Gateway client API.
Since the primary use case is to modify the off-line signing flow by both generating and signing request messages at the client to avoid the need for the server to generate messages and return them to the client for signing, a more practical approach might be to lift and refactor a subset of the existing code out into a separate browser package. This would include capability to:

Directly build cut-down variants of the Proposal, Transaction, Commit and ChaincodeEventsRequest objects.
The built objects would only provide capability to:

Serialize themselves - equivalent of getBytes().
Return the full message content to be signed - equivalent of getDigest() when the none hash is used to pass back the message unaltered.

An optional addition would be to directly build similar, cut-down variants of the block event request objects: FilteredBlockEventsRequest, BlockEventsRequest and BlockAndPrivateDataEventsRequest.
The fabric-protos package also has a dependency on @grpc/grpc-js since it includes gRPC service stubs. As described in previous comments, @grpc/grpc-js has dependencies on many standard Node packages. It might be necessary to build and package within this browser package a subset of the fabric-protos, including only the ones needed to build the objects described above, and excluding gRPC services. Since the browser environment would only interact with the Fabric Gateway client API indirectly by passing serialised protocol buffer messages, this should not present a compatibility problem, since wire-level interoperability of serialized protocol buffer messages is robust.

Hi! Do you have a status update on this issue? I see your PR has been in draft since April, and I'd love for this feature to be merged

My progress on this stalled, partly due to time commitments and largely due to my lack of experience in developing, packaging and testing bundles for the browser. The people who were interested in this capability also went quiet. With nobody actively looking to make use of it, development took a back seat to other things.
If you (or anyone else) can provide some guidance (or help) on some of the areas I am lacking experience, I would really like to get this done.
I have rebased my working branch on the latest main branch content, and you can find it here. The actual implementation is pretty well complete. If you want to pull down that branch and build the Web bundle with make build-web, you should get web/fabric-gateway-web.js as output. I would be really interested to see if it is usable for you.
You can generate API documentation with make generate-docs-web. You should find content with example code at web/apidocs/index.html.

Ok great, so at first glance here's what I would propose:

The tsconfig.json setup seems pretty standard. Since you're transpiling with ESBuild, some settings (like "declaration": true, for example), won't affect the bundled code. TypeScript is being used more like a linter/typechecker in this case, which is perfectly fine, I would probably even keep these settings in case a different bundler is used in the future. You can see the tsconfig attributes ESBuild inspects here.
In addition to the current setup, I would also suggest enabling noUncheckedIndexedAccess, as well as noImplicitOverride, especially because we're dealing with classes (though I don't see any inheritance being used so it won't really affect the existing code).
How you bundle the code is up to you. I think a single minified file with dependencies included works in a vanilla browser context where we're loading the js in a script tag. I would also suggest bundling for modules (ESM and CJS) for maximum compatibility. In this case, we can omit external dependencies from the final bundle. This will significantly reduce the bundle size and help avoid code redundancy if, say, a dependency is already installed within the project.
The API seems fine from what I could tell. I would have to play around with it to be 100% certain.
This depends on the bundle. For the browser, you would normally serve the minified js file via a CDN of some sort. It looks like this can be done with GitHub Pages, but this seems more like a workaround than an actual solution (but whatever works, right?). The modules can be deployed to the public npm registry, in the same way the node package is being deployed.


upgrade go module to v2

Codecov Report

Merging #523 (ec7cc35) into main (b5f2337) will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##            main    #523   +/-   ##
=====================================
  Coverage   9.34%   9.34%
=====================================
  Files         52      52
  Lines       7277    7277
=====================================
  Hits         680     680
  Misses      6549    6549
  Partials      48      48

Impacted Files
Coverage Δ

app/app.go
85.25% <ø> (ø)

x/alloc/keeper/grpc_query.go
0.00% <ø> (ø)

x/alloc/keeper/keeper.go
71.15% <ø> (ø)

x/alloc/keeper/msg_server.go
100.00% <ø> (ø)

.../alloc/keeper/msg_server_create_vesting_account.go
0.00% <ø> (ø)

x/alloc/keeper/params.go
100.00% <ø> (ø)

x/claim/keeper/claim.go
69.40% <ø> (ø)

x/claim/keeper/genesis.go
87.50% <ø> (ø)

x/claim/keeper/grpc_query.go
0.00% <ø> (ø)

x/claim/keeper/hooks.go
41.93% <ø> (ø)

... and 10 more

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 b5f2337...ec7cc35. Read the comment docs.


Windows and macOS exclude some integration tests

The Windows and macOS builds exclude integration tests that require fetching information via gcloud.  Seems like a shame, since gcloud is installed, we use it in parts of the script, we load credentials, etc.

Closing. We no longer run integration tests on these platforms.


Doc

Documentations as specified in #91 .

There is a failed test case, 01_cmath.t, which was not introduced in this pull request but some changes we made during the past a few days.
For \nappa{f}{a_1, a_2, a_3}
the difference is this line (and the lines alike).
We expected  <XMTok name="f"/> in
  <XMath>
#               <XMApp>
#                 <XMTok meaning="times" role="MULOP"></XMTok>
#                 <XMApp>
#                   <XMTok name="f"/>
#                   <XMDual>
#                     <XMApp>
#                       <XMTok meaning="list"/>
#                       <XMRef idref="S0.Ex1.m1.1"/>
#                       <XMRef idref="S0.Ex1.m1.2"/>
#                       <XMRef idref="S0.Ex1.m1.3"/>
#                     </XMApp>

but we got
<XMTok font="italic" role="UNKNOWN">f</XMTok> in
 <XMath>
#               <XMApp>
#                 <XMTok meaning="times" role="MULOP"></XMTok>
#                 <XMApp>
#                   <XMTok font="italic" role="UNKNOWN">f</XMTok>
#                   <XMDual>
#                     <XMApp>
#                       <XMTok meaning="list"/>
#                       <XMRef idref="S0.Ex1.m1.1"/>
#                       <XMRef idref="S0.Ex1.m1.2"/>
#                       <XMRef idref="S0.Ex1.m1.3"/>
#                     </XMApp>

@kohlhase was this change done on intention? If so, we can just modify the test case, or we might need to investigate more?

@kohlhase was this change done on intention? If so, we can just modify the test case, or we might need to investigate more?

Actually the change is probably introduced from the LaTeXML trunk, Bruce has changed the fonts to math italic some time ago. So just change the test case to the new form.


Adds buttonWidth property to set button widths

Set value of buttonWidth property on Swipeout to control the width of the buttons.

Just made this a suggestion but your solution works. @ryanoboril thanks

but what if the buttons don't have the same width?


feat agent - support vhost user

This PR is for:

Agent

support vhost user
Checklist

[ ] Added unit test.

Backport to branches

main

pr title 格式不对 @yuanchaoa


Update jsdom version

jest currently uses<EMAIL_ADDRESS>which is kinda old and has a few bugs that I'd like fixed.
I'd like to bump the jsdom version to 11.0.0. The API is completely different, but it should be straightforward to migrate since jest doesn't do anything complicated with it.
jsdom@11 doesn't support node v4 though. I think that might be a problem--it looks like jest tries to support node v4: https://github.com/facebook/jest/blob/master/circle.yml#L13

You can fork jest-environment-jsdom and build your own version of it that uses another version of jsdom :) Then use that using testEnvironment.

@flaviut yes, Jest still supports Node 4, that's why we can't really use jsdom@10+. I'll close this issue, but will definitely revisit after we drop Node 4, probably near its EOL which is in a year.

Great, I'll go ahead and do that! Thank you for the suggestion, I didn't know that was possible.

@flaviut how do i use this npm download?