Add Audit Support

This PR adds flexible audit support to gabi. Users wishing to add a different audit backend will need to add a struct which implements the Audit.Write() interface. Currently, only stdout logging is supported, with plans in the future to add CloudWatch audit support.
The audit interface is included in gabi's Env struct, which also houses the DB connection pool and logger for passing to handlers.
2021-07-12T17:15:59.984-0700	INFO	audit/audit.go:22	gabi API audit record	{"Query": "SELECT * FROM company;", "User": "placeholder", "Timestamp":<PHONE_NUMBER>}

[test]


Passing $event for on-event-click is throwing error

I am trying to pass $event for an event click and I am getting the following error "Error: [$injector:unpr] Unknown provider: eventProvider <- event" Am I missing something here? Thanks!
html

js
//Modal Controller
function DialogController(event, drb, $filter, $scope, $mdDialog) {
$log.debug("drb object::", drb);
$log.debug("event:", event);
$scope.drbRequest = drb;
    $scope.hide = function() {
      $mdDialog.hide();
    };

    $scope.cancel = function() {
      $mdDialog.cancel();
    };
  }

  //Modal for event click
  $scope.viewEvent = function(ev, drb) {
    $mdDialog.show({controller: DialogController,
      templateUrl: modalTemplatesFactory.getDrbViewModal(),
      parent: angular.element(document.body),
      clickOutsideToClose: true,
      targetEvent: ev,
      fullscreen: true,
      locals: {drb: drb}
    });
  };

My bad. Figured out the issue.


Removing non-existent storage module from autodocs.

Error was introduced in #941 mistakenly.

Shouldn't we be documenting the "core" stuff somewhere else?

@tseaver Yes we should (JSONConnection as well). Shall I do it here?

Drop them in a new issue, I guess, so we can merge this one and fix the breakage.

Filed #945


Release Google.Cloud.Run.V2 version 2.0.0-beta03

Changes in this release:
New features

Adds gRPC probe support to Cloud Run v2 API client libraries (commit e832ba9)
Adds Cloud Run Jobs v2 API client libraries (commit 85bc403)

Created release for Google.Cloud.Run.V2-2.0.0-beta03


New config

WiP PR for the new config files.
I suggest we add here the best config for uc_10 and uc_50 as a first start.

Before merge: agree on DQN and IQL.
For me, they could be the same as QMix and QVMix in term of epsilon and buffer/batch sizes

Everything seems to be ok for n_comp < 50.
Just some tests to be sure for the 100 param.

Some modif for dqn to come to increase network capacity.
I think we can merge the PR for now?


shuttle::thread_local isn't dropped when threads exit the scheduler

I have a crate that setups up cross-thread channels via thread_local and lazy_static. Shuttle reports a spurious deadlock, however, because it only frees the thread_local value for threads when they actually exit and not when they "exit" the thread scheduler (such as hitting the end of shuttle::check_random(|| { })) - I am using the thread_local Drop impl causing the last sender of a channel to go away to unblock another thread's receiver, so the other thread can exit once there are no more clients. Because thread_locals don't drop, the sender is never removed, and so the receiver is reported as a deadlock, despite this not being possible in normal operations.
I have a manual workaround, where I just RefCell::take() the channel at the end of my shuttle tests in order to manually drop the sender, but it would be nice to not need this (and it took me more than a little while to figure out what exactly was going on and realize the problem, which may hit other people).

Hmm, this is supposed to work — we go to some trouble to run thread-local destructors when a thread finishes, and we have a test for thread-locals dropping at the right time. I'll try to dig into this a bit more. Thanks for the report!

    #[test]
    fn shuttle_issue() {
        use shuttle::sync::*;
        use core::cell::Cell;
        let MU: &'static mut Mutex<usize> = Box::leak(Box::new(Mutex::new(0)));
        shuttle::thread_local! {
            static STASH: Cell<Option<MutexGuard<'_, usize>>> = Cell::new(None);
        }
        shuttle::check_random(|| {
            shuttle::thread::spawn(|| {
                STASH.with(|s| s.set(Some(MU.lock().unwrap())) );
            });
            STASH.with(|s| s.set(Some(MU.lock().unwrap())) );
        }, 100);
    }

is maybe a simpler reproduction of the reported deadlock. The std variant of the same test function doesn't deadlock. Maybe this is out of scope - turns out if you remove the spawn's thread_local then it will actually panic instead!

---- test::test::shuttle_issue stdout ----
thread 'test::test::shuttle_issue' panicked at 'assertion failed: (left != right)
left: Finished,
right: Finished', /home/charlie/.cargo/registry/src/github.com-1ecc6299db9ec823/shuttle-0.4.1/src/runtime/execution.rs:397:17

The Mutex (and channel, in my original example) are both outliving the shuttle scheduler since the static_local and 'static Mutex escape its closure. If shuttle provided its own lazy_static that is re-initialized and dropped by the thread scheduler so the concurrency primitives don't escape this would also probably be less of an issue, though maybe that's just a poor man's version of #81

Actually, you can probably just make an mpsc channel inside the shuttle::check_random scope and hand the receiver to a scoped thread to block on recv, and put the sender in a thread_local. In which case no concurrency primitives have a 'static lifetime or are escaping the closure...

I think #88 will fix this. We weren't running the thread-local destructors for the main thread until the entire test ended. In your example that caused both spurious deadlocks (if the main thread held the lock) and the weird Finished assertion failure (if the main thread tried to drop the lock, which happened after the entire test finished). Thanks for the simple reproducer!


A question about future-rs regarding immutable borrows

I am not sure if that is the right place to ask this question, so feel free to ignore it.
I have created a proof of concept task system before I even knew about future-rs. It is not even remotely polished and I haven't touched it in a while. I had a look at future-rs and I am not sure if it would satisfy my needs.
Let me quickly show how my task system works
fn main() {
    let res: Future<i32> = TASK.submit(move || {
        println!("Before long running task");
        let short_running_task: Future<i32> = TASK.submit(|| 24);
        // Submits a long running task
        let long_running_task: Future<i32> = TASK.submit(|| {
            std::thread::sleep(Duration::from_secs(10));
            return 42;
        });
        // Waits for the short running task to complete, does not block other tasks!
        println!("After short running task {}", short_running_task.await());
        // Waits for the long running task to complete, does not block other tasks!
        println!("After long running task {}", long_running_task.await());
        42
    });

    let v: Vec<Future<()>> = (0 .. 20).map(|i|{
        TASK.submit(move || println!("Another Task {}", i))
    }).collect();

    println!("{}", res.await());
}

which prints
Another Task 2
Another Task 0
Before long running task
Another Task 3
Another Task 5
Another Task 8
Another Task 6
Another Task 17
Another Task 7
Another Task 9
Another Task 1
Another Task 10
Another Task 4
Another Task 13
Another Task 11
Another Task 14
Another Task 12
Another Task 19
Another Task 15
Another Task 16
Another Task 18
After short running task 24
After long running task 42
42

