Addressing disconnected communities for edge deletions

Think of edge deletions within a community. These may cause a community to be internally-disconnected. Accordingly, we should mark the community to be refined.
But the issue  I am currently facing is not related to this ...

I have pinpointed the error to the partial resetting of communities (to sub-communities) before the refinement phase. Simply resetting all communities makes this error go away, but doing a selecting resetting causes the disconnected communities issue --- a large number of disconnected communities are created.
I was assuming this issue might be due to out-of-community IDs, i.e., none of the vertices in the community have the same ID as the community ID. This might happen if a vertex leaves its community during the local-moving phase. But it appears this is not the issue.

So, here are the details.

Simply forcing all the vertices to refine eliminated the issue.

handle disconnected communities

Obtain any vertex from each community (no atomic ops needed).
Rename communities based on the ID of any vertex within each community.
Initialize a subset of communities such that each vertex is its own community (as usual).

template <bool DYNAMIC=false, bool SUBREFINE=false, bool RANDOM=false, bool USEPARENT=false, class FLAG=char, int CHUNK_SIZE=2048, class RND, class G, class FI, class FM, class FA>
...

...
auto fr = [&](auto u) { return SUBREFINE? cchg[vcob[u]] : B(1); };
if (SUBREFINE && isFirst) {
  swap(ctot, dtot); swap(vcob, ucom);
  leidenSubsetRenameCommunitiesW(ucom, ctot, bufc, x, vcob, dtot);
}

fix tracking of changed communities
This resulted in some disconnected communities.
// @param cchg communities that have changed (output)
// @param dchg old communities that have changed
template <class G, class K, class W, class B>
inline void leidenSubsetRenameCommunitiesW(vector<K>& vcom, vector<W>& ctot, vector<B>& cchg, vector<K>& cvtx, const G& x, const vector<K>& vdom, const vector<W>& dtot, const vector<B>& dchg) {
// ...

if (SUBREFINE && isFirst) {
  swap(ctot, dtot); swap(vcob, ucom); swap(vaff, cchg);
  leidenSubsetRenameCommunitiesOmpW(ucom, ctot, cchg, bufc, x, vcob, dtot, vaff);
}

handle data race while changing community
The data races in parallel code was doing this ...
/**
 * Move vertex to another community C.
 * @param vcom community each vertex belongs to (updated)
 * @param ctot total edge weight of each community (updated)
 * @param x original graph
 * @param u given vertex
 * @param c community to move to
 * @param vtot total edge weight of each vertex
 */
template <bool REFINE=false, class G, class K, class W>
inline bool leidenChangeCommunityOmpW(vector<K>& vcom, vector<W>& ctot, const G& x, K u, K c, const vector<W>& vtot) {
  K d = vcom[u];
  if (REFINE) {
    W ctotd = ctot[d];
    W ctotc = ctot[c];
    W btotd = ctotd - vtot[u];
    W btotc = ctotc + vtot[u];
    if (ctotd!=vtot[u] || !ctotc) return false;
    bool okLeave = __atomic_compare_exchange((int64_t*) &ctot[d], (int64_t*) &ctotd, (int64_t*) &btotd, false, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST);
    if (!okLeave) return false;
    bool okJoin  = __atomic_compare_exchange((int64_t*) &ctot[c], (int64_t*) &ctotc, (int64_t*) &btotc, false, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST);
    if (!okJoin) {
      #pragma omp atomic
      ctot[d] += vtot[u];
      return false;
    }
    vcom[u] = c;
  }
  else {
    #pragma omp atomic
    ctot[d] -= vtot[u];
    #pragma omp atomic
    ctot[c] += vtot[u];
    vcom[u] = c;
  }
  return true;
}


fix(toast): description of offset property has been added

Pull Request Test Coverage Report for Build<PHONE_NUMBER>2
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.006%) to 83.412%

Totals

Change from base Build<PHONE_NUMBER>0:
0.006%

Covered Lines:
10112

Relevant Lines:
11135

💛  - Coveralls


Improve readability and error messages

Summary
This PR improves general readability (mostly adding whitespaces and removing dead code) and brings consistency to error messages.
Depends on #14.

@victorkirov Rebased and ready to be reviewed.
Depending on how you wanna treat error messages, some of these changes could be considered breaking. If you prefer, I could combine this PR with #16, just let me know.

@victorkirov Thank you for updating the branch!

@victorkirov Given that other breaking changes were merged to develop since the latest release (#10), maybe we can consider merging this? I'd love for you to give me feedback on #16 after too.


Screen larger then some length is not captured.

For example if I open whatsapp then first ~x contact chats are displayed, not all.
Open some large static webpage, only some content is copied
What can be reason behind this?

Could you please attach a captured image and exact command line invocation?


⚠ Bofrost.at has degraded performance

In 946f385, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1844 ms

Resolved: Bofrost.at performance has improved in 5ac95bf after 6 minutes.


Prefix query new format

Use field value instead of prefix to get rid of deprecated warning.

The PR was not quite correct. The query

... is still valid and not deprecated according to the docs.
No worries. I will create a fix myself. Thanks for pointing this out.


Update TREZOR related python packages

Motivation for this change
Things done

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

[X] NixOS
[ ] OS X
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[X] Fits CONTRIBUTING.md.

from travis:
Found duplicated packages in closure for dependency 'protobuf':
  protobuf 2.6.1 (/nix/store/xqyid386bwh1cm7x0my9561829gbii7z-python2.7-protobuf-2.6.1/lib/python2.7/site-packages)
  protobuf 3.0.0 (/nix/store/axx1la20z6dzs4hg5q2nmkbbpkmlnpxx-python2.7-protobuf-3.0.0/lib/python2.7/site-packages)


BAMOE Canvas installtion fails for 9.1 due to extended service pod crashloopbackoff.

Hi,
We attempted installation of BAMOE 9.1 on EKS (v1.28.12-eks-a18cd3a ). We followed IBM's document. Please find link for the document as follows.

Issue :
After running
 helm install my-bamoe-canvas ./canvas-helm-chart --values ./canvas-helm-chart/values-kubernetes.yaml --set global.kubernetesClusterDomain="<YOUR_KUBERNETES_CLUSTER_DOMAIN>" --set global.kubernetesIngressClass="<YOUR_KUBERNETES_INGRESS_CLASS>"
with updated values from terminal extended-service pods keep failing with error log saying expected integer value.
What is Fix ?
To fix above issue we need pass  this environment variable to extended service deployment  Key: "EXTENDED_SERVICES_PORT" Value: 21345 Then pods become up and running.
OR
Upgrade Kubernetes to v1.30.3+
Please find GIF with action attached with Issue and Fix.

Thanks & Regards,
Sachin Karale,
Cloud Solutions Architect,
Decision Management Solutions

Hi @skaraleDMS. This repository tracks issues for Apache KIE, not IBM BAMOE. Please refer to https://github.com/IBM/bamoe/issues.


Attempt to remove flakiness from test

Flaky test
com.twitter.graphjet.algorithms.salsa.SalsaTest.testSalsaWithRandomGraph
What is the test meant for?
The test is meant for testing the SALSA algorithm on a random bipartite graph.
What causes flakiness in this test?
In Lines 270 - 278, a random bipartite graph is being generated. Hash sets are being used to store nodes. Nodes in this context are, randomly generated User-ID's (upto 'maxUserId' in this case). The graph is intended to have 'maxNumLeftNodes' number of nodes on the left, each having a degree of 'leftDegree'.  There's a finite chance that the random integer generator might give equal integers and as Hash Sets only store unique values, the number of nodes created could be less than intended. The change I have made, removes this non-determinism from the test.
How is the flakiness corrected?
Increase the number of random UserId generating iterations and break the loop when the size of Hash Set (containing nodes) becomes equal to the intended size.
NonDex log before the changes
(The test passed when run normally without NonDex)
Failed tests:
SalsaTest.testSalsaWithRandomGraph:298 expected:<SalsaStats{numSeedNodes=1, numDirectNeighbors=64, numRightNodesReached=998, numRHSVisits=21050, minVisitsPerRightNode=1, maxVisitsPerRightNode=227, numRightNodesFiltered=64}> but was:<SalsaStats{numSeedNodes=1, numDirectNeighbors=63, numRightNodesReached=1000, numRHSVisits=21135, minVisitsPerRightNode=1, maxVisitsPerRightNode=223, numRightNodesFiltered=63}>
Failed tests:
SalsaTest.testSalsaWithRandomGraph:298 expected:<SalsaStats{numSeedNodes=1, numDirectNeighbors=64, numRightNodesReached=998, numRHSVisits=21050, minVisitsPerRightNode=1, maxVisitsPerRightNode=227, numRightNodesFiltered=64}> but was:<SalsaStats{numSeedNodes=1, numDirectNeighbors=63, numRightNodesReached=1000, numRHSVisits=21184, minVisitsPerRightNode=1, maxVisitsPerRightNode=232, numRightNodesFiltered=63}>
Failed tests:
SalsaTest.testSalsaWithRandomGraph:298 expected:<SalsaStats{numSeedNodes=1, numDirectNeighbors=64, numRightNodesReached=998, numRHSVisits=21050, minVisitsPerRightNode=1, maxVisitsPerRightNode=227, numRightNodesFiltered=64}> but was:<SalsaStats{numSeedNodes=1, numDirectNeighbors=63, numRightNodesReached=998, numRHSVisits=21097, minVisitsPerRightNode=1, maxVisitsPerRightNode=230, numRightNodesFiltered=63}>
Failed tests:
SalsaTest.testSalsaWithRandomGraph:293 expected:<SalsaStats{numSeedNodes=1, numDirectNeighbors=64, numRightNodesReached=998, numRHSVisits=21050, minVisitsPerRightNode=1, maxVisitsPerRightNode=227, numRightNodesFiltered=64}> but was:<SalsaStats{numSeedNodes=1, numDirectNeighbors=62, numRightNodesReached=997, numRHSVisits=21174, minVisitsPerRightNode=1, maxVisitsPerRightNode=233, numRightNodesFiltered=62}>
Failed tests:
SalsaTest.testSalsaWithRandomGraph:293 expected:<SalsaStats{numSeedNodes=1, numDirectNeighbors=64, numRightNodesReached=998, numRHSVisits=21050, minVisitsPerRightNode=1, maxVisitsPerRightNode=227, numRightNodesFiltered=64}> but was:<SalsaStats{numSeedNodes=1, numDirectNeighbors=64, numRightNodesReached=998, numRHSVisits=21111, minVisitsPerRightNode=1, maxVisitsPerRightNode=232, numRightNodesFiltered=64}>
NonDex log after changes:
(The test fails when run normally without NonDex. It seems that the test deterministically fails now.)
Failed tests:
SalsaTest.testSalsaWithRandomGraph:298 expected:<SalsaStats{numSeedNodes=1, numDirectNeighbors=64, numRightNodesReached=998, numRHSVisits=21050, minVisitsPerRightNode=1, maxVisitsPerRightNode=227, numRightNodesFiltered=64}> but was:<SalsaStats{numSeedNodes=1, numDirectNeighbors=64, numRightNodesReached=999, numRHSVisits=20984, minVisitsPerRightNode=1, maxVisitsPerRightNode=220, numRightNodesFiltered=64}>
Failed tests:
SalsaTest.testSalsaWithRandomGraph:298 expected:<SalsaStats{numSeedNodes=1, numDirectNeighbors=64, numRightNodesReached=998, numRHSVisits=21050, minVisitsPerRightNode=1, maxVisitsPerRightNode=227, numRightNodesFiltered=64}> but was:<SalsaStats{numSeedNodes=1, numDirectNeighbors=64, numRightNodesReached=1000, numRHSVisits=21146, minVisitsPerRightNode=1, maxVisitsPerRightNode=230, numRightNodesFiltered=64}>
Failed tests:
SalsaTest.testSalsaWithRandomGraph:298 expected:<SalsaStats{numSeedNodes=1, numDirectNeighbors=64, numRightNodesReached=998, numRHSVisits=21050, minVisitsPerRightNode=1, maxVisitsPerRightNode=227, numRightNodesFiltered=64}> but was:<SalsaStats{numSeedNodes=1, numDirectNeighbors=64, numRightNodesReached=999, numRHSVisits=21033, minVisitsPerRightNode=1, maxVisitsPerRightNode=223, numRightNodesFiltered=64}>
Failed tests:
SalsaTest.testSalsaWithRandomGraph:298 expected:<SalsaStats{numSeedNodes=1, numDirectNeighbors=64, numRightNodesReached=998, numRHSVisits=21050, minVisitsPerRightNode=1, maxVisitsPerRightNode=227, numRightNodesFiltered=64}> but was:<SalsaStats{numSeedNodes=1, numDirectNeighbors=64, numRightNodesReached=999, numRHSVisits=21056, minVisitsPerRightNode=1, maxVisitsPerRightNode=222, numRightNodesFiltered=64}>
A few observations

Before the change, 'numDirectNeighbors' parameter took different values (62, 63, 64) in different runs of NonDex.

After the change, 'numDirectNeighbors' always takes the value 64 (which is, as intended).

The other parameters are dependent on the execution of the Salsa Algorithm. I checked out relevant portions of the implementation of the SALSA algorithm and couldn't find anything which could lead to flaky behaviour except for the fact that the algorithm itself is non-deterministic, meaning: the decision to visit a particular node is probabilistic (random number generator is used for this). I think, as NonDex affects the sequence of random numbers generated, the test parameter values would be variable when run with NonDex. This will automatically imply test-failures when run with NonDex as the test simply compares the parameter values against a fixed set of values.

There is a possibility that the test hasn't been designed correctly. The expected parameter values may have been wrongly determined by the programmer who developed the test, which is why the test keeps failing deterministically

According to your description, does the test still fail with NonDex after your changes?

Yes, it fails with NonDex after my changes. The test fails when run without NonDex too after my changes.

How did you check that your fix actually removed the flakiness?

I checked the values of the 'numDirectNeighbors' parameter in the test log.
Before making the change:
This parameter would either take the value 64 (the intended value) or 63. It takes the value 64, when the test is run normally. It takes the value 63, when run with NonDex.
After making the change:
This parameter always takes the value 64 (with and without NonDex). But, the test always keeps failing (with and without NonDex) because the value of other parameters don't come out to be, as intended.
Essentially, the change I have made ensures that the 'structure' of the random graph produced is deterministic and as intended. The other aspect of this test is to run the Salsa algorithm over the random graph generated. I didn't make any changes in the implementation of Salsa as I couldn't find any bug in it.

Thanks for the info. The fix here is unlikely to be of any use as of now if the fixed code still fails when run with NonDex. Please do update this PR when you have made more progress.


Can't upgrade helm charts after deployment

I'm using flux to deploy a HelmChart CRD into my k3s setup. The initial deploy works fine, but i update the HelmChart manifest with a new version of a chart the controller doesn't detect this as an upgrade. It attempts to do a new install of the chart, with the same deployment name. Which fails. Using v2 or v3 helm. With:
Error: cannot re-use a name that is still in use
Is this a feature that is planned to be added?

Can you give an example of a before and after HelmChart CR that fails?

I suspect issue is the job uses helm install, which is perform when the args method parses over the helm spec.
https://github.com/rancher/helm-controller/blob/master/pkg/helm/controller.go#L321
To make it more idempotent, we should probably change the args to helm upgrade --install

I dug around some more.. here is a sample when install is present
apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: wordpress
  namespace: default
spec:
  targetNamespace: default
  chart: wordpress
  repo: https://charts.bitnami.com/bitnami
  version: 7.4.0
  set:
    persistence.enabled: "false"
    mariadb.master.persistence.enabled: "false"
  helmVersion: v3

Initial install works fine. When I update the manifest to a new version
apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: wordpress
  namespace: default
spec:
  targetNamespace: default
  chart: wordpress
  repo: https://charts.bitnami.com/bitnami
  version: 9.0.0
  set:
    persistence.enabled: "false"
    mariadb.master.persistence.enabled: "false"
  helmVersion: v3

https://github.com/rancher/klipper-helm/blob/master/entry#L33
I suspect check should be [ $INSTALLED_VERSION != $VERSION ] for the upgrade branch to be executed.
Because of equality comparison the code falls through and goes back to the default execution:
https://github.com/rancher/klipper-helm/blob/master/entry#L33
After the tweak, the upgrade works as expected.
Already installed wordpress, upgrading
+ echo Already installed wordpress, upgrading
+ shift 1
+ helm_v3 --namespace default --repo https://charts.bitnami.com/bitnami --version 9.0.0 --set mariadb.master.persistence.enabled=false --set persistence.enabled=false upgrade wordpress wordpress

Possible fix

Perhaps using helm upgrade --install would work better.
It should be possible to modify values and redeploy.
I am seeing the same error: Error: cannot re-use a name that is still in use.
The weird thing is that I see this error after deleting the helm chart CR.
I made a change to a helm chart and it caused the helm-install job to fail. I deleted the HelmChart Custom Resource and attempted to reinstall when I saw the Custom Resource actually disappear.
Now I can't install that chart.

+1 for this issue. My use case is with jupyterhub on k3s. Deploying initially works fine, redeploying with updates image or what have breaks with Error: cannot re-use a name that is still in use.
On regular k8s we use the helm upgrade --install command for our workflow, so that will probably fix it.

Same issue with same context here...

I stopped using this and moved over to using HelmRelease from the fluxcd folks:
https://github.com/fluxcd/helm-operator-get-started

Seems fixed in klipper-helm v0.2.4 and helm-controller v0.6.3 already ship klipper-helm v0.2.7.
Can this issue be closed? Or problem is still there?

Verified in k3s version v1.19.2+k3s1, above issue is resolved.
Installed openebs chart to validate
INSTALLED_VERSION: 1.8.0
UPGRADED to VERSION: 1.9.0
kubectl describe pod  -n kube-system helm-install-openebs-24mm7  |grep VERSION
      VERSION:          1.8.0

kubectl describe pod  -n kube-system helm-install-openebs-g5vlf |grep VERSION
      VERSION:          1.9.0

Closing this on behalf of @ShylajaDevadiga
@cjellick or I to fix her permissions.


class hierarchy not quite right

In Jadeite for Rowan v3.0, there are a few circumstances where the class hierarchy isn't right. All involve a newly added subclass.

[ ] If two class hierarchies are opened on the same class and a subclass is added to one hierarchy, the new class appears in the other hierarchy correctly, but it is not in alphabetical order.
[x] Aborting a newly added subclass in a hierarchy doesn't get rid of it.
[x] Reloading a newly added subclass in a hierarchy doesn't get rid of it.

The incorrect alphabetization in other browser is in 3.2.12.
In the browser in which you added the new class, it reverted the expand hierarchy to only show the newly created subclass.  This was quite annoying (which could be since I was testing), but would mask if it was in the wrong order in the same browser too.

Finally finally finally found where to make the children of a tree  node appear in sorted order. Buried very deep in the hierarchy gui code.


[WIP] Fix bad spec.

Blargh!

:+1: This spec was erroring, due to the authorization changes breaking the brittle stubbing that was in this spec.

:+1:


Kebab-case client-id and client-secret error messages.

Description of change

Guide to reproduce test results

Checklist

[x] I have self-reviewed this change.
[ ] I have tested this change.
[ ] This change is covered by tests that are already landed, or in this PR.

I think the README needs updated too?


[coroutine] message order, version up

Note

Version: 1.4 -> 1.4.1
Architecture error message comes before source download.

Still, the package works for x64 only.
History

#5597

https://github.com/Microsoft/vcpkg/pull/5597#discussion_r263902107

#5593
#5433

Thanks for the PR!


[BinderTransport] Send correct version to server and verify it

cc @littlecvr

Note to myself: Did a copybara import and this work fine internally


IPVS for kube_proxy

Hello, amazing package!
I am trying to switch the kube_proxy proxy mode to ipvs, here's my hetzner-k3s config file
---
hetzner_token: token
cluster_name: cluster_name
kubeconfig_path: "./kubeconfig"
k3s_version: v1.25.5+k3s1
public_ssh_key_path: ""
private_ssh_key_path: ""
use_ssh_agent: false
ssh_allowed_networks:
  - <IP_ADDRESS>/0
api_allowed_networks:
  - <IP_ADDRESS>/0
schedule_workloads_on_masters: false
masters_pool:
  instance_type: cpx21
  instance_count: 1
  location: nbg1
worker_node_pools:
- name: small
  instance_type: cpx31
  instance_count: 10
  location: nbg1
  autoscaling:
    enabled: true
    min_instances: 0
    max_instances: 10

 kube_proxy_args:
  - proxy-mode=ipvs
  - ipvs-scheduler=lc

Note that ipvs-scheduler here is lc which i've also verified by by sshing into the master node
root@raxy-cpx21-master1:/# cat /etc/systemd/system/k3s.service
[Unit]
Description=Lightweight Kubernetes
Documentation=https://k3s.io
Wants=network-online.target
After=network-online.target

[Install]
WantedBy=multi-user.target

[Service]
Type=notify
EnvironmentFile=-/etc/default/%N
EnvironmentFile=-/etc/sysconfig/%N
EnvironmentFile=-/etc/systemd/system/k3s.service.env
KillMode=process
Delegate=yes
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.

TCP  resolved-staging-cpx21-maste rr
  -> <IP_ADDRESS>:8008            Masq    1      0          0
  -> <IP_ADDRESS>:8008            Masq    1      0          0
TCP  resolved-staging-cpx21-maste rr
  -> <IP_ADDRESS>:9008            Masq    1      0          0
  -> <IP_ADDRESS>:9008            Masq    1      0          0
TCP  resolved-staging-cpx21-maste rr
  -> <IP_ADDRESS>:9091             Masq    1      0          0
TCP  resolved-staging-cpx21-maste rr
  -> <IP_ADDRESS>:http             Masq    1      0          0
TCP  resolved-staging-cpx21-maste rr
  -> <IP_ADDRESS>:https            Masq    1      0          0
TCP  resolved-staging-cpx21-maste rr
  -> <IP_ADDRESS>:8003            Masq    1      0          0
  -> <IP_ADDRESS>:8003            Masq    1      0          0
TCP  resolved-staging-cpx21-maste rr
  -> <IP_ADDRESS>:9003            Masq    1      0          0
  -> <IP_ADDRESS>:9003            Masq    1      0          0
TCP  resolved-staging-cpx21-maste rr
  -> <IP_ADDRESS>:https            Masq    1      0          0
TCP  resolved-staging-cpx21-maste rr
  -> <IP_ADDRESS>:http             Masq    1      0          0
TCP  resolved-staging-cpx21-maste rr
  -> <IP_ADDRESS>:https            Masq    1      0          0
TCP  resolved-staging-cpx21-maste rr
  -> <IP_ADDRESS>:http             Masq    1      0          0
UDP  resolved-staging-cpx21-maste rr
  -> <IP_ADDRESS>:domain           Masq    1      0          0

And when I run ipvsadm command on any of the worker nodes, I get the following output
root@small-146b591af88443ee:/etc/rancher/node# ipvsadm
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn

I am not sure if I have done any configuration mistake but basically I want to run the kube_proxy in IPVS mode for our use-case.  I tried sending some requests to the cluster and I dont see any change in active connections in the output given by ipvsadm command. Any help is appreciated!

Hi, did you make this change on an existing cluster? if yes did you try restarting all the nodes?

Hello,
Yes the changes were made to an existing cluster, let me try to restart all the nodes and see!

Hello, yes same behaviour unfortunately.

I'm not familiar with ipvs with k3s unfortunately so I am afraid I can't offer much help with this :(

Hi @mechaadi  - did you find a solution in the meantime?

Hi, no I just went with NATS protocol, so kubeproxy mode is not needed anymore

Thanks, I'll close then.


Downgrade AKD firmware

Version M_01-04-00-05 is the latest that is qualified by ACS.

Actually, Minarik says the older AKD firmware has some safety issues, and recommends upgrading to the newest version.


Remove GraphQL compiled queries

📖 Description
We only used this GraphQL feature in one project and we are now leveraging Apollo’s Automatic persisted queries.
Which will be added to the boilerplate in a future PR, once the setup is fully functional in a current client project.
🦀 Dispatch

#dispatch/elixir

🦀 Requesting reviewers for this pull request:

@charlesdemers (contributor with 0 commits in the last 90 days and 2 commits overall)
@garno (reviewer for the elixir stack)


Implement toggle switch for propageteAllChildVariables setting

Is your feature request related to a problem? Please describe.
Implement toggle switch for propageteAllChildVariables setting propagateAllChildVariables and disabling/deleting output parameter mappings.
Describe the solution you'd like

For the CallActivity I/O tab, a toggle/slider Propagate all child variables? will be added on top of the output parameter mapping. This toggle will control whether it is possible to have output parameter mappings or not.

Toggle on equals to true, and off equals to false
If the toggle is on, it is not possible to add output parameter mappings.
If the toggle is set to on, existing output parameter mappings will be deleted.
If the toggle is off, the output parameter mapping component will work as usual.

[For new CallActivities created]: the toggle is off as default.

Implementation approach

[ ] Create a new behavior which will add the propgateAllChildVariables property when creating a new CallActivity
[ ] Add toggle switch to the Output Parameters and update them based on toggle switch

(Migration I will deal with in a separate issue, see #252)
Describe alternatives you've considered
See #252
Additional context
Child of #252

Closed via https://github.com/zeebe-io/zeebe-modeler/pull/271


pnp linker fails in yarn plugin

When using the plugin, it throws the type error: pe.ZipOpenFS is not a constructor
Do either of the following options:

fix is
verify that the plugin can be used without the ZipOpenFS
remove support for pnp

Tested it on the berry repository, which uses pop as linker.
It worked as expected and wrote a document successfully.

Added a workaround to avoid the error.
Created https://github.com/spdx/tools-ts/issues/146 to implement a proper fix and support different Yarn versions.


Guide instructions for validator creation have incorrect priv_validator_key.json path

Describe the bug
The instructions for creating a validator on guide.penumbra.zone have a grep command that extracts the validators consensus key.  This currently points to a ~/.tendermint/ path and not the ~/.penumbra/testnet_data path created by pd testnet join.

Closed by #1213


fix(message-input): emoji picker to insert the emoji node into editor

fix(message-input): emoji picker to insert the emoji node into editor

:hammer_and_wrench: Type Of Change

[x] Fix
[ ] Feature
[ ] Refactoring
[ ] Documentation

:book: Description
When an emoji is selected by emoji picker, we currently just insert plain text that does not trigger the emoji plugin to show the exact emoji. it also overwrote the previously rendered emoji. We fix this by using insertContent that allows you to insert the specific node that can be parsed by the plugin. it also makes sure we dont overwrite previous text/ emoji or nodes.
:link: Sources
https://tiptap.dev/api/commands/insert-content

When I open the emoji picker, there is two tooltips that should disappear

https://dialpad.atlassian.net/browse/DLT-1262


Find a bedspace results include overlapping residents in the same property

Context

Changes in this PR
Screenshots of UI changes
Before
After
Release checklist
Release process documentation.
Pre-merge checklist

[ ] Are any changes required to dependent services for this change to work?
(eg. CAS API)
[ ] Have they been released to production already?

Post-merge checklist

[ ] Manually approve
release to test
[ ] Manually approve
release to preprod
[ ] Manually approve
release to prod

 Find a bedspace results include overlapping residents in the same property

@libuk Converting back to draft until CI passes - need to rebase on top of #571

@libuk Ready for you to take a look


Add minnow to UntradeableItemMapping

One minnow is 1/40 of a raw shark and I added a field to the the UntradeableItemMapping to handle cases like this. The price check of minnows will not be 100% accurate at all times because of rounding errors but it will be a lot more accurate than it was before.

Resolves #9802
I'm thinking this should just use floats?

Updated to use floats.


Publish to Maven Central

Starting from May 1, 2021 JCenter will stop working
Describe the solution you'd like
CameraView artifacts should be available outside of JCenter, preferably in Maven Central.
Describe alternatives you've considered
JitPack
GitHub Packages

Jitpack actually says the latest version is 2.1.1, but here it says it's 2.1.2.
How come?

No need to publish Maven central. Need some modification and make your custom library

@AndroidDeveloperLB you found any solution?

@mianaliasjad No idea. I used:
implementation 'com.github.warkiz:IndicatorSeekBar:v2.1.1'


Carma test nondeterministic fail in the CI pipeline tests

Describe the bug
A clear and concise description of what the bug is.
Bug found by the CI pipeline on unreleated branch checks -
=========================== short test summary info ============================
FAILED tests/gentropy/method/test_carma.py::TestCARMA::test_time_limited_CARMA_spike_slab_noEM_pips_no_restriction - assert False
 +  where False = <function allclose at 0x7f617c2aceb0>(0.99, 1)
 +    where <function allclose at 0x7f617c2aceb0> = np.allclose
 +    and   0.99 = <function round at 0x7f617c2a20b0>(0.9945418431237626, decimals=2)
 +      where <function round at 0x7f617c2a20b0> = np.round
===== 1 failed, 387 passed, 1 skipped, 1308 warnings in 180.21s (0:03:00) ======
Error: Process completed with exit code 1.

Observed behaviour
A clear and concise description of what happened.
test fails - check https://github.com/opentargets/gentropy/actions/runs/10946286782/job/30392428897?pr=768
Expected behaviour
A clear and concise description of what you expected to happen.
test succeds
To Reproduce
TBA
Additional context
Add any other context about the problem here.

I can't reproduce it. And it seems in other brunches it is fine.

I think it is fine for now.  We only should set the Ci variable for pytest to expand the test case info that fails.


Blocking call when using ProgressiveResult (asyncio)

What I want to do: send a  heavy payload to a remote component using the progressive result.

What I do: The sender creates a function to send the payload by chunk, register that function with a temp uri then call a receive rpc registered by the Receiver that take the temp uri in parameter. the receive function got the chunk send by the Sender and reconstruct the payload once all pieces have been received.

What happens: the sender block after it calls the receive rcp. ie it blocks while sending stuff if details.progress is not None.

Minimal example: https://gist.github.com/rdebroiz/0143ab027c17cc641ad20cea5238821c

Start first a receiver
python autobahn_progressive_send_block.py receive

then a sender
python autobahn_progressive_send_block.py send

The receiver call a rcp to the sender that just print "pouet" each time it receive a chunk.
On the receiver console all works as expected. On the sender console no ping/pong  message are received until all the chunk have been sent, all the pouet message arrived when all the chunk have been sent as well

What I would expect: receive pouet and ping/pong messages while it is still sending chunks. But the ping/pong just stop until sending all the chunks is finish, then it comes back and the sender receive all the pouet message.

Maybe what'd like is to write something like:
async def send_bytes_by_chunk(payload, details=None):
    if details.progress:
        for i in range(0, len(payload), CHUNK_SIZE):
            await details.progress(payload[i:i+CHUNK_SIZE])
            print("send chunk!")
    else: return payload

ie have an async details.progress()

Yes, you've gotten closer to the answer yourself. I don't know exactly how you'd express that in asyncio off the top of my head, but in Twisted you'd either do @inlineCallbacks and have a bare yield in the loop, or do your own tail-recursion with something along the lines of: reactor.call_later(0, send_more(chunks[1:]))

you'd either do @inlineCallbacks and have a bare yield

This is what I did in the line above (if my understanding of twisted is correct) but it doesn't work because details.progress  does not return a coroutine, it is not async. ie: There is no async keyword in its definition in AP. (nor @inlineCallbacks decorator in the twisted implementation I suppose).

or do your own tail-recursion with something along the lines of: reactor.call_later(0, send_more(chunks[1:]))

Not sure to understand what you mean here, could you be more explicit?

Right, but in Twisted you can just do "yield" inside @inlineCallbacks and it's kind-of-the-same-as re-calling your routine with a "reactor.callLater" -- it lets the reactor "do an iteration" (so, e.g., service any pending I/O or timers).
"Tail recursion" is like you're writing your own loop without a "for" or "while". So you'd chunk out your input and call something like:
def send_one(chunks):
   if not len(chunks):
       return
   send(chunk[0])
   reactor.callLater(0, send_one, chunks[1:])

So then each "reactor loop" you'll send one chunk and give other things a chance to do some work as well.  For example, imagine running 10 of these at once.

Ok I got you now, the equivalent of a "bare" yield in asyncio is await asyncio.sleep(0).  Thanks!

Anyway I'm surprised that such a thing is not already done in autobahn, I think one would expect progressive result being non blocking on both size (progress and on_progress calls) without doing anything, no?

I was going to say that a hint in the doc and the example that it's the user's responsibility to yield if needed to the event loop in detail.progress  would have helped me.
It's kind of already there. Maybe a comment to emphasize this point would be great:
# In autobahn-python/examples/asyncio/wamp/rpc/progress/backend.py

        async def longop(n, details=None):
            if details.progress:
                for i in range(n):
                    details.progress(i)
                     # Yield to the loop here,
                     # otherwise it will block until all `details.progress` calls
                     # has been done.
                    await asyncio.sleep(1)

Also what confused me, I think, is that it's not needed  for on_progress, The event loop got the hand back after each call of on_progress even if you don't explicitly yield to it. It would be good to have the same behavior on both side.

All of this behavior has nothing to do with Autobahn, but with async programming.


include that retrain_full = True does not include the user provided validation data in the docs.

          It'd be worth including that `retrain_full = True` does not include the user provided validation data in the docs.

Originally posted by @RossDeVito in https://github.com/microsoft/FLAML/issues/735#issuecomment-1735978213

I am not able to find the supported documentation for this issue.

https://microsoft.github.io/FLAML/docs/Use-Cases/Task-Oriented-AutoML#resampling-strategy

Sure. Assigned.


Backward Incompatible Order of Get Request keyword

There was addition of json parameter in the Get Request keyword, but it was added in the argument before params parameter. It means that the positional argument which user expects to be set as params actually becomes json.
Previous signature get_request(self, alias, uri, headers, json, params, ...)
Backward compatible signature should be get_request(self, alias, uri, headers, params, json, ...)

I guess now it's too late to change since would break again the compatibility

Actually also the PUT keyword has not the same order of parameters as the POST :(

What's the plan on this ticket? How do you guys want to manage it?

As you can see the new Keywords structure followed completely the original requests order so this will be handled by 0.8 release.


feat: hide Chat Participant entry

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 29.33%. Comparing base (35ade24) to head (d7a5bad).

Additional details and impacted files
@@           Coverage Diff           @@
##              dev     #161   +/-   ##
=======================================
  Coverage   29.33%   29.33%
=======================================
  Files          70       70
  Lines        4305     4305
  Branches       88       88
=======================================
  Hits         1263     1263
  Misses       3042     3042

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


[qwik-graphql-tailwind] P1: Search On Profile Page Needs Fixed And Remove Double Profile Page

For Milestone 2: searching on the profile page doesn't find results but also shows a 2nd profile page on the same page

Currently, can't reproduce this issue locally and on production. I will suggest another check to see if the last build fixed it. @kenslachtajr @dustinsgoodman

I didn't see this in our demo. Seems like maybe an issue with the deployment.


Numpy dimension error

Got this error after install the latest version, can you please figure out any thing wrong for my installnation? ValueError: numpy.ndarray size changed, may indicate binary incompatibility. Expected 88 from C header, got 80 from PyObject

Hi @DennisBang, could you please provide your installation details (how you installed--pip or setup.py, which Python version, Anaconda or standard Python, etc.), the function you were calling, the input to that function, and a full stack trace? That will help me figure out what the issue is. Thanks!


Update map style

Increase qwant-basic-gl-style version to include latest changes about city hierarchy (https://github.com/Qwant/qwant-basic-gl-style/pull/118) and clickable POIs (https://github.com/Qwant/qwant-basic-gl-style/pull/117)
Also remove ref to the poi-level-no-name layer as it doesn't exist anymore.

@amatissart yes, I planned to open that separately.


Establish Screenshot/image Guidelines

Guidelines for now: (cc @hollyschinsky )

Take screenshots in as png.
If using the full window, leave shadow
If using partial shadow, feel free to crop the shadow out


fixing rollbar error when only destroyed records present

We have been getting an error from rollbar when the record_syncer runs complaining of an infinite value in the JSON. Turns out that we had a number of deleted records with no other record changes, making the percentage in the rollbar log infinite. Since deleted records aren't related to other records processed by the syncer, percentage isn't meaningful in this case.

Premature! Closing until this error gets investigated a little further.


Expose underlying data stream in h2quic

Background
When using HTTP/2, http.Request and http.ResponseWriter do not implement http.Hijacker.  This makes sense in the context of TCP because the stream multiplexing happens outside of the wire protocol; the call to Hijack would return a TCP connection over which multiple request/response cycles travel, not just the one being hijacked.  As such, it is often said that HTTP/2 and Hijack are fundamentally incompatible.
In the context of QUIC, this is no longer true.  Each request/response cycle is mapped to its own OSI Layer-4 stream, which can be manipulated independently of others.
As such, HTTP/2 over QUIC is not fundamentally incompatible with Hijack-like semantics.
Proposal
I would like to propose a mechanism for exposing the quic.Stream that underpins HTTP/2 over QUIC, similar to the Hijack semantics in net/http.
The use-cases for this feature are mostly the same ones as for WebSocket.  Nevertheless there are a few important design considerations:

This is NOT a proposal to implement WebSocket.  The intent is not to expose message-oriented semantics, nor any of the special features proposed by the protocol.  The WebSocket spec contains too many corner-cases that map onto QUIC and HTTP/2 quite poorly.  Rather, the idea is to expose the quic.Stream directly, enabling bidirectional streaming.
This is NOT a proposal to implement http.Hijacker.  Implementing http.Hijacker sends a strong message that this library can be used interchangeably with standard transports.  This is likely to break things that don't expect separate streams for headers and data, e.g. gorilla/websocket.  I propose instead to make the data stream available to those who are intentionally looking for it, while making it clear this "thing" behaves differently from Hijack.

Instead of implementing Hijacker, I propose the following:
type DataStreamer interface {
    DataStream() quic.Stream
}

I have to admit to a small bit of pleasure that the interface is so simple.  Used in conjunction with http.ResponseWriter, application developers can both send response headers and enjoy bidirectional streaming with a familiar interface.
Consider the following example, which shows a homegrown protocol for negotiating such a connection upgrade:
func handler(w http.ResponseWriter, r *http.Request) {
    if r.Header.Get("Connection") != "Upgrade" || r.Header.Get("Upgrade") != "QUIC-Stream" {
        http.Error(w, "raw QUIC stream required", http.StatusUpgradeRequired)
        return
    }

    w.WriteHeader(http.StatusSwitchingProtocols)  // this writes to the header stream

    s := w.(h2quic.DataStreamer).DataStream()
    useStream(s)
}

Final note
@lucas-clemente, @marten-seemann and contributors:  I wanted to open a discussion before submitting a PR.  I already have this working on a private branch, which I have been happily using for several months, so I'm happy to submit this implementation for review if you're okay with this in principle.
Cheers,
Louis

Hello @lthibault, that sounds like a reasonable proposal. Thanks for writing this up, I wish every feature request came with such a well though out description.
I'm probably something obvious here, but I'm wondering why you're not using a POST request? That should allow you do bidirectional streaming as well, doesn't it? Are you concerned about the H2 framing overhead?
It would be great if you could send us a PR with your implementation. I'm particularly curious how you worked around this gQUIC hack https://github.com/lucas-clemente/quic-go/blob/ad9618ef9e878bbc0f820bd133869dfbb80d0190/h2quic/server.go#L205-L209

Closing due to inactivity.

Reopening, as this would be very useful for MASQUE.

Reopening, as this would be very useful for MASQUE.

The interesting problem to solve here is how to do the same thing on the client. Maybe have the http.Request.Body also implement DataStreamer?

The interesting problem to solve here is how to do the same thing on the client. Maybe have the http.Request.Body also implement DataStreamer?

The interesting problem to solve here is how to do the same thing on the client. Maybe have the http.Request.Body also implement DataStreamer?

Yes, please add this as well. Looking at the code it shouldn't have many changes.


Create Add Recommendation Popup

Thanks for the review @raniarusly - really helpful comments! Just a quick note but I don't think I had requested a review yet. There were still a few commits I was going to add, and then the screenshot. It's not a problem, but just for the future, maybe it's something to be aware of!

Here's a screenshot to help with visualisation:


address more header names that are not canonicalized before use

Because Header Names are canonicalized to lowercase, these were other areas that were broken when the headername implementation changed.

It would be great if we could find a way to ensure header names are always canonicalized moving forwards.  These were not caught during the shift from http::Request to azure_core::Request as part of #833.
For reference, our existing methods for creating HeaderName, which only check when we're creating them from String or Cow, but not when making static versions:
https://github.com/Azure/azure-sdk-for-rust/blob/a2fc3403121f3e03a048469b2fab6c387a6696c5/sdk/core/src/headers/mod.rs#L174-L206


add pelias/mapzen support

Thanks for this PR :)
The code is good. Please make the documentation in readme more clear. Thanks :dancer:

Documentation updated per your instructions.  pelias is not strictly local (definitely not local file based).  It's just a self-hosted version of mapzen's service, so we haven't renamed it with _local

Ah makes sense! and awesome thanks for the documentation update. :D


Add performance testing

@dirkmueller anything in particular that you'd like to check?

I have started a PR with that, for which we have a new tox unit (therefore we have a single isolated test). That tox unit will not fetch the containers in advance, and should build everything in one place. The test timings from pytest (through junit output) is a good start, but if we need more details, we should maybe add a pytest plugin.

Performance tests on openQA are almost impossible to do, because we are always using shared workers with no guarantees at all.

This issue is so old, if it were a kid, it would be in kindergarten right now. I think the scope of this project changed sufficiently to consider it no longer relevant


What is the proguard/dexguard rules ?

Sorry, if duplicated.

how to proguard？

No custom rules required.


WaterOneFlow: GetVariableInfo only Transmits Intergers for timeSupport

kimschreuders[CodePlex] When I queried all variables from this WaterOneFlow web service quothttp://drought.usu.edu/NIDISTimeSeries/cuahsi_1_1.asmx?WSDLquot with quotGetVariableInfoquot,
the variables where the value for time support in the ODM is 0.5, were transmitted on the WaterML as 0. The WaterML file is attached. There are 5 variables at this service for which this is true. Each variable that has a timeSupport of 0.5 in the ODM, has
a variableCode that contains quot-P0.5Mquot.

kimschreuders[CodePlex] Still waiting for a build and testing.

valentinedwv[CodePlex] Fixed in source control
** Closed by valentinedwv 5/3/2011 6:26 PM

valentinedwv[CodePlex] WaterML schema has xsd:float, ODM has float
Somewhere between the two is the issue


Packet: handle automatic authorization of all API-level SSH keys

The Packet API has two knobs which control which SSH keys are authorized on a device: project_ssh_keys and user_ssh_keys. Both of these keys accept a list of IDs which reference public keys which are known to the Packet API.
Lokomotive doesn't use this mechanism at all, but rather specifics a list of strings where each element is the actual text of a public SSH key.
The problem is that when no key IDs are specified in the API call to create a Packet device, Packet authorizes all the known keys in a project. This happens in addition to the keys we provision via Ignition. Passing an empty list here doesn't seem to help.
I suggest we do the following:

Document the existing Packet behavior.
Ask Packet to make it possible to toggle this behavior off.
Add a workaround to Lokomotive (controlled by a knob if necessary) to allow switching this behavior off until a better solution exists.

One possible workaround is to disable the<EMAIL_ADDRESS>service.

Ask Packet to make it possible to toggle this behavior off.

We asked Packet about it some time ago, I poked them again today to see what's the status of it.

One possible workaround is to disable the<EMAIL_ADDRESS>service.

I would say we just implement that, this way we don't have to document anything. IMO adding a note in the changelog for existing cluster would be sufficient.
The reason we ask about SSH keys explicitly is that we don't take Packet integration into consideration, so I don't think we should be documenting it.


Predict next meal start time and duration

Using Facebook Prophet

Tried to fit a model after several hundred meals, but the fit is low (r² = 0.3) and the confidence interval is too wide to be worth it ... for the moment? Closing the feature request for now.

Interesting trends but nothing a human can't anticipate with experience:


Change apply method to always return a boolean value. This makes converti

Change apply method to always return a boolean value. This makes converting attributes with the name name as a action parameter possible.
https://github.com/symfony/symfony/issues/1547#issuecomment-1807290
Before this patch it was not possible to have a /blog/archive/{date} route and a action like myAction(DateTime $date) as the request attribute would already exists and the paramconverter would not be called.
This path is breaking BC for the apply method on ParamConverterInterface which now MUST return a boolean value indicating if a conversion was done.

@fabpot rebased and tests pass :) good to go.


adding a "renderer" framework so assets can render themselves

first, thanks for creating a great tool for managing assets!
one of the things that i found odd about webassets was the fact that when referencing an asset in a template, the template needs to be sensitive to the internals of the assets to be able to reference it correctly. for example, it had to know if it was css or javascript, if the less output was being compiled or not, etc.
this merge request is the beginnings of a solution that allows assets to render themselves using a renderer registry. for example, given the following bundle setup (notice that the bundle contains both css and javascript):
all_assets = Bundle(
  Bundle('style.css', output='app.css', renderer='css'),
  Bundle('script.js', output='app.js', renderer='js'))
env.register('app', all_assets)

knowing that the 'css' and 'js' renderers come baked-in, you can have the following mako template:
    <html>
      <head>
        % for asset in env['app'].renderers():
          ${asset.render()|n}
        % endfor
      </head>
      ...
    </html>

which will generate the following output:
    <html>
      <head>
        <link rel="stylesheet" type="text/css" href="/app.css"/>
        <script type="text/javascript" src="/app.js"></script>
      </head>
      ...
    </html>

to be yslow-optimized, you typically want styles defined at the top, and scripts at the bottom. this is possible with renderer "selection":
    <html>
      <head>
        ## only select renderers that are neither "js" nor "amd"
        % for asset in env['app'].renderers('!js,!amd'):
          ${asset.render()|n}
        % endfor
      </head>
      ...

        ## select renderers that are either "js" or "amd"
        % for asset in env['app'].renderers('js,amd'):
          ${asset.render()|n}
        % endfor

    </html>

asset contents can also be rendered inline via asset.render(inline=True).
existing renderers can be overridden and custom renderers added, eg:
env.register_renderer('meta-url', '<meta name="URL" content="{url}"/>')

the merge request has:

the full implementation for HTML referencing and inlining
unit tests for css and js renderers
documentation for how to use the renderer framework

please let me know if you agree that this would be a nice addition and/or what needs improvement.
thanks!

hi @miracle2k, have you had a chance to think about this? (i need to upgrade various dependencies, and this is a conflict for me because i'm working off the branch)
IMHO, this belongs to webassets core because, well, how often does one use webassets outside of the context of HTML? i'd love to see this merged, but will only do the work of updating the branch to be mergeable if you're going to accept it.


Auto-trigger broken?

Included a non empty .bib file with \bibliography(test) in my .tex document.
When I start to type \cite{ no suggestions will be made. The select view panel won't pop up.
Can you confirm this? How do you debug?
Atom    : 1.11.2
Electron: 1.4.5
Chrome  : 53.0.2785.113
Node    : 6.5.0

@nokianhunter For me, it was caused my choice of the UI theme. Specifically, I was using the Nucleus Dark UI. Changing to a different UI theme fixed the problem.

Thanks for the tip.
I changed UI and syntax theme to Atom Dark but it didn't help
Unfortunately I must have something else configured wrong.
I also tried a fresh Atom configuration with only the latextools package added.
Additionally a second .tex/.bib example didn't work.
Do you have other suggestions?

Could you provide minimal examples of a bibliography and a .tex document where \cite would fail?

I took this example: https://tex.stackexchange.com/questions/225209/bibtex-simple-example
I tried it as it is and in addition like  below:
\documentclass{article}
\usepackage[hyperref=true,
    natbib=true,
    style=authortitle-dw,
    backend=biber]{biblatex}

% jobname.bib is in a extra file in the same directory

\addbibresource{jobname.bib}

\begin{document}
    Hallo world
    \cite{einstein}
    \printbibliography
\end{document}

Thanks for helping me out

@nokianhunter: Is your \addbibresource line actually \addbibresource{\jobname.bib}? We currently don't support completions from files using the \jobname macro, though it's on the list of things to add.

No it's like this "\addbibresource{jobname.bib}"

I didn't know \jobname is a macro. But the line is exactly like this "\addbibresource{jobname.bib}".
Does it work in your configuration?
Any idea how to compare?

@nokianhunter Your example works for me. The only thing I can think of is to look at the Atom console window (it's in the developer tools bit of the section). It also might be helpful to see an example entry from your bib file...

My bib file looks like this:
@artikel{einstein,
  author = {Albert Einstein},
  title = {the true about tree},
  journaltitle = {Annalen der Physik},
  year = {1905},
  volume = {322},
  number = {10},
  pages = {891-921}
}

Dev console output when choosing "Latextools: Ref Cite Complete":
requiring if needed: completion-manager
requiring if needed: snippet-manager
??

Running the command directly is actually not too useful, unfortunately :). It checks to see if it's inside a citation command before doing anything. It'd be better to see the output when actually typing { after the cite command.

@nokianhunter Everything works for me using your sample entry and the sample tex file on 1.12.4.

Thanks for testing and making this example gif.
Looking at your example, I recognized I had no syntax highlighting. Installing language-latex helped.
And finally the auto-trigger worked again!
Afterwards I found this on the project page:

The package does not provide syntax highlighting. Rather, it is supposed to be used in conjunction with the language-latex package: this must be installed for snippets to work.


add retry to build acr image e2e

Description
Adds a retry on acr image build in e2e. This fixes a random error that started appearing yesterday where e2e occasionally says it can't find the acr in the subscription on an acr build.
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Local e2e
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules

/ok-to-test sha=b14624c

/ok-to-test sha=970cdb3

/ok-to-test sha=9ebfb69

/ok-to-test sha=e625e15

/ok-to-test sha=e625e15

/ok-to-test sha=e625e15

/ok-to-test sha=83c74dc

/ok-to-test sha=5ee961a


Check for lower case content-type header

Headers are case insenstive. IIS seems to return content-type and not Content-Type. This I guess could still break if someone did CONTENT-TYPE or ConTeNT-TYPE but lets not get silly.

shakes fist
I'm not sure how to handle this completely case insensitively, but this is definitely a good start.
I'll get this merged when I'm back home sometime early next week


fix(compat): ensure fallthrough *Native events are not dropped during props update (fix #5222)

This PR solves #5222 where a fallthrough event listener from a Vue 2 v-bind.native was removed on a component re-render.
I would need some guidance regarding how to add a test for this.

can't we move it to p1 or p2? 😀
I'm trying to migrate a big project to Vue 3 and this issue is blocking me
Thank you for the PR

@yyx990803 We got to migrate to Vue 3 using this amazing compat mode, however this is the last issue for us to fix before pushing forward to production. The more we wait on it the more conflicts we have which is pretty hard to handle since it's a big codebase, so...
Do you have a lot of native event listeners in your codebase?

yes, I have some .native listeners, not sure how many, but I'll definitely search all places and go with your suggestion, thanks again, and sorry for the coffee joke, it wasn't my intention to "buy" a position in the queue, but to say how important this fix is for me :)

I understand. We are moving a bit slower right now as docs are being polished, amongst other reasons. We will pick up speed soon. :)


Shorter NODE_TAPE_OBJECT_PRINT_DEPTH env variable

A very useful feature for me is NODE_TAPE_OBJECT_PRINT_DEPTH, because I work with a lot of large JSON objects, added in https://github.com/substack/tape/issues/418. and #420. However, it’s a rather long name. I find myself reading the docs, CMD+F for depth, and copy pasting that line a lot because I can’t seem to remember it.
Would it be of interest to add a shorter alias for that flag? Perhaps NODE_TAPE_DEPTH or TAPE_DEPTH or so? I can make the PR.

env vars have a high chance of conflicting, so it’s usually best if they’re long.
While this feedback may have been helpful when it was added, I’m pretty sure it’s not worth the complexity of having two env vars for the same thing - which one wins? What if they’re different? etc.

Yeah, understandable.
And alt idea that solves my use case is to have a different flag that presents more as “expand/inspect all”. I don‘t really care about what number the depth it set to, just that it’s very large.
That still has the problem of how the two different variables work together though.
Say, NODE_TAPE_DEEP, which when set is equivalent to 100 or so. NODE_TAPE_OBJECT_PRINT_DEPTH precedes over it. And opts.objectPrintDepth precedes over that.

The env var is meant as a universal shortcut, that shouldn’t need to be typed often - the thing expected for common use is the depth option on each inspect call.

The normal behavior of tape is great. I want the normal size to be small. Just, sometimes, I need to inspect a deep and complex case. Where I can either dive into the code and add a console.dir(actual, {depth: null})  / {objectPrintDepth: 100}, but using an env variable to just print it all feels cleaner to me.
In any case, my usage seems to be an edge case so I’ll close this.


Distributing js library with pypi package

As I understand it, the py-builtins.js library is an integral part of any javascript compiled with pyjaco. Therefore, this file should be distributed with, or buildable from the python binary distribution shipped via setup.py.
As discussed in http://stackoverflow.com/questions/4519127/setuptools-package-data-folder-location there are essentially two ways to ship data files with setup.py; package_data and data_files. The problem with package_data is that the data file must be distributed inside the pyjaco library. The problem with data_files is that it is impossible to reliably determine the location of the installed file from inside the python code across operating systems and virtualenvs.
I see the following options:

move the library directory to pyjaco/jslib or similar and ship the various ##-*.js files in package_data. Then merge the generate_library.py script into pyjs.py so that the script can generate the complete library for users.
leave library where it is, but when setup.py is run, ensure that pyjaco/jslib exists and generate py-builtins.js into that directory before calling setup. Then ship py-builtins.js as part of package_data.
assume that py-builtins.js has been generated at the time that setup.py is run and include the script in data_files. Then create fragile code that attempts to guess where the file was installed. This fragile code is guaranteed not to work on all possible platforms, buildouts, or virtualenvs.

I am willing to implement either of the first two options. I have a preference for the first option because it means that only files that are included in version control are shipped with the distribution; py-builtins.js is generated from these files instead of being shipped directly. No setup.py hack is required to ensure that the data has been generated. I didn't want to start moving directories around without your blessing, though, so I'll await feedback on this issue before developing anything.

Regarding the first solution, isn't there some way to include library in package_data? I'm not very familiar with the pypi packaging. I'm all for merging generate_library into the pyjs.py file. Especially with an improvement where pyjs.py will check if the newest mtime for a library/*.js file is newer than the py-builtins.py file, and generate it only in that case. That would be very nice :)
For now, let's stick to the name py-builtins.js, but pending discussion on the mailing list, we will probably find another name soon. That shouldn't affect the change here, though.

Yes it's possible to include the library in package_data using the first solution. I'm sorry I worded it the way I did, what I meant is that the library directory has to be moved inside the pyjaco package directory in order for setup.py to pick it up and distribute it. I will do this on another branch to demonstrate. As I mentioned in a recent mailing list message, I'd eventually like to see setup.py as the main source of distribution, with debian (and other OS) packages generated from that.

+1 for debian package using pypi. But do we really have to put javascript files in our python package dir? It seems so very dirty. Can't we at least move the python files one level in, so we have:
root/setup.py
root/src/library/..
root/src/pyjaco/..
or something like that? I'm really against mixing python and javascript into a python package, it seems wrong.

After the discussion on the mailing list, and the merging of your recent patch, I believe this issue is closed. Have I missed anything?


files: use canonical name in nativeBuildInputs

Description
Allow home-manager to be used with allowAliases = false;
rycee/nmd also has aliases so this will only work when manual.manpages.enable = false; is set.
Checklist

[x] Change is backwards compatible.

[ ] Code formatted with ./format.

[x] Code tested through nix-shell --pure tests -A run.all.

[ ] Test cases updated/added. See example.

[x] Commit messages are formatted like
{component}: {description}

{long description}

See CONTRIBUTING for more information and recent commit messages for examples.

If this PR adds a new module

[ ] Added myself as module maintainer. See example.

[ ] Added myself and the module files to .github/CODEOWNERS.

Thanks! Rebased to master in 3b33862b04c8e4ae1b8258376520f3ce1f90a73a.

The nmd issue should also be fixed now.


apply is not a function at Generator.Plugins.forEach

Version
3.7.0
Reproduction link
https://github.com/CodeSpent/CodeSpent.dev
Environment info
Environment Info:

  System:
    OS: Windows 10
    CPU: (4) x64 Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
  Binaries:
    Node: 10.15.3 - C:\Program Files\nodejs\node.EXE
    Yarn: Not Found
    npm: 6.4.1 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: 44.17763.1.0
  npmPackages:
    @fortawesome/vue-fontawesome: ^0.1.6 => 0.1.6
    @sagalbot/vueable: 0.0.3 => 0.0.3
    vue: ^2.5.11 => 2.6.10
    vue-chartjs: ^3.4.2 => 3.4.2
    vue-cli-webpack:  1.0.0
    vue-github-api: ^0.1.7 => 0.1.7
    vue-hot-reload-api:  2.3.3
    vue-loader: ^13.0.5 => 13.7.3
    vue-resource:  1.5.1
    vue-style-loader:  3.1.2
    vue-template-compiler: ^2.4.4 => 2.6.10
    vue-template-es2015-compiler:  1.9.1
    vuetify: ^1.5.14 => 1.5.14
    vuex: ^3.1.1 => 3.1.1
  npmGlobalPackages:
    @vue/cli: Not Found

Steps to reproduce
use vue add router
What is expected?
vue add router
What is actually happening?
? Use history mode for router? (Requires proper server setup for index fallback in production) No
(node:4328) UnhandledPromiseRejectionWarning: TypeError: apply is not a function
    at Generator.plugins.forEach (C:\Users\hanfo\AppData\Roaming\npm\node_modules\@vue\cli\lib\Generator.js:103:7)
    at Array.forEach (<anonymous>)
    at new Generator (C:\Users\hanfo\AppData\Roaming\npm\node_modules\@vue\cli\lib\Generator.js:101:13)
    at Function.runGenerator (C:\Users\hanfo\AppData\Roaming\npm\node_modules\@vue\cli\lib\invoke.js:123:21)
    at process._tickCallback (internal/process/next_tick.js:68:7)
(node:4328) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)(node:4328) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.```

<!-- generated by vue-issues. DO NOT REMOVE -->

This also occurs on my desktop which is a similar environment. Is it a dependency not compatible with Windows possibly?

This error may occur when your node_modules does not contain any actual Vue CLI plugins. Please rerun npm install and try again.
We need to improve the error message, though.

@sodatea Can you close this? Fixed by #4242

😂forgot to put the fix keyword before each issue id.


feat: add support for Livewire v3

@chosww I did a quick look over things and it seemed okay. I'll leave the final review to you though because the auto-merge is enabled.


AVRO-3223: Support optional codecs in C# library

Make sure you have checked all steps below.
Jira

[x] My PR addresses the following Avro Jira issues and references them in the PR title.

Tests

[x] My PR adds the following unit tests OR does not need testing for this extremely good reason: FileTests.TestOptionalCodecs.

Commits

[x] My commits all reference Jira issues in their subject lines. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters (not including Jira issue reference)
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Documentation

[x] In case of new functionality, my PR adds documentation that describes how to use it.

All the public functions and the classes in the PR contain Javadoc that explain what it does

I have just rebased master and fixed a few code quality warnings I had missed. Would be great to get more feedback on this PR and see if we can get this merged. Thanks!

@KyleSchoonover @zcsizmadia Any comments ?

Closed/reopened the PR to trigger the CI checks.

@tgnm What is the advantage using a CodecResolver delagate, instaed of assigning a codec to a name at registration time?
Something like this, instead of RegisterResolver, have a RegisterCodec:
`
private static readonly ConcurrentDictionary<string, Codec> _registeredCodecs = new ConcurrentDictionary<string, Codec>();
public static void RegisterCodec(string codecString, Codec codec)
{
_codecResolvers[codecString] = codec;
}
public static Codec CreateCodecFromString(string codecType)
{
// Check registered codecs
if (TryGetValue(codecType, out Codec codec))
{
return codec;
}
...

}
`

@zcsizmadia I guess the main advantage is that the function call uses a factory approach which allows for flexibility when it comes to the lifetime management of the Codec instance. I like the idea that I can either return a new instance or reused it across calls (depending on whether or not the Codec implementation supports reusing the instance). This is totally transparent to the Avro library.
These approaches are also different when it comes to registrations in that the function approach iterates over all resolvers until the first match is found. The approach you suggested replaces a previous registration.
From a performance point of view, there's not a lot of meaningful differences simply because I don't expect there to be more than one registration in practice... the dictionary approach is a bit less space efficient but this is negligible.
Btw, I don't think using a concurrent data structure is really justified here. I'd expect consumers to first register any resolvers before they actually start using it to encode/decode data. Certainly don't expect this to be something that occurs dynamically at runtime.

I definetely like the idea registering codecs. I would love to have xz, however many of the codecs are not trivial to add to the base Avro library, because of other wierd package dependencies.

Thank you for the contribution, @tgnm !


Install extension for C/C++ automatically V extension VScode is installed

Since Install  V extension VScode depends on C/C++ extension to debug,installing the C/C++ extension automatically when V lang extension is installed will improve the developer experience.

don't think it's a good idea, user shall have options to choose whatever extension they'd like to install along with V

I just described one way in my previous message.

I will not debug with a debugger until the V source code can be debugged directly.

https://github.com/vlang/vscode-vlang/pull/527 slightly helped to address this issue.


Update

Pull request
Describe your changes
Issue ticket number and link
Checklist before requesting a review

[x] I have performed a self-review of my code
[x] If it is a core feature, I have added thorough tests and documentation

Failed tests are safe to ignore imo. The UBI ones fail bc we don't build those bc we don't use them.


Add ComboBox Component

Related Issue or Background Info

Prerequisite to #268 and #1196

Changes Proposed

Adds the ComboBox component from https://github.com/trussworks/react-uswds
Updates some dependencies to match

Additional Information

I spent a bunch of time trying to get the native-JS ComboBox provided by USWDS to work in React, and this route, suggested by @nickscialli-usds, was way more straightforward
TrussWorks uswds-react library is great, and it's Apache 2.0-licensed and as a result is neatly compatible with our CC0 license
I think we should consider, generally, using the TrussWorks uswds-react library as an out of the box dependency instead of maintaining our own USWDS React components. That refactor is outside the scope of the feature need that motivated this PR, but, let's discuss :)

Screenshots / Demos

That refactor is outside the scope of the feature need that motivated this PR, but, let's discuss :)

We don't need to refactor existing components prior to bringing int he trussworks dependency, right? I could be worth having the discussion now (frontend + design) about adding the trussworks dependency and using their components going forward while refactoring old components as the opportunity arises.


Added IP2Location.io API

what is the request limits using the API?

The limit is 500 requests daily for tokenless queries.
@Normalnoise

for every IP per day?

Yes, per caller IP, there is a 500 queries per day limit.

can you extend to 1000 request per day limit?

@Normalnoise At the moment, tokenless API is limit to 500 calls daily. However, token-based API calls have a monthly limit of 30,000.

Hi @Normalnoise, I work for IPinfo, and we genuinely appreciate being part of your project. Just for context:

IPinfo.io provides 1,000 requests per day without a token.
IPinfo provides 50,000 requests per month with a free tier token.
Universal access to a globally distributed load-balancing network regardless of access tier.
Higher accuracy is driven by latency-based IP geolocation methods. (Blog post)
Bulk API endpoint, native request caching through all our official libraries, HTTPS/SSL encryption on all API interaction, and a free IP database that essentially allows infinite offline lookups.

In addition to offering generous no-tier and free-tier access, we also have incredible uptime hours and a community to support our users. I am not sure what value this failover code brings to the project. But please let us know if you have any issues with our services. We are committed to supporting open-source projects and the developer experience surrounding them.
Thank you.

@abdullahdevrel thanks for your support for our project

@ip2location thanks for your explains, I hope we can merge it next version


Docs not showing intro and app sections

When I visit http://koajs.com/ there seems to be a problem on the docs homepage, where the "Introduction" and "Application" sections are blank. The docs start from the "Context" section.
Is this just on my side, or do you also notice the same problem?
Thanks!

yeah i noticed this, but i couldn't figure out what's going on. anyone have any ideas?

Seems somewhat urgent to fix... @tj or @dead-horse any idea?

I can reproduce it locally, just by not running make -j4.
Redeploy the koajs.com and that'll update the docs as well. ;)

👍  thanks @draconteus

Awesome thanks @jonathanong and @draconteus!


Avoid double-free of borrowed Object

resolves https://github.com/LaurentMazare/tch-rs/issues/475

Thanks for the PR, maybe you could add some comments to give some insights on why it's safe to handle tag 14 differently from the others?

@LaurentMazare I was hoping you'd have more context.  I'm not an expert on libtorch internals.
I see that Object holds a pointer which it frees on drop: https://github.com/LaurentMazare/tch-rs/blob/ea61a05ce2190c422e41d208422e3ba60dfad078/src/wrappers/jit.rs#L752 and came to the notion that it may be a double-free issue based how Object is handled here: https://github.com/LaurentMazare/tch-rs/blob/ea61a05ce2190c422e41d208422e3ba60dfad078/src/wrappers/jit.rs#L309
I only tested the case for Object as an argument to CModule.method_is: https://github.com/LaurentMazare/tch-rs/issues/475

https://github.com/LaurentMazare/tch-rs/commit/2d7c2cf868c76aba7ffd18f4d7316716815c4041 looks much nicer, thanks @LaurentMazare!


Increased E2E Testing

Will continue to add e2e tests, but don't need the epic ticket to track anymore.


Missing TemplateName in Connect event payload

When connect sends an event, there is a node inside of EnvelopeStatus node, looking like this:
       <DocumentStatuses>
            <DocumentStatus>
                <ID>1</ID>
                <Name>medical_intake_form.pdf</Name>
                <TemplateName />
                <Sequence>1</Sequence>
            </DocumentStatus>
        </DocumentStatuses>

I'm pretty sure that TemplateName had always come up with a value.
I've tried different templates and different connect configurations - it's all the same, TemplateName is missing.

Hi @tehnetaholic , I haven't had time to test this yet but my understanding is that the <TemplateName /> node will only have a value if the document in question was provided by a DocuSign Template in your account.  For instance, if you send a signature request on a local document that's on the sending device then it would be null, but if you sent a signature request from a server-side template then it should have a value.
Can you confirm that the particular payload that you are examining definitely came from a DocuSign Template and was not provided at real-time?

Hi, @Ergin008
I can confirm that sent envelopes were based on server-side templates. However a few days after I've noticed this issue the TemplateName property began to have value. I guess it must have been some kind of a glitch or a bug.

Ok thanks for the update and apologies for the inconsistent behavior.  Our demo is environment is relatively stable and most bugs get caught before they make it to demo, however occasionally some slip through before they are identified.
Feel free to log a new one issue if you happen to encounter this again and we'll investigate.
Thanks,
-Ergin


[test] Fix test failure on non-x86_64 targets in failed-clang-module test case.

What's in this pull request?
Use %target-cpu instead of x86_64 in lit RUN: script
Use %target-swiftmodule-name instead of x86_64.swiftmodule in lit RUN: script
Fixes:
FAIL: Swift(iphonesimulator-i386) :: Serialization/failed-clang-module.swift (1 of 1)
******************** TEST 'Swift(iphonesimulator-i386) :: Serialization/failed-clang-module.swift' FAILED ********************
...
--
/Users/buildnode/jenkins/workspace/swift-PR-osx/buildbot_incremental/swift-macosx-x86_64/test-iphonesimulator-i386/Serialization/Output/failed-clang-module.swift.tmp/MixModA.framework/Modules/module.modulemap:3:10: error: inferred submodules require a module with an umbrella
  module * { export * }
         ^
/Users/buildnode/jenkins/workspace/swift-PR-osx/buildbot_incremental/swift-macosx-x86_64/test-iphonesimulator-i386/Serialization/Output/failed-clang-module.swift.tmp/MixModA.framework/Modules/module.modulemap:3:10: error: inferred submodules require a module with an umbrella
  module * { export * }
         ^
/Users/buildnode/jenkins/workspace/swift-PR-osx/swift/test/Serialization/Inputs/SwiftModB.swift:1:8: error: could not build Objective-C module 'MixModA'
import MixModA
       ^

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

A smoke test on macOS does the following:

Builds the compiler incrementally.
Builds the standard library only for macOS. Simulator standard libraries and
device standard libraries are not built.
lldb is not built.
The test and validation-test targets are run only for macOS. The optimized
version of these tests are not run.

A smoke test on Linux does the following:

Builds the compiler incrementally.
Builds the standard library incrementally.
lldb is built incrementally.
The swift test and validation-test targets are run. The optimized version of these
tests are not run.
lldb is tested.

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

@swift-ci Please test

%target-cpu.swiftmodule isn't quite right either; armv7 and armv7k are both arm.swiftmodule. Use %target-swiftmodule-name.

@jrose-apple Thank you! I didn't know that.
@swift-ci  Please test

@swift-ci Please test

Linux CI bot substituted %target-swiftmodule-name to unknown.swiftmodule. Investigating

It seems, only if run_vendor == 'apple': path properly set config.target_swiftmodule_name
and, current test cases that uses %target-swiftmodule-name are all XFAIL: linux or UNSUPPORTED.
I'm not sure what should I do.
@jrose-apple, @gribozavr ?

I think marking the test as XFAIL: linux is reasonable for now. We should get the bots back to passing.

Added XFAIL: linux
@swift-ci Please test

I think marking the test as XFAIL: linux is reasonable for now. We should get the bots back to passing.

Agreed, but it would be great to properly set %target-swiftmodule-name on Linux, too.

Oh, certainly. But right now we're replicating the driver logic for every architecture we care about, and doing that for Linux seems problematic.
(The reason the names don't match up, by the way, is because iOS allows armv7 and armv7s modules to coexist and interoperate.)

Thanks @rintaro !


[Regression] JSON conflicts with AWS SDK

New Issue Checklist

[x] Updated fastlane to the latest version
[x] I have read the Contribution Guidelines

Issue Description
When running fastlane, using the S3 uploader action, I get the following error:
/usr/local/Cellar/ruby/2.3.1/lib/ruby/2.3.0/rubygems/specification.rb:2284:in `raise_if_conflicts': Unable to activate aws-sdk-v1-1.66.0, because json-2.0.2 conflicts with json (~> 1.4) (Gem::ConflictError)
from /usr/local/Cellar/ruby/2.3.1/lib/ruby/2.3.0/rubygems/specification.rb:1407:in `activate'
from /usr/local/Cellar/ruby/2.3.1/lib/ruby/2.3.0/rubygems.rb:196:in `rescue in try_activate'
from /usr/local/Cellar/ruby/2.3.1/lib/ruby/2.3.0/rubygems.rb:193:in `try_activate'
from /usr/local/Cellar/ruby/2.3.1/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:125:in `rescue in require'
from /usr/local/Cellar/ruby/2.3.1/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:40:in `require'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane/lib/fastlane/actions/s3.rb:221:in `load_from_v1_gem_name'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane/lib/fastlane/actions/s3.rb:247:in `s3_client'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane/lib/fastlane/actions/s3.rb:70:in `run'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane/lib/fastlane/runner.rb:232:in `block (2 levels) in execute_action'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane/lib/fastlane/actions/actions_helper.rb:50:in `execute_action'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane/lib/fastlane/runner.rb:217:in `block in execute_action'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane/lib/fastlane/runner.rb:213:in `chdir'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane/lib/fastlane/runner.rb:213:in `execute_action'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane/lib/fastlane/runner.rb:135:in `trigger_action_by_name'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane/lib/fastlane/fast_file.rb:146:in `method_missing'
from Fastfile:50:in `block (2 levels) in parsing_binding'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane/lib/fastlane/lane.rb:33:in `call'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane/lib/fastlane/runner.rb:49:in `block in execute'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane/lib/fastlane/runner.rb:45:in `chdir'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane/lib/fastlane/runner.rb:45:in `execute'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane/lib/fastlane/lane_manager.rb:52:in `cruise_lane'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane/lib/fastlane/command_line_handler.rb:30:in `handle'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane/lib/fastlane/commands_generator.rb:96:in `block (2 levels) in run'
from /usr/local/lib/ruby/gems/2.3.0/gems/commander-4.4.3/lib/commander/command.rb:178:in `call'
from /usr/local/lib/ruby/gems/2.3.0/gems/commander-4.4.3/lib/commander/command.rb:153:in `run'
from /usr/local/lib/ruby/gems/2.3.0/gems/commander-4.4.3/lib/commander/runner.rb:446:in `run_active_command'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane_core/lib/fastlane_core/ui/fastlane_runner.rb:38:in `run!'
from /usr/local/lib/ruby/gems/2.3.0/gems/commander-4.4.3/lib/commander/delegates.rb:15:in `run!'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane/lib/fastlane/commands_generator.rb:293:in `run'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane/lib/fastlane/commands_generator.rb:36:in `start'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/fastlane/lib/fastlane/cli_tools_distributor.rb:59:in `take_off'
from /usr/local/lib/ruby/gems/2.3.0/gems/fastlane-2.3.1/bin/fastlane:5:in `<top (required)>'
from /usr/local/bin/fastlane:23:in `load'
from /usr/local/bin/fastlane:23:in `<main>'

Captured Output
Command Used: upload
Output/Log

[18:36:22]: It seems like you wanted to load some plugins, however they couldn't be loaded
[18:36:22]: Please follow the troubleshooting guide: https://github.com/fastlane/fastlane/blob/master/fastlane/docs/PluginsTroubleshooting.md
[18:36:22]: -------------------------------------------------
[18:36:22]: --- Step: Verifying required fastlane version ---
[18:36:22]: -------------------------------------------------
[18:36:22]: Your fastlane version 2.3.1 matches the minimum requirement of 1.111.0  ✅
[18:36:22]: ------------------------------
[18:36:22]: --- Step: default_platform ---
[18:36:22]: ------------------------------
[18:36:22]: Driving the lane 'ios upload' 🚀
#########[18:36:22]: ----------------
[18:36:22]: --- Step: s3 ---
[18:36:22]: ----------------
+------------------+------------+
|         Lane Context          |
+------------------+------------+
| DEFAULT_PLATFORM | ios        |
| PLATFORM_NAME    | ios        |
| LANE_NAME        | ios upload |
+------------------+------------+

+------+-------------------------------------+-------------+
|                     fastlane summary                     |
+------+-------------------------------------+-------------+
| Step | Action                              | Time (in s) |
+------+-------------------------------------+-------------+
| 1    | Verifying required fastlane version | 0           |
| 2    | default_platform                    | 0           |
| 3    | s3                                  | 0           |
+------+-------------------------------------+-------------+

[18:36:22]: fastlane finished with errors

✅ fastlane environment ✅
Stack

Key
Value

OS
10.12

Ruby
2.3.1

Bundler?
false

Git
git version 2.9.0

Installation Source
/usr/local/bin/fastlane

Host
Mac OS X 10.12 (16A323)

Ruby Lib Dir
/usr/local/Cellar/ruby/2.3.1/lib

OpenSSL Version
OpenSSL 1.0.2g  1 Mar 2016

Is contained
false

Xcode Path
/Applications/Xcode.app/Contents/Developer/

Xcode Version
8.2.1

System Locale

Variable
Value

LANG
en_GB.UTF-8
✅

LC_ALL

LANGUAGE

fastlane files:
`./fastlane/Fastfile`
# Customise this file, documentation can be found here:
# https://github.com/fastlane/fastlane/tree/master/fastlane/docs
# All available actions: https://github.com/fastlane/fastlane/blob/master/fastlane/docs/Actions.md
# can also be listed using the `fastlane actions` command

# Change the syntax highlighting to Ruby
# All lines starting with a # are ignored when running `fastlane`

# If you want to automatically update fastlane if a new version is available:
# update_fastlane

# This is the minimum version number required.
# Update this, if you use features of a newer version
fastlane_version "1.111.0"

default_platform :ios

platform :ios do
  before_all do
    # ENV["SLACK_URL"] = "https://hooks.slack.com/services/..."
  end

  desc "Runs all the tests"
  lane :test do
    scan
  end

  desc "Submit a new Beta Build to Apple TestFlight"
  desc "This will also make sure the profile is up to date"
  lane :beta do
    # match(type: "appstore") # more information: https://codesigning.guide
    gym # Build your app - more options available
    pilot

    # sh "your_script.sh"
    # You can also use other beta testing services here (run `fastlane actions`)
  end

  desc "Build and deploy an ad-hoc version of the app"
  lane :release do
    increment_build_number
    cert
    sigh(adhoc: true)
    gym
  end

  desc "Upload the latest ad-hoc build to the S3 bucket"
  lane :upload do
    print ENV['S3_ACCESS_KEY']
    s3(
      access_key: ENV['S3_ACCESS_KEY'],               # Required from user.
      secret_access_key: ENV['S3_SECRET_ACCESS_KEY'], # Required from user.
      bucket: <redacted>,                            # Required from user.
      ipa: <redacted>,
      dsym: <redacted>,
      path: <redacted>,
      upload_metadata: true,                          # Upload version.json, plist and HTML. Set to false to skip uploading of these files.
    )
  end

  desc "Grabs a new cert & provisioning profile"
  lane :dev do
    # 1
    cert(development: true)
    # 2
    sigh(development: true)
  end

  after_all do |lane|
    # This block is called, only if the executed lane was successful

    # slack(
    #   message: "Successfully deployed new App Update."
    # )
  end

  error do |lane, exception|
    # slack(
    #   message: exception.message,
    #   success: false
    # )
  end
end

# More information about multiple platforms in fastlane: https://github.com/fastlane/fastlane/blob/master/fastlane/docs/Platforms.md
# All available actions: https://github.com/fastlane/fastlane/blob/master/fastlane/docs/Actions.md

# fastlane reports which actions are used
# No personal data is recorded. Learn more at https://github.com/fastlane/enhancer

fastlane gems

Gem
Version
Update-Status

fastlane
2.3.1
✅ Up-To-Date

Loaded fastlane plugins:
No plugins Loaded
Loaded gems

Gem
Version

did_you_mean
1.0.0

slack-notifier
1.5.1

CFPropertyList
2.3.4

claide
1.0.1

colored
1.2

nanaimo
0.2.3

xcodeproj
1.4.2

rouge
1.11.1

xcpretty
0.2.4

terminal-notifier
1.7.1

unicode-display_width
1.1.2

terminal-table
1.7.3

plist
3.2.0

public_suffix
2.0.4

addressable
2.5.0

multipart-post
2.0.0

word_wrap
1.0.0

babosa
1.0.2

highline
1.7.8

commander
4.4.3

excon
0.54.0

faraday
0.10.0

unf_ext
<IP_ADDRESS>

unf
0.1.4

domain_name
0.5.20161129

http-cookie
1.0.3

faraday-cookie_jar
0.0.6

fastimage
2.0.1

gh_inspector
1.0.2

uber
0.0.15

representable
2.3.0

retriable
2.1.0

mime-types-data
3.2016.0521

mime-types
3.1

hurley
0.2

little-plugger
1.1.4

multi_json
1.12.1

logging
2.1.0

jwt
1.5.6

memoist
0.15.0

os
0.9.6

signet
0.7.3

googleauth
0.5.1

httpclient
2.8.3

google-api-client
0.9.20

json
2.0.2

mini_magick
4.5.1

multi_xml
0.6.0

rubyzip
1.2.0

security
0.1.3

xcpretty-travis-formatter
0.0.4

dotenv
2.1.1

bundler
1.13.7

faraday_middleware
0.10.1

io-console
0.4.5

generated on: 2016-12-30

We have the same problem: in order to use S3 upload action, our code uses aws-sdk-v1-1.66.0 instead of newer one. 3 days ago, it began to raise the conflict with json gem installed in the system.

Same here, with fastlane-2.3.1, which depends on json-2.x which is apparently not liked by aws-sdk-v1...

Hey everyone, we just pushed fastlane 2.4.0 which fixes the bundled fastlane, just run fastlane update_fastlane to get the latest release 🚀
However this release breaks support for Ruby 2.4.0 for now, which we should be able to add again soon. For now, please downgrade to an older version of Ruby, or use the bundled fastlane from download.fastlane.tools
Please let us know if that works for you 👍

@KrauseFx to the rescue 2.4.0 fixed my issue.
If you:

use ruby 2.3.x
use aws-sdk-v1-1.66.0

if you have nokogiri issues this post helped http://www.nokogiri.org/tutorials/installing_nokogiri.html#mac_os_x (which I found here https://github.com/sparklemotion/nokogiri/issues/1483)

@KrauseFx Yes, it works fine now. Thank you

Thanks everyone 👍

Thank you Felix, 2.4.0 worked, however I had to uninstall json-2.0.2 before running the update:
sudo gem uninstall json -v2.0.2
sudo fastlane update_fastlane

@pipacs This worked for me. Thanks!


Android Basics: Fragments Navigation component

URL of codelab
https://developer.android.com/codelabs/basic-android-kotlin-training-fragments-navigation-component?continue=https%3A%2F%2Fdeveloper.android.com%2Fcourses%2Fpathways%2Fandroid-basics-kotlin-unit-3-pathway-2%23codelab-https%3A%2F%2Fdeveloper.android.com%2Fcodelabs%2Fbasic-android-kotlin-training-fragments-navigation-component#0
In which task and step of the codelab can this issue be found?

Before you begin

Describe the problem
Just a small typo to the word 'Fragment', there's a missing 't'
[...]"below, both the navigation UI on the left and the content on the right can each be contained in a separate fragmen."
Steps to reproduce?

Go to the provided Codelab URL
in the third paragraph of the Before you begin section
typo in the word fragment as stated in the Describe the problem of this report

Thanks for filing! This has now been fixed


Update Mesa-geo visualisation based on updated SolaraViz API

Since the SolaraViz API was updated, the Mesa-geo API also needs to be updated to match it. See:

https://github.com/projectmesa/mesa/pull/2447

Thanks for noticing this! Do you mean renaming make_geospace_leaflet to make_geospace_component to be consistent with Mesa? Anything else that I'm missing?

Implemented in https://github.com/projectmesa/mesa-geo/pull/270. Closing.


Recipe build fails on OSX.

Currently, the recipe does not build on OSX. It will need some adjustments to make this work.
@adamerose you'll probably need https://github.com/conda-forge/pyqt-feedstock/blob/master/recipe/xcrun and https://github.com/conda-forge/pyqt-feedstock/blob/master/recipe/xcodebuild on macOS.
Originally posted by @ocefpaf in https://github.com/conda-forge/staged-recipes/issues/13237#issuecomment-768466908

@ocefpaf Do you know of any feedstock that uses xcrun and xcodebuild to get X11 running on OSX? Then, we could probably check out how this is implemented there. Currently, I have no idea how to fix the OSX build.

@ocefpaf Do we simply have to include xcrun and xcodebuild from the pyqt-feedstock into our recipe folder or is there anything else needed?

I don't recall all the details but we need to include those and probably call the test with xcrun or something. We need to check the pyqt recipe that does this.

I opened a draft PR here: https://github.com/conda-forge/pandasgui-feedstock/pull/7 (still fails)
In the pyqt recipe , they simply run the test call for Linux only:
https://github.com/conda-forge/pyqt-feedstock/blob/ac7967ad076bc2feba691e5c76419c40fe56d58a/recipe/meta.yaml#L131
We run it for [not win]:
https://github.com/conda-forge/pandasgui-feedstock/blob/90c8480cc99adc93be0aa9cebcfba67bd140e159/recipe/meta.yaml#L38

We may need to ask for @mingwandroid's help here. I believe he created that. I'm almost certain the package would work but it is a bit hard to test that in the CIs.

Well, it would be nice to get a CI test running for OSX. I don´t have a Mac here to test it locally.


cache after first load

pwa is kind of hard to test locally so doing this PR so I get a deploy I can test
working on #238 mostly

I didn't manage to get updates to work, too much stuff was breaking when I tried to update. or it would just show the new content without requiring the update. BUT. I did manage to get caching actually working so loads should be a lot faster now after install / first load

closes #238

Refreshing the preview seems much faster

Without manual updates, how would forcing an update work? Can you configure cache time or something?

this the autoUpdate behavior from vite-pwa: https://vite-pwa-org.netlify.app/guide/auto-update.html#automatic-reload
on further reading this might not be good because eventually we will want prompt and they warn upgrading from autoUpdate to prompt might be hard:

changing this to draft while I try to figure out how to actually do prompt correctly

my plan right now is to move away from solid-start and just use solid-js which can give us a single bundle so we can do atomic upgrades


Integrate Travis CI as Streamline's CI

As a part of #923, this issue tracks the work for integrating Travis CI as Streamline's CI.

PR: #929