Changing shape at drop on paper

'm using rappidjs 3.2 and I'm trying to make a stencil shape that changes shape when I drop it to the paper. For testing purposes I want to just print in the console the type of shape throught dragEndClone (As far as I understood from documentation this is what I have to use).
Graph :
var graph = new joint.dia.Graph;
Paper :
var paper = new joint.dia.Paper({
el: $('.paper-container'),
width: 'calc(100% - 480px)',
height: '100%',
gridSize: 10,
drawGrid: true,
model: graph, // Set graph as the model for paper
defaultLink: function (elementView, magnet) {
return new joint.shapes.standard.Link({
attrs: {
line: {
strokeWidth: 2,
stroke: 'white'
}
}
});
},
interactive: { linkMove: false },
snapLinks: { radius: 70 },
defaultConnectionPoint: { name: 'boundary' }
});
Stencil :
var stencil = new joint.ui.Stencil({
paper: paper,
scaleClones: true,
width: 240,
groups: {
myShapesGroup1: { index: 1, label: 'My Shapes' }
},
dropAnimation: true,
groupsToggleButtons: true,
search: {
'*': ['type', 'attrs/label/text']
},
layout: true, // Use default Grid Layout
dragEndClone: function (el) {
console.log(el.get('type'));
}
});
document.querySelector('.stencil-container').appendChild(stencil.el);
Shape :
joint.dia.Element.define('standard.Rectangle', {
attrs: {
body: {
refWidth: '100%',
refHeight: '100%',
strokeWidth: 0,
stroke: '#000000',
fill: {
type: 'linearGradient',
stops: [
{ offset: '0%', color: '#FEB663' },
{ offset: '100%', color: '#31D0C6' }
],
// Top-to-bottom gradient.
attrs: { x1: '0%', y1: '0%', x2: '0%', y2: '100%' }
}
},
label: {
textVerticalAnchor: 'middle',
textAnchor: 'middle',
rx: '1%',
refX: '50%',
refY: '50%',
fontSize: 14,
fill: '#333333',
text: 'Siemans'
}
}
}, {
markup: [{ tagName: 'rect', selector: 'body' }, { tagName: 'text', selector: 'label' }]
});
Add shape to stencil :
stencil.render().load({ myShapesGroup1: [{ type: 'standard.Rectangle' }] });
The code previously shown gives me this error when I did write dragEndClone line in the stencil :
rappid.js:50779 Uncaught TypeError: Cannot read property 'getBBox' of undefined
at child.drop (rappid.js:50779)
at child.onDragEnd (rappid.js:50638)
at HTMLDocument.dispatch (jquery.js:5429)
at HTMLDocument.elemData.handle

Seems like you created an issue for the wrong project.
From what I see, it seems the framework you're using has a null pointer. Most likely it tries to create a SVG node, but doesn't do so, and then has no reference to the SVG node where it tries to call getBBox.

And here is the right project: https://resources.jointjs.com/docs/rappid/v3.2/index.html

That error like I said come from this line :
dragEndClone: function (el) {
console.log(el.get('type'));
}
I don't know what you mean by wrong project as example I used GettingStarted project.

Wrong project means, you have created an issue for rAppid.js - the declaration js framework, but you actually have a problem with a different product/project/library which is not maintained in this repository.


UMAP analysis for Wave 1 Nucleus features

Also adding visualization and umap embeddings

@gwaybio
Is this still a PR we are looking to merge?

Is this still a PR we are looking to merge?

Is it still relevant? We could close if not.

I would say this is a good PR to add since it involves the analysis of wave 1. I just changed it from being a draft and looks like there is no conflicts.
I went over the files and it LGTM!


Uncaught TypeError: Right-hand side of 'instanceof' is not callable

[Enter steps to reproduce:]

...
...

Atom: 1.37.0 x64
Electron: 2.0.18
OS: Unknown Windows version
Thrown From: markdown-scroll-sync package 2.1.2
Stack Trace
Uncaught TypeError: Right-hand side of 'instanceof' is not callable
At C:\Users\a\.atom\packages\markdown-scroll-sync\lib\main.coffee:38

TypeError: Right-hand side of 'instanceof' is not callable
    at /packages/markdown-scroll-sync/lib/main.coffee:38:14
    at Function.simpleDispatch (~/AppData/Local/atom/app-1.37.0/resources/app/static/<embedded>:11:1174290)
    at Emitter.emit (~/AppData/Local/atom/app-1.37.0/resources/app/static/<embedded>:11:1175731)
    at Workspace.didChangeActivePaneItemOnPaneContainer (~/AppData/Local/atom/app-1.37.0/resources/app/static/<embedded>:11:424512)
    at WorkspaceCenter.paneContainer.onDidChangeActivePaneItem.t (~/AppData/Local/atom/app-1.37.0/resources/app/static/<embedded>:14:39313)
    at Function.simpleDispatch (~/AppData/Local/atom/app-1.37.0/resources/app/static/<embedded>:11:1174290)
    at Emitter.emit (~/AppData/Local/atom/app-1.37.0/resources/app/static/<embedded>:11:1175731)
    at PaneContainer.didChangeActiveItemOnPane (~/AppData/Local/atom/app-1.37.0/resources/app/static/<embedded>:11:446795)
    at PaneContainer.didActivatePane (~/AppData/Local/atom/app-1.37.0/resources/app/static/<embedded>:11:446272)
    at Pane.activate (~/AppData/Local/atom/app-1.37.0/resources/app/static/<embedded>:11:463696)
    at Pane.focus (~/AppData/Local/atom/app-1.37.0/resources/app/static/<embedded>:11:455149)
    at HTMLElement.handleFocus (/app.asar/src/pane-element.js:41:20)

Commands
  4x -4:54.7.0 window:increase-font-size (input#markdown-preview-plus.useGitHubStyle.input-checkbox)
  3x -4:52.8.0 window:decrease-font-size (input#markdown-preview-plus.useGitHubStyle.input-checkbox)

Non-Core Packages
atom-mdtoc-sef 0.12.0
markdown-assistant 0.2.0
markdown-preview-plus 3.8.1
markdown-scroll-sync 2.1.2
markdown-table-editor 1.1.2
oss-uploader 0.9.0

It could be that the markdown-preview-plus version is too high3.8.1 was originally installed, but error was reported all the time;Change it to low


Referrals: Add code, url, and description

when complete on the api, finish referrals implementation.

Complete: Closing


Dual Forecasting Heads

May I ask how the results of the dual prediction head are combined? Is the optimal result obtained by multiplying the predicted results for each head with different weights?

As the code shows, it simply adds up the output results of the dual heads, allowing the network itself to learn and assign weights.


Stop doing link time redirection of malloc & friends

We should rather rely on calling GC_malloc. This will also make it much easier to just directly call malloc directly and mix GC and non-GC memory in the same process.

[x] argp-standalone

only used in actondb server and it's not using GC anyway so doesn't matter

[x] bdwgc

eh, not a user of malloc, it provides it :)

[x] bsdnt

does not expose ways to use custom allocator

[x] libuv
[x] libxml2
[x] mbedtls

[x] compile with MBEDTLS_PLATFORM_MEMORY
[x] link with mbedcrypto
[x] call mbedtls_platform_set_calloc_free

[x] pcre2
[x] protobuf-c

only used in actondb server and it's not using GC anyway so doesn't matter

[x] snappy

malloc is the responsbility of the calling code I think, so no mallocs, at least not in the functions we call!?

[x] tlsuv

[x] first upgrade to latest tlsuv (we're lagging behind and there have been API changes AFAIK)
[x] add custom allocator support

[x] utf8proc

only has a single malloc in utf8proc.c and it is in a function we do not use

[x] remove redirect_malloc & ignore_free
part 2...
[ ] re-enable link time redirect as default
[ ] add new actonc compilation to disable link time redirection of malloc
[x] fix asprintf wrapper or similar

Okay, not quite done here. Reopening. Need to take a step back and regroup.

I have missed places, the most obvious being asprintf that implicitly allocates memory that is never freed. Having memory that is malloced on non-GC-heap is a frequent source of segfaults, since the GC won't find references to objects on the GC-heap but for the case of asprintf, it never contains any pointers anyway and most of the time I suspect we do a to$str on it, which copies the value anyway so the old non-gc-heap allocated object is never beyond the to$str.
We should obviously fix asprintf but perhaps there are more places. To avoid memory leaks, I think we need to have a compilation flag whether to do malloc redirect or not.

In #1782 we've removed all asprintf invocations. $FORMAT has been fixed to use snprintf and acton_malloc instead. I've also fixed the yyjson calls in our json module so they're using acton_malloc. These are all the memory leaks I know of, so think we are done now. Since this went relatively painless I will opt not to reimplement malloc redirect and have an option to enable / disable. Closing.


config file: typo in uuid

In config.json file, the uuid for tcp-client of AirInterfacePowerSaver shall be aips-0-0-5-tcp-c-aips-0-0-5-000. But it is present as ps-0-0-5-tcp-c-aips-0-0-5-000. This shall be changed

will be corrected and updated to v0-0-10


How to check Already labelled images again?

OS: Ubuntu
I have install labelimg using pip. I have labelled all image successfully in yolo format and train my model using those labels. Now I just want to see bounding box of earlier annotated images to see the comparison of ground truth and prediction done by model.  Is there any way by which I can load image file as well as it's annotation text file so that I can see bounding box on that image?

Did you solve the question?

I used labelImg for Pascal VOC. On opening the folder which contains the images that have been annotated, the annotations are already present. Did you also experience the same behavior ?
In addition, did you try specifying your save directory ?

@eb642w No. I am not able to get answer to this yet.

@Tanmay-Kulkarni101  I had tried this,  but I am not able to get results.

The same problem, after restart I have lost all labels when they actually exist but not displayed.

The same problem, after restart I have lost all labels when they actually exist but not displayed. (Ubuntu)

running with sudo helps, so it's something about permissions

Hello Team,
Can we do this with LabelImg? I am also looking for a tool to import already labeled images and verify and correct them.
Platform: Windows 10
Thanks a lot!

I followed the coment of @vadzimyatskevich running labelImg with sudo and everything was Ok! I can check all annotations

@veer5551 Did you find a way to open the annotations and verify them in Windows 10. I tried executing labelImg in Anaconda Prompt as admin mode, but that did not work.

You can edit existing annotations by opening the annotations folder through File ->  Change Save Dir.

https://github.com/tzutalin/labelImg/issues/639#issuecomment-700672557

I did "chmod 777" on my images and Pascal/VOC xml files, as well as on the folder were they are. And it worked.

remember putting the classes.txt file in the same folder, it solves my problem.


Helm install times out on Azure AKS with RBAC enabled

What did you do?
Since it is possible these days to create an Azure AKS with RBAC, I have done so. I have tried to install the prometheus-operator using Helm.
What did you expect to see?
A successful outcome, like when doing the same in a Kubernetes cluster without RBAC (and passing the relevant rbacEnable flag.
What did you see instead? Under which circumstances?
Command:
helm install coreos/prometheus-operator --name prometheus-operator --namespace monitoring --debug
Output:
[debug] Created tunnel using local port: '53575'

[debug] SERVER: "<IP_ADDRESS>:53575"

[debug] Original chart version: ""
[debug] Fetched coreos/prometheus-operator to /Users/me/.helm/cache/archive/prometheus-operator-0.0.26.tgz

[debug] CHART PATH: /Users/me/.helm/cache/archive/prometheus-operator-0.0.26.tgz

Error: watch closed before Until timeout

I guess it may timeout because of the Azure load balancer timeout. But when doing the same in a cluster without RBAC there is no such wait.

Kubernetes version information:

Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.2", GitCommit:"81753b10df112992bf51bbc2c2f85208aad78335", GitTreeState:"clean", BuildDate:"2018-05-12T04:12:12Z", GoVersion:"go1.9.6", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.6", GitCommit:"9f8ebd171479bec0ada837d7ee641dec2f8c6dd1", GitTreeState:"clean", BuildDate:"2018-03-21T15:13:31Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

Kubernetes cluster kind:
Azure AKS 1.9.6 with RBAC enabled.

Prometheus Operator Logs:

The prometheus operator ends up running and I can see it in the pods list. However, the helm list shows the install as FAILED. Trying to see if this would explain why I cannot see my ServiceMonitors working...

I also experience this issue.  Deploy via helm / tiller times out after ~60s (during job creation) and does not honour the wait / timeout values (default or passed explicitly).  Interestingly, using helm template to generate something that can be used via kubectl apply -f . works fine.
This feels like an issue with the underlying proxy timeout perhaps?
(NB: I also had to create the cluster-admin clusterrole, which appears to be missing on AKS deployments, in order to get Tiller to play nice with RBAC / namespaces)

Please paste the output of kubectl get pods -n monitoring and kubectl describe pod -n monitoring

Same problem here with Azure AKS with K8s 1.10.3 with RBAC enabled.
# helm install coreos/prometheus-operator --name prometheus-operator --namespace monitoring --debug
[debug] Created tunnel using local port: '49938'

[debug] SERVER: "<IP_ADDRESS>:49938"

[debug] Original chart version: ""
[debug] Fetched coreos/prometheus-operator to /root/.helm/cache/archive/prometheus-operator-0.0.27.tgz

[debug] CHART PATH: /root/.helm/cache/archive/prometheus-operator-0.0.27.tgz

Error: watch closed before Until timeout

# kubectl get pods -n monitoring
NAME                                      READY     STATUS      RESTARTS   AGE
prometheus-operator-create-sm-job-x4jxw   0/1       Completed   0          1m
prometheus-operator-d75587d6-f65j2        1/1       Running     0          1m
prometheus-operator-get-crd-lgvkv         0/1       Completed   0          1m

# kubectl describe pod -n monitoring
Name:           prometheus-operator-create-sm-job-x4jxw
Namespace:      monitoring
Node:           aks-nodepool1-11456975-2/<IP_ADDRESS>
Start Time:     Wed, 04 Jul 2018 12:54:47 +0200
Labels:         app=prometheus-operator
                controller-uid=aac189d2-7f78-11e8-9dcb-32ef8f1d8ad2
                job-name=prometheus-operator-create-sm-job
                release=prometheus-operator
Annotations:    <none>
Status:         Succeeded
IP:             <IP_ADDRESS>
Controlled By:  Job/prometheus-operator-create-sm-job
Containers:
  hyperkube:
    Container ID:  docker://c2aeced096ecea1de5f4c474c60ce9424a6e62d4e15daf1e69070b312408570f
    Image:         quay.io/coreos/hyperkube:v1.7.6_coreos.0
    Image ID:      docker-pullable://quay.io/coreos/hyperkube@sha256:699fc03fccb1c4662fee9d996cf30106aea55a6f594d16c1504cc7334dadcee4
    Port:          <none>
    Host Port:     <none>
    Command:
      ./kubectl
      apply
      -f
      /tmp/servicemonitor/servicemonitor-operator.yaml
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Wed, 04 Jul 2018 12:54:48 +0200
      Finished:     Wed, 04 Jul 2018 12:54:49 +0200
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /tmp/servicemonitor from tmp-configmap-servicemonitor (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from prometheus-operator-token-mfxf5 (ro)
Conditions:
  Type           Status
  Initialized    True
  Ready          False
  PodScheduled   True
Volumes:
  tmp-configmap-servicemonitor:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      prometheus-operator
    Optional:  false
  prometheus-operator-token-mfxf5:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  prometheus-operator-token-mfxf5
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type    Reason                 Age   From                               Message
  ----    ------                 ----  ----                               -------
  Normal  Scheduled              2m    default-scheduler                  Successfully assigned prometheus-operator-create-sm-job-x4jxw to aks-nodepool1-11456975-2
  Normal  SuccessfulMountVolume  2m    kubelet, aks-nodepool1-11456975-2  MountVolume.SetUp succeeded for volume "prometheus-operator-token-mfxf5"
  Normal  SuccessfulMountVolume  2m    kubelet, aks-nodepool1-11456975-2  MountVolume.SetUp succeeded for volume "tmp-configmap-servicemonitor"
  Normal  Pulled                 2m    kubelet, aks-nodepool1-11456975-2  Container image "quay.io/coreos/hyperkube:v1.7.6_coreos.0" already present on machine
  Normal  Created                2m    kubelet, aks-nodepool1-11456975-2  Created container
  Normal  Started                2m    kubelet, aks-nodepool1-11456975-2  Started container
  Normal  SandboxChanged         2m    kubelet, aks-nodepool1-11456975-2  Pod sandbox changed, it will be killed and re-created.

Name:           prometheus-operator-d75587d6-f65j2
Namespace:      monitoring
Node:           aks-nodepool1-11456975-1/<IP_ADDRESS>
Start Time:     Wed, 04 Jul 2018 12:54:47 +0200
Labels:         app=prometheus-operator
                operator=prometheus
                pod-template-hash=83114382
                release=prometheus-operator
Annotations:    <none>
Status:         Running
IP:             <IP_ADDRESS>
Controlled By:  ReplicaSet/prometheus-operator-d75587d6
Containers:
  prometheus-operator:
    Container ID:  docker://a37d7563d956435b0e48397ce979cf25dfd0f68ed977885b396972016ba9c550
    Image:         quay.io/coreos/prometheus-operator:v0.20.0
    Image ID:      docker-pullable://quay.io/coreos/prometheus-operator@sha256:88cd66e273db8f96cfcce2eec03c04b04f0821f3f8d440396af2b5510667472d
    Port:          8080/TCP
    Host Port:     0/TCP
    Args:
      --kubelet-service=kube-system/kubelet
      --prometheus-config-reloader=quay.io/coreos/prometheus-config-reloader:v0.20.0
      --config-reloader-image=quay.io/coreos/configmap-reload:v0.0.1
    State:          Running
      Started:      Wed, 04 Jul 2018 12:54:48 +0200
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from prometheus-operator-token-mfxf5 (ro)
Conditions:
  Type           Status
  Initialized    True
  Ready          True
  PodScheduled   True
Volumes:
  prometheus-operator-token-mfxf5:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  prometheus-operator-token-mfxf5
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type    Reason                 Age   From                               Message
  ----    ------                 ----  ----                               -------
  Normal  Scheduled              2m    default-scheduler                  Successfully assigned prometheus-operator-d75587d6-f65j2 to aks-nodepool1-11456975-1
  Normal  SuccessfulMountVolume  2m    kubelet, aks-nodepool1-11456975-1  MountVolume.SetUp succeeded for volume "prometheus-operator-token-mfxf5"
  Normal  Pulled                 2m    kubelet, aks-nodepool1-11456975-1  Container image "quay.io/coreos/prometheus-operator:v0.20.0" already present on machine
  Normal  Created                2m    kubelet, aks-nodepool1-11456975-1  Created container
  Normal  Started                2m    kubelet, aks-nodepool1-11456975-1  Started container

Name:           prometheus-operator-get-crd-lgvkv
Namespace:      monitoring
Node:           aks-nodepool1-11456975-0/<IP_ADDRESS>
Start Time:     Wed, 04 Jul 2018 12:54:49 +0200
Labels:         app=prometheus-operator
                controller-uid=ac2e816f-7f78-11e8-9dcb-32ef8f1d8ad2
                job-name=prometheus-operator-get-crd
                release=prometheus-operator
Annotations:    <none>
Status:         Succeeded
IP:             <IP_ADDRESS>
Controlled By:  Job/prometheus-operator-get-crd
Containers:
  hyperkube:
    Container ID:  docker://5393eab83d149c2188a374e08c718913b442a8bfe3d4c167ead502ccb4ad7635
    Image:         quay.io/coreos/hyperkube:v1.7.6_coreos.0
    Image ID:      docker-pullable://quay.io/coreos/hyperkube@sha256:699fc03fccb1c4662fee9d996cf30106aea55a6f594d16c1504cc7334dadcee4
    Port:          <none>
    Host Port:     <none>
    Command:
      ./kubectl
      get
      customresourcedefinitions
      alertmanagers.monitoring.coreos.com
      prometheuses.monitoring.coreos.com
      servicemonitors.monitoring.coreos.com
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Wed, 04 Jul 2018 12:56:12 +0200
      Finished:     Wed, 04 Jul 2018 12:56:13 +0200
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from prometheus-operator-token-mfxf5 (ro)
Conditions:
  Type           Status
  Initialized    True
  Ready          False
  PodScheduled   True
Volumes:
  prometheus-operator-token-mfxf5:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  prometheus-operator-token-mfxf5
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type    Reason                 Age   From                               Message
  ----    ------                 ----  ----                               -------
  Normal  Scheduled              2m    default-scheduler                  Successfully assigned prometheus-operator-get-crd-lgvkv to aks-nodepool1-11456975-0
  Normal  SuccessfulMountVolume  2m    kubelet, aks-nodepool1-11456975-0  MountVolume.SetUp succeeded for volume "prometheus-operator-token-mfxf5"
  Normal  Pulling                2m    kubelet, aks-nodepool1-11456975-0  pulling image "quay.io/coreos/hyperkube:v1.7.6_coreos.0"
  Normal  Pulled                 47s   kubelet, aks-nodepool1-11456975-0  Successfully pulled image "quay.io/coreos/hyperkube:v1.7.6_coreos.0"
  Normal  Created                47s   kubelet, aks-nodepool1-11456975-0  Created container
  Normal  Started                47s   kubelet, aks-nodepool1-11456975-0  Started container
  Normal  SandboxChanged         44s   kubelet, aks-nodepool1-11456975-0  Pod sandbox changed, it will be killed and re-created.

@StianOvrevage I cannot see any errors on helm, all the pods were deployed and the jobs are completed. Did you try to investigate if this also happen with other users running helm on Azure? I find this issue that could be related https://github.com/Azure/AKS/issues/455

Was having this issue also on AKS — until I upgraded my cluster.
kubectl get pods -n monitoring
NAME                                      READY     STATUS      RESTARTS   AGE
prometheus-operator-5cd488b98b-54rx6      1/1       Running     0          5m
prometheus-operator-create-sm-job-5cj4h   0/1       Completed   0          5m

kubectl get pods -n monitoring
NAME                                      READY     STATUS      RESTARTS   AGE
prometheus-operator-5cd488b98b-54rx6      1/1       Running     0          5m
prometheus-operator-create-sm-job-5cj4h   0/1       Completed   0          5m
scotts-mbp:hbwtadmin scottimbrie$ kubectl describe pod -n monitoring
Name:           prometheus-operator-5cd488b98b-54rx6
Namespace:      monitoring
Node:           aks-nodepool1-29667973-0/<IP_ADDRESS>
Start Time:     Wed, 18 Jul 2018 12:12:23 -0400
Labels:         app=prometheus-operator
                operator=prometheus
                pod-template-hash=1780446546
                release=prometheus-operator
Annotations:    <none>
Status:         Running
IP:             <IP_ADDRESS>
Controlled By:  ReplicaSet/prometheus-operator-5cd488b98b
Containers:
  prometheus-operator:
    Container ID:  docker://6f10109beb89e23359d6f556fee0171f9efc29378ccc0d5360e9eaf1b5f3b97d
    Image:         quay.io/coreos/prometheus-operator:v0.20.0
    Image ID:      docker-pullable://quay.io/coreos/prometheus-operator@sha256:88cd66e273db8f96cfcce2eec03c04b04f0821f3f8d440396af2b5510667472d
    Port:          8080/TCP
    Host Port:     0/TCP
    Args:
      --kubelet-service=kube-system/kubelet
      --prometheus-config-reloader=quay.io/coreos/prometheus-config-reloader:v0.20.0
      --config-reloader-image=quay.io/coreos/configmap-reload:v0.0.1
    State:          Running
      Started:      Wed, 18 Jul 2018 12:12:24 -0400
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-njm6b (ro)
Conditions:
  Type           Status
  Initialized    True
  Ready          True
  PodScheduled   True
Volumes:
  default-token-njm6b:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-njm6b
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type    Reason                 Age   From                               Message
  ----    ------                 ----  ----                               -------
  Normal  Scheduled              6m    default-scheduler                  Successfully assigned prometheus-operator-5cd488b98b-54rx6 to aks-nodepool1-29667973-0
  Normal  SuccessfulMountVolume  6m    kubelet, aks-nodepool1-29667973-0  MountVolume.SetUp succeeded for volume "default-token-njm6b"
  Normal  Pulled                 6m    kubelet, aks-nodepool1-29667973-0  Container image "quay.io/coreos/prometheus-operator:v0.20.0" already present on machine
  Normal  Created                6m    kubelet, aks-nodepool1-29667973-0  Created container
  Normal  Started                6m    kubelet, aks-nodepool1-29667973-0  Started container

Name:           prometheus-operator-create-sm-job-5cj4h
Namespace:      monitoring
Node:           aks-nodepool1-29667973-0/<IP_ADDRESS>
Start Time:     Wed, 18 Jul 2018 12:12:23 -0400
Labels:         app=prometheus-operator
                controller-uid=5ae3085b-8aa5-11e8-8ba7-7adaba262e71
                job-name=prometheus-operator-create-sm-job
                release=prometheus-operator
Annotations:    <none>
Status:         Succeeded
IP:             <IP_ADDRESS>
Controlled By:  Job/prometheus-operator-create-sm-job
Containers:
  hyperkube:
    Container ID:  docker://4f6ecb35320ae94a85ad2104dd146e12d288977f12a554767d5dd0b9dbcb001d
    Image:         quay.io/coreos/hyperkube:v1.7.6_coreos.0
    Image ID:      docker-pullable://quay.io/coreos/hyperkube@sha256:699fc03fccb1c4662fee9d996cf30106aea55a6f594d16c1504cc7334dadcee4
    Port:          <none>
    Host Port:     <none>
    Command:
      ./kubectl
      apply
      -f
      /tmp/servicemonitor/servicemonitor-operator.yaml
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Wed, 18 Jul 2018 12:12:24 -0400
      Finished:     Wed, 18 Jul 2018 12:12:25 -0400
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /tmp/servicemonitor from tmp-configmap-servicemonitor (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-njm6b (ro)
Conditions:
  Type           Status
  Initialized    True
  Ready          False
  PodScheduled   True
Volumes:
  tmp-configmap-servicemonitor:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      prometheus-operator
    Optional:  false
  default-token-njm6b:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-njm6b
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type    Reason                 Age   From                               Message
  ----    ------                 ----  ----                               -------
  Normal  Scheduled              6m    default-scheduler                  Successfully assigned prometheus-operator-create-sm-job-5cj4h to aks-nodepool1-29667973-0
  Normal  SuccessfulMountVolume  6m    kubelet, aks-nodepool1-29667973-0  MountVolume.SetUp succeeded for volume "tmp-configmap-servicemonitor"
  Normal  SuccessfulMountVolume  6m    kubelet, aks-nodepool1-29667973-0  MountVolume.SetUp succeeded for volume "default-token-njm6b"
  Normal  Pulled                 6m    kubelet, aks-nodepool1-29667973-0  Container image "quay.io/coreos/hyperkube:v1.7.6_coreos.0" already present on machine
  Normal  Created                6m    kubelet, aks-nodepool1-29667973-0  Created container
  Normal  Started                6m    kubelet, aks-nodepool1-29667973-0  Started container

Install Successful After Cluster Upgrade
Per the user comments over here https://github.com/Azure/AKS/issues/455#issuecomment-405198324 a Cluster upgrade to v1.10.5 via the Azure AKS upgrade docs (https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster) solved the problem in my particular case.

Thanks for your feedback @necevil. I'm gonna close this issue since it's not related to this project

the following works fine from 10.3.6 up until 1.11.1
git clone https://github.com/coreos/prometheus-operator.git
cd prometheus-operator
kubectl apply -f bundle.yaml
helm install helm/prometheus-operator --name prometheus-operator --namespace monitoring --set rbacEnable=false  --wait --timeout 1000
mkdir -p helm/kube-prometheus/charts
helm package -d helm/kube-prometheus/charts helm/alertmanager helm/grafana helm/prometheus  helm/exporter-kube-dns \
helm/exporter-kube-scheduler helm/exporter-kubelets helm/exporter-node helm/exporter-kube-controller-manager \
helm/exporter-kube-etcd helm/exporter-kube-state helm/exporter-coredns helm/exporter-kubernetes
helm install helm/kube-prometheus --name kube-prometheus --name kube-prometheus --namespace monitoring --set global.rbacEnable=false


Action bar title changes to 'false' on going back from Legal option in About Us

Describe the bug
Action bar title changes to 'false' on going back from Legal option in About Us section.
Would you like to work on the issue?

[x] Yes
[ ] No

Hey, I would like to pick this up. are you working on this?

@codedsun Go ahead.

I am taking this up!


Fix Sentry placeholders

Automated message from Dropbox CLA bot
@borisyankov, it looks like you've already signed the Dropbox CLA. Thanks!


Can I remap a key combination to mouse button press/release?

Can I make something like this:
press ctrl+super+m -> press mouse button 3
release ctrl+super+m -> release mouse button 3

Not at the moment. Adding some rudimentary mouse support should be fairly trivial, though you may want to check out one of my other projects, warpd, in the meantime.

Ok. Thanks.


integration tests: colorization test are run 6 times

npm run needs -- before script arguments that start with --
e.g. npm run test-extension -- -l vscode-colorize-tests

I also added the -- in vscode/.github/workflows/ci.yml

Oh thanks for catching this!
I adjusted the callsites in the pipeline files https://github.com/microsoft/vscode/tree/main/build/azure-pipelines but missed to check script files 🤦


Terra launch-with WDL tools

Feature Request
Desired behaviour
Bring over launch-with from workflows like https://dockstore.org/workflows/github.com/DataBiosphere/topmed-workflows/UM_variant_caller_wdl:1.32.0?tab=info
to tools like
https://dockstore.org/containers/quay.io/mduran/generate-igv-session_2/GenerateIGVSession:dockstore?tab=info
┆Issue is synchronized with this Jira Story
┆Issue Type: Story
┆Issue Number: DOCK-666

Is this a duplicate of #1705?

Yup


RS010N Support

Is it support rs010n ?

We don't support RS010N for now.

@MasaoAramoto  Is there a plan to support?


MM-31118: 3rd party OAuth2 support

Ticket
https://mattermost.atlassian.net/browse/MM-31118

To demo:

Follow Google Calendar Plugin README to set up your OAuth2 app on the Google side.
In a separate window, run go run ./server/examples/go/hello-3rdparty
In Mattermost,

/apps debug-add-manifest --url http://localhost:8080/manifest.json
/apps install --app-id hello3rdparty (any secret)
/hello3rdparty configure --client-secret VALUE --client-id VALUE
/hello3rdparty connect
/hello3rdparty send

Breaking changes

static should be invoked as .../apps/APPID/static/NAME (was something else)
KV schema changed, prior data should be wiped out

Changes

Added http/gateway that supports .../apps/AppID/(static|oauth2) paths, moved the static handler there
Added hello3rdparty example App
Removed mock_config - config.TestService is a simpler functional equivalent.
Added AppPath to Context, re-factored the new Context creation.
Simplified initialization of mmclient
shortened internal key names for KV REST API, see https://github.com/mattermost/mattermost-plugin-apps/pull/113/files?file-filters[]=.go&file-filters[]=.json&file-filters[]=.md&file-filters[]=.png&file-filters[]=.sum#diff-a3021be373b09ef7dfe9949ad06ae9d2fc9c4a47c6afb7c415e50f9203a6dfd8L26

Next

Add 3rd party OAuth as a Permission
Add App's OAuth paths to ExpandedContext
Add a Config/Token store REST API (instead of using KV awkwardly)
Add 3rd party OAuth config/tokens to ExpandedContext

@catalintomai @larkox see the Next section in the updated description. I'd like to finish it as a P1, but as a separate PR.


Deal with jest warnings

● Multiple configurations found:
    * /release-with-commit/jest.config.js
    * `jest` key in /release-with-commit/package.json

  Implicit config resolution does not allow multiple configuration files.
  Either remove unused config files or select one explicitly with `--config`.

  Configuration Documentation:
  https://jestjs.io/docs/configuration.html

how to deal with it


bug in multiple compilations

I got this bug when parcels was compiled multiple times in a for loop:
Traceback (most recent call last):
  File "/home/staff/sebil001/parcels/parcels/compiler.py", line 53, in compile
    subprocess.check_call(cc, stdout=logfile, stderr=logfile)
  File "/home/staff/sebil001/miniconda3/envs/py3_parcels/lib/python3.7/subprocess.py", line 342, in check_call
    retcode = call(*popenargs, **kwargs)
  File "/home/staff/sebil001/miniconda3/envs/py3_parcels/lib/python3.7/subprocess.py", line 323, in call
    with Popen(*popenargs, **kwargs) as p:
  File "/home/staff/sebil001/miniconda3/envs/py3_parcels/lib/python3.7/subprocess.py", line 775, in __init__
    restore_signals, start_new_session)
  File "/home/staff/sebil001/miniconda3/envs/py3_parcels/lib/python3.7/subprocess.py", line 1453, in _execute_child
    restore_signals, start_new_session, preexec_fn)
OSError: [Errno 12] Cannot allocate memory

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "microbes_eac_cmemsrun.py", line 89, in <module>
    pset.execute(SampleFields, dt=0, runtime=0)  # initial sampling
  File "/home/staff/sebil001/parcels/parcels/particleset.py", line 368, in execute
    self.kernel.compile(compiler=GNUCompiler(cppargs=cppargs))
  File "/home/staff/sebil001/parcels/parcels/kernel.py", line 194, in compile
    compiler.compile(self.src_file, self.lib_file, self.log_file)
  File "/home/staff/sebil001/parcels/parcels/compiler.py", line 57, in compile
    raise RuntimeError(err)
RuntimeError: OSError during compilation

This needs to be investigated

This is fixed in #656


Responsive styles for Dashboard

Description
As the rest of the responsive work has been handled in separate component tasks, this PR is mainly adding responsive styles/markup for the notification center. Comments are throughout to explain the details, but we are using Hidden to 'toggle' content. A new CMR-specific component has been created for styles and to support the 'item count' displayed on the mobile version notification items.
Type of Change

Non breaking change ('update')

Thanks @Jskobos ! The blue was actually left over from MUI's styling, but we should probably have a differentiating focus/active state- I'll ask for clarification on that. Along the same line, I believe the blue is persisting because it is still the focused, 'active' element. We could update that so once you close the panel, focus/activated state is removed.

Updated to rotate the arrow on expansion 👍


fix: Fixes Review Page showing the "Go back" button twice

Summary | Résumé
This bug happens when a form group has no "nextAction" in the JSON. The current logic will then show both the GroupsBackButton and the submit BackButton. This PR fixes this case where both back buttons will show at the same time.
Follow up: send support the updated (fixed) JSON: give-feedback-2024-11-19 (updated).json
NOTE:
When a form is in this state, the current logic would also not allow the form to Submit.
Currently the form-builder editor tree view should handle the case of automatically auto-flowing and fixing any pages not pointing to a next action. If we can learn how the user got the form into this state then we could try to debug it.
One idea is to add an additional validation when a form is being saved. The validation would check each group, and make sure it has next action, if it does not, then a minor error message could show.
Test
If you load the original form JSON (below), the back button show only display once on the "Give feedback" page. Get to this page by selecting "yes" on the "Would you like to receive a response from us?" question.
give-feedback-2024-11-19 (updated).json

Note that this only fixes the two back buttons showing at once. The form is still in a broken state and will not be able to submit (if you click submit, nothing will happen).
Below is an updated (fixed) version of the form that will work correctly. (note how this version has a "continue" button and not a broken submit button)
give-feedback-2024-11-19 (original).json

QA tested groups and non-group forms to ensure all works well, and LGTM


2.4 - Update libdjinterop to version 0.20.3

Adds compatibility to EngineOS 3.3.0 and 3.4.0

I have pushed this to the other branches as well.


Compiling with Cray Fortran 14

Hello! I am trying to compile the library using Cray Fortran on an HPC machine. Unfortunately, there is a compilation error
Cray Fortran : Version 14.0.1<PHONE_NUMBER>4428_3a8780657c742829e80f36338fb6ec6578642bb7)
Cray Fortran : Tue May 09, 2023  16:59:12
Cray Fortran : Compile time:  1.9750 seconds
Cray Fortran : 1964 source lines
Cray Fortran : 0 errors, 1 warnings, 0 other messages, 0 ansi
Cray Fortran : "explain ftn-message number" gives more information about each message.
[79/122] Building Fortran object CMakeFiles/toml-f-lib.dir/src/tomlf/diagnostic.f90.o
FAILED: CMakeFiles/toml-f-lib.dir/src/tomlf/diagnostic.f90.o include/tomlf_diagnostic.mod
/opt/cray/pe/craype/2.7.16/bin/ftn -I/cfs/klemming/projects/snic/kthmech/tmu/Software/toml-f/src/tomlf -I/cfs/klemming/projects/snic/kthmech/tmu/Software/toml-f/_build/include -em -Jinclude -h PIC -c CMakeFiles/toml-f-lib.dir/src/tomlf/diagnostic.f90-pp.f90 -o CMakeFiles/toml-f-lib.dir/src/tomlf/diagnostic.f90.o
*** fei_op( arg_count = 1 ), expected at least 2 args*** error ***
fei_op( FEI_OP_MINUS, integer*4, 1, 16777470 )
   Error message      ::  Invalid number of arguments
   Error detected     ::  File '/workspace/crayftn/pdgcs/v_fei.c', line 11531
   Optimizer built    ::  2022-05-26 (production)

   File               ::  CMakeFiles/toml-f-lib.dir/src/tomlf/diagnostic.f90-pp.f90
   Function           ::  render_text_with_label
   at or near line    ::  254

   File path          ::  /cfs/klemming/projects/snic/kthmech/tmu/Software/toml-f/_build/CMakeFiles/toml-f-lib.dir/src/tomlf/diagnostic.f90-pp.f90
   Compiler hash      ::  3a8780657c742829e80f36338fb6ec6578642bb7
   Target             ::  x86-rome

Is there possibly a way to fix this?
The background here is that we would like to incorporate an established input file format for a new CFD solver, but we are struggling to find a solution that supports compilers relevant for HPC machines.

I don't have access to Cray compilers for checking this unfortunately. The error message however looks like an internal compiler error rather than an issue with TOML Fortran. Maybe it is possible to reduce the tomlf_diagnostic module to isolate the exact problem. This way it is easier to find a workaround or/and send a support request to Cray.

Looks like it is caused by this lines:
https://github.com/toml-f/toml-f/blob/5a199212002abba3aff472c77bce56378884d286/src/tomlf/diagnostic.f90#L253C14-L255

Trying to understand the code a bit. We have
   type :: line_token
      integer :: first, last
   end type line_token

Then we have in failing function
type(line_token), allocatable :: token(:)
! ...
associate(first => token%first)
      shift = first(line) - 1
end associate

The code is a bit unclear to me, token is an array, so is the idea here that token%first will be a corresponding array of all first attributes? Does it work that way? Can we do
associate(first => token%first(line))
      shift = first - 1
end associate

instead?

The module compiles now, but unfortunately there is more trouble down the road with
FAILED: CMakeFiles/toml-f-lib.dir/src/tomlf/ser.f90.o include/tomlf_ser.mod
/opt/cray/pe/craype/2.7.16/bin/ftn -I/cfs/klemming/projects/snic/kthmech/tmu/Software/toml-f/src/tomlf -I/cfs/klemming/projects/snic/kthmech/tmu/Software/toml-f/_build/include -em -Jinclude -h PIC -c CMakeFiles/toml-f-lib.dir/src/tomlf/ser.f90-pp.f90 -o CMakeFiles/toml-f-lib.dir/src/tomlf/ser.f90.o
ftn-2116 ftn: INTERNAL
  "/opt/cray/pe/cce/14.0.1/cce/x86_64/bin/ftnfe" was terminated due to receipt of signal 013:  Segmentation fault.

This does not seem helpful at all :(. Perhaps one can engage Cray somehow to look at this.

This seems to fail in the tomlf_ser module, which provides the implementation to turn a data structure into a string.
You could try to comment out part of the visitor implementation to see which routine exactly breaks the compiler (they will probably appreciate a minimal reproducer for this).
The module is pretty separated from the rest of TOML Fortran, you could remove it for the time being to see whether Cray can pass the unit and decoder tests or there are more issues.

By making the ser.f90 empty and removing the "compliance" subdir from the tests, I could compile.
Unfortunately, the unit tests fail
  Starting lexer-from-sequential ... (108/108)
       ... lexer-from-sequential [FAILED]
  Message:
# Testing: parser
  Starting root-invalid ... (1/39)
       ... root-invalid [EXPECTED FAIL]
  Message: error: Invalid syntax
 --> mocked:1:1
  |
1 | }
  | ^ unexpected opening brace
  |
  Starting table-body ... (2/39)
       ... table-body [PASSED]
  Starting table-header-long ... (3/39)
Segmentation fault (core dumped)

Sad times.

Can we get a better backtrack for the segmention fault? If it fails in the table header then there might be an issue with the way the internal stack for the TOML parser is handled.
Also not happy to see a failure in the lexing... if you can give me more details I might figure out a workaround, but ultimately this are bugs in the Cray compiler which should be reported and fixed.

I will also try with version 15 of the compiler. I guess we can't report bugs on an older version anyway.


[TVM_TUNE]how to speed up tvm-tune process?

This is my tune process
[Task  1/15]  Current/Best:  203.76/ 218.31 GFLOPS | Progress: (456/456) | 640.50 s Done.
[Task  2/15]  Current/Best:   80.40/ 419.17 GFLOPS | Progress: (1596/1596) | 4903.65 s Done.
[Task  3/15]  Current/Best:   42.18/ 481.95 GFLOPS | Progress: (2128/2128) | 4875.32 s Done.
[Task  4/15]  Current/Best:   49.33/ 398.59 GFLOPS | Progress: (2128/2128) | 3484.17 s Done.
[Task  5/15]  Current/Best:  165.78/ 452.15 GFLOPS | Progress: (2432/2432) | 7505.86 s Done.
[Task  6/15]  Current/Best:  312.07/ 457.73 GFLOPS | Progress: (2592/2592) | 5653.20 s Done.
[Task  7/15]  Current/Best:  126.27/ 482.35 GFLOPS | Progress: (2592/2592) | 3867.81 s Done.
[Task  8/15]  Current/Best:  177.73/ 489.10 GFLOPS | Progress: (2916/2916) | 8795.57 s Done.
[Task  9/15]  Current/Best:  129.73/ 380.58 GFLOPS | Progress: (1440/1440) | 4954.11 s Done.
[Task 10/15]  Current/Best:  206.29/ 509.71 GFLOPS | Progress: (1440/1440) | 2401.94 s Done.
[Task 11/15]  Current/Best:  259.05/ 366.04 GFLOPS | Progress: (1600/1600) | 7182.31 s Done.
[Task 12/15]  Current/Best:  218.73/ 396.80 GFLOPS | Progress: (1600/1600) | 4050.32 s Done.
[Task 13/15]  Current/Best:  169.96/ 470.15 GFLOPS | Progress: (1600/1600) | 2884.35 s Done.
[Task 14/15]  Current/Best:   56.56/ 194.11 GFLOPS | Progress: (180/180) | 418.50 s Done.
[Task 15/15]  Current/Best:    8.65/ 186.24 GFLOPS | Progress: (4320/4320) | 10059.10 s Done.
==========================
my tune option
tuning_option = {
"log_filename": log_file,
"tuner": "random",
"early_stopping": None,
"measure_option": autotvm.measure_option(
builder=autotvm.LocalBuilder(),
runner=autotvm.LocalRunner(
number=1, repeat=10, min_repeat_ms=0    #, enable_cpu_cache_flush=True
),
),
}
target = "llvm -mcpu=core-avx2"
========================
my perfermance
inference time
pytorch: 0.09s
tuned-tvm:0.22s

Please ask questions on the forum.


Thoughts on how to convert this Bash HG to Zsh?

I found (what I believe) is a Bash instruction on how to include the mercurial patch information on the CLI, but I can't figure out how to include it in my Zsh.
Any thoughts on this?
link
hg_ps1() {
    hg prompt " ({patch})" 2> /dev/null
}
export PS1='$ \W$(hg_ps1):

I'd love to be able to track patches and which one is at the tip, etc. I think anyone who did what you did is probably interested and so I thought I'd push this query up to you as a likely far senior coder to me; I'm in my first year, so legitimately you are more skilled than me.

Hi @iarkhanhelsky sorry for the delay. Your email notification got burried. When you closed it, then I found you. Thank you for your answer. I'm not entirely certain how to apply your solution to what I have. I am not a bash buy and what you wrote is simple and elegant, but to me I won't know where to place it.
I'm using the Obraun theme and my code in the theme is:
if [ "$USER" = "root" ]; then CARETCOLOR="red"; else CARETCOLOR="blue"; fi

local return_code="%(?..%{$fg[red]%}%? ↵%{$reset_color%})"

PROMPT='%{$fg[green]%}[%*]%{$reset_color%} %{$fg_no_bold[cyan]%}%n %{${fg_bold[blue]}%}%{$fg_no_bold[magenta]%}➜%{$reset_color%} %{${fg[green]}%}%3~ $(git_prompt_info)$(hg_prompt_info "{patch}")%{${fg_bold[$CARETCOLOR]}%}»%{${reset_color}%} '

RPS1="${return_code}"

ZSH_THEME_GIT_PROMPT_PREFIX="%{$fg[red]%}‹"
ZSH_THEME_GIT_PROMPT_SUFFIX="› %{$reset_color%}"

ZSH_THEME_HG_PROMPT_PREFIX="%{$fg_bold[magenta]%}hg:(%{$fg[red]%}"
ZSH_THEME_HG_PROMPT_SUFFIX="%{$reset_color%}"
ZSH_THEME_HG_PROMPT_DIRTY="%{$fg[magenta]%}) %{$fg[yellow]%}✗%{$reset_color%}"
ZSH_THEME_HG_PROMPT_CLEAN="%{$fg[magenta]%})"

I super appreciate your feedback and I'm thankful to have it, but sadly I'm not sure where to drop it. Perhaps a tiny bit more guidance? I've included my code assuming the addition you suggest will get dropped into this mess some where. FYI I did not write this code I simple smashed together two other people's code and found I made progress, but couldn't figure out how to get the patch part in too.
Please and thank you!!

Hi again!
It's super simple. Look at looooong string assigned to PROMPT. Something called hg_prompt_info already here: $(hg_prompt_info "{patch}").  I don't know what it is excactly but it looks like something you looking for. So you already have function call with same parameter ({patch}). You just need to ensure if this hg_prompt_info really works. Or replace with my function from answer above.
Try to comment this PROMPT and define your own more simple PROMPT just to see how things work.
Try this for start:
function hg_ps1() {
    echo `hg prompt " ({patch})"`
}

export PROMPT='$ %1~ $(hg_ps1):'

You can change your .zshrc in your favorite editor and just source it any time you need to apply changes with following command in your terminal:
$ source ~/.zshrc

Cheers!


Problem?

Challenge Prioritize One Style Over Another has an issue.
User Agent is: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0.
Please describe how to reproduce this issue, and include links to screenshots if possible.
My code:

Hello World!

Please check the FreeCodeCamp chat before posting here. ☺
The problem is that in the style tags, "pink-text" has no dot (.) before it. This is the class selector.

@CullenIO Thanks.
@DrineTN Github Issues are not for Code Help, please follow our guidelines and seek assistance in the Help Chat.
Thanks and Happy Coding!

Okey Thanks :+1:


k8s resources managed by Tilt vi k8s_yaml have no unique id?

I have k8s_yaml(local(helm template....)) going on. tilt pushes these resources to k8s and I see this label on everything app.kubernetes.io/managed-by: tilt, however there is no unique identifier, seems like there should be one, should you end up in a situation whereby tilt for whatever reason is unable to cleanly remove all those tracked resources on down and someone has to go in an remove all the references, then it could be qualified on a kubectl delete w/ the unique id label.
I see Deployments and Pods have something like tilt.dev/pod-template-hash=5bcff0f9584f00377588. Might be good to have some unique thing like this on any other k8s object it applied to a cluster. Then I could kubectl delete -l tilt.dev/invocation-hash=5bcff0f9584f00377588 -n namespace with confidence I got everything from that tilt k8s_yaml invocation

Good question!
One pattern I've seen teams use for this is to use Helm or Kustomize to inject their own labels. e.g.,
id = os.environ.get('JENKINS_BUILD_ID', '')
k8s_yaml(helm('./chart-dir', set=['build.id=%s' % id]))

And then use those labels to associate everything with a particular piepline.
The idea of having a tilt.dev/invocation-hash is a good one! It's what Tilt used to do. But it leads to undesirable behavior. For devs, it's important that if you run tilt up twice in the same directory, Tilt can cache as much as possible and attach to existing pods (rather than restarting them).
So Tilt will probably never do this by default. But we want to make sure there are good APIs for doing it that integrate well with existing k8s tooling (like Helm or Kustomize)
Does that work for you?

thanks @nicks, I'm actually already doing something like that, but imagine the chart above in your example alters the object names based on that buildid, it leads to orphans no longer tracked by tilt: https://github.com/windmilleng/tilt/issues/3035


Chore/misc work (resolves #79)

Added client side event listeners and socket factory.  Creator_id is now stored with a new game.  The creator of a game has their invite initialized to accepted (1).  POST /invitations now utilizes helpers.resolveInvite to resolve invite value based on req.body.accept.

This doesn't use socket-io correctly in angular right now, not merging


Avoid using deprecated ContourSet attributes

🚀 Pull Request
Description

For Matplotlib v3.8 the ContourSet class had a re-write (https://github.com/matplotlib/matplotlib/pull/25247) and various of its attributes will be deprecated in the upcoming release.  Relevant release notes are
https://matplotlib.org/devdocs/api/next_api_changes/deprecations/25138-AL.html
https://matplotlib.org/devdocs/api/next_api_changes/deprecations/25247-AL.html
https://matplotlib.org/devdocs/api/next_api_changes/deprecations/26399-REC.html
iplt.contourf uses some of these attributes so this PR updates it to work with the new ContourSet.

Consult Iris pull request check list

Thanks @trexfeathers that was quick! 🚀


Transform widget is broken in master

The current master branch of Flutter seems to have a bug in the Transform widget that breaks rendering. See issue 18376 for more information (this new issue is not redundant, issue 18376 is for a separate bug but in trying to fix it this new bug was uncovered).
This new bug breaks the app developed in the article https://medium.com/flutter-io/perspective-on-flutter-6f832f4d912e
Switching to flutter channel beta fixes the bug.
$ flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel master, v0.5.7-pre.50, on Mac OS X 10.13.5 17F77, locale en-US)
[✓] Android toolchain - develop for Android devices (Android SDK 27.0.3)
[✓] iOS toolchain - develop for iOS devices (Xcode 9.4)
[✓] Android Studio (version 3.1)
[✓] IntelliJ IDEA Community Edition (version 2018.1.5)
[✓] Connected devices (1 available)
• No issues found!

I can reproduce this in both a physical android device and on an iOS simulator.

Same here. Tested on physical Pixel 2 XL and iOS simulator. Both fail.
You can see this easier if you run the following gist (also from the article linked above) -- https://gist.github.com/wmleler/cfc18137ce7db77d7e599e179dee4619#file-main2-dart
The app is initially rendered correctly. Do a drag gesture on the screen and the app will rotate in 3D, but the app itself will stop rendering. If you double-tap on the screen, then the rotation is reset and the app will again be rendered correctly.

This was introduced by me in f5f055113ad92836985f36d4adabddb6a22e2c5c.  Removing the insertion of an AnnotatedRegionLayer into the layer tree fixes the issue.  Still investigating what the cause is.

I've narrowed down the issue to a problem in the RenderAnnotatedRegion:
Removing the addition of the annotated region layer does not fix the transform issue.
  @override
  void paint(PaintingContext context, Offset offset) {
    if (child != null) {
      final AnnotatedRegionLayer<T> layer = new AnnotatedRegionLayer<T>(value, size: sized ? size : null);
      //context.pushLayer(layer, super.paint, offset);
      super.paint(context, offset);
    }
  }

Only if alwaysNeedsCompositing is also set to false does the transform being working again.  Setting alwaysNeedsCompositing to true when the layer is still added cause exceptions to be thrown, but only breaks the transform for the appBar.

The error message is:
flutter: ══╡ EXCEPTION CAUGHT BY RENDERING LIBRARY ╞═════════════════════════════════════════════════════════
flutter: The following message was thrown during paint():
flutter: Object has been disposed.
flutter:
flutter: When the exception was thrown, this was the stack:
flutter: #0      Canvas.restore (dart:ui/painting.dart:2879:41)
flutter: #1      RenderPhysicalModel.paint (package:flutter/src/rendering/proxy_box.dart:1645:16)
flutter: #2      RenderObject._paintWithContext (package:flutter/src/rendering/object.dart:2024:7)
flutter: #3      PaintingContext.paintChild (package:flutter/src/rendering/object.dart:131:13)
flutter: #4      _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.paint (package:flutter/src/rendering/proxy_box.dart:127:15)
flutter: #5      RenderObject._paintWithContext (package:flutter/src/rendering/object.dart:2024:7)
flutter: #6      PaintingContext.paintChild (package:flutter/src/rendering/object.dart:131:13)
flutter: #7      _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.paint

This error can be reproduced by placing the following render object into an application.  If alwaysNeedsCompositing is true, then the screen goes blank when a rotation is applied.  If false, then the transform does not update the children.

class RenderAncestor extends RenderProxyBox {
  @override
  bool get alwaysNeedsCompositing => true;

  @override
  void paint(PaintingContext context, Offset offset) {
    context.pushLayer(new OffsetLayer(), super.paint, offset);
    //super.paint(context, offset);
  }

I checked against some commits in early jun and may and I can still reproduce the error with the above snippet

This is also doesn't happen if the perspective line is removed
Matrix4.identity()
        //..setEntry(3, 2, 0.001) // perspective - removed
        ..rotateX(0.01 * _offset.dy) // changed
        ..rotateY(-0.01 * _offset.dx),

... it also doesn't happen if you set that entry after the rotations... I'm thinking this might not be a bug

Matrix multiplication is not commutative. Moving the setEntry method call
after the rotations is not a workaround because the perspective doesn't
happen if you do that.
This code, with the perspective line first, has worked for at least 8
months. It still works just fine in the current beta version. I know of at
least two articles that have been published using this code. So this
definitely looks like a bug.
On Thu, Jul 5, 2018 at 7:54 PM, Jonah Williams<EMAIL_ADDRESS>wrote:

... it also doesn't happen if you set that entry after the rotations...
I'm thinking this might not be a bug
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/19062#issuecomment-402910497,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADEtaF9g0OWdXh-6Vb5nfGmba87hEicks5uDtFTgaJpZM4VB6Mv
.

@wmleler Right, moving the perspective produces an entirely different matrix - But that matrix renders correctly.  So for some reason the particular matrix being generated by the example does not work in general, but only with certain render objects as children.  So you're right, it's a bug somewhere, but it wasn't introduced recently.

A more minimal reproduction:

class Example extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final matrix = Matrix4.identity();
    matrix.setEntry(3, 0, 0.0003);
    return Transform(  // Transform widget
      transform: matrix, // changed
      alignment: FractionalOffset.center,
      child: new Ancestor( // remove and it renders correctly
        child: new Material(
          child: new Container(
            color: Colors.red,
            width: 200.0,
            height: 200.0,
          ),
        ),
      ),
    );
  }
}

class Ancestor extends SingleChildRenderObjectWidget {
  const Ancestor({Widget child, Key key}): super(child: child, key: key);

  @override
  RenderObject createRenderObject(BuildContext context) {
    return new RenderAncestor();
  }
}

class RenderAncestor extends RenderProxyBox {
  @override
  bool get alwaysNeedsCompositing => true;

  @override
  void paint(PaintingContext context, Offset offset) {
    context.pushLayer(new OffsetLayer(), super.paint, offset);
  }
}

If it wasn't introduced recently, why did it work just fine for at least 8
months and then suddenly stop working recently? I've been using this
program as a demo for a long time.
On Fri, Jul 6, 2018 at 9:06 AM, Jonah Williams<EMAIL_ADDRESS>wrote:

@wmleler https://github.com/wmleler Right, moving the perspective
produces an entirely different matrix - But that matrix renders correctly.
So for some reason the particular matrix being generated by the example
does not work in general, but only with certain render objects as children.
So you're right, it's a bug somewhere, but it wasn't introduced recently.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/19062#issuecomment-403077320,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADEtUHtoPMg3vLGWeCzZ3C1UkMXLX0dks5uD4sagaJpZM4VB6Mv
.

Because I can checkout a commit from two months ago and reproduce the issue with the reduced sample above.  A few weeks ago I changed the app bar which results in the addition of a new layer, that is what caused your code to stop working.  But removing that won't fix the underlying issue, which is what I am trying to do.

That's fine. I was just concerned because when you said maybe this isn't a
bug, it sounded like you didn't think it needed to be fixed.
I look forward to having my code work again soon!
Thanks.
On Fri, Jul 6, 2018 at 10:16 AM, Jonah Williams<EMAIL_ADDRESS>wrote:

Because I can checkout a commit from two months ago and reproduce the
issue with the reduced sample above. A few weeks ago I changed the app bar
which results in the addition of a new layer, that is what caused your code
to stop working. But removing that won't fix the underlying issue, which is
what I am trying to do.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/19062#issuecomment-403095253,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADEtYQ7K0dyTQOw3tgOjD2_sCbgXQLkks5uD5tmgaJpZM4VB6Mv
.

Ahh sorry about that, just the ramblings of someone who spent too long debugging.  Though it is obviously not ideal, removing the appBar from the demo will make it work again for now

Updating the code in published articles probably isn't a good option. I
hope you figure this out and fix it soon. Thanks again.
On Fri, Jul 6, 2018 at 10:32 AM, Jonah Williams<EMAIL_ADDRESS>wrote:

Ahh sorry about that, just the ramblings of someone who spent too long
debugging. Though it is obviously not ideal, removing the appBar from the
demo will make it work again for now
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/19062#issuecomment-403099261,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADEte_d0zGlf-1hPAXv4cARxXTKfMj3ks5uD58pgaJpZM4VB6Mv
.

The difference in removing/adding the AncestorWidget is in whether the TransformLayer uses pushLayer or canvas.transform.  If it is the former, because a child needs to be recompositied, then it uses the transform matrix and the current painting context to estimate the paint bounds for the layer.
According to the engine timeline, when the view isn't painted it is because all of the child paint bounds are empty.  The problem might lie in how these bounds are computed or shared between flutter and the engine.  For reference, a normal frame (top) and a frame with a perspective (bottom). After the preroll which computes bounds, none of the layers are painted

While I assumed the Flutter runners layer tree dump was accurate, what is actually happening is that the DefaultLayerBuilder is not adding the child picture layer when its picture doesn't intersect with the current cullRect.
https://github.com/flutter/engine/blob/f52955c2558a8bc2539192f88d84fe7d339f5d4b/flow/layers/default_layer_builder.cc#L146-L150
The transformLayer updates the cullRect by inverting its transformation and applying this to the current cullRect to produce a new cullRect. (The cullRect beings with the kGiantRect)
https://github.com/flutter/engine/blob/f52955c2558a8bc2539192f88d84fe7d339f5d4b/flow/layers/default_layer_builder.cc#L38-L44
When there is no perspective transform applied, the cullRect produced might look something like Rect.LTRB{-3.33333e+08, -4.71228e+09, 3.33333e+08, 4.71227e+09}, whereas with a perspective we end up will a cullRect like Rect.LTRB{-793.003, -13768.9, -792.997, 14504.9}.  Since the picture doesn't intersect, it isn't drawn. If the TransformLayer doesn't have another child layer, then none of this happens, since it uses the canvas.transform instead.
A reasonable approach might be to detect perspective transforms  just default to the either the kGiantRect or the previous element of the cull rect stack.  (Another possibility is that there is some math is subtly wrong here )
https://github.com/google/skia/blob/dd962a95c5f21cba18a8ef90f2a6f974e2968142/include/core/SkMatrix.h#L1443

Flutter does have a function makePerspectiveMatrix that creates a new
OpenGL perspective matrix. I wonder if using this instead would cause the
same problem? If not, then its implementation might yield some helpful
insights.
I don't use that function because I'm not dealing with a scene with a field
of view or near and far planes. The transformation I'm using is pretty
standard (I've done a lot of 3D graphics, and even wrote a book on it).
I'm looking at the implementation of makePerspectiveMatrix and it just
calls setPerspectiveMatrix, which does the real work. That code sets the
scaling -- entries (0,0), (1,1), (2,2) -- which are safe to ignore. It then
sets (3,2) to a constant –1.0 (that's the entry I set to 0.001), and then
sets (2,3) to an expression.
I'd play around with this, but I'm leaving on a trip tomorrow morning to
give some talks and don't have time.
On Sat, Jul 7, 2018 at 8:37 PM, Jonah Williams<EMAIL_ADDRESS>wrote:

While I assumed the Flutter runners layer tree dump was accurate, what is
actually happening is that the DefaultLayerBuilder is not adding the child
picture layer when its picture doesn't intersect with the current cullRect.
https://github.com/flutter/engine/blob/f52955c2558a8bc2539192f88d84fe
7d339f5d4b/flow/layers/default_layer_builder.cc#L146-L150
The transformLayer updates the cullRect by inverting its transformation
and applying this to the current cullRect to produce a new cullRect. (The
cullRect beings with the kGiantRect)
https://github.com/flutter/engine/blob/f52955c2558a8bc2539192f88d84fe
7d339f5d4b/flow/layers/default_layer_builder.cc#L38-L44
When there is no perspective transform applied, the cullRect produced
might look something like Rect.LTRB{-3.33333e+08, -4.71228e+09,
3.33333e+08, 4.71227e+09}, whereas with a perspective we end up will a
cullRect like Rect.LTRB{-793.003, -13768.9, -792.997, 14504.9}. Since the
picture doesn't intersect, it isn't drawn. If the TransformLayer doesn't
have another child layer, then none of this happens, since it uses the
canvas.transform instead.
A reasonable approach might be to detect perspective transforms just
default to the either the kGiantRect or the previous element of the cull
rect stack. (Another possibility is that there is some math is subtly wrong
here )
https://github.com/google/skia/blob/dd962a95c5f21cba18a8ef90f2a6f9
74e2968142/include/core/SkMatrix.h#L1443
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/19062#issuecomment-403259711,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADEtWcZszzP1Udlp-d-G1d2zy87lL9Eks5uEX59gaJpZM4VB6Mv
.


best FPS for motionless scene?

| Camera Model                       | D435 |
Hello,
I am using a D435 cam to capture motionless scenes, and I am wondering what would be the best FPS to use in this case? Are there any other parameters that are recommended to use when capture motionlessscene, to improve depth quality and precision?
Thank you and regards,
Emmanuel

In general the exposure time should be dictated by the lighting. So in normal lighting this may be about 5ms for the d435. That means that you can actually set the frame rate to 90fps and there is no benefit to going to shorter frame rate. However with a motionless scene you should definitely use the post-processing temporal filter and you can decrease the alpha parameter to increase the filtering. This will improve the results about 3x.

If there is no motion in the scene then 30 FPS should be fine.  If you are using RGB color then there should not be blurring of the RGB image if there is nothing moving in the scene.
For optimal depth accuracy the 848x480 resolution should be used for D435.
If you find that there is noise or holes in the image then you can improve the quality of the image by applying post-processing filters to perform enhancement functions such as hole-filling.
If possible, avoid fluorescent lights such as ceiling strip lights, which may flicker at frequencies that are hard to see with the human eye and create noise on the image.  The ideal lighting may be LED lights such as those used in photography studios, as doing so should reduce shadows in the scene.

Thank you for your answers! And the exposure time for the depth cameras shouldn't be increased when there is no motion?

I am trying to play with the temporal filter on realsense viewer, modifying the alpha parameter, but don't see any difference at all. Should I reset the cameras or so?

@agrunnet can give better advice on exposure times than I can.  I would add the following points though:

An exposure of 5 ms for normal lighting is suggested above.  In Intel's excellent camera tuning guide for the 400 Series cameras, which @agrunnet co-authored, Section 15 on the bottom of the final page states that in bright sunlight the exposure can be reduced to near 1 ms (which can also reduce motion artifacts).

https://www.intel.com/content/dam/support/us/en/documents/emerging-technologies/intel-realsense-technology/BKMs_Tuning_RealSense_D4xx_Cam.pdf

Manually setting exposure may have an effect on FPS.

https://github.com/IntelRealSense/librealsense/issues/1957#issuecomment-400715579
In regard to making changes in the Viewer to the temporal filter, have you enabled the post-processing filters by setting the parent Post Procesing Filters option to On (blue color) as well as the temporal filter itself, please?

Hi @EmmanuelCos   Do you still require assistance with this case please, or can it be closed?   Thanks!

Case closed due to no further comments received.


[BUG] [Remote Store Migration] Remote index settings are not applied if replica count is decremented during an ongoing migration

Describe the bug
Today, we apply remote store index settings on an index migrating from docrep if the following conditions are met:

All primary shards of the index are in STARTED state and are on remote nodes
No RELOCATING replica shard copies
All STARTED replicas are on remote nodes

We use the existing IndexMetadataUpdater flow invoked by AllocationService to perform this update. This code path is only invoked if the cluster is in:

MIXED mode
Direction is set to REMOTE_STORE

We have recently found an issue wherein the index settings are not applied because:

Primary moved over to remote nodes
Replica count was reduced to 0 from 1
Replica was never migrated to remote nodes (since the shard copy was deleted with the replica count reduction)

The code flow for decreasing replica count does not seem to be flowing through the RoutingAllocation logic and the IndexMetadataUpdater path was never executed.
Related component
Storage:Remote
To Reproduce

Create a docrep enabled cluster
Create an index with 1 primary and 1 replica shard
Introduce remote store enabled nodes in the cluster
Move over the primary shard copy from docrep nodes to remote store enabled nodes
Decrease the replica count to 0
Stop all the docrep enabled nodes and attempt to switch compatibility mode to STRICT

Compatibility mode switch would fail with the following error:
can not switch to STRICT compatibility mode since all indices in the cluster does not have remote store based index settings

Expected behavior
Remote Store based index settings should be applied even when the replica count of an index is decreased during the migration process.
Additional Details
Plugins
Please list all plugins currently enabled.
Screenshots
If applicable, add screenshots to help explain your problem.
Host/Environment (please complete the following information):

OS: [e.g. iOS]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

@shourya035 If the replica count was to increase, would the new replica be created on the node with remote store attributes?

@ashking94 Yes. We have that handled. If there is a replica count increase during migration, the new shard copy would be allocated to the remote store enabled nodes directly.


Remove title attributes from xref macros

User story
As an MDN maintainer, I want to convert MDN JavaScript docs from HTML to markdown, so I can edit documentation effectively once MDN content is stored on GitHub. The title attributes currently contain the page's summary in the rendered html. If we stop to do this, it will allow us to generate cleaner markdown.
Acceptance criteria
xref macros that are used in the JS docs can be rendered out without title attributes.
Current output of e.g. {{jsxref("Array")}}:

Array

Which would create noisy markdown and duplicate the page summary into articles where we don't want to maintain the page summary again:
[`Array`](/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array
"The JavaScript Array class is a global object that is used in the
     construction of arrays; which are high-level, list-like objects.")

Desired output of {{jsxref("Array")}}:

  Array

which would generate a clean markdown like this:
[`Array`](/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)

It is assumed that links lacking a title containing the page summary has no effect on SEO. Or in other words: title attributes on links never had benefits in the first place (ping @atopal).
For accessibility, it also seems to rather hurt that we are having noisy titles.
Tasks

[ ] Update jsxref macro

[ ] Update domxref macro

[ ] Update Glossary macro

[ ] Update bug macro

I don't think "cleaner markdown" is a good reason to remove functionality, unless we follow up by adding code to the platform to generate the tooltips automatically on the fly. These are incredibly useful and I don't think we should lose this feature.
Keep in mind how thrilled we were when Microsoft added tooltips presenting data from MDN into VS Code. You're proposing removing this from MDN even though we acknowledge it's a useful feature.
I use them instead of actually visiting pages a few times a day most days, if all I need is a quick reminder what something is. Not just on MDN, but on other sites that do the same thing.

Keep in mind how thrilled we were when Microsoft added tooltips presenting data from MDN into VS Code.

This has nothing to do with VS Code.

You're proposing removing this from MDN even though we acknowledge it's a useful feature.

I've not acknowledged them as useful. I said they have no effect on SEO, they are even bad for accessibility, and they are bad for our conversion to markdown.

The title attributes have been removed from all 4 macros. I think the next step is to render them out. @wbamberg, do we do that here or in https://github.com/mdn/sprints/issues/2522?

I think we should do that in https://github.com/mdn/sprints/issues/2522, and close this one :).

Okay, closing here then.


Repo doesn't shows any language

My Repository with bunch of c++ files has not been detected as c++ language

Is it a private repository? Can you share a link to it?

Sorry for the delay,link is here
github link https://github.com/madclaws/OverCover-Game_Engine
On Fri, Dec 23, 2016 at 8:44 AM, Paul Chaignon<EMAIL_ADDRESS>wrote:

Is it a private repository? Can you share a link to it?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/github/linguist/issues/3401#issuecomment-269016109,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQ_vhzQS6StYmwXWeBxgRWJz77aOtOhaks5rK_qLgaJpZM4LU6ls
.

Only programming and markup languages are part of the language statistics and displayed in the language bar. The 2 files in your repository are XML files, which is considered a data language.

Sorry That was master branch link .The files are in Development branch.
here is the link.
https://github.com/madclaws/OverCover-Game_Engine/tree/development/OverCover
This branch has .cpp files.
On Tue, Jan 3, 2017 at 1:28 PM, Paul Chaignon<EMAIL_ADDRESS>wrote:

Only programming and markup languages are part of the language statistics
and displayed in the language bar. The 2 files in your repository are XML
files, which is considered a data language.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/github/linguist/issues/3401#issuecomment-270229821,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQ_vh7mqMrymundeAUVlh55HgcZdZHxWks5rOr2FgaJpZM4LU6ls
.

Ah. Unfortunately, statistics are only computed for the main branch (which you can redefine to be the development branch though).

By redefining you mean setting it default?
On Wed, Jan 4, 2017 at 2:38 AM, Paul Chaignon<EMAIL_ADDRESS>wrote:

Ah. Unfortunately, statistics are only computed for the main branch (which
you can redefine to be the development branch though).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/github/linguist/issues/3401#issuecomment-270342106,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQ_vh-Sj64soukvlg581ibNW2WHX4m1Rks5rO3atgaJpZM4LU6ls
.

Yes.

Ok thanks
On Jan 4, 2017 5:11 PM, "Paul Chaignon"<EMAIL_ADDRESS>wrote:

Yes.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/github/linguist/issues/3401#issuecomment-270352726,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQ_vh6D0CqvlprbOQ0SF0Z1jOPHqowo1ks5rO4VagaJpZM4LU6ls
.

My repo https://github.com/SidPaliwal/CryptoCurrency-Tracker is not showing any language? Can anyone please resolve this issue !

Please start a new discussion as this issue is old and has already been resolved.


feat(pubsub): implement a throughput benchmark

Implement a benchmark to measure publisher and/or subscriber throughput.
Fixes #4565

This change is

google/cloud/pubsub/benchmarks/README.md, line 41 at r1 (raw file):

the the

typo: "the the"


add --net options for docker build .

fixed 10324
docker could't point a network mode when build a image ,in my case, we are unable to use bridge  network mode because my company's restriction. So when I building a docker image , I could't connect to network in container, which is quite annoying.
So I add --net options for docker build command to use host network mode.
To verify this feature， create Dockerfile like following:

From debian:jessie
RUN /bin/bash -c 'ip addr'

then run:

docker build --net=host .

to get the output the make sure use the correct mode

Signed-off-by: sandyskies<EMAIL_ADDRESS>

Initially I had some hesitation here (still not 100% sold), but I think this should be ok.
I can't see why this would break the image portability.
The portability of the build itself is probably still fine as people can rely on the same kind of functionality that networks provide (DNS discovery) even without this change.

Thanks @sandyskies! Following the discussion on https://github.com/docker/docker/issues/10324 I'm not sure we should implement this though; there's quite some concerns around adding this option, but let's wait for other maintainers to comment here as well

I think --net=host options is what most guys want most as we can see in the issue mentioned about.   In some occasion, bridge network mode is not allowed because of security reason and lack of ip resource.  So if some guys want to build a image from a Dockerfile in this particular occasion, he just can't connect to network, which makes him unable use apt-get or yum command to manager software.
A solution to this is to run a container with --net=host option, and finally commit as a image. So I   think  using --net=host option when build a image from Dockerfile will  be just fine, otherwise people will use the way I mentioned about  to achieve this purpose.  @cpuguy83  @thaJeztah

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "master" git@github.com:sandyskies/docker.git somewhere
$ cd somewhere
$ git rebase -i HEAD~2
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "master" git@github.com:sandyskies/docker.git somewhere
$ cd somewhere
$ git rebase -i HEAD~2
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

ping @tiborvass @calavera could you have a look at this please? what are your thoughts?

It is impossible to install uhd-host Ubuntu package during "docker build" as there are missing files that are required by it (/proc/sys/net/core/rmem_max and /proc/sys/net/core/wmem_max). This files are created by --net=host option when calling docker run.

@ptrkrysik  Can this PR fix ur problem or not？

I messed this PR with issue that there is no --net=host during 'docker build'. The discussion here seemed much more fruitful than in #10324 (which messes two separate issues). Sorry for confusion.

We just discussed this PR in our maintainers review session, and would like to look into the use-cases in https://github.com/docker/docker/issues/10324 to see if this is the best solution, or if there are other solutions that may be better. @justincormack is going to have a look at those, and @vdemeester has some alternative approaches that may be worth investigating.

There seem to be a bunch of reasons for this feature request mainly discussed in #10324, will try to summarise:

People who have desktop hosts that do not work with docker networking usually due to VPN settings outside your control, so they use --net=host for all docker run commands, but cannot build.

If anyone in this situation is using a Mac, then we have VPN mode in the new Docker for Mac, which should fix this by doing all network requests from the host. If you have this problem and use a Mac, please sign up on https://beta.docker.com/ and email<EMAIL_ADDRESS>mentioning this issue and we can give you an accelerated invite to test this. This will be available for Docker for Windows in future as well, and we will try to support any issues with VPNs here.

People with a similar issue on AWS/other clouds.

This does not seem to be a common problem, and I think the cloud boxes are just not configured correctly and should be fixed. Network isolation is a normal Docker feature and should work, and --net=host is normally only required for a few use cases, such as higher performance on 10Gb networking, but this does not apply to build.

People who want to disable networking for build for full reproducibility.

This is a pretty unusual use case, I quite like it, but I don't know that it is best addressed by a patch that allows more networking options.

People who want to run local services that run while a build is taking place, for example a database to run tests against.

This is not the recommended way to run your tests. You should run tests using docker run using the built artefact, not at build time. This will not work with an external builder, and means that your build is not self contained. Build should be limited to just build and potentially small self contained tests, not integration tests. We also do not want to support things in build that cannot be built elsewhere because they require additional services, for example as automated builds on services like Docker Hub.

People who want to modify the hosts file during a build to point a name at an external host without using DNS.

This PR does not address this. There are workarounds discussed in the issue, which are a bit ugly but will work if people really need to do this.
Overall I think that adding features to support what are essentially not properly working docker installs that do not have working network isolation, is probably a mistake, as there does not seem to be any justifiable use case on  working docker install, so I have to recommend that we do not go ahead with this PR.

@justincormack   Ur summarise doesn't include my use case. The commany I work for has a strict security policy ,iptable_nat is not allow to use in production environment, and we are not allow to allocate ip freely. Therefor bridge network mode is not a option in our production environment, host network mode is the only one choice(We consider performance as well) .   Without this pr, there is no way I can use networking When build a image from Dockerfile.
I think many people have  the same use case as I do, include cloud vm u mentioned in number 2( I don't agree about that u think this is not a common issue. Cloud providers providing a guest os that bridge network mode won't work should be common issue.)

@sandyskies It is not really recommended that you do builds on your production servers, you should be aiming to do them in your CI pipelines. I don't think there is any security reason why your CI machines should not use NAT in general, even if production is restricted like that.
Can you give me an example of a cloud provider guest image that does not work with bridged networking?
Note that you should be able to use bridged networking without NAT as well if you allocate routed IP addresses to the bridge (ipv4 or ipv6).

@justincormack  As I mentioned ,  routed IP addresses could not be  allocated freely in my company.
In #10324
junlian1 mentioned that:
+1 --net=host
Also, on a cloud vm. run works with --net=host, but I can't build a docker container.
michaeljoy  mentioned that:
+1 --net=host
"docker build" does not work often times in various permutations of AWS EC2 VPC's as well, while docker run works perfectly fine on 1.8.1. The divergent networking behavior between docker build and docker run needs to be sorted.
I don't think this is just a coincidence.

@justincormack Another use case:
Users who build images with dependencies on private rubygems servers and/or npm repositories, and where they are hosting said repositories inside docker.
Workarounds include passing IP addresses to docker build via --build-args, or bypassing ruby/npm repositories' HTTP interfaces and reaching directly into their file volumes.

@rkuzsma that's not a use case that we want to support; building a Dockerfile should be reproducible, and requiring other containers or services to be started in order to build the Dockerfile make them non-reproducible, unless you're in exactly the same setup, so not something we want to support.

@sandyskies you say ""docker build" does not work often times in various permutations of AWS EC2 VPC's as well, while docker run works perfectly fine on 1.8.1" - can you give me more information about the EC2 setup that causes an issue? There may well be some other ways in which we can resolve the issue in EC2 if we have some more information.

@thaJeztah, the use case you're rubbishing comes from people who are

already hacking it in via other means which also aren't reproducible, and
building containers for their own use, thus not polluting the public with images the public aren't reproducible.

I think you can help them out, and leave it to the community to insist on reproducibility-from-Dockerfile from their image providers if that's what they want.
I don't think you need to maintain an architectural wall to keep the riff-raff out, at the expense of helping enterprise users who'd very much like their ten minute npm install from node:4 to go faster.

@garthk do the workarounds @rkuzsma mentions not work for you, they seem like good designs to me? Also you could run a DNS server on the build host to give the addresses of the services. Removing network isolation is a rather drastic way of passing a different address in.

I'm not planning on using build --net=host, @justincormack; rather build --net=customnet so I can resolve containername.customnet in my build. I'll try a hack-around with --build-args as suggested, while maintaining build --net is reasonable and won't harm the ecosystem.

@justincormack I understand your recommendation not to move forward, but is there a workable solution for those of us on a restrictive VPN? It seems a bit asymmetric that containers can be run with --net=host, but not similarly built. Note that I'm running Docker in a Linux host, so improvements to either Docker for Mac or Docker for Windows aren't workable solutions I'm afraid.

No is temporary, Yes is forever. If you're not sure about a new feature, say no. You can change your mind later.

With that in mind...
It is not agreed on that:

We really need it (ie, there may be other ways to solve this)
It won't cause harm to the ecosystem at large

The quote above is from the guiding principles for the project.
I definitely understand the use case and sympathize with the frustration, but in the end I think we need to close this for now. It doesn't mean it's forever, but I do think we need to explore other ways to solve the problem.

I appreciate the concern, but this has been a problem for quite some time now with little more than a set of issues closed out as dupes. We have a PR that seems to address the problem. And the solution is not without precedent: there's already a way to run containers with --net=host. The PR adds symmetry to existing commands.
I'm open to alternatives, but where is that discussion taking place? I've tried on IRC, but nothing came of it. Unfortunately, my Docker workflow currently requires an absurd number of reboots to get the Docker daemon and route tables back into a pristine state (yes, this could be done via scripts, but I don't want to have to revalidate them after new Docker release in case something changed). And this doesn't include the changes I had to make to my Dockerfile to manually fetch resources from the network because the build process can't access the VPN link at all (something --net=host would fix).
Anyway, if this PR isn't the path forward, I can't force the issue. But it would be nice for a resulting action item so those affected are continually affected indefinitely.

+1 for --net= for build the build command.

@thaJeztah Was this one discussed in maintainer meeting? Can we please schedule it for the upcoming one? Thanks!

What is ur conclusion？

+1 for add --net option for docker build.
In my working environment, there is http_proxy I have to set to make apt works.
I tried the docker on the VMware hosted ubuntu using Bridge VMware networking.
In docker run, I found --net option resolved my issues, and why docker build not support ?

-1, this could create unreproducable builds which is one of the reasons docker is so awesome.
Say for example the Dockerfile uses net host to contact a service on localhost to download arbitary content. Also what does this mean in terms of things building on hub or any other bash executioner as a service.

Unless I'm mistaken (and I'm hardly an expert in Docker so I may very well be), you can already induce the unreproducible build situation. The ADD instruction can take a URL and there aren't any restrictions on that and the Docker bridge is able to access resources on localhost, by default. I was just able to build an image that fetched a file from a local web server.
On the other hand, we also have unreproducible builds by not being able to access any network content. Essentially no images can be built when connected with a Cisco VPN client. Fetching something from localhost is bad, sure. But that's a policy/cultural/people problem that's easily solvable with communication. Not being able to use --net options is a technical hurdle that simply can't be cleared in many environments.

The absence of this option is creating unreproduceable builds for many
people, including me. In some systems docker cannot touch iptables in any
way, which means unless a user is able to specify the network and/or IP the
build will run on, it is very well possible the build instance won't be
able to access the internet. Can't get more unreproduceable than this.
Gonçalo Luiz
On 23 June 2016 at 19:24, Jess Frazelle<EMAIL_ADDRESS>wrote:

-1, this could create unreproducable builds which is one of the reasons
docker is so awesome.
Say for example the Dockerfile uses net host to contact a service on
localhost to download arbitary content. Also what does this mean in terms
of things building on hub or any other bash executioner as a service.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/pull/20987#issuecomment-228139341, or mute
the thread
https://github.com/notifications/unsubscribe/AFPBTvlwkWXuC_AJavbEvS6bOabP4cX7ks5qOs9bgaJpZM4HqP8i
.

I am agree with @gedl .  The absence of --net host may cause much more unportable builds. People use the same Dockerfile ,and they are under different environment, one can connect to network and one are unable to because without this option. Do u think they can build the exact same image from that Dockerfile ?  @jfrazelle

@mrjana @aboch Do either of you have any ideas about how to solve the vps issues that people are having during builds?

Wanted to chime in and say that the lack of --net=host during build is causing issues inside an Azure VM as well. When I do docker run, all is fine and dandy. docker build will fail.

@crosbymichael If the user has VPN enabled it will hijack the main routing table so bridge network which also needs routing may be affected. There is nothing we can do there as this is really the security policy in VPN which in most deployments disables "split tunneling" mode.
As far as users having issues with cloud providers we should try to understand what they are. Because there shouldn't be any and if there is any that should be fixed first because that probably affects docker run over bridge network as well.

@dend Can you explain what issues you are having in an Azure VM when doing a docker build? Is it possible to provide daemon logs when this happens so we can understand the different between docker run and docker build?

@mrjana But, Docker already has a solution for this for "docker run". This issue is about extending that same functionality to "docker build", which would address the issue.

@mrjana I have a Stack Overflow question that documents my case.

I also bump into this limitation today. As others pointed out, I don't see how this feature makes building less reproducible considering that network traffic that is already allowed during a docker build already introduces substantial amount of non-determinism (apt-get update if frequently user on moving targets).

+1 I badly need this.
I need to pull from git repo only accessible via vpn when building my private image.
I can't pull during build or from a container without specifying the --net=host option on running the container!

Hi @	sandyskies  we are reconsidering this - would you like to rebase it and we can look at reviewing and merging it.

Hi @sandyskies  we are reconsidering this - would you like to rebase it and we can look at reviewing and merging it.

I extended this in https://github.com/docker/docker/compare/master...tonistiigi:net-builder to add builder directives for net and add-host. This way author of Dockerfile can define if it should only be used in a special configuration and if the user doesn't pass correct arguments they get an error before the build starts.
# net = none
# add-host = myserver

from ubuntu
run wget http://myserver/foo

The values are comma separated list of keys. Negation is supported with !. host,bridge reads as "host or bridge". !none means any network option but none is allowed.
Let me know if this seems reasonable compromise and I'll add more integration tests.

@tonistiigi that seems like it could be useful in some cases.

Shouldn't the option be called --network to match the corresponding option on the docker run command?
Or does this (--net) option on docker build only do a subset of what docker run --network does?

@Bill It should probably match the new name, but they both do the same thing. This issue and pull request predate the rename of --net to --network in c0c7d5e71586ec8e4d54aef9e061f061e9223cc4.

ping @sandyskies could you have a look at @tonistiigi's comment? https://github.com/docker/docker/pull/20987#issuecomment-253288362

This is being carried in https://github.com/docker/docker/issues/27702, so I'll close this PR

@thaJeztah sorry ，it takes a long time in design-review， as someone else has make the another pull
request ,it is ok to close this PR.

@sandyskies no worries! your commit is preserved in https://github.com/docker/docker/pull/27702, thanks so much for starting the work on this


Homegraph not syncing

I removed all of my devices from the web app, created a new device and tired to 'sync devices' from Google Home - now everything is our of sync.

Try syncing again. The action had got into the state where it wouldn't do any actions until I remove/add somebody to white list

"sync devices" - Sure, syncing devices for TP-Link Kasa
Yeelight, and Nest. The account owner
will need to sync Node-RED. Sorry, an
error occurred while syncing Node-RED.

Try again, and if that doesn't work follow the link in the email I've forwarded to make sure it's enabled for you again.
But It's not my end as it didn't even register as a incoming http request.

Fixed it!


possible race condition in emails()

I have one thread checking for count of unread emails in INBOX, another one is calling emails for all emails. I think the data is getting mixed.
The situation is that i use a thread to check unread counts for all labels (so that application is not held up). In the meantime, user fetches mails for Inbox. It appears that 2 concurrent calls for messages of one label, cause data inconsistency.
Perhaps this is an application issue, but i thought i would just point it out to you.

This issue was moved to gmailgem/gmail#6