I basically create n-1 local task queues which receives a task, it then wraps that task in a fiber/ coroutine and continuously tries to do some work.
Now I had a very rough look at future-rs. http://alexcrichton.com/futures-rs/src/futures/src/lib.rs.html#260
And you require a 'static lifetime, I think that means that I can basically not have references in my task right?
I am currently designing a Vulkan library and I want to be able to do some work on different threads. To satisfy a 'static would basically mean that I would have to wrap a lot of stuff in Arc. I made also a reddit post recently about this problem.
The thing is, it complicates the library and I don't think it is actually needed. In my head I want to do something like this
let physical_device = ...;
let ref_physical_device = &physical_device;
let future_something: Future<Something> = TASK.submit(move || {
    ref_physical_device.create_something()
};
//Blocks
let something: Something = future_something.await();

The only thing I have to worry about is that the reference lives long enough. But I know that it will live long enough because I am calling await which will block the main thread or reschedule the fiber (otherwise I could call await in the destructor to make sure that it always lives long enough). I haven't currently implemented this because I wanted to see if future-rs might also allow this.

Thanks for the report! I've got some good news for you as well :). There's a large PR right now which removes the 'static bound and enables precisely the use case you've mentioned here, a future with borrowed data that you then call .await() on so you know it doesn't leave the stack frame (e.g. scoped-thread-style).
Other than that it looks like everything would also be possible? Was that your main concern?

That sounds really great, thanks for the update! I think that should address all my worries.


Add SIO FIFO

I think I cleared by my wfe/sev mix-ups. Is this OK now @jannic ?

Yes, looks good.


Fixes incorrect markdown rendering

This PR fixes a problem with the markdown rendering of the map descriptions.
Original issue: #4811.

Please, have a look, @matallo.

Frontend tests were OK :+1: (details)

uhm, maybe I'm missing something?

user
https://cartodb-staging.com/superadmin/users/2489

@matallo: I tried with [test](http://www.cartodb.com) and it worked ¿?

oh! :green_heart: then

Super, thanks for the review!


CUDA 9.2

Hi!
I'm trying to compile pytorch\caffe2 on Jetson TX2.

caffe2 configuring and compilation is failed because of gcc-6 (std::tuple not supported in cuda 9.0, but suported in CUDA 9.2). It suggests to use CUDA_HOST_COMPILER gcc-5.
and I cannot bitbake thud with gcc-5.4 because of too much errors

Are you planning to support CUDA 9.2 in your layer?
How can I bitbake gcc-5.4 rpm to install second gcc on board?
Is there any way to use gcc-5.4 on image compiled with gcc-6?
Thank you!

Thank you for explanation!
As far as I know, poky-thud goes without gcc-5 layer. Where did you get gcc-5 layer to make your test?
Thank you!

I copied them into the distro layer I use for testing from an older OE-Core version (here). You can also try using the meta-linaro-toolchain layer, which maintains older versions of gcc and binutils. I've done that in the past, but found it slightly harder to get that integrated into my builds.

Thank you! That helps!
Good luck in supporting this great layer!


Cannot upload files

The permission for uploading files is missing from requests it seems, that or there is some daemon bug going on.

Not a bug it seems.

This is actually occuring still, seems to happen to me when I am an admin and try to upload a file to a different user's server.

then?


Fix a concurrency issue in fakedns

In rare cases different domains asking for dns will return the same IP, Add a mutex.

Codecov Report

Merging #1666 (28ad957) into master (97f6d8f) will decrease coverage by 0.08%.
The diff coverage is 80.00%.

:exclamation: Current head 28ad957 differs from pull request most recent head f4d7134. Consider uploading reports for the commit f4d7134 to get more accurate results

@@            Coverage Diff             @@
##           master    #1666      +/-   ##
==========================================
- Coverage   39.20%   39.12%   -0.09%
==========================================
  Files         605      597       -8
  Lines       35629    35495     -134
==========================================
- Hits        13970    13887      -83
+ Misses      20098    20060      -38
+ Partials     1561     1548      -13

Impacted Files
Coverage Δ

app/dns/fakedns/fake.go
61.76% <80.00%> (+0.40%)
:arrow_up:

testing/servers/tcp/tcp.go
81.81% <0.00%> (-5.46%)
:arrow_down:

testing/scenarios/common.go
73.07% <0.00%> (-4.62%)
:arrow_down:

transport/internet/udp/hub.go
73.61% <0.00%> (-4.17%)
:arrow_down:

transport/internet/kcp/dialer.go
80.39% <0.00%> (-3.93%)
:arrow_down:

transport/internet/system_listener.go
48.07% <0.00%> (-3.85%)
:arrow_down:

transport/internet/system_dialer.go
46.98% <0.00%> (-2.41%)
:arrow_down:

transport/internet/kcp/connection.go
69.61% <0.00%> (-2.21%)
:arrow_down:

transport/pipe/impl.go
87.87% <0.00%> (-2.03%)
:arrow_down:

transport/internet/kcp/receiving.go
98.65% <0.00%> (-1.35%)
:arrow_down:

... and 9 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 97f6d8f...f4d7134. Read the comment docs.


{Tutorial 1} Muscle 'Show Only' changes the muscle color from blue to red

Steps to reproduce

Load gait2392
Expand muscle list
Right-click on a muscle group and select 'Show Only'

Expected result
Muscles selected are shown only and stay blue
Actual result
Muscles that are shown turn red. They return to the correct color, blue, when you move the motion slider.

Environment and GUI version
Mac, OpenSim e07981e-2018-05-15

Let me explain why that's the case and I'd like to hear your thoughts:

When playing back a motion, muscles are colored from state (blue in this case)
If you do any editing (could be show/hide but could disable muscle or do something more significant) then we switch to whatever arbitrary colors stored with the model since the state could be invalidated.
I think part of the problem is the default red-color that ties in users' minds to activation when in reality it means nothing unless showing results.

Seems like it might be necessary to treat some property edits differently from others. I can see invalidating the state if I edit a GeometryPath, for example, but I wouldn't expect any "collateral damage" if I just show/hide Components because the simulation is not affected by whether or not a geometry/mesh is drawn in the Visualizer.

Similar issue in #859:
Do we agree that muscles should be drawn red when posed? I don't mind, since it reminds the user that it isn't a result of the simulation, but perhaps there is a better way to indicate that while leaving muscle states the same.


[FEATURE] Write Dockerfile

Write Dockerfile for continuous integration in Dockerhub.
What does that feature do?

Create Dockerfile from ubuntu/miniconda
Run tests

Notes

Must integrate with Dockerhub CI.

Started with #29


[BUG] The embedded DHCP server IP is not validated

Describe the bug

https://github.com/harvester/harvester/pull/4960#discussion_r1470915415

It assumes that the serverIP is in same range with next item cidr, is this checked by the webhook?

To use the managed DHCP feature, the user must create an IPPool object before allocating IP addresses for VMs. The user is responsible for defining the embedded DHCP server's IP address in the object in the current implementation (<= v0.1.0). Usually, users don't bother to determine the DHCP server IP address. A UX enhancement is needed here and was tracked in #5045. However, there are no checks against the server IP validation during the IPPool creation nor prompt error reporting by the controller for such cases. The result is a misconfigured agent Pod created, and the embedded DHCP server cannot serve DHCP requests.
For example, with the following out-of-subnet DHCP server IP:
apiVersion: network.harvesterhci.io/v1alpha1
kind: IPPool
metadata:
  namespace: default
  name: test-net
spec:
  ipv4Config:
    serverIP: <IP_ADDRESS>
    cidr: <IP_ADDRESS>/16
    pool:
      start: <IP_ADDRESS>
      end: <IP_ADDRESS>
    router: <IP_ADDRESS>
    leaseTime: 300
  networkName: default/test-net

The IPPool is initialized without any error reported:
$ kubectl get ippools.network.harvesterhci.io test-net
NAME       NETWORK            AVAILABLE   USED   REGISTERED   CACHEREADY   AGENTREADY
test-net   default/test-net   65277       0      True         True         True

However, look into the agent Pod definition:
$ kubectl -n harvester-system get pods default-test-net-agent -o yaml
...
  initContainers:
  - command:
    - /bin/sh
    - -c
    - |2

      #!/usr/bin/env sh
      set -ex

      ip address flush dev eth1
      ip address add <IP_ADDRESS>/16 dev eth1
    image: busybox
    imagePullPolicy: Always
    name: ip-setter
...

The agent Pod is attached to the network but configured with an IP that is not within the subnet.
To Reproduce

Install the vm-dhcp-controller chart
Create an IPPool object with misconfigured .spec.ipv4Config.serverIP
The invalid IPPool object is created without errors, and the corresponding agent Pod is spawned
The embedded DHCP server could not serve any DHCP requests due to the misconfigured IP address

Expected behavior

The webhook should reject any IPPool objects with an invalid server IP defined. Also, the agent Pod should not be spawned in such cases. The controller should report an error on the incident.
Support bundle

N/A
Environment

Harvester ISO version: v1.2.1 (with vm-dhcp-controller v0.1.0)
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630): KVM

Additional context
Add any other context about the problem here.
N/A

BTW, the serverIP, pool start/end, router, exclude should all in same CIRD now.
    serverIP: <IP_ADDRESS>
    cidr: <IP_ADDRESS>/16
    pool:
      start: <IP_ADDRESS>
      end: <IP_ADDRESS>
    router: <IP_ADDRESS>

validation issue:
@starbops I'm seeing a bit of a validation issue with this.
Setting up the expiremental addon via:
╭─mike at suse-workstation-team-harvester in ~/Projects/crop-bushels on main✘✘✘
╰─± kubectl create -f https://raw.githubusercontent.com/harvester/experimental-addons/main/harvester-vm-dhcp-controller/harvester-vm-dhcp-controller.yaml
addon.harvesterhci.io/harvester-vm-dhcp-controller created

And enabling it on Settings -> Addons in v1.3.0-rc3, two node bare metal cluster.
So the loadout like:

╭─mike at suse-workstation-team-harvester in ~/Projects/test-5065
╰─○ kubectl describe network-attachment-definition/test-net
Name:         test-net
Namespace:    default
Labels:       network.harvesterhci.io/clusternetwork=sample
              network.harvesterhci.io/ready=true
              network.harvesterhci.io/type=L2VlanNetwork
              network.harvesterhci.io/vlan-id=30
Annotations:  network.harvesterhci.io/route: {"mode":"manual","cidr":"<IP_ADDRESS>/24","gateway":"<IP_ADDRESS>","connectivity":"true"}
API Version:  k8s.cni.cncf.io/v1
Kind:         NetworkAttachmentDefinition
Metadata:
  Creation Timestamp:  2024-02-23T22:33:37Z
  Finalizers:
    wrangler.cattle.io/harvester-network-nad-controller
    wrangler.cattle.io/harvester-network-manager-nad-controller
  Generation:  1
  Managed Fields:
    API Version:  k8s.cni.cncf.io/v1
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
      f:spec:
        .:
        f:config:
    Manager:      harvester
    Operation:    Update
    Time:         2024-02-23T22:33:37Z
    API Version:  k8s.cni.cncf.io/v1
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          f:network.harvesterhci.io/route:
        f:finalizers:
          .:
          v:"wrangler.cattle.io/harvester-network-manager-nad-controller":
          v:"wrangler.cattle.io/harvester-network-nad-controller":
        f:labels:
          .:
          f:network.harvesterhci.io/clusternetwork:
          f:network.harvesterhci.io/ready:
          f:network.harvesterhci.io/type:
          f:network.harvesterhci.io/vlan-id:
    Manager:         harvester-network-controller
    Operation:       Update
    Time:            2024-02-23T22:33:45Z
  Resource Version:  109386
  UID:               d760c5bf-5fff-44e3-89e8-4e2013d65654
Spec:
  Config:  {"cniVersion":"0.3.1","name":"test-net","type":"bridge","bridge":"sample-br","promiscMode":true,"vlan":30,"ipam":{}}
Events:    <none>
╭─mike at suse-workstation-team-harvester in ~/Projects/test-5065
╰─○ cat ippool.yaml
apiVersion: network.harvesterhci.io/v1alpha1
kind: IPPool
metadata:
  namespace: default
  name: test-net
spec:
  ipv4Config:
    serverIP: <IP_ADDRESS>6
    cidr: <IP_ADDRESS>/24
    pool:
      start: <IP_ADDRESS>
      end: <IP_ADDRESS>
    router: <IP_ADDRESS>
    leaseTime: 300
  networkName: default/test-net

Where spec.ipv4Config.serverIP is outside the scope of the block of IPs on the network.
Gateway IP: <IP_ADDRESS>
Brodcast IP: <IP_ADDRESS>
Subnet Mask: <IP_ADDRESS>
VLAN ID: 30
DHCP Mode: None
VLAN Config of:

apiVersion: network.harvesterhci.io/v1beta1
kind: VlanConfig
metadata:
  annotations:
    network.harvesterhci.io/matched-nodes: '["node6-v130rc3","node5-v130rc3"]'
  creationTimestamp: '2024-02-23T22:31:07Z'
  finalizers:
    - wrangler.cattle.io/harvester-network-vlanconfig-controller
  generation: 1
  labels:
    network.harvesterhci.io/clusternetwork: sample
  managedFields:
    - apiVersion: network.harvesterhci.io/v1beta1
      fieldsType: FieldsV1
      fieldsV1:
        f:spec:
          .: {}
          f:clusterNetwork: {}
          f:uplink:
            .: {}
            f:bondOptions:
              .: {}
              f:miimon: {}
              f:mode: {}
            f:linkAttributes:
              .: {}
              f:txQLen: {}
            f:nics: {}
      manager: harvester
      operation: Update
      time: '2024-02-23T22:31:07Z'
    - apiVersion: network.harvesterhci.io/v1beta1
      fieldsType: FieldsV1
      fieldsV1:
        f:metadata:
          f:finalizers:
            .: {}
            v:"wrangler.cattle.io/harvester-network-vlanconfig-controller": {}
      manager: harvester-network-controller
      operation: Update
      time: '2024-02-23T22:31:07Z'
  name: test-net
  resourceVersion: '106704'
  uid: 0b9a3310-89ec-47d3-8637-8dd96b8071f8
spec:
  clusterNetwork: sample
  uplink:
    bondOptions:
      miimon: -1
      mode: active-backup
    linkAttributes:
      txQLen: -1
    nics:
      - enp11s0

The serverIP set to <IP_ADDRESS>6 is valid and the webhook does not reject it.
╭─mike at suse-workstation-team-harvester in ~/Projects/test-5065
╰─○ kubectl create -f ippool.yaml
ippool.network.harvesterhci.io/test-net created

That IPPool CRD should be rejected, correct?

@irishgordo Thanks for looking into this. We've just bumped the harvester-vm-dhcp-controller add-on today with the defaulting v0.2.1 app version. The default app version for the add-on was v0.1.0 before. The fix was released in v0.2.0, so I guess what you tested did not contain the fix yet. If you still have the environment, you could check the image used for harvester-vm-dhcp-controller Pod to verify if that's the case.
I will update the test plan with more details. Thanks again!

@starbops this looks good testing with variations of:

╭─mike at suse-workstation-team-harvester in ~/Projects/test-5065
╰─○ cat ippool.yaml
apiVersion: network.harvesterhci.io/v1alpha1
kind: IPPool
metadata:
  namespace: default
  name: test-net
spec:
  ipv4Config:
    serverIP: <IP_ADDRESS>6
    cidr: <IP_ADDRESS>/24
    pool:
      start: <IP_ADDRESS>
      end: <IP_ADDRESS>
    router: <IP_ADDRESS>
    leaseTime: 300
  networkName: default/test-net
╭─mike at suse-workstation-team-harvester in ~/Projects/test-5065
╰─○ kubectl create -f ippool.yaml
The IPPool "test-net" is invalid:
* spec.ipv4Config.serverIP: Invalid value: "<IP_ADDRESS>6": spec.ipv4Config.serverIP in body must be of type ipv4: "<IP_ADDRESS>6"
* <nil>: Invalid value: "null": some validation rules were not checked because the object was invalid; correct the existing errors to complete validation
╭─mike at suse-workstation-team-harvester in ~/Projects/test-5065
╰─○ nvim ippool.yaml
╭─mike at suse-workstation-team-harvester in ~/Projects/test-5065
╰─○ kubectl create -f ippool.yaml
error: error validating "ippool.yaml": error validating data: ValidationError(IPPool.spec.ipv4Config.leaseTime): invalid type for io.harvesterhci.network.v1alpha1.IPPool.spec.ipv4Config.leaseTime: got "string", expected "integer"; if you choose to ignore these errors, turn validation off with --validate=false
╭─mike at suse-workstation-team-harvester in ~/Projects/test-5065
╰─○ nvim ippool.yaml
╭─mike at suse-workstation-team-harvester in ~/Projects/test-5065
╰─○ kubectl create -f ippool.yaml
The IPPool "test-net" is invalid:
* spec.ipv4Config.leaseTime: Invalid value: "number": spec.ipv4Config.leaseTime in body must be of type integer: "number"
* spec.ipv4Config.serverIP: Invalid value: "<IP_ADDRESS>6": spec.ipv4Config.serverIP in body must be of type ipv4: "<IP_ADDRESS>6"
* <nil>: Invalid value: "null": some validation rules were not checked because the object was invalid; correct the existing errors to complete validation
╭─mike at

It is now validating the CRD's server IP and other elements.
Due to this not being in rc3, built a 2 node cluster on bare-metal dl160s, testing off of:
 Version: v1.3-7cb8315c-head
I am open to close this out but I did have one last validation question.
If given something like:
apiVersion: network.harvesterhci.io/v1alpha1
kind: IPPool
metadata:
  namespace: default
  name: test-net
spec:
  ipv4Config:
    serverIP: <IP_ADDRESS>
    cidr: <IP_ADDRESS>/24
    pool:
      start: <IP_ADDRESS>
      end: <IP_ADDRESS>
    router: <IP_ADDRESS>
    leaseTime: 300
  networkName: default/test-net

Question: Is it allowed for a User to build an IPPool CRD where the spec.ipv4Config.serverIP 's IPv4 Address is "within" the spec.ipv4Config.pool range?
As I'm not sure if this should be allowed or not allowed - as it will "create" successfully.
But unsure if the "pool"'s start->end is going to be able to juggle having the spec.ipv4Config.serverIP existing within that IP block range

Yes, for the Managed DHCP feature, users can define the embedded DHCP server's IP address in the range of an allocatable pool. For such cases, the IP addresses must be marked as RESERVED in the .status.ipv4.allocated field of the IPPool object. If that's not the case, there might be bugs.

Thanks for the mention @starbops :smile: !
Since it's allowed, the Object still undergoes validation and this looks good :smile: :+1:
I'll go ahead and close this out :smile: :+1: !
However, I've opened up:
https://github.com/harvester/harvester/issues/5273
To track the fact that if a user sets the serverIP address to be within the pool start -> end range, that IP is not set to "allocated" or "excluded" from the IPPool Status ipv4 aallocation list.
The workaround for this would for a user to simply "not" set the serverIP address within the pool's start -> end range, to rather put it outside the range - as perhaps there would be an issue if the VM DHCP Controller tried to assign a VM that IP since it can't recognize that that IP address is the "excluded"

@starbops
Did happen to recently notice this:
https://github.com/harvester/harvester/issues/5299


Any plans for Lumen 5.4 ?

Hi !
How are you ? Hope you are fine !
It appears that we cannot upgrade to Lumen 5.4 because of Landlord's "illuminate/support 5.2.*" dependecy.. Any plans for supporting Lumen 5.4 ?
Thank you

Same for Laravel 5.4

And me also

It was already done. @HipsterJazzbo Needs to force an update to packalyst

Yeah I am using dev-master right now

Just kicked it in the pants. Should be fine now :)


ensure meter(...) helper function is used everywhere in Signer

The meter helper function is currently being used in many places but not everywhere in the signer. For consistency, we should use this function instead of the more verbose metering code that is currently used in places such as https://github.com/celo-org/celo-monorepo/blob/79c6bdbe530cf872de6a63d0567a407172298cc6/packages/phone-number-privacy/signer/src/common/database/wrappers/domainState.ts#L61
It will probably make sense to batch this work with #9795 as much of the old metering code is used in db wrapper functions

Sprint planning:

No changes left, part of same PR

fixed in #9796


Can you make it work with required() instead of import?

Hi @AdrianGzzEsc
Can you provide more details please?

I hope I can close this issue.


DEVX-2301: update repo to conform to install.yml changes

Description
install.yml configuration was updated to rename services to apis
https://wiki.corp.adobe.com/pages/viewpage.action?spaceKey=AdobeCloudPlatform&title=App+Builder+Template+Install+Configuration
How Has This Been Tested?
Updated tests
npm run test
Types of changes

[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[X] I have signed the Adobe Open Source CLA.
[X] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[X] I have read the CONTRIBUTING document.
[X] I have added tests to cover my changes.
[X] All new and existing tests passed.

@roribio See Serhii's comment on the other PR. Shaz is planning on updating templates to use runtime and event in their configurations, so DEVX-2301 is for updating all of template registry ASAP.


Update to latest CoffeeNet parent version 0.30.0

New CoffeeNet parent version 0.30.0 was released! Please check https://github.com/coffeenet/coffeenet-starter/blob/master/CHANGELOG.md for more information

Pull Request Test Coverage Report for Build 176

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 87.778%

Totals

Change from base Build 174:
0.0%

Covered Lines:
158

Relevant Lines:
180

💛  - Coveralls


corrected data units

as per user report #2535, so i corrected data units, i conformed after checking on PowerShell commands.
also taken suggestion @dariomws in PR #2539 .

Docs Build status updates of commit 2fd1b17:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docset/winserver2012r2-ps/netqos/New-NetQosPolicy.md
:white_check_mark:Succeeded
View (winserver2012r2-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


motor 3.4.0 ❄

motor 3.4.0 ❄
Destination channel: Snowflake
Links

PKG-4494
Upstream repository
Upstream changelog/diff

Explanation of changes:

...

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_41rougk65p/clone` failed. (See above for error)
The following problems have been found:
===== ERRORS =====

clone/recipe/meta.yaml:15: missing_build_number: The recipe is missing a build number
===== Final Report: =====
1 Error and 0 Warnings were found


Update service-premium-per-user-faq.yml

PPU license is a limited license, one of the limitations is you cant share data between tenants.
So a dataset from a different tenant (which also uses PPU) can't pull data from a dataflow in a different tenant also using PPU)

@KesemSharabi
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


UITabBarController Disabled After Navigation

I have an issue when navigating and having the UITabBarController being disabled.
When push on a new viewController then popping back, the tabBarController is disabled. It only reenables when you present a modal viewController.
Steps:

Select a tableViewCell
Navigate back
Select the tabBarController
Nothing Happens
Select the top right barButtonItem
Dismiss viewController
TabBarController is reenabled

Attached is a sample project.
HeroSample.zip
Love the Hero framework, keep up the good work!

This is a work around I read.
func navigationController(_ navigationController: UINavigationController, didShow viewController: UIViewController, animated: Bool) {
viewController.tabBarController?.tabBar.layer.removeAllAnimations()
}


Error piecewise when simulating fish spatial example

I just tried the
https://github.com/sbmlteam/sbml-spatial-models/blob/master/Analytic models/fish_300x300.xml
example.
The support for spatial looks great. I especially like the geometry part with the compartments.
When trying to run the simulation I get an error about piecewise (see below)
Simulation setup failed.

Error message: IOError [handle_parser_error:/opt/smelibs/include/dune/copasi/common/pdelab_expression_adapter.hh:35]: Evaluating muParser expression failed:
  Parsed expression:   -1.0*(-0.02*u + piecewise(0.5, 0.5 <= 0.37 - 0.04*v - 0.055*w, 0, true) + piecewise(0.37 - 0.04*v - 0.055*w, and(0 < 0.37 - 0.04*v - 0.055*w, 0.37 - 0.04*v - 0.055*w < 0.5), 0, true)) - 1.0*(-0.025*v + piecewise(0.5, 0.5 <= 0.25 - 0.05*u, 0, true) + piecewise(0.25 - 0.05*u, and(0 < 0.25 - 0.05*u, 0.25 - 0.05*u < 0.5), 0, true)) - 1.0*(-0.06*w + piecewise(0.5, 0.5 <= 0.24 + 0.016*u - 0.03*v, 0, true) + piecewise(0.24 + 0.016*u - 0.03*v, and(0 < 0.24 + 0.016*u - 0.03*v, 0.24 + 0.016*u - 0.03*v < 0.5), 0, true))
  Token:               piecewise
  Error position:      16
  Error code:          16
  Error message:       Unexpected token "piecewise" found at position 16.

Using the compiled linux version on Ubuntu 20.04.
Best M

Sorry, just read your piecewise comment. Just ignore this issue.

Thanks for the report - the latest 1.3.1 release available to download contains #815 so I'll close this issue.

Thanks.


Generalize Reporting & Introduce suite-by-suite HTML Reporting

This introduces and Event Manager similar to ExUnit's.
We can send test information to more than one outputter and keep the outputter processes spinning between test suites. This way the outputters, namely the HTML outputter, can report on a suite-by-suite basis. The Console outputter is adapted (this PR makes it responsible for more of the console output we see).

I'll resolve the failed builds on Travis: not sure why only some fail.

Okay: the release notes for 1.2 write the following under enhancements.

[GenServer] Add GenServer.stop/1 for shutting down servers reliably

Bit late looking at this but I like the approach. Thanks for the contribution :+1:  I'll merge and tag this morning.

@meadsteve: Thanks for updating the README.


Support for additional data ordering formats

This API looks fairly simple to use & convenient but could you consider adding one small convenience feature?
I tried inputting a 4d numpy array and got the following:
Processing /home/cpaxton/.costar/data/2018-04-24-14-19-15_example000001.failure.h5f:   0%| | 0/454 [00:00<?, ?it/s]Traceback (most recent call last):
  File "scripts/make_gif.py", line 78, in <module>
    main(args)
  File "scripts/make_gif.py", line 74, in main
    write_gif(images, gif_filename, fps=10)
  File "/home/cpaxton/.local/lib/python2.7/site-packages/array2gif/core.py", line 361, in write_gif
    check_dataset(dataset)
  File "/home/cpaxton/.local/lib/python2.7/site-packages/array2gif/core.py", line 56, in check_dataset
    check_dataset_shape(dataset)
  File "/home/cpaxton/.local/lib/python2.7/site-packages/array2gif/core.py", line 45, in check_dataset_shape
    raise ValueError('The dataset needs 3 dimensions: rgb, nrows, ncols')
ValueError: The dataset needs 3 dimensions: rgb, nrows, ncols
Exception KeyError: KeyError(<weakref at 0x7fe647f1fd08; to 'tqdm' at 0x7fe6634d8910>,) in <bound method tqdm.__del__ of Processing /home/cpaxton/.costar/data/2018-04-24-14-19-15_example000001.failure.h5f:   0%| | 0/454 [00:00<?, ?it/s]> ignored
cpaxton@babylon:~/catkin_ws/src/costar_plan/ctp_integration$

I then tried a list of 3d numpy arrays with jpeg images decoded into numpy arrays in the standard format output by pillow (PIL) and got the following:
1.failure.h5f:   0%| | 0/453 [00:00<?, ?it/s]Traceback (most recent call last):
  File "scripts/make_gif.py", line 78, in <module>
    main(args)
  File "scripts/make_gif.py", line 74, in main
    write_gif(images, gif_filename, fps=10)
  File "/home/cpaxton/.local/lib/python2.7/site-packages/array2gif/core.py", line 361, in write_gif
    check_dataset(dataset)
  File "/home/cpaxton/.local/lib/python2.7/site-packages/array2gif/core.py", line 71, in check_dataset
    .format(err, i)
ValueError: The dataset's first dimension must have all 3

Here is some code you can use to test if you have two jpegs lying around:

def JpegToNumpy(jpeg):
    stream = io.BytesIO(jpeg)
    im = Image.open(stream)
    return np.asarray(im, dtype=np.uint8)

def ConvertJpegListToNumpy(data, format='numpy'):
    """ Convert a list of binary jpeg files to numpy format.

    # Arguments

    data: a list of binary jpeg images to convert
    format: default 'numpy' returns a 4d numpy array,
        'list' returns a list of 3d numpy arrays
    """
    length = len(data)
    imgs = []
    for raw in data:
        imgs.append(JpegToNumpy(raw))
    if format == 'numpy':
        imgs = np.array(imgs)
    return imgs

Is there any chance you can add support for:

list of 3d numpy arrays in the default pil format (HWC)

4d numpy formats

NHWC (number of images, height, width, channels)

most common way to store images in numpy arrays

NCWH (number of images, channels, height, width)

second most common

Each of those is probably only a couple lines, plus perhaps a data_format parameter.

Thank you! Cool! I just got back from PyCon (which was great) and just noticed this issue, so sorry for the delay.
I will try your code and also look up HWC...and ping back. Always thankful for good input 👍 .

Thank you for your helpful feedback @ahundt! The updated package is now on pypi. For the record, the newer versions of Pillow also have animated gif output (here's a link to their docs on it) but thank you for taking the time on this one. 🎉 🌟

cool, thanks!


Unusually large number of partitions

I was working on some APIs to query data from accumulated-usage-log database. Queries that took seconds to execute took unusually large amount of time after merging with the latest source. Also the logs showed that many requests failed owing to connection time out.
From the logs I could see unusually large number of partition maps being created. I modified the dbserver to see the number of requests that are being sent to the db while running the demo. The latest commit  had 773 requests to the db, while an earlier commit had only 38 requests
Here is the code that I added to the dbserver to count the requests
const debug2 = require('abacus-debug')('request-counter');
let i = 0;
app.use(function(req,res,next) {
        i++;
        debug2('[%s] [%s] %s', i, req.method, req.url);
        next();
});

I was not able to attach the log files here and hence I uploaded it to dropbox. You can find the Logs Here

Queries that took seconds to execute took unusually large amount of time after merging with the latest source.

We saw the same problem with demo client at Travis [1]. We are now taking more than 250 ms to retrieve usage report and agree with you that this needs more investigation.
[1] Github issue #68

Yup seeing the same issue here as well.

One of the issues here lies in the partitioning logic. Specifically when determining the periods from the bounds in a range Operation.
const periods = range(bounds[0], bounds[1] + 1, bounds[1] < bounds[0] ?
        -1 : 1);

Since this logic does a pure +1 or -1 as a step regardless of the period function passed in, db names of 201499, 201498 will happening. It would good to make this logic extendible since limiting it would limit all use of partition to a monthly date range.
This range is used in dbpartitions() inside of dbclient and subsequently pool(). pool() eventually calls the the default dbcons() function(in this case, it's using the default)
const dbcons = (uri, opt, cb) => cb(undefined,
  /:/.test(uri) ? new PouchDB(uri, defaults(opt || {}, {
    ajax: {
      rejectUnauthorized: false
    }
  })) : new PouchDB(uri, defaults(opt || {}, {
    db: memdown
  })));

Calling PouchDb creates the database in this case. So querying the range of [201401, 201501] will create about 100 databases before it tries to do the query.
Since reporting is doing a descending range query of a limit of 1, it should ideally stop once it finds its first record(or if it finds nothing). rangeOp has such logic for doing that
 if(opt.limit && accum.length === opt.limit)
          return rcb(undefined, accum);

However, as shown above. The list of dbhandles is already created, so this line only stops subsequently queries into each database.
There's a couple of things here to consider:

The range creation based upon the bounds from the period

Currently, the range creation is using a simple step of +1 or -1. This results in creating dbhandles for databases with invalid months.
This functionality would need to be extendible to prevent any limitations in the partitioning module

Databases are being created on an allDoc requests.

Databases should probably not be created on a retrieval operation since they would have no data to return in that case

The query itself

The query does a range operation from the month of the time passed to the beginning of the year before the time passed in. Since the time windows will be keep track in a single document up to the previous year, the query starts with the beginning of the last year

1444246062000 would do a query from 201401 to 201510

We might have to understand how far we look in terms of a report. If by chance a report for an organization is asked for 2015-10, would it make sense to return 2014-04 assuming that's the latest usage of that org?

I'm thinking that the second point would solve this current issue, but that we would need to also solve the first issue(since a bulkDocs request could create many databases with invalid months).
Thoughts?

OK, if you want I can look into the issues in the dbclient and partitioning code, specifically:

run the time period range over a set of valid time periods (as 201499 is not a valid period)
not create a DB partition if it doesn't exist and the requested operation is a read

With respect to how far back we want to look for a report? I'm thinking that we could stick to the requested month (and if you had no usage this month then just return 404), but that may deserve a broader discussion. Would you mind posting to cf-dev about that part, so we can continue the discussion there?

Looks like we need to upgrade to a more recent version of PouchDB to leverage the ability to skip the DB creation. Working on it...

We're now using PouchDB 5.0.0. We're still iterating through too many databases but at least they're not created automatically anymore so that should help.

To fix the time period range issue, I'm going to change the period format from YYYYMMDD to 'number of days since time 0' and the epoch format from YYYYMM to 'number of months since time 0 (time 0 new Date(0), basically Jan 1 1970). The db naming function will just convert the epoch back to a YYYYMM db name to keep these names user friendly.

Closing as this is now fixed. I didn't have to change the epoch and db naming after all (keeping it in the format YYYYMM), only changed the time period to a number of days.


BODS-6820 avl-consumer-data-sender

Closed - superseded by https://github.com/Department-for-Transport-Disruptions/bods-integrated-data/pull/388


Issue in getting serial number of BLE device

I am working on a project in which i have to get the readings from device (BLE device). I have two devices BP and BG. I can successfully get the data from the devices using your library. I also want the serial number and the MAC address of both the devices to be fetched but unable to get them. Please help me to get the device serial number and the MAC address.

Hi, iOS api does not allow to get the address. You'd have to implement a characteristic that returns it if you need to have it on iOS.

I was trying to get serial number of device by it's information service with serial number characteristic. I am able to get information service, but it does not contain serial number characteristic.
In android, able to get serial number for the device.
Is there any way to get serial  number from device when service does not contain serial number characteristic?
It's basic requirement for app,  to verify Bluetooth device.

This is not an issue, and it's not related to DFU library, please post your questions at our DevZone instead :)


k_thread_entry_t undefined in in kernel/thread.h if CONFIG_THREAD_MONITOR is enabled

Building with CONFIG_THREAD_MONITOR  fails because k_thread_entry_t is undefined in zephyr/kernel/thread.h.
Maybe <zephyr/sys/arch_interface.h> include is missing ?

Please use our bug template when reporting bugs. You need to edit this issue to include the needed information from https://github.com/zephyrproject-rtos/zephyr/blob/main/.github/ISSUE_TEMPLATE/bug_report.md


Match .NET package dependencies to .NET version

Proposed changes
I'd like to request that the Microsoft.* and System.* package references use 6.x for the .NET 6.0 version of the Deepgram assembly.

Context
There are compatibility issues, in Azure Functions specifically, when bringing in 7.x assemblies, and we've had to avoid upgrading any packages which pull in .NET 7 assemblies. (Commonly, using the newer version of the Extensions.* packages seem to cause problems.)
Possible Implementation
Change .csproj to only reference 6.x assemblies when building for .NET 6.

hey @kirk-marple we'd welcome a PR :)

is this with the V3 or the V2 Nuget packages?

V2 and V3 both have all current features supported(need to go back and refactor to add the changes thindal made), v2 does not have .net7 support in it.

I'll deal with it once the csproj CI/CD PR is merged.

@lukeocodes @ThindalTV Added a PR for this, and a couple cleanup things I noticed.
@CopperBeardy I believe it was for v3 package.  I was still using 2.2.0 and couldn't upgrade to 3.1.0 because we're still using .NET 6.

I believe this issue is resolved now as i see the change was merged in from #124. I'll close if someone can confirm.


Set default Storageclass, rewritten namespace and chart version

Fixes:

https://github.com/kubeshark/kubeshark/issues/1349
https://github.com/kubeshark/kubeshark/issues/1348
https://github.com/kubeshark/kubeshark/issues/1343

I deleted the 00-namespace.yml file because in Helm charts this is usually provisioned by other external means, breaking compatibility with usual tooling. Another option would be to create it depending on a value in values.yaml

The thing is, that the ReadWriteMany setting on the PVC is incompatible with any of the default StorageClasses that I have in my clusters in GKE, EKS nor Rancher... This is a feature not much implemented in the principal Kubernetes providers. I would suggest rewriting the app so as to use some kind of external DB. Otherwise we will need to install NFS servers.

On AWS EKS, EFS with dynamic provisioning would be required for this PV sharing to work. Having all of that in place is rather rare.

Codecov Report
Patch and project coverage have no change.

Comparison is base (2563cc1) 5.02% compared to head (08751ad) 5.02%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@          Coverage Diff           @@
##           master   #1350   +/-   ##
======================================
  Coverage    5.02%   5.02%
======================================
  Files          60      60
  Lines        4335    4335
======================================
  Hits          218     218
  Misses       4106    4106
  Partials       11      11

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

Closing in favor of current HEAD (dfe5605032fa34799a123ef88acd4b35b7d1399e)


Dev fix minor issues

Codecov Report

Merging #242 (077efe7) into master (a0abe98) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #242   +/-   ##
=======================================
  Coverage   89.46%   89.46%
=======================================
  Files          16       16
  Lines         579      579
  Branches      144      144
=======================================
  Hits          518      518
  Misses         55       55
  Partials        6        6

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


[doc] typo in Declaration Merging

Updating https://www.typescriptlang.org/docs/handbook/declaration-merging.html
observable.js should be observable.ts since it includes TypeScript code
export class Observable<T>

and the file is referenced below with // observable.ts stays the same which make it clear that we expect the file to end with .ts

Yeah, I agree - thanks


[Feature] Polling remote

Is there an existing issue for this?

[X] I have searched the existing issues

Is your feature request related to a problem? Please describe.
@rikschennink could you take a look at the following use case. My server does process uploaded files. That results in an extra file per upload, the file with results (think of file converter). How would you recommend to cover this case with FilePond? Output files with results could be in the same FilePond instance, or next to it in a separate one. The both input/output could be matched by the same file name but different extension. It appears this is a polling use case (think of long processing in the background). Currently it is not clear how to refresh components and display generated files with results in SPA.
Describe the solution you'd like
Polling data from remote.
Describe alternatives you've considered
WebSockets

I think you'd have one FilePond uploading and another instance showing results ("local" files) the polling part I would build outside of FilePond and then update the files property.


Rename const_generics feature gate to adt_const_params

Fixes #328

Hmm, it seems Travis CI for this repo has been turned off: https://app.travis-ci.com/github/rust-lang/packed_simd
It's time to migrate to GHA :)

Any chance for merging this? 😉

If packed_simd is failing in an upstream crate or any other dependency you can't change, add this to your Cargo.toml
[patch.crates-io]
packed_simd = { git = "https://github.com/JohnTitor/packed_simd", branch = "rename-const-generics-feature-gate", package = "packed_simd_2" }

This project is effectively retired, so I'm not sure what we want to do about CI.  @workingjubilee?

Once more for old time's sake, I suppose.

Published this version as a point release: 0.3.6
Yes, Travis CI has broken for basically everything.
I will review a PR that changes it over.


NoMethodError: undefined method retry?' for {"N-<oe"=>""}:Hash

Using Rantly 1.1.0, and ruby 2.4.1p111, I tried a simple test that would fail:
require 'rantly/shrinks'
require 'rantly/rspec_extensions'

describe "Test" do
  it "fails" do
     property_of {
       dict { [string, string] }
     }.check { |i|
       expect(i).to be_a(Integer)
     }
  end
end

will give me the output:

failure: 0 tests, on:
{"?A11+I"=>"\\=>B{A",
 "6xpu|C"=>".\\T7^k",
 "!Jo/Ly"=>"G'j-Q`",
 "WuEo5C"=>"px p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 0:
{"?A11+I"=>"\\=>B{A",
 "6xpu|C"=>".\\T7^k",
 "!Jo/Ly"=>"G'j-Q`",
 "WuEo5C"=>"px p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 1:
{"?A11+I"=>"\\=B{A",
 "6xpu|C"=>".\\T7^k",
 "!Jo/Ly"=>"G'j-Q`",
 "WuEo5C"=>"px p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 2:
{"?A11+I"=>"\\=B{",
 "6xpu|C"=>".\\T7^k",
 "!Jo/Ly"=>"G'j-Q`",
 "WuEo5C"=>"px p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 3:
{"?A11+I"=>"\\={",
 "6xpu|C"=>".\\T7^k",
 "!Jo/Ly"=>"G'j-Q`",
 "WuEo5C"=>"px p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 4:
{"?A11+I"=>"\\=",
 "6xpu|C"=>".\\T7^k",
 "!Jo/Ly"=>"G'j-Q`",
 "WuEo5C"=>"px p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 5:
{"?A11+I"=>"\\",
 "6xpu|C"=>".\\T7^k",
 "!Jo/Ly"=>"G'j-Q`",
 "WuEo5C"=>"px p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 6:
{"?A11+I"=>"",
 "6xpu|C"=>".\\T7^k",
 "!Jo/Ly"=>"G'j-Q`",
 "WuEo5C"=>"px p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 7:
{"?A11+I"=>"",
 "6xpu|C"=>"\\T7^k",
 "!Jo/Ly"=>"G'j-Q`",
 "WuEo5C"=>"px p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 8:
{"?A11+I"=>"",
 "6xpu|C"=>"\\T7k",
 "!Jo/Ly"=>"G'j-Q`",
 "WuEo5C"=>"px p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 9:
{"?A11+I"=>"",
 "6xpu|C"=>"T7k",
 "!Jo/Ly"=>"G'j-Q`",
 "WuEo5C"=>"px p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 10:
{"?A11+I"=>"",
 "6xpu|C"=>"Tk",
 "!Jo/Ly"=>"G'j-Q`",
 "WuEo5C"=>"px p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 11:
{"?A11+I"=>"",
 "6xpu|C"=>"k",
 "!Jo/Ly"=>"G'j-Q`",
 "WuEo5C"=>"px p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 12:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"G'j-Q`",
 "WuEo5C"=>"px p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 13:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"G'-Q`",
 "WuEo5C"=>"px p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 14:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"G'-Q",
 "WuEo5C"=>"px p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 15:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"G'Q",
 "WuEo5C"=>"px p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 16:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"'Q",
 "WuEo5C"=>"px p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 17:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"'",
 "WuEo5C"=>"px p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 18:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"",
 "WuEo5C"=>"px p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 19:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"",
 "WuEo5C"=>"p p-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 20:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"",
 "WuEo5C"=>"pp-c",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 21:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"",
 "WuEo5C"=>"pp-",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 22:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"",
 "WuEo5C"=>"p-",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 23:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"",
 "WuEo5C"=>"-",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 24:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"",
 "WuEo5C"=>"",
 ".]uXT8"=>"X\"G~NZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 25:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"",
 "WuEo5C"=>"",
 ".]uXT8"=>"X\"GNZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 26:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"",
 "WuEo5C"=>"",
 ".]uXT8"=>"\"GNZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 27:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"",
 "WuEo5C"=>"",
 ".]uXT8"=>"\"GZ",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 28:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"",
 "WuEo5C"=>"",
 ".]uXT8"=>"\"Z",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 29:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"",
 "WuEo5C"=>"",
 ".]uXT8"=>"\"",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 30:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"",
 "WuEo5C"=>"",
 ".]uXT8"=>"",
 "rg\\K$h"=>"|n3!]W"}
Shrinking at depth 31:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"",
 "WuEo5C"=>"",
 ".]uXT8"=>"",
 "rg\\K$h"=>"n3!]W"}
Shrinking at depth 32:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"",
 "WuEo5C"=>"",
 ".]uXT8"=>"",
 "rg\\K$h"=>"n!]W"}
Shrinking at depth 33:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"",
 "WuEo5C"=>"",
 ".]uXT8"=>"",
 "rg\\K$h"=>"n]W"}
Shrinking at depth 34:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"",
 "WuEo5C"=>"",
 ".]uXT8"=>"",
 "rg\\K$h"=>"nW"}
Shrinking at depth 35:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"",
 "WuEo5C"=>"",
 ".]uXT8"=>"",
 "rg\\K$h"=>"W"}
Shrinking at depth 36:
{"?A11+I"=>"",
 "6xpu|C"=>"",
 "!Jo/Ly"=>"",
 "WuEo5C"=>"",
 ".]uXT8"=>"",
 "rg\\K$h"=>""}
Shrinking at depth 37:
{"6xpu|C"=>"", "!Jo/Ly"=>"", "WuEo5C"=>"", ".]uXT8"=>"", "rg\\K$h"=>""}
Shrinking at depth 38:
{"!Jo/Ly"=>"", "WuEo5C"=>"", ".]uXT8"=>"", "rg\\K$h"=>""}
Shrinking at depth 39:
{"WuEo5C"=>"", ".]uXT8"=>"", "rg\\K$h"=>""}
Shrinking at depth 40:
{".]uXT8"=>"", "rg\\K$h"=>""}
Shrinking at depth 41:
{"rg\\K$h"=>""}
Shrinking at depth 42:
{}
F

Failures:

  1) Reports that only have new_service events integer property only returns Integer type
     Failure/Error:
       property_of {
         dict { [string, string] }
       }.check { |i|
         expect(i).to be_a(Integer)
       }

     NoMethodError:
       undefined method `retry?' for {"rg\\K$h"=>""}:Hash
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:79:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:73:in `rescue in shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:69:in `shrinkify'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:50:in `rescue in check'
     # /home/mauricio/.rvm/gems/ruby-2.4.1/gems/rantly-1.1.0/lib/rantly/property.rb:30:in `check'
     # ./spec/properties/new_service_spec.rb:9:in `block (2 levels) in <top (required)>'
     # ------------------
     # --- Caused by: ---
     #   expected {"?A11+I"=>"\\=>B{A", "6xpu|C"=>".\\T7^k", "!Jo/Ly"=>"G'j-Q`", "WuEo5C"=>"px p-c", ".]uXT8"=>"X\"G~NZ", "rg\\K$h"=>"|n3!]W"} to be a kind of Integer
     #   ./spec/properties/new_service_spec.rb:10:in `block (3 levels) in <top (required)>'

Finished in 0.03759 seconds (files took 0.10705 seconds to load)
1 example, 1 failure

Thanks for reporting it @mauricioszabo :bouquet: I am on it! :wink:

@Ana06 I have added you as an owner using your GitHub email<EMAIL_ADDRESS>Great job as current maintainer! :tada:

Thanks @abargnesi! :cupid:

@mauricioszabo new version released! It should work now :wink:


Added Most Asked Queries

@greg-lindsay Would you be able to review this PR that is contributed by the community? Thanks.

@greg-lindsay Any updates with the PR? Thanks.

I recommend closing this PR. The contributor is suggesting a non-Microsoft page, not even belonging to a Microsoft partner. As a matter of fact, this is self promotion, which Microsoft will not accept at all.

@rahulkumarsingh73690 As mentioned by @illfated , third party links outside the Microsoft domains are not referenced within the docs.
Thank you for taking the time to contribute to docs, any other contributions are always welcome.

@officedocsbot close


adds missing write.wait_for_active_shard default val documentation

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@bf0aba9). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #6023   +/-   ##
=========================================
  Coverage          ?   83.07%
  Complexity        ?    12433
=========================================
  Files             ?     1436
  Lines             ?    47036
  Branches          ?     5782
=========================================
  Hits              ?    39074
  Misses            ?     5265
  Partials          ?     2697

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 bf0aba9...3498442. Read the comment docs.

@mikethebeer yep we agreed to do that.


Cypress tests for new PDF generator

In #861 I took a mental note that automatic PDF generation might not work after my (extensive) changes. Sadly, PDF crashes immediately, but no cypress test ever alerted me of that fact.

We need automatic tests for this PDF (preview mode) in cypress, including:

[ ] Mocking the pdfFormat API response with different results
[x] Asserting that all the filled-in data is present and visible (look at summary.ts for inspiration)
[x] With/without custom PDF layout/automatic PDF layout
[ ] With different hidden components in excludeFromPdf (also inside repeating groups)

@bjosttveit I thought of this, in relation to the new Percy tests.. Right now I've restructured so that all-process-steps.ts is the only test setting the cookie to generate PDFs on the frontend-test app. And, it tests that the files are present in the receipt. What if we download those files, identify which process step each of them are for, display them in the browser (using pdf.js if Cypress isn't able to) and perform a snapshot so that Percy can notify us if there's differences?
To achieve this, I think we'll need:

A way to make the frontend-test load the frontend js/css from the correct location, even inside the PDF service container. Possibly by forwarding a cookie, and using that in Index.cshtml? 🤔 Would only need to work for that app, not every app.
Some way to block out the selected date and other generated infomation in the PDF (i.e. by injecting percy.css for that app when running in the PDF service?)

What do you think? I think that would help to get some test coverage for these generated PDFs.

Sounds good to me!

Update:
We have decent test coverage for PDF now in cypress and percy, testing that the data is present, that expressions/dynamics hides the correct fields, that pages are excluded, as well as visual tests in percy that simulates the PDF format (using viewport size and print media emulation).
We do not however have any coverage for the PDF-file itself, only tests for the content used to generate the PDF. There is not much coverage for the pdfFormat API nor the excludedComponents setting either.


Fixes for fluent bootstrap design

Todo:
-spacing between projects
-adding of the people section

re adding of anchors
-testing

Thanks, Dom! You're awesome. I'll do some testing this afternoon.


code style : update remaining files

Updated the remaining files that were specified in issue #600 . The below files are false positives to the command which was ran by @williballenthin .
capa/main.py:                                        parser.add_argument("--version", action="version", version="%(prog)s {:s}".format(capa.version.__version__))
scripts/setup-linter-dependencies.py:   logging.basicConfig(level=logging.INFO, format="%(asctime)s [%(levelname)s] %(message)s")
capa/ida/plugin/form.py:                      "Failed to load capa rules from %s" % settings.user[CAPA_SETTINGS_RULE_PATH]
capa/ida/plugin/form.py:                      "formatted capa rules. You can download and extract the official rules from %s. "
capa/ida/plugin/form.py                       f"{results.meta.timestamp.strftime('%Y-%m-%d at %H:%M:%S')}.\n"
capa/main.py:                                        "successfully loaded %s rules",
capa/main.py:                                        "Please ensure you're using the rules that correspond to your major version of capa (%s)",
capa/main.py:                                        "Or, for more details, see the rule set documentation here: %s",
capa/features/extractors/strings.py:      ASCII_BYTE = r"<EMAIL_ADDRESS>tests/fixtures.py:                                     ("773290...", "function=0x140001140", capa.features.common.String(r"%s:\\OfficePackagesForWDAG"), True),

Also there were some byte string that were present in the command :
capa/features/extractors/strings.py:ASCII_RE_4 = re.compile(b"([%s]{%d,})" % (ASCII_BYTE, 4))
capa/features/extractors/strings.py:UNICODE_RE_4 = re.compile(b"((?:[%s]\x00){%d,})" % (ASCII_BYTE, 4))
capa/features/extractors/strings.py:        reg = b"([%s]{%d,})" % (ASCII_BYTE, n)
capa/features/extractors/strings.py:        reg = b"((?:[%s]\x00){%d,})" % (ASCII_BYTE, n)

At capa/features/insn.py: and at capa/helpers.py: hex(x :int) -> str: is defined which is also a builtin function. There are some files that contain the use of .format() for strings. They were not a part of the output so should they be changed?
Checklist

[x] No CHANGELOG update needed

[x] No new tests needed

[x] No documentation update needed

would you please address the CI failure here: https://github.com/mandiant/capa/actions/runs/4374215130/jobs/7653361589

@williballenthin made the required changes and fixed the CI issue

@mr-tz would you take a pass next?

Great, I'll do some manual tests and then we should be good to merge.

I've done minor manual checks. We should be good here.


Durability mechanism

It would appear that the durability mechanism isn't working as intended, as it isn't adjusting the durability.
debug -r
https://one.denizenscript.com/paste/54858

Mechanism works fine. You don't know how adjusting items works. Ask for help on Discord, will explain there.


Update to use Objective-C generics

This provides some advantages when using ORSSerialPort from Objective-C, but is particularly good for Swift integration. It should wait for release in master until Xcode 7.0 is no longer in beta, unless the feature can be conditionally compiled as is being done with nullability annotations.

It seems that __has_feature(objc_generics) can be used to check for generics support.

Upon further investigation, this should actually wait until Xcode 7.0 final is released but can be made backwards compatible using __has_feature(objc_generics).


Text-input memory/element leak?

Hi Nikgraf,
Cool branch off! One note - there might be a memory/element leak somewhere. I noticed that after typing in the demo textbox (http://nikgraf.github.io/belle/#text-input) my browser tends to go ballistic and adds hundreds of new DOM elements on key keystroke, which brings it to a halt and introduces a lengthy lag between keydown and character appearing on the screen. After a few lines document.getElementsByTagName('*') reporting 20,000 elements (vs 300 at the start).
I didn't have a chance to investigate whether the problem is with the textbox itself or the page wrapping or any external change listeners.

@eugene1g thanks a lot for the feedback. Which browser do you use? I can't reproduce it :(

Chrome42 - the screenshot is attached you can see node count (the blue line) jiggling up and down hitting 300k and then going back.
All I did was type in "one two three four five six seven eight nine ten eleven twelve"

@eugene1g This screenshot was worth gold. Thanks :smile:
I did a bit of testing & now believe it's an issue of the valueLink functionality. Could you confirm?
Providing a defaultValue for the TextInput (new lines not allowed) results in this:

With new lines allowed you can see little spike which I believe are due the height calculation. The number of total nodes rised, but only by a handful.

I tried valueLink first with a plain textarea & then with an input of type text and it resulted in a similar memory behaviour:
<input type="text" valueLink={ this.linkState('value') } />

<textarea valueLink={ this.linkState('value') } placeholder="Just fill in whatever you like :)" />

Perfect fix - no more leaks!

People still have issues here: https://www.reddit.com/r/reactjs/comments/3dh9k0/introducing_belle_100_easy_to_style_react/ct596fp

Ya I just checked it there...

I saw that in general controlled components in our docs are slowing down as we type more. But I came across this fiddle with controlled input and textarea components really fast: http://jsfiddle.net/f1v1fac1/
As I copied the same components in our docs, they also became slow, interesting :)

Finding: in docs we are using highlightJs for highlighting the code. When we type a lot in controlled  render is called multiple times and these code blocks are rendered again and again, this is adding crazy number of elements to dom and slowing down the page.

Solved with https://github.com/nikgraf/belle/pull/129
Really good find @jpuri


OS X Private notification missing

Hello
I am using both on iPhone Gitify, and OS X and none of my devices receive the private notifications!
http://prntscr.com/foh319
Looking forward for a quick reply to this. Since both Private repos or public should have notifications.

Hello @uhlhosting! Are your repositories part of an organization? If so, did you try this?

@manosim that link worked for me. Perhaps we can add that to the readme as it's not quite clear...

Also recommend closing stale issues such as tis. 😸


Setting Up Migration

Expected Behavior
I run
use migration::{Migrator, MigratorTrait};

let connection = sea_orm::Database::connect(&database_url).await?;
Migrator::up(&connection, None).await?;

I expected that at the end of the app the DB would close.
Actual Behavior
Db does not close at the end of the app and still has .shm and .wal files.
I had this problem trying to copy the Db after the migration ended.

Hey @zbinhazzaa, thanks for the report! This has to do with the underlying database connector: SQLx.
Related Issues:

https://github.com/launchbadge/sqlx/issues/1760
https://github.com/launchbadge/sqlx/issues/272

I think at SeaORM we could introduce an async close method to close the connection.

https://docs.rs/sea-orm/latest/sea_orm/entity/prelude/enum.DatabaseConnection.html#method.close


Replace is_valid_signature with assert_valid_signature

Fixes #327
This PR removes the is_valid_signature method on the Account and replaces it with assert_valid_signature to make the API more intuitive. It introduces breaking changes (is_valid_signature no longer exists ^^).
For rationale behind this PR, see #327 :)

Question: since Argent have their own impl of Account, should I submit a similar PR on Argent's repo?
pinging @juniset

As discussed in #327 I don't think we should merge that PR.


Wrong CUDA buffer size used in addsub.cu AllocateCudaBuffers() when reading payloads

Description
As the addsub.cu code works with an individual payload, it calculates sizes of the payload to allocate appropriately-sized CUDA buffers as follows:

batch1_element_count
this is the number of elements in the first input tensor, based on its shape. A [5] would have 5 elements, a [2, 5] would have 10 elements, and a [3, 2, 5] would have 30 elements, and so on.

batch1_byte_size
this is the number of elements multiplied by the number of bytes in the tensor's data type. A FP32 tensor would have its number of elements multiplied by 4, since there's 4 bytes in an FP32 value.

batchn_element_count
this is the total number of elements for all inputs and outputs in the payload, calculated from the payload.batch_size attribute times the number of elements in the first input's tensor. The assumption that all inputs and outputs have the same dimensions, is enforced earlier.

batchn_byte_size
this is the total number of bytes for all payload tensors, again, multiplying by bytes in the datatype.

The AllocateCudaBuffers() function is called with the batchn_byte_size, that is, the total amount of memory needed for all inputs and outputs in the payload.
However, in that function, the byte_size argument is treated as the size for each input and output buffer when used with cudaMalloc(), rather than as the total size for the entire payload:
  err = AllocateCudaBuffers(batch_byte_size);

...etc...

int AllocateCudaBuffers(size_t byte_size) {
  cuerr = cudaMalloc(&cuda_input0_, byte_size); // entire payload
  ...
  cuerr = cudaMalloc(&cuda_input1_, byte_size); // entire payload

Triton Information
Triton 20.03 container
Expected behavior
The AllocateCudaBuffers should be called with batch1_byte_size - the number of bytes in a single tensor - as the argument, and the cuda_buffer_byte_size_ should be set to batchn_byte_size upon a successful return, or via a calculation in AllocateCudaBuffers() based on the number of buffers allocated. It may also be useful to pass the batch_cnt value, to make adapting this code to different numbers of inputs and/or outputs more straightforward.
One might ask, "what difference does this sample code make?" Sample code is used to inform, or form the basis of, the development of useful production code. The addsub backend uses 3x more CUDA memory than it should, and that doesn't scale well.

The main purpose of the provided custom backends is to provide guidance on how one may create customized utilities that is recognized by Triton via the custom interface. That being said, I agree that in general the sample code should be concise and efficient, and we will improve it when the inefficiency is found.
Going back to the addsub example, note that the batch1_element_count is actually the element count for one input, and thus the byte_size passed to AllocateCudaBuffers() is the size required to hold one input of the payload. AllocateCudaBuffers() exploits the knowledge that all inputs and outputs must have the same shape (and element count).

Yes, batch1_element_count is the element count for one input, but that's not what's passed to AllocateCudaBuffers(), the batchn_byte_size, is. So each input and the output is allocated enough CUDA memory to hold all of the elements.
https://github.com/NVIDIA/triton-inference-server/blob/81ab4584b4603bb6fd50d47cf312f8a6257d33e7/src/custom/addsub/addsub.cu#L612

I made mistake on my previous comment, but the idea is still the same. A payload can be a batch with variable batch size (from 1 to max_batch_size), so the batchn_byte_size is the size needed to hold one I/O for the payload. I still don't see why it will allocate extra CUDA memory than it should, perhaps you can provide a concrete example?

A single addsub.cu payload consists of two input and two output tensors. The first payload is checked to insure that it only has two inputs:
https://github.com/NVIDIA/triton-inference-server/blob/81ab4584b4603bb6fd50d47cf312f8a6257d33e7/src/custom/addsub/addsub.cu#L401
The batch1_byte_size is set to the size of a single input tensor, by first determining the shape of the first payload's first input tensor:
https://github.com/NVIDIA/triton-inference-server/blob/81ab4584b4603bb6fd50d47cf312f8a6257d33e7/src/custom/addsub/addsub.cu#L585-L587
... then getting the number of elements in a tensor of that shape:
https://github.com/NVIDIA/triton-inference-server/blob/81ab4584b4603bb6fd50d47cf312f8a6257d33e7/src/custom/addsub/addsub.cu#L595
... and then multiplying it by the size of the datatype:
https://github.com/NVIDIA/triton-inference-server/blob/81ab4584b4603bb6fd50d47cf312f8a6257d33e7/src/custom/addsub/addsub.cu#L596-L597
Then starting with the first payload and looping over subsequent payloads...
https://github.com/NVIDIA/triton-inference-server/blob/81ab4584b4603bb6fd50d47cf312f8a6257d33e7/src/custom/addsub/addsub.cu#L600-L601
... the batchn_byte_size is set to the total number of batches in the current payload times the size of the first payload's first input tensor:
https://github.com/NVIDIA/triton-inference-server/blob/81ab4584b4603bb6fd50d47cf312f8a6257d33e7/src/custom/addsub/addsub.cu#L605-L607
I am assuming that payload.batch_cnt is the number of input and output tensors in the payload, is that correct? The docs are a bit vague. I assume that for addsub.cu we can expect that the payload.batch_cnt would be four, two for the input tensors and two for the output tensors. I may be incorrect, and this may be the crux of a misunderstanding.
So now that we have the batchn_byte_size set to the number of bytes needed for all four tensors used by addsub. the AllocateCudaBuffers() is called with that value:
https://github.com/NVIDIA/triton-inference-server/blob/81ab4584b4603bb6fd50d47cf312f8a6257d33e7/src/custom/addsub/addsub.cu#L612
However, in that function, each of the two inputs and the one output buffer is allocated the number of bytes needed for all four tensors in the payload (batchn_byte_size, passed to the function), rather than the number of bytes needed for one input or output:
https://github.com/NVIDIA/triton-inference-server/blob/81ab4584b4603bb6fd50d47cf312f8a6257d33e7/src/custom/addsub/addsub.cu#L198-L210
Am I understanding this correctly? If so, the cuda_input0_, cuda_input1_, and cuda_output_ should be allocated batch1_byte_size, rather than batchn_byte_size, rather than four tensors' worth of space.
Or does the batch_cnt indicate perhaps more than one set of four input and output tensors in the payload? I don't think so, because payload.input_cnt is confirmed as 2, yes?

Correction - the payload does not contain any outputs, so I'm left wondering what does batch_size represent for the payload? The total number of payloads? The model's current or maximum batch size?

Batch size is not the number of I/O tensors. The batch size of one payload can be considered as the number of samples in the payload. At the minimum, a model can process a sample and produce proper outputs for the sample. And often a model can process multiple samples within the same execution, thus there is the notion of maximum batch size, the maximum number of samples that the model can process in one execution.

Ok, so when the model's config.pbtxt is set to a batch size of 32, you could have up to 32 input tensors in each of cuda_input0_ and cuda_input1_, for each payload, it would appear, and then you operate on all of those as a unit. Thanks for the clarification, let me see if I can untangle my understanding of the code.


Clicking 'Upload' doesn't do anything in Upload dialog with 'Use AzCopy for Improved Blob Upload and Download' checked

Storage Explorer Version: 1.5.0
Platform/OS Version: Windows 10/ Linux Ubuntu 16.04/ MacOS High Sierra
Architecture: ia32/x64
Build Number: 20180926.5
Commit: d6717c99
Regression From: Not a regression
Steps to Reproduce:

Navigate to 'Experimental' menu -> Check 'Use AzCopy for Improved Upload and Download'.
Open one blob container then open Upload dialog -> Select a blob to upload.
Check the result after clicking 'Upload' button in Upload dialog.

Expected Experience:
Succeed to upload the selected blob after clicking 'Upload' button .
Actual Experience:
It doesn't do anything after clicking 'Upload' button.

I believe this was due to a build issue. Please try again with 20180927.3.


V6 compatibility

The FOSElasticaBundle v6 has a lot of BC breaks so in order to support it, we need to drop support for v5 and fix some BC issues.

Hello,
Do you think it will merge?

@makasim ping :)


gc_worker: Change log about gc failure to warn level

Signed-off-by: MyonKeminta<EMAIL_ADDRESS>
What problem does this PR solve?
Issue Number: Fixes #8294
Problem Summary:
Distributed GC may print some annoying error logs about GC failures, but in most cases these are not errors. This PR changes the log level to warn.
Related changes

Need to cherry-pick to the release branch

release-4.0, release-3.1, release-3.0

Check List
Tests

No code

Side effects
Release note

No release note

/merge


Added: React Vector Icons, Maps and Location, Updated: Main Page

Added: react-native-maps, react-native-location and react-native-vector-icons to create the map function in main page.

@fernandovfilho you can change value to @strings/google_maps_api_key

I will update my master with the current changes to avoid conflicts and open another PR.


JOSS review: Recommend adding coverage to toml file

I added this to check test coverage. I would recommend adding this since it will be useful as package gets more users, contributors.
https://github.com/openjournals/joss-reviews/issues/4588

Do you mean to add this package as a dependency?

That is correct. Given that pytest is one of the dependencies in the toml file. It would make sense to add this as well as a means to check coverage of tests.

@kanishkan91 thanks a lot for this suggestion! coverage works great and I agree that it can be very helpful (and good to know for potential users/contributors).
I've added the package as a development dependency (changes are on the develop branch) and compiled the following report:

Name                                   Stmts   Miss  Cover
----------------------------------------------------------
floodlight\__init__.py                     8      0   100%
floodlight\core\__init__.py                0      0   100%
floodlight\core\code.py                   55      2    96%
floodlight\core\definitions.py             4      0   100%
floodlight\core\events.py                156     14    91%
floodlight\core\pitch.py                  95      6    94%
floodlight\core\property.py               33     10    70%
floodlight\core\xy.py                     91      2    98%
floodlight\io\__init__.py                  0      0   100%
floodlight\io\datasets.py                186    148    20%
floodlight\io\statsbomb.py                94     86     9%
floodlight\io\utils.py                    17      3    82%
floodlight\metrics\__init__.py             0      0   100%
floodlight\metrics\entropy.py             24      3    88%
floodlight\models\__init__.py              0      0   100%
floodlight\models\base.py                 26      0   100%
floodlight\models\geometry.py             53      3    94%
floodlight\models\kinematics.py           65     12    82%
floodlight\models\kinetics.py            103      0   100%
floodlight\settings.py                     4      0   100%
floodlight\transforms\__init__.py          0      0   100%
floodlight\transforms\filter.py           49      0   100%
floodlight\utils\__init__.py               0      0   100%
floodlight\utils\types.py                  4      0   100%
floodlight\vis\__init__.py                 0      0   100%
floodlight\vis\pitches.py                170      6    96%
floodlight\vis\positions.py               22      2    91%
floodlight\vis\utils.py                   11      0   100%
tests\__init__.py                          0      0   100%
tests\test_core\__init__.py                0      0   100%
tests\test_core\conftest.py              108      0   100%
tests\test_core\test_code.py              44      0   100%
tests\test_core\test_definitions.py       24      0   100%
tests\test_core\test_events.py           234      1    99%
tests\test_core\test_pitch.py            166      0   100%
tests\test_core\test_xy.py               157      0   100%
tests\test_io\__init__.py                  0      0   100%
tests\test_io\conftest.py                 10      0   100%
tests\test_io\test_datasets.py             7      0   100%
tests\test_io\test_utils.py               10      0   100%
tests\test_metrics\__init__.py             0      0   100%
tests\test_metrics\test_apen.py           31      0   100%
tests\test_models\__init__.py              0      0   100%
tests\test_models\conftest.py             35      0   100%
tests\test_models\test_base.py            58      0   100%
tests\test_models\test_geometry.py        43      0   100%
tests\test_models\test_kinematics.py      73      0   100%
tests\test_models\test_kinetics.py        86      0   100%
tests\test_transforms\__init__.py          0      0   100%
tests\test_transforms\conftest.py         39      0   100%
tests\test_transforms\test_filter.py      89      0   100%
tests\test_vis\__init__.py                 0      0   100%
tests\test_vis\conftest.py                28      0   100%
tests\test_vis\test_pitches.py            39      0   100%
tests\test_vis\test_positions.py          38      0   100%
tests\test_vis\test_utils.py              16      1    94%
----------------------------------------------------------
TOTAL                                   2605    299    89%

@kanishkan91 I think it's quite useful to also publicly show these coverage reports, so I've also included the pytest-cov plug-in and integrated codecov. At last, I added a codecov badge displaying the current coverage of the package in the package README:
https://github.com/floodlight-sports/floodlight/tree/develop#readme

Thanks! Also thanks for adding the badge.


feat(curriculum): DRY-out backend project descriptions

Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] All the files I changed are in the same world language, for example: only English changes, or only Chinese changes, etc.

Groundwork and test to help maintainers with the descriptions.
Here is a link to old PR for conversation: https://github.com/freeCodeCamp/freeCodeCamp/pull/40456

When we decide to pursue this further, I will need to figure out how to best transition this into Crowdin.

Originally posted by @RandellDawson in https://github.com/freeCodeCamp/freeCodeCamp/issues/40456#issuecomment-770896491


fix(build): Hybrid package change for ESM and CJS support

Replicates: https://github.com/pmndrs/zustand/pull/507
Attempts to fix:  https://github.com/pmndrs/valtio/issues/179

Browserify Working Example : https://codesandbox.io/s/react-browserify-forked-2ikqw?file=/src/index.js (Since the generated template isn't updated to work properly)
Working Snowpack Example: https://codesandbox.io/s/react-snowpack-forked-nq77c?file=/src/index.jsx for the attempted fix.

I suppose this is ready for review.


docker.Container: 'expose' property

There is 'ports' property in the fabricio.docker.Container but lack of 'expose'.

expose property can be passed with options dict.


[v9] error: Bootstrap source map error on all front end pages

I get that error in the browser development console:
Source map error: Error: request failed with status 404 on every front end page.

I don’t get that on the Dashboard. What may be causing that? I can see in the page source the Bootstrap is loaded. All site functionality is working fine though.
Deleting that line in concrete/js/bootstrap.js:
//# sourceMappingURL=bootstrap.bundle.min.js.map
removes the error. But is that the right thing to do?

I'm not sure why you wouldn't get it in the Dashboard. It's present everywhere, if you have your browser detecting source maps. I will check in the source map for bootstrap in 9.0.2

This has been fixed in GitHub and will be released in 9.0.2


Enable Azure Pipelines build validation

In order to enable automatic CI in Azure Pipelines, we need to ensure that the appropriate version of the Insider Preview SDK is installed on the build machine. This is achieved by the new Install-WindowsSdkISO script. This is the same approach that other projects use, for instance microsoft-ui-xaml.
The PR also fixes an issue with build order/dependency for the C# demo app: it now explicitly depends on the Microsoft.UI.UIAutomation project (since it needs the metadata produced by this step). The Windows.winmd file that was referenced when Microsoft.UI.UIAutomation.winmd itself was built is copied to the same output directory just to make sure that all projects wind up referencing all the same metadata.
Closes #7

/azp run

Any reason not to use GitHub Actions in this repo?

Any reason not to use GitHub Actions in this repo?

Current policy for open source projects.


Versioned documentation, change logs request.

🙋 Documentation Request
Would like to versioned documentation. Also related to this it will be lovely to see change logs in new versions for better upgradeability.
🧢 Your Company/Team

Related to https://github.com/adobe/react-spectrum/issues/2735, https://github.com/adobe/react-spectrum/issues/841

Closing as dupe


Replace all buffs that disarm with this effect

https://www.hiveworkshop.com/threads/disarm.329772/

Closing as stale. To my knowledge this model is also fairly performance intensive.


WIP: ci: Upload binaries to github release

Signed-off-by: Andrii Soluk<EMAIL_ADDRESS>

Codecov Report

Merging #15 (d5d1d00) into main (db0d388) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #15   +/-   ##
=======================================
  Coverage   87.12%   87.12%
=======================================
  Files           7        7
  Lines         637      637
=======================================
  Hits          555      555
  Misses         52       52
  Partials       30       30

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 db0d388...d5d1d00. Read the comment docs.


k8s upgrade

(waiting on pygraphistry[ai] branch to land -> enterprise release)
This should be getting selection API observability to enterprise releases


Add Github issue template

When people open a new issue they will see these questions. Should help automate getting useful information. Any suggestions for improvements? I got it from https://www.talater.com/open-source-templates/#/page/98 and modified it slightly

Style wise .. the ## seems to make the text too big :)
will the comments < ... > be visible when creating the issue (otherwise the titles don't say much)
not every issue is a "bug", most of them are "questions/features" so if possible, it would be nice to be able to allow ppl to chose a tag and a template for that tag (not sure if possible).
For the bug template (which this PR seems to implement) it would help if steps to reproduce would be like: provide sample schema dump, provide curl request, provide result output, provide desired output ...
As a conclusion, what i find most lacking in the process is the tagging (question/bug/feature) and not that ppl do not provide information.

Yeah you're probably right. I'll close this for now. We can just remember for later that we can add an issue template if need be.


Add more tests

Especially for differently formatted method code like:
public function someMethod(
  string $param1,
)
{

Or
public function someMethod(string $param1) {

And I'm near positive anonymous and arrow functions won't work, but I'd like them to, so lets test those too.

More tests added in 34f8fc5c73aea0fbb4113837e78a0a5b8a4f0b16 through 28b61c29c6dc77cdf2b2ce824cdb8fefa9695a18.
TODO: arrow and anonymous function tests

Let's forget about those arrow and anonymous functions. There's no way to fully qualify them easily anyway


Thank You

Wish I knew another way of saying thank you without creating an issue, but I just want to let you know that your brilliant library saved me several hours, thank you!
Adam

Thanks, happy to hear! I love GitHub issues like these :smiley